2013-02-28 196 views
3

deploy:setup的正確方法是什麼,並與Capistrano進行冷配置?如何設置服務器進行部署並使用Capistrano進行冷部署?

使用

  • this deploy.rb
  • Capistrano的v2.14.2
  • 流浪虛擬化我的服務器,

這是我的情景:

  1. 運行時,Capistrano的利用的根特權準備的目錄結構進行部署:還

    $ 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. deploy:cold Capistrano的嘗試檢出(從GIT中在這種情況下)和寫爲vagrant用戶 - 在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 [email protected]: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 [email protected]: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 [email protected]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. 當然,deploy:check報告剝開沒有驚喜:vagrant用戶不能在deploy:setup創建的目錄寫,因爲這兩個用戶都屬於二fferent羣體 - root:rootvagrant: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) 
    

這背後的理由,什麼前提是尚未滿足這樣的部署通過這個問題?

+0

並且您不想手動更改權限? – gmaliar 2013-02-28 20:35:13

+1

我已經有了完全相同的問題......我不明白爲什麼這些目錄是作爲root用戶而不是作爲'deploy.rb'文件中指定的用戶創建的。我假設這是一個錯誤?我最終只是通過SSH進入並手動更改權限。 – aardvarkk 2013-02-28 21:37:23

回答

1

deploy:setup任務可能不應該使用sudo來創建應用程序目錄,因爲這很可能導致它被歸屬爲root

你可以把它們關掉你的deploy.rb文件有:

set :use_sudo, false 
+0

謝謝。它的工作原理,比我的解決方案更加優雅。 – 2013-03-05 00:13:20

0

既然有no group setting in Capistrano我的解決方法是延長這樣的設置,例如:

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

,然後創建一個任務在運行後「修復」所有權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 

但唯一比解決問題更好的方法並不在於首先,所以Stuart's answer既明智也更優雅。

相關問題