スケーリングを管理するために、ロードバランサーと自動スケーリンググループを使用してWebアプリケーションをセットアップしています。ソースコードはgitリポジトリにあるため、コードが変更されたときにイメージを更新する必要はありませんが、環境が変更される場合があるため、新しいイメージを作成します。次に、その画像を自動スケーリンググループに循環させる必要があります。
画像を自動的に循環させる方法はありますか?今、私は古いインスタンスを取り除くスケールアップとスケールダウンのアクションをスケジュールします。
これを行うには、「AWS-HA-Release」を提案したいと思います-AWS-HA-Releaseの仕組み:
この場合、ダウンタイムなしで新しいコードまたは新しいAMIバージョンを出荷でき、完全に新しいインスタンスの利点があります。 AWS-HA-Releaseツールは https://github.com/colinbjohnson/aws-missing-tools で入手できます。
より簡単な方法は、Auto-Scalingグループ(ASG)の最小インスタンス数を現在の数の2倍に増やし、それらがすべて開始されるまで待ってから、インスタンスの最小数をそれまでの最小数に変更することです。 ELBは古いインスタンスを強制終了し、新しいインスタンスをコードに残します。そのためには、ターミネーションポリシーを「OldestInstance」に設定して、意図したとおりに機能させる必要があります。デフォルトの終了ポリシーには、望ましくない副作用がある場合があります。
AWS CLIのパラメーターと例については、こちらをご覧ください。 http://docs.aws.Amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html
このシナリオを管理する方法は、クラウド形成でAWS :: AutoScaling :: AutoScalingGroupオブジェクトのUpdatePolicy機能を使用することです。クラウド形成スタックが更新されると、インスタンスの循環を管理します。
いくつかの参照。 http://docs.aws.Amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.htmlhttp://docs.aws.Amazon.com/ AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html
また、オープンソースとなった Netflix Asgard ツールもご覧ください。 Auto Scalingグループを設定できるだけでなく、インスタンスのグループに対して新しいAMIイメージのローリングリリースを実行することもできます。
正直に言うと本当に良い方法はありません。私が見つけた最良の方法は、ASG名にバージョンを入れることです。 AMIを更新するたびに、新しいバージョンで新しいASG + Launch Configを作成し、他のグループと競合しないようにします。次に、古いグループのすべてのインスタンスを終了します。
よりフォールトトレラントな展開が必要な場合は、新しいロードバランサーの作成も含めて、別の手順を追加することをお勧めします。これにより、両方のASGを互いに分離することができます。また、「ステージング」エリアを使用して、更新前に最後に変更をテストできます。次に、切り替える準備ができたら、DNSレコードを更新し、古いグループのすべてのインスタンスを終了します。
私が投稿した here (Terraformと同様の質問)は、cloudformationを使用する場合を除いて、ASGに組み込まれていません。私もそれに苦労したので、複数のASGを監視し、その状態と更新を確認する「ローラー」を作成することになりました。フィードバックをお寄せください。 http://github.com/deitch/aws-asg-roller