13

ELB (ロードバランサー) の背後にある EC2 サーバーインスタンスのグループに新しいコミットをプッシュする良い方法を見つけようとしています。各インスタンスは Nginx と PHP-FPM を実行しています

次のワークフローを実行したいのですが、ロード バランサーの背後にあるすべてのインスタンスに新しいバージョンをプッシュする良い方法がわかりません。

  • 開発はローカル マシンで行われます
  • 変更の準備ができたら、「git push origin master」を実行して、変更を BitBucket (すべての git リポジトリをホストする場所) にプッシュします。
  • bitbucket にプッシュされた後、新しいバージョンをすべての EC2 インスタンスに同時にプッシュしたいと考えています。
  • 各インスタンスに SSH 接続する必要なくこれを実行したいと思います (明らかに)。

リモート プッシュを受け入れるようにリモート サーバーを構成する方法はありますか? これを行うより良い方法はありますか？

4

6 に答える 6

10

はい、私は常にこれを行っています (実際には、同じアプリケーション スタックを使用しています)。

  1. デフォルトの「Amazon Linux」など、信頼できるソースからのベース AMI を使用するか、独自の AMI を作成します。

  2. 起動構成の一部として、「ユーザー データ」フィールドを使用して、起動時にプロビジョニング プロセスをブートストラップします。yum install nginx php-fpm -yこれは、シェル スクリプトを実行して S3 バケットからファイルをコピーしたり、リポジトリからプルしたりするのと同じくらい簡単です。Amazon が作成した AMI には、もう少し柔軟性が必要な場合のcloud-initスクリプトのサポートも含まれています。さらに強力な機能が必要な場合は、Puppet、Chef、またはSalt (私のお気に入り) などの変更管理およびオーケストレーション ツールを使用できます。

  3. 既存のインスタンスのコードを更新する限り、次の 2 つの考え方があります。

    • クラウドを最大限に活用して、起動時に新しいコードを取得するまったく新しいインスタンスのフリートをスピンアップするだけです。次に、ロード バランサーを反転して、新しいフリートを指すようにします。これは瞬時に実行でき、何か問題が発生した場合に古いフリートにすばやく戻すことができます。数時間 (または数日) 後、古いインスタンスをスピンダウンします。
    • FabricやCapistranoなどのツールを使用して、すべてのインスタンスに一度に並列 "プッシュ" デプロイを実行できます。これは通常、サーバーが起動時に実行したのと同じスクリプトを再実行するだけです。Salt and Puppet の MCollective も、基本的な「プル」プロビジョニングと連携する同様の機能を提供します。
于 2012-12-14T21:10:08.600 に答える
2

このジョブのツールは Capistrano です。

capistrano のロールを EC2 セキュリティ グループにマッピングするために、capistrano-ec2groupという素晴らしい gem を使用します。

これは、カピストラーノが何をインスタンスにデプロイするかを知るために、EC2 セキュリティ グループ (例: app-web または app-db) をインスタンスに適用するだけでよいことを意味します。

これは、アプリでサーバー IP のリストを維持する必要がないことを意味します。

ワークフローへの変更は、bitbucket へのプッシュ時にデプロイを自動化することに集中するのではなく、プッシュしてから実行することです。

cap deploy

本当にやりたくない場合は、エイリアスを作成してください:D

alias shipit=git push origin master && cap deploy
于 2013-03-05T01:01:30.583 に答える
2

このソリューションは、E_p のアイデアに基づいています。E_p は、問題は、各サーバーに新しい更新をプルするように指示するために、どこかにサーバー リストを維持する必要があることだと言います。私だったら、ec2 でタグを使用して、サーバーのグループを識別しやすくします (たとえば、「Role=WebServer」など)。そうすれば、ec2 コマンド ライン インターフェースを使用してインスタンスを一覧表示し、それぞれに対してプル コマンドを実行できます。

for i in \
    `ec2din --filter "tag-value=WebServer" --region us-east-1 \
    | grep "running" \
    | cut -f17`\
; do ssh $i "cd /var/www/html && git pull origin"; done

注: タグ付けされたすべてのインスタンスの IP アドレスを取得し、ssh 経由でそれらに接続するコードをテストしましたが、特定のgit pullコマンドはテストしませんでした。

これを実行したい場所に amazon cli ツールをインストールし、更新しようとしているサーバー用に ssh キーをインストールする必要があります。bitbucket の機能が何であるかはわかりませんが、このコードはそこで実行できないと思います。E_p が示唆するように実行して、更新を別の管理インスタンスにプッシュし、このコードをコミット後のフックに含めるか、または私が行ったように行うことができる頭痛の種を保存して、インストールする必要があります。 CLI ツールをローカル マシンにインストールし、更新を展開するときに手動で実行します。

ec2din出力から IP アドレスを簡単に抽出し、結果を繰り返し処理できる別の質問への回答については、AdamK に感謝します: How can I kill all my EC2 instances from the command line?

EC2 CLI ツールリファレンス: http://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/Welcome.html

于 2014-01-10T05:37:50.153 に答える
2

オプション 1

  1. 1 台のマシンにプッシュします。
  2. http://git-scm.com/book/en/Customizing-Git-Git-Hooksに git フックを作成します。
  3. 他のマシンでフック ラン プルを実行します。

唯一の問題は、更新を実行するマシンのリストを維持する必要があることです。

別のオプション

bitbucket アカウントからプルする cron ジョブがあります。定期的に。

于 2012-12-13T21:43:33.143 に答える
1

あなたの最善の策は、展開に実際に AMI を使用することです。

個人的には、通常、リポジトリの変更をプルできるステージング インスタンスがあります。意図したとおりに動作していることを確認したら、そのインスタンスから AMI を作成します。

デプロイには、ロード バランサーの背後にある自動スケーリング グループを使用します (動的にスケーリングする必要はありません)。自動スケーリング グループ内のサーバーの数が固定されている単純なセットアップ (たとえば、10 インスタンス)。自動スケール グループに関連付けられている AMI を新しい AMI に変更し、自動スケール グループで一度にいくつかのインスタンスの終了を開始します。たとえば、10 個のインスタンスがあり、2 個を終了して 8 個のインスタンスに減らしたとします。自動スケール グループは最小 10 個のインスタンスを持つように構成されているため、新しい AMI で 2 つの新しいインスタンスが自動的に起動されます。その後、フリートのパフォーマンスに影響を与えないように、負荷のレベルに適した速度でインスタンスを削除し続けることができます。

自動スケーリング グループがなくても、ELB からインスタンスを直接追加/削除することで、これを手動で行うことができます。

これを完全に自動化する (つまり、継続的なデプロイ) ことを検討している場合は、Jenkins などのビルド システムの使用を検討することをお勧めします。これにより、コミットがビルドを開始し、必要な AWS コマンドを実行して作成することができます。 AMI を作成してデプロイします。

于 2012-12-14T16:52:11.223 に答える
0

同じ問題の解決策を探しています。この投稿に出くわし、興味深いアプローチだと思いました

https://gist.github.com/Nilpo/8ed5e44be00d6cf21f22#pc

「複数のサーバーへの変更のプッシュ」に進みます

基本的には、「プロダクション」などと呼ぶ別のリモートを作成し、そのリモートに複数の URL (すべてのサーバーの IP) を追加するという考え方です。これは、編集によって行うことができます.git/config

次に、実行するgit push production <branch>と、「プロダクション」の下にリストされているすべての URL にプッシュされます。

このアプローチの要件の 1 つは、サーバー上のリポジトリが裸のリポジトリである必要がありpost-receive、作業ツリーを更新するためのフックが必要になることです。

これを行う方法の例を次に示します:ベア リポジトリのポスト受信フックの設定

于 2018-12-13T18:51:25.133 に答える