私たちはここで仕事中のプロジェクトに Symfony 2 を採用し始めています。これは素晴らしいことですが、私が解決しようとしている課題があります。
symfony は、環境の概念を単一サーバー上の個別のランタイムとして扱います。これは、さまざまなフロント コントローラー (web) を使用してランタイムを切り替えたり、env スイッチ (cli) を気まぐれに使用したりできるため、優れています。
ただし、コードは開発プロセスの一環として多くのサーバーにデプロイされます。誰もがローカル VM を持っており、コードは統合、QA、ステージング、そして最後に本番環境に伝播します。
したがって、環境の概念はサーバー (仮想または物理) です。このカスタム構成の目標は次のとおりです
- ランタイム環境の切り替えに関して Symfony の ootb 機能を維持する
- サーバーごとにパブリック (つまり、開発者が制御する) 構成を許可する
- サーバーごとにプライベート (つまり、sysad 制御) 構成を維持する
- Web と CLI の両方で動作します
これは、開発者が各サーバーの構成を制御する必要があり、これらすべてのファイルが git で隣り合って存在するため、parameters.iniまたは静的に名前が付けられたファイルに 100% 依存することはできないことを意味します。
だから、私がやりたいのはこれです。サーバー環境を設定する parameters.ini に新しい値を追加します。このようなもの
app/config/parameters.ini
[parameters]
server="int"
次に、カーネルで、その値に基づいて追加の構成ファイルを読み込みます。たとえば、これが機能することを望んでいますが、機能しません (このステップではコンテナーがまだ存在しないため)。
アプリ/AppKernel.php
public function registerContainerConfiguration(LoaderInterface $loader)
{
$loader->load(__DIR__.'/config/config_'.$this->getEnvironment().'.yml');
// Per-server config
$server = $this->getContainer()->getParameter( 'server' );
if ( $server )
{
$loader->load(__DIR__.'/config/server/'.$server.'.yml');
}
}
これにより、app/config/server/int.ymlのようなファイルを使用して、開発者が非プライベート (つまり、parameters.ini ではない) 構成値を制御できるようになります。
読んでくれてありがとう。何かわかりにくいことがあれば教えてください。
編集
明確にするために、私が使用できない、または信頼できないもの
- * ユーザーのプロファイルからの、または 経由の nix 環境変数
export
。なんで?統合、QA、およびステージングはすべて同じボックスにある可能性があります - 仮想ホスト構成のすべて (cli では機能しません)
- 静的に名前が付けられたファイル (つまり、単にserver.iniという名前のファイルは機能しません)