1

どうやら、Web アプリケーションの展開には 2 つの戦略が使用されているようです。間違っている場合は修正してください。

プル展開

独自のビルド、デプロイ スクリプトがあります。私はgitをvcsとして使用しています。デプロイ スクリプトは git リポジトリからコードをプルし、ビルド スクリプトはアプリを構成します。

長所

  • 簡単インストール。
  • スケーラビリティの向上 (私の ssh キーはサーバーにあるため、vcs サーバーに接続できます)。そのため、アプリケーション サーバーが大きくなっても、気にする必要はありません。

短所

  • すべてのアプリケーション サーバーでの ssh キーとしてのセキュリティの問題。

プッシュ展開

この方法は、rsync を使用してコードをプッシュする古いプロジェクトで使用していました。ローカル マシンからコピーをプッシュしましたが、まだ vcs を使用していました。

長所

  • コードを vcs にプッシュする必要がないため、完全な制御と柔軟性があります。

短所

  • より良いスケーラビリティではありません。

両方の戦略を提供するいくつかのツールを確認しました。( http://capifony.org/ )

質問

  • 大規模なプロジェクトでこれをどのように処理しますか? （phpで構築）。
  • より良い戦略はありますか？
  • この2つの中でどちらが優れていますか？
  • ロード バランサーの下に多数のアプリケーション サーバーがある場合はどうなりますか? ここでプッシュは意味がありますか？

前もって感謝します。

4

1 に答える 1

2

コードを vcs にプッシュする必要がないため、完全な制御と柔軟性

これは私にとって良いことではありません。VCS を使用すると、使用しない場合よりも詳細に制御できます。私は通常、開発および機能ブランチと一緒に運用ブランチを作成します。これにより、運用サーバーは、私が意図的に運用ブランチに配置したコードのみをプルダウンします。

さらに、製品コードが突然壊れるという問題に遭遇した場合、VCS を使用している場合は、コードの問題点を突き止めながら、動作中のバージョンにロールバックできるはずです。これは、私にとって、プル デプロイを使用することの最も有益な側面の 1 つです。

Jenkins のような継続的インテグレーション ツールを使用すると、VCS の特定のブランチの変更を定期的にチェックし、Jenkins にプロジェクトを自動的にプルしてビルドさせることができます。誰も本番サーバーにログインする必要はありません。これにより、リポジトリ内のコードを更新するのと同じくらい簡単に展開できます。

すべてのアプリケーション サーバーでの ssh キーとしてのセキュリティの問題

コードがホストされている場所によっては、デプロイ専用キーを設定できる場合があります。これが Bitbucket のセットアップ方法であるため、本番サーバーはコードをプルするだけで、プッシュすることはできません。さらに、これらのサーバーの 1 つが危険にさらされた場合、その特定のキーへのリポジトリへのアクセスを簡単に取り消すことができます。

于 2013-02-20T05:34:07.573 に答える