Chef Deployment with irrelevant default symlinks

Question

I am trying to deploy my application code with Chef, which is working for one node and failing on another. I cannot determine why it works for one node and not another when they have the exact same config, but I can at least try to debug the problem on the node that fails.

  deploy_revision app_config['deploy_dir'] do
    scm_provider Chef::Provider::Git 
    repo app_config['deploy_repo']
    revision app_config['deploy_branch']
    if secrets["deploy_key"]
      git_ssh_wrapper "#{app_config['deploy_dir']}/git-ssh-wrapper" # For private Git repos 
    end
    enable_submodules true
    shallow_clone false
    symlink_before_migrate({}) # Symlinks to add before running db migrations
    purge_before_symlink [] # Directories to delete before adding symlinks
    create_dirs_before_symlink [] # Directories to create before adding symlinks
    # symlinks()
    action :deploy
    restart_command do
      service "apache2" do action :restart; end
    end
  end

This is my recipe for deploying the code. Notice that I have tried disabling symlinking entirely, as Chef always jams its own defaults in. Even with this I get the error:

================================================================================
Error executing action `deploy` on resource 'deploy_revision[/var/www]'
================================================================================


Chef::Exceptions::FileNotFound
------------------------------
Cannot symlink /var/www/shared/config/database.yml to /var/www/releases/7404041cf8859a35de90ae72091bea1628391075/config/database.yml before migrate: No such file or directory - /var/www/shared/config/database.yml or /var/www/releases/7404041cf8859a35de90ae72091bea1628391075/config/database.yml

Resource Declaration:
---------------------
# In /var/chef/cache/cookbooks/kapture/recipes/api.rb

 68: 
 69:   deploy_revision app_config['deploy_dir'] do
 70:     scm_provider Chef::Provider::Git 
 71:     repo app_config['deploy_repo']
 72:     revision app_config['deploy_branch']
 73:     if secrets["deploy_key"]
 74:       git_ssh_wrapper "#{app_config['deploy_dir']}/git-ssh-wrapper" # For private Git repos 
 75:     end
 76:     enable_submodules true

Compiled Resource:
------------------
# Declared in /var/chef/cache/cookbooks/kapture/recipes/api.rb:69:in `from_file'

deploy_revision("/var/www") do
  destination "/var/www/shared/cached-copy"
  symlink_before_migrate {"config/database.yml"=>"config/database.yml"}
  updated_by_last_action true
  restart_command #<Proc:0x00007f40f366e5a0@/var/chef/cache/cookbooks/kapture/recipes/api.rb:82>
  repository_cache "cached-copy"
  retries 0
  keep_releases 5
  create_dirs_before_symlink ["tmp", "public", "config"]
  updated true
  provider Chef::Provider::Deploy::Revision
  enable_submodules true
  deploy_to "/var/www"
  current_path "/var/www/current"
  recipe_name "api"
  revision "HEAD"
  scm_provider Chef::Provider::Git
  purge_before_symlink ["log", "tmp/pids", "public/system"]
  git_ssh_wrapper "/var/www/git-ssh-wrapper"
  remote "origin"
  shared_path "/var/www/shared"
  cookbook_name "kapture"
  symlinks {"log"=>"log", "system"=>"public/system", "pids"=>"tmp/pids"}
  action [:deploy]
  repo "[email protected]:kapture/api.git"
  retry_delay 2
end

[2012-09-24T15:42:07+00:00] ERROR: Running exception handlers
[2012-09-24T15:42:07+00:00] FATAL: Saving node information to /var/chef/cache/failed-run-data.json
[2012-09-24T15:42:07+00:00] ERROR: Exception handlers complete
[2012-09-24T15:42:07+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2012-09-24T15:42:07+00:00] FATAL: Chef::Exceptions::FileNotFound: deploy_revision[/var/www] (kapture::api line 69) had an error: Chef::Exceptions::FileNotFound: Cannot symlink /var/www/shared/config/database.yml to /var/www/releases/7404041cf8859a35de90ae72091bea1628391075/config/database.yml before migrate: No such file or directory - /var/www/shared/config/database.yml or /var/www/releases/7404041cf8859a35de90ae72091bea1628391075/config/database.yml

Here you can see it mention database.yml, tmp/, system/ and pids folders, all of which are defaults that Chef likes to set (see related bug)

Question 1

What are these symlinks for and how do I know if I even need any. What sort of things am I symlinking? I will be using migrations, so if they are useful for the migration then I'll need them working.

I have read the documentation many times and it just doesn't explain this is plain English - at least not that I have found.

Question 2

If I do not require them, how can I disable symlinking entirely? Following the examples in that bug report have not helped.

Answer 1

Clear out all the symlink attributes.

deploy_revision("/var/www") do
  # ...
  symlink_before_migrate.clear
  create_dirs_before_symlink.clear
  purge_before_symlink.clear
  symlinks.clear
end

Answer 2

Make sure the deployment directory in shared has the proper directory structure (/var/www/shared/[log,pids,system,config]) and that all config files necessary for your application are in the config directory.

Your recipe for your application's cookbook should have an array of directory names to create (recursively) so that you won't run into this error again.

The symlinks are there so that while your application code will continue to evolve, you can share the log, pids, and system folder by symlinking shared/log to current/log and so on and so forth..

Answer 3

Chef happens to cache the directory structure - somehow, I haven't dug into that - with this troll application cookbook. It's something in the deploy resource I believe - I never use that - but you can fix it by deleting the directory structure it creates in /var/derp or whatever. Also ensure your tmp directory is setup.

A couple reasons this may be an issue:

• File permissions are incorrect
• The currently running chef user cannot access the file
• You are using the application cookbook in a configuration for rails deploys and your application does not have the same directory structure.

It's definitely caused by Chef caching the state of the deploy somewhere, then reading that state out of it's cache - wherever that is - and then reusing that. I would look at either the application cookbook to see for any persistance, and if you fail at finding it there, look in the deploy resource from chef itself.