3

これは少しニッチな問題かもしれませんが、誰かが助けてくれることを願っています。これは、昨日本番環境にいくつかの変更をプッシュしようとするまでは常に正常に機能していましたが、それ以降、最後の3つのデプロイメントはすべて一時的にライブサイトを破壊しました。ログからの例外の1つは次のとおりです。

[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は良い考えですか？

4

1 に答える 1

1

umask更新で述べたように、私はオプションを選択することになりました。それはコンソールが原因の問題だと思ったのですが、コメントを外したのumask(1000);はapp/console-notweb/app.phpまたはweb/app_dev.php。この変更を行ってから行ったいくつかの展開では問題は発生していないので、うまくいったと思います。

于 2012-12-20T14:52:38.820 に答える