Capifony и владельцы каталогов

Когда я cap deploy запускаю свой проект Symfony2, а затем захожу на свой сервер, я вижу, что версия dev (app_dev.php) работает нормально, а рабочая версия (app.php) — нет.

Ошибка

[Tue Jan 03 14:31:48 2012] [error] [client xxx.xxx.xxx.xxx] PHP Fatal error:  Uncaught exception 'RuntimeException' with message 'Failed to write cache file "/var/www/example/prod/releases/20120103202539/app/cache/prod/classes.php".' in /var/www/example/prod/releases/20120103202539/app/bootstrap.php.cache:1079\nStack trace:\n#0 /var/www/example/prod/releases/20120103202539/app/bootstrap.php.cache(1017): Symfony\\Component\\ClassLoader\\ClassCollectionLoader::writeCacheFile('/var/www/example/p...', '<?php  ????name...')\n#1 /var/www/example/prod/releases/20120103202539/app/bootstrap.php.cache(682): Symfony\\Component\\ClassLoader\\ClassCollectionLoader::load(Array, '/var/www/example/p...', 'classes', false, false, '.php')\n#2 /var/www/example/prod/releases/20120103202539/web/app.php(10): Symfony\\Component\\HttpKernel\\Kernel->loadClassCache()\n#3 {main}\n  thrown in /var/www/example/prod/releases/20120103202539/app/bootstrap.php.cache on line 1079

Глядя на недавно развернутый каталог кеша, я вижу:

drwxrwxrwx 4 root     root     4096 Jan  3 14:28 .
drwxrwxr-x 5 root     root     4096 Jan  3 14:28 ..
drwxr-xr-x 6 www-data www-data 4096 Jan  3 14:28 dev
drwxrwxr-x 7 root     root     4096 Jan  3 14:28 prod

Я могу решить проблему с chown -R www-data.www-data prod/, но мне интересно, могу ли я вообще предотвратить это? И почему у каталогов разные владельцы?


deployment symfony capistrano capifony
person ed209    schedule 03.01.2012    source источник

Ответы (4)


arrow_upward
10
arrow_downward

Это происходит потому, что ваш веб-сервер запущен пользователем, который не может писать в только что созданный каталог cache/prod.

Есть два решения, которые я знаю и использую. Во-первых, добавьте дополнительные команды для запуска после развертывания в Capfile. Capfile понравится:

load 'deploy' if respond_to?(:namespace) # cap2 differentiator
Dir['vendor/bundles/*/*/recipes/*.rb'].each { |bundle| load(bundle) }
load Gem.find_files('symfony2.rb').last.to_s

after "deploy:finalize_update" do
  run "sudo chown -R www-data:www-data #{latest_release}/#{cache_path}"
  run "sudo chown -R www-data:www-data #{latest_release}/#{log_path}"
  run "sudo chmod -R 777 #{latest_release}/#{cache_path}"
end

load 'app/config/deploy'

Второе решение более элегантно. Вы указываете правильный user, который может писать cache в deploy.rb и убедитесь, что вы не используете sudo:

set :user, "anton"
set :use_sudo, false
person Anton Babenko    schedule 05.01.2012
comment
спасибо, звучит как то, что мне нужно. Чего я не понимаю, так это почему директория dev принадлежит www-data. Capifony работает от имени пользователя root на сервере, поэтому я предполагаю, что php пытается создать файлы кеша (а не пользователя root)? - person ed209; 05.01.2012
comment
cache/dev каталог создается php, работающим с версией CLI, которая отличается от пользователя, работающего на веб-сервере. cache/prod работает так, как если бы он запускался веб-сервером. Вот это я понимаю :) - person Anton Babenko; 05.01.2012
comment
Я понимаю, что вы имеете в виду, хотя, глядя на владельцев каталогов, я бы сказал, что все наоборот: /prod принадлежит root, а /dev принадлежит www-data? - person ed209; 06.01.2012

arrow_upward
7
arrow_downward

В последней версии capifony добавлена ​​возможность устанавливать каталоги, доступные для записи. Вот официальная статья, которая объясняет то, что я написал ниже: http://capifony.org/cookbook/set-permissions.html

Вы должны развернуть с помощью sudo (не очень хорошая практика, но она выполняет свою работу)

set   :use_sudo,      false
# To prompt the sudo password
default_run_options[:pty] = true

и скажите capifony, какие файлы сделать кешем и папкой журналов доступными для записи:

set :writable_dirs,     ["app/cache", "app/logs"]
set :webserver_user,    "www-data"
set :permission_method, :acl

(вы должны установить acl на свой компьютер или использовать :chwon вместо :acl)

EDIT: я только что понял, что этого недостаточно, задача "set_permissions" не вызывается автоматически, поэтому вам нужно явно запустить

cap deploy:set_permissions

Или добавьте эту строку в свой файл deploy.rb:

before "deploy:restart", "deploy:set_permissions"
person Julien    schedule 17.09.2012
comment
Вы также можете добавить набор :use_set_permissions, true в свой файл deploy.rb вместо before "deploy:restart", "deploy:set_permissions". - person Pierre; 10.12.2014

arrow_upward
5
arrow_downward

Я решил эту проблему, добавив папку кеша в общие папки.

set :shared_children,     [app_path + "/cache", app_path + "/logs", web_path + "/uploads", "vendor"]

Таким образом, каталог не создается заново каждый раз во время развертывания, поэтому нет проблем с разрешениями.

person Dziamid    schedule 26.02.2012
comment
У вас могут возникнуть проблемы при откате. Убедитесь, что вы также очистили кеш при возвращении роли. Ох, когда вы пытаетесь очистить кеш, вы снова сталкиваетесь с той же проблемой, у вас нет разрешения на удаление файлов, созданных сервером. - person David Lin; 31.10.2013

arrow_upward
1
arrow_downward

Да, не нужно пересоздавать кеш каждый раз после деплоя, это решение логичное и прагматичное.

Второе решение от Антона - работает, если вы кешируете разрешение на папку true в среде разработки.

person Vladislav Lezhnev    schedule 14.07.2012