0

EC2 インスタンスの 1 つから AMI を作成したとします。これを手動で LB に追加するか、AutoScaling グループに任せることができます (提供した条件に基づいて)。この時点までは、すべて問題ありません。

ここで、開発者が新しい機能を追加し、私が既存のインスタンスに新しいコードをプルしたとします。この時点では AMI は更新されておらず、古いコードが残っていることに注意してください。私の質問は、自動スケーリング グループが私の AMI から新しいインスタンスを作成するときに最新のコードを使用できるように、この状況をどのように処理する必要があるかということです。

2つの方法が頭に浮かびます。他に解決策があれば教えてください。

a) AMI を常に最新の状態に保つ。つまり、プルリクエストがあるたびに、古い AMI を削除 (削除) し、新しいものに置き換える必要があります。

b) 初期起動時にリポジトリから最新のコードを取得する起動スクリプト (cloud-init) を AMI に用意します。(リポジトリ資格情報をインスタンスに保存し、コードを git から直接プルすることにより)

これらの方法のうち、どちらが優れていますか? 両方が良くない場合、この目標を達成するためのベストプラクティスは何ですか?

4

2 に答える 2

1

APIを使用してAWSを使用して（ほとんど）何でも自動化できるとします。それは再び目前の特定のユースケースに分類されます。

最初に、必要なパッケージがインストールおよび構成されたベース AMI を用意し、ソース コードをダウンロードする init スクリプトを常に最新のものにすることをお勧めします。ここでカウントする必要がある非常に重要な要素は、コードをチェックアウトまたはプルして、インスタンスを構成し、すぐに使用できるようにするのにかかる時間です。その期間が非常に長い場合、自動スケーリングにその戦略を使用することはお勧めできません。ウォームアップ時間と自動スケーリングおよびクラウド ウォッチの統計を組み合わせると、異なる現実が生じるため [可能性があります/そうでない可能性がありますが、確率はゼロではありません]。これは、新しい AMI を頻繁にベイクすることを検討する場合です。これにより、インスタンスがトラフィックとの戦いに備えるためにかかる時間を最小限に抑えることができます。

どれが便利で費用対効果が高いかを測定して確認することをお勧めします. インスタンスをプルダウンして AMI を使用して再起動するには、実際の費用がかかります。ただし、それはあなたが行う必要があるトレードオフです。

その間、私はほとんど自由に答えました。だって。質問も少ないです。

構成管理を行うChef、Ansible、Puppetが利用され始めています。これらのツールは、まったく異なるレベルの自動化を追加します。そのオプションも検討したいと考えています。同様のアプローチは、Docker またはその他のコンテナーを使用することです。

于 2016-04-04T22:25:16.467 に答える
1

a) AMI を常に最新の状態に保つ。つまり、プルリクエストがあるたびに、古い AMI を削除 (削除) し、新しいものに置き換える必要があります。

ソースコードを AMI に保存しないでください。これにより、メンテナンスの悪夢と、あなたが特定した自動スケーリングの問題が発生します。

b) 初期起動時にリポジトリから最新のコードを取得する起動スクリプト (cloud-init) を AMI に用意します。(リポジトリ資格情報をインスタンスに保存し、コードを git から直接プルすることにより)

これらの方法のうち、どちらが優れていますか? 両方が良くない場合、この目標を達成するためのベストプラクティスは何ですか?

サーバーの起動時にソースをダウンロードする 2 番目の項目は、これを行う正しい方法です。

その他のオプションとして、Amazon CodeDeploy またはその他のデプロイ サービスを使用して更新をデプロイする方法があります。展開サービスを使用して、既存のインスタンスに更新を展開し、新しいインスタンスが起動時に最新のコードを自動的にダウンロードできるようにすることもできます。

于 2016-04-04T22:34:44.193 に答える