AWSでAutoScalingを使用してロードバランサーの背後で複数のインスタンスを実行しています。
さて、これらのインスタンスと、自動スケーリングポリシーのために起動する可能性のある新しいインスタンスにコードの変更をプッシュする必要がある場合、これを行うための最良の方法は何ですか？
私が知っている唯一の方法は、最新のコードで新しいAMIを作成し、この新しいAMIを使用するように自動スケーリングポリシーを変更してから、既存のインスタンスを終了することです。ただし、これにはダウンタイムが長くなる可能性があり、プロセス全体を自動化できるかどうかはわかりません。
この方向へのポインタは高く評価されます。
コードの変更を行う方法は、コードを編集するマスター サーバーを用意することです。すべてのファイルを最新の状態にするために、cron ジョブによって ssh を介してスケールし、rsync するすべてのスレーブ サーバー。すべてのサーバーは 30 分ごとに同期します +- まったく同じ秒にアクセスしないようにランダムな数秒。(ユーザーが常に同じコードを送信されるように、マスターをロード バランサーから外したままにしていることに注意してください。同様に、コードの変更を公開することにした場合は、テスト サーバーからマスター サーバーに rsync を実行します。
このアプローチを使用すると、起動時に sync コマンドを入力するだけでよく、起動後にスレーブ イメージが最新になるため、スレーブ イメージのコード状態を気にする必要はありません。
編集: 現在、この方法の使用を停止し、まさにこの目的のために作成された新しいサービス AWS CodeDeploy の使用を開始しました。
http://aws.amazon.com/codedeploy/
お役に立てれば。
「クリーンな」既製の AMI を使用するように起動設定を構成します - これらを使用します: http://aws.amazon.com/amazon-linux-ami/
これらの AMI の機能の 1 つは CloudInit です - https://help.ubuntu.com/community/CloudInit
この機能により、新しく生成されたプレーン バニラ EC2 インスタンスにデータを配信できます。具体的には、インスタンスに実行するスクリプトを与えます。
このスクリプトは (簡単に言えば) 次のことを行います。
事前構成された AMI から起動するよりも時間がかかりますが、ソフトウェアを更新するたびに (週に数回) これらの AMI を実際に作成するプロセスをスキップし、サーバーは常に「クリーン」です。手動パッチはありません。すべてのソフトウェアモジュールは最新です。
ここで、ソフトウェアをアップグレードするために、ローカルの boto スクリプトを使用します。このスクリプトは、古いコードを実行しているサーバーを 1 つずつ強制終了します。Auto Scaling メカニズムは、新しい (およびアップグレードされた) サーバーを起動します。
を使用すると、ヘルスチェックに失敗するまで、ELB がシャットダウン中のインスタンスにトラフィックを送信し続けるas-terminate-instance-in-auto-scaling-groupため、必ず使用してください。ec2-terminate-instance
興味深い関連ブログ投稿: http://blog.codento.com/2012/02/hello-ec2-part-1-bootstrapping-instances-with-cloud-init-git-and-puppet/
Auto Scaling グループのサイズを手動で 2 倍にできるようです。これにより、現在の起動構成から AMI を使用して EC2 インスタンスが作成されます。Auto Scaling グループを以前のサイズに戻すと、古いインスタンスは強制終了され、新しい AMI から作成されたインスタンスのみが残ります。