4

簡単な部分...

通常、ZF1 アプリケーションを組み込みの自動読み込みからコンポーザー ベースの自動読み込み (CloudControls Pinkyスタックにデプロイする場合に強くお勧めします) に移行する場合、いくつかの簡単な手順を実行するだけで済みます。

composer.json ファイルを作成し、Zend Framework (バージョン 1.12 からの最新リリースなど) を必要とします。

{
    "require" : {
        "zendframework/zendframework1" : "1.12.*"
    }
}

次のコマンドを使用して、CLI 経由で composer 依存関係をインストールします。

composer install

.gitignore ファイルを更新して以下を追加します。

vendor/*

ライブラリ パスから現在の ZF フォルダーを再帰的に削除します (例: ./library)。

rm -r library/Zend

以下を追加して、クラスを使用するindex.php 前にcomposer autoloader を組み込みます。Zend_

$loader = include 'vendor/autoload.php';

廃止された ZF 関連のrequireorrequire_onceステートメントをすべて削除します。index.phpたとえば、これはもう必要ありません。

require_once 'Zend/Application.php';

上記の変更が完了したら、通常どおりコミットして git 経由でプッシュし、CLI 経由で CloudControl に新しいバージョンをデプロイします (ここでAPP_NAME、DEP_NAMEアプリとデプロイの名前を参照してください)。

cctrlapp APP_NAME/DEP_NAME deploy

cctrlappcomposer の依存関係の解決に関する情報が出力され、最終的に新しいバージョンのデプロイが開始されることに気付くでしょう。完了したかどうかを確認するには、次を実行できます。

cctrlapp APP_NAME/DEP_NAME log deploy

OK、デプロイ ログは問題ないようです。いいですね。ブラウザを開きましょう。

なんてこった！内部サーバーエラー？どうして？？すべてがローカル LA(M)P スタックでうまく機能しました!!!

4

1 に答える 1

5

トリッキーな部分...

幸いなことに、CloudControl を使用すると、エラー ログにもアクセスできます...

cctrlapp APP_NAME/DEP_NAME log error

ここで何が問題なのかを見つけるのはそれほど難しくありません。

しかし...えっと...

8/1/14 5:23 AM  error [error] [client ] FastCGI: incomplete headers (0 bytes) received from server "/app/php/box/php-fpm"
8/1/14 5:23 AM  error [error] [client ] (104)Connection reset by peer: FastCGI: comm with server "/app/php/box/php-fpm" aborted: read failed

上記のエラー メッセージはまったく役に立たないため、まずこのバグを追跡する必要があります。そして、これは確かにトリッキーです！少しググってみましょう。何かを試すことができます。その後、再デプロイできます。もう少しググってみましょう。別のことを試すことができます。その後、再度再デプロイできます。別の機会にグーグルできます。他のすべてを試すことができます。できます...でも、したいですか？

幸いなことに、Pinkyスタックは、物事を高速化する別の方法を提供します ( Luigiがすべてではありません)。面倒な手動デバッグが組み込まれていますが、少なくとも時間を節約できます。CLI に移動して次を実行します。

cctrlapp APP_NAME/DEP_NAME run bash

CloudControl は新しいコンテナをインスタンス化し、SSH ベースのシェル アクセスを提供します。ドキュメントに記載されているように、すべてが展開ボックス内にある必要があります。

cloudControl プラットフォームの分散型の性質は、実際のサーバーに SSH 接続できないことを意味します。代わりに、新しいコンテナを起動して SSH 経由で接続できる run コマンドを提供しています。

コンテナーは Web コンテナーまたはワーカー コンテナーと同じですが、Procfile コマンドの 1 つの代わりに SSH デーモンを開始します。これは同じスタック イメージとデプロイ イメージに基づいており、アドオンの資格情報も提供します。

(コンテナー内から) 詳細を確認できるかどうかを見てみましょう。

cd code/public
php index.php

うーん...ここでは何も報告されていません...そして...ログには何も報告されていませんか?! なんてこったい？！！

したがって、Web コンテナーと実行コンテナーには違いがあるようです。index.phpこれを見つけるために、私はすぐに編集することから始めました：

vi index.php

そしてしばらくして、ついに少なくとも別のエラーを再現するようになりました:

8/1/14 8:55 AM  error [error] [client ] FastCGI: server "/app/php/box/php-fpm" stderr: PHP message: PHP Fatal error:  require_once(): Failed opening required '' (include_path='/srv/www/code/vendor/zendframework/zendframework1/library:/srv/www/code/library:.:/usr/share/php') in /srv/www/code/vendor/zendframework/zendframework1/library/Zend/ ...
8/1/14 8:55 AM  error [error] [client ] FastCGI: server "/app/php/box/php-fpm" stderr: PHP message: PHP Warning: require_once(/srv/www/code/vendor/zendframework/zendframework1/library): failed to open stream: No such file or directory in /srv/www/code/vendor/zendframework/zendframework1/library/Zend/ ...

一部のファイルが欠落しているようです – おそらく自動読み込みに関連しています – 修正するのはそれほど難しくありません。

しかし、待ってください、それは何ですか: Failed opening required ''? 確かに、あなたは愚かなコードを何も必要としません!!

まあ...それぞれのZFライブラリファイルを見ると、そこには何も問題はありません。インクルード パスも正しいようです。ファイルは存在します。composer は両方を正しく管理しました。

PHPのバグです！

より正確に言うと、Pinky の現在のバージョンのPHP 5.4.30 / APC 3.1.13 に影響する PECL APC のバグです。以下を参照してください。

https://bugs.php.net/bug.php?id=62398

php.iniオプションが Web コンテナーの場合は(オフ) にapc.stat設定され、実行コンテナーの場合は (オン) に設定されているため、これがまさに実行と Web コンテナーの違いです。01

tl;dr

GitHub から CloudControl Pinky PHP ビルドパックを複製します。

git clone https://github.com/cloudControl/buildpack-php.git

このリポジトリからすべてのファイルをコピーし、次のプロジェクト ルート フォルダーに追加します。

.buildpack/php

編集.buildpack/php/conf/php.iniして設定:

apc.stat = 1

コミット、プッシュ、デプロイして楽しんでください!

ノート：

このような環境 (デプロイ時にスタックが再作成される) では APC 統計を有効にする必要がなく、実行が遅くなるため、これは単なる回避策であることに注意してください。PHP ドキュメントを参照してください。

スクリプト ファイルがめったに変更されない運用サーバーでは、統計を無効にすることでパフォーマンスを大幅に向上させることができます。

ありがとう：

最後に、一般的なアドバイスをくれた CloudControl の Dimitris と Mateusz に感謝したいと思います。さらに、スタック オーバーフローの @BullfrogBlues と @Thierry_Marianne に感謝したいと思います。彼らは、昨年 11 月にさかのぼる別の質問者のスレッドに答えようとしてくれました。

于 2014-08-05T04:19:54.720 に答える