Comment configurer un serveur pour le déploiement et faire un déploiement à froid avec Capistrano?

Question

Quelle est la bonne façon de deploy:setup et de faire un déploiement à froid avec Capistrano?

En utilisant

• this deploy.rb
• Capistrano v2.14.2
• Vagrant virtualiser mon serveur,

ceci est mon scénario:

1. lors de l'exécution deploy:setup, Capistrano utilise des privilèges root pour préparer la structure de répertoire pour le déploiement:

   $ cap deploy:setup 
       * 2013-02-28 14:50:21 executing `deploy:setup' 
       * executing "sudo -p 'sudo password: ' mkdir -p /home/vagrant/example /home/vagrant/example/releases /home/vagrant/example/shared /home/vagrant/example/shared/system /home/vagrant/example/shared/log /home/vagrant/example/shared/pids" 
       servers: ["example.com"] 
       [example.com] executing command 
       command finished in 29ms 
       * executing "sudo -p 'sudo password: ' chmod g+w /home/vagrant/example /home/vagrant/example/releases /home/vagrant/example/shared /home/vagrant/example/shared/system /home/vagrant/example/shared/log /home/vagrant/example/shared/pids" 
       servers: ["example.com"] 
       [example.com] executing command 
       command finished in 11ms 
   

2. encore sur deploy:cold Capistrano tente de la caisse (de git dans ce cas) et écrire que l'utilisateur vagrant - l'utilisateur spécifié dans deploy.rb :

   $ cap deploy:cold 
       * 2013-02-28 14:50:47 executing `deploy:cold' 
       * 2013-02-28 14:50:47 executing `deploy:update' 
   ** transaction: start 
       * 2013-02-28 14:50:47 executing `deploy:update_code' 
       updating the cached checkout on all servers 
       executing locally: "git ls-remote git@github.com:mariusbutuc/realtime-faye.git master" 
       command finished in 2360ms 
       * executing "if [ -d /home/vagrant/example/shared/cached-copy ]; then cd /home/vagrant/example/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard a7c05516bc31c2c18f89057c02f84bfad83a6b59 && git clean -q -d -x -f; else git clone -q git@github.com:mariusbutuc/realtime-faye.git /home/vagrant/example/shared/cached-copy && cd /home/vagrant/example/shared/cached-copy && git checkout -q -b deploy a7c05516bc31c2c18f89057c02f84bfad83a6b59; fi" 
       servers: ["example.com"] 
       [example.com] executing command 
   ** [example.com :: out] fatal: could not create work tree dir '/home/vagrant/example/shared/cached-copy'.: Permission denied 
       command finished in 26ms 
   *** [deploy:update_code] rolling back 
       * executing "rm -rf /home/vagrant/example/releases/20130228195049; true" 
       servers: ["example.com"] 
       [example.com] executing command 
       command finished in 7ms 
   failed: "sh -c 'if [ -d /home/vagrant/example/shared/cached-copy ]; then cd /home/vagrant/example/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard a7c05516bc31c2c18f89057c02f84bfad83a6b59 && git clean -q -d -x -f; else git clone -q git@github.com:mariusbutuc/realtime-faye.git /home/vagrant/example/shared/cached-copy && cd /home/vagrant/example/shared/cached-copy && git checkout -q -b deploy a7c05516bc31c2c18f89057c02f84bfad83a6b59; fi'" on example.com 
   

3. Bien sûr, le rapport deploy:check pas de surprises bares: l'utilisateur vagrant ne peut pas écrire dans les répertoires créés lors de deploy:setup puisque les deux utilisateurs appartiennent à di groupes fférents - root:root par rapport vagrant:vagrant:

   $ cap deploy:check 
       [...] 
   The following dependencies failed. Please check them and try again: 
   --> You do not have permissions to write to `/home/vagrant/example'. (example.com) 
   --> You do not have permissions to write to `/home/vagrant/example/releases'. (example.com) 
   --> `/home/vagrant/example/shared' is not writable (example.com) 
   

Quel est le raisonnement derrière cela, et quelle condition ne se contente pas encore si le déploiement passe cette question?

Answer 1

La tâche deploy:setup ne devrait probablement pas utiliser sudo pour créer le répertoire de l'application, car il est probable qu'elle soit la propriété de root.

Vous pouvez désactiver cette fonctionnalité dans votre fichier deploy.rb avec:

set :use_sudo, false 

Answer 2

Comme il y a no group setting in Capistrano ma solution de contournement est d'étendre un tel cadre, par exemple:

set :user, 'vagrant' 
set :group, 'vagrant' 

puis créer une tâche pour "réparer" la propriété après l'exécution deploy:setup:

after "deploy:setup", :setup_ownership 
task :setup_ownership do 
    run "#{sudo} chown -R #{user}:#{group} #{deploy_to} && chmod -R g+s #{deploy_to}" 
end 

Mais la seule chose mieux que de résoudre un problème est de ne pas l'avoir en premier lieu, alors Stuart's answer est à la fois plus sage et plus élégant.