12

CentOS 6 で Capistrano を使用して PHP デプロイメントをセットアップしていて、興味深い問題に遭遇しました。カピストラーノの仕組みでは、次のようなフォルダーを設定します。

  • /var/www/myapp.com/
    • current (/releases 内の最新リリースへのシンボリック リンク)
    • 共有
    • リリース
      • 20130826172737
      • 20130826172114

「現在の」シンボリックリンクを見ると、最新のリリースを指しています。最初に、Web アプリを開くと、すべてが正常に機能しました。新しいリリースをデプロイした後、現在のフォルダーは新しいリリースを正しく指していますが、Web アプリケーションは古いリリース (Capistrano のクリーンアップ プロセスで削除された) からファイルをロードしようとします。また、仮想ホストは/var/www/myapp.com/current/Publicを指すように構成されています。

シンボリックリンクは何らかの方法でキャッシュされていますか?

(フレームワークを初期化する) 失敗する特定の PHP コードは次のとおりです。

require_once dirname(dirname(__FILE__)) . '/App/App.php';
App\App::run();

これは、現在/var/www/app.com/current/Public/index.phpにあるindex.phpにあります。

私のApacheエラーログには次のように表示されます：

PHP 致命的なエラー: require_once(): 必要な '/var/www/myapp.com/releases/20130826172237/App/App.php' を開くことができませんでした (include_path='.:/usr/share/pear:/usr/share/php ') /var/www/myapp.com/releases/20130826172237/Public/index.php 内

そして、現在のシンボリックリンクは次を示しています：

現在 -> /var/www/zverse/releases/20130826172641

明らかに 20130826172641 != 20130826172237 後者は以前のバージョンでした。

私が見ることができるアイデアや分野はありますか？

4

2 に答える 2

4

これを確認することはできませんが、シンボリックリンクの古い場所をたどる/キャッシュするApacheに予測できない動作があるようです:

この問題を完全に解決する唯一の方法は、Apache を循環させることでした。これは、すべての展開で行うことは避けたいと考えています。-- マイク・ブリテン

彼は、シンボリックリンクを更新する代わりに、ディレクトリ全体を移動することを提案しています。

于 2013-10-28T08:40:54.633 に答える