0

それで、本番環境と同じvagrantボックスで開発するPHPアプリを開発するとしましょう。したがって、最終的には、コードを含む *.tar.zip ファイルが作成されます...

多くのアプリケーション サーバーがある実稼働環境への展開をどのように編成しますか? つまり、コードを同期的に一度に本番環境にプッシュする方法がわかりませんか?

詳しくは：

サーバーコードでは、次のように保存されます。

project
  +current_revision ->link to revisions/v[n]
  +revisions
    +v1
    +v2
    +v3
    ...
  +data

したがって、変更をデプロイする必要があるときは、通常、更新されたtarをsshでサーバーにアップロードし、リビジョンの下の特定のディレクトリに解凍し、それをcurrent_revisionにシンボリックリンクして、php-fpmを再起動するデプロイスクリプトを実行します....このようにして、いつでもロールバックできます古いリビジョンへのシンボリックリンク。

複数のサーバーで気になるのは、すべてのボックスが一度に更新されるわけではないことです。技術的には、いくつかの不具合が発生する可能性があります。

4

2 に答える 2

2

「すぐに使える」回答を探している場合は、セットアップに関する詳細情報を提供する必要があります。たとえば、VCS に git を使用する場合はrsync、サーバーで最新のコミットと s を取得する単純なシェル スクリプトを作成できます。または、Symfony の上に構築している場合、capifonyは優れたツールです。AWS を使用している場合は、非常に使いやすい Vagrant の作成者によって作成されたプロバイダー プラグインがあり、使用するマシンの正規表現を指定できupますprovision。

代わりに、より多くの「ロードマップ」を探している場合は、次の考慮事項を検討してください。

  1. リモート環境とローカル環境で同一のボックスをできるだけ簡単に構築できるようにし、プロビジョニングで冪等性が強調されるようにしてください。
  2. バージョン管理/リリース構造を検討してください。ほとんどまたはまったく変更されないリソースは? それらをsetup関数ではなく関数に含めdeploy、同期の実行には含めないでください。
  3. 開発とシステム管理の問題を分離します。つまり、vagrant ボックスを *.tar.gz でパッケージ化して、.tar.gz で結び付けないでconfig.vm.box_urlください。この理由は、サーバー上のファイルを変更したり、サーバーからいくつかのパッケージを追加/削除したりするのではなく、展開するたびにすべての運用サーバーを新しいボックスで再パッケージ化する必要があるためです。
  4. ChefやPuppetなどの構成管理ツールを確認してください。それらを使用しなくても、システム管理の専門家がこの問題にどのように取り組んでいるかを知ることができます。
于 2013-04-05T23:54:28.220 に答える