Развертывание моего приложения Symfony2 с Capifony начало ломать кеш живого релиза

Это может быть немного нишевой проблемой, но я надеюсь, что кто-то может помочь. Это всегда работало нормально до вчерашнего дня, когда я пытался внести некоторые изменения в производство, но с тех пор последние 3 развертывания временно нарушили работу сайта. Вот одно из исключений из логов:

[2012-12-18 12:12:16] request.CRITICAL: Exception thrown when handling an exception (InvalidArgumentException: The directory "/path/to/app/releases/20121217134758/app/cache/prod/jms_diextra/metadata" is not writable.) [] []
[2012-12-18 12:12:18] request.CRITICAL: InvalidArgumentException: The directory "/path/to/app/releases/20121217134758/app/cache/prod/jms_diextra/metadata" is not writable. (uncaught exception) at /path/to/app/releases/20121217134758/vendor/jms/metadata/src/Metadata/Cache/FileCache.php line 17 [] []

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

--> Updating code base with remote_cache strategy
--> Creating cache directory...........................✔
--> Creating symlinks for shared directories...........✔
--> Creating symlinks for shared files.................✔
--> Normalizing asset timestamps.......................✔
Do you want to copy last release vendor dir then do composer install ?: (y/N)
y
--> Copying vendors from previous release..............✔
--> Downloading Composer...............................✔
--> Updating Composer dependencies..................... BREAK HAPPENS HERE OR SOON BEFORE

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

# in deploy.rb

set :shared_files,      ["app/config/parameters.yml"]
set :shared_children, [app_path + "/logs", web_path + "/uploads", web_path + "/videos", app_path + "/spool"]

К счастью, я был готов к этому после первого раза, и у меня была консоль ssh с готовым к запуску sudo chmod -R 0777 app/cache/ app/logs/, но это не совсем постоянное решение.

ПРИМЕЧАНИЕ. В настоящее время я обрабатываю права доступа к каталогам кеша/журнала как настраиваемый хук после развертывания:

# in deploy.rb

after "deploy:finalize_update" do
  # Ensure htaccess points to app.php and not app_dev.php
  run "sed -i 's/app_dev/app/' #{latest_release}/#{web_path}/.htaccess"

  # Use a unique APC prefix to guarantee there are no clashes
  run "sed -i 's/_VERSION/_#{release_name}/' #{latest_release}/#{web_path}/app.php"

  # Set permissions of all 'writable_dirs' using sudo
  pretty_print "--> Setting permissions"
  dirs = []
  writable_dirs.each do |link|
    if shared_children && shared_children.include?(link)
      absolute_link = shared_path + "/" + link
    else
      absolute_link = latest_release + "/" + link
    end
    dirs << absolute_link
  end
  sudo sprintf("chmod -R 0777 %s", dirs.join(' '))
end

Обновлять

Во время моего последнего развертывания я заметил, что исключения начали возникать позже, поэтому это не имеет ничего общего с зависимостями. Я подозреваю, что причина этого может заключаться в том, что выполняется cron, который вызывает консоль текущей версии, а затем, очевидно, влияет на кеш. Это имело бы смысл, поскольку я только недавно запустил cron.

Но я не уверен, как это решить. Глядя на раздел Настройка разрешений в документации, кажется, что может быть несколько вариантов. Я ничего не знаю о setfacl, поэтому боюсь что-нибудь сломать. Будет ли использование опции umask хорошей идеей?


person RobMasters    schedule 18.12.2012    source источник


Ответы (1)


В итоге я выбрал вариант umask, как я упоминал в обновлении. Хотя, как я понял, это была проблема, вызванная консолью, я раскомментировал только строку umask(1000); в app/console, а не web/app.php или web/app_dev.php. Проблема не возникала для нескольких развертываний, которые я сделал после внесения этого изменения, поэтому я думаю, что это помогло.

person RobMasters    schedule 20.12.2012