0

私のawsセットアップでは、すべて共通のAPIを使用するいくつかのアプリサーバーを指す負荷分散があります。アプリ サーバーにはすべて同じ NGINX コング (nginx.conf) があり、さまざまな理由で更新する必要があります。

これを処理する方法は何ですか？AMI を更新してアプリサーバーを再起動する必要がありますか? サーバーを再起動する必要がありますか? AMI を更新してサーバーを実行したままにする方法はありますか?

この状況を処理する方法に関するチュートリアル/ベストプラクティスを必死に探しています。ありがとうございました。

4

2 に答える 2

0

おそらくシェフかパペットがその仕事をするでしょう。または、単純なシェルスクリプトとを使用して独自のロールを作成することもできますrsync。

于 2012-11-22T07:34:39.973 に答える
0

シェフとパペットは正しい方法ですが、そのようなことをしたくない場合は、いくつかの手順で行うことができます.

  1. AMI の作成中に、負荷分散されたインスタンスの 1 つの AMI を作成します ([再起動] を選択しないでください)。
  2. その AMI からインスタンスを作成し、変更を加え、このインスタンスをテストします。このインスタンスから AMI を作成します。

ここでの秘訣は、インスタンスを不良にすることです。これにより、ロード バランサーが不良になったと感じ、不良インスタンスを置き換える新しいマシンを作成します。しかし、新しいインスタンスを維持したいのはなぜですか。ロードバランサーに最低いくつのインスタンスを持たせる必要があるかを指定しない限り、そうしません。ロードバランサーのプロファイルの一部ではないため、そうするための構成がありません。そのスケーリングポリシーです。

したがって、自動スケーリング ポリシーを (新しい AMI を使用して) オフコースにし、新しい起動構成を (新しい AMI をオフコースで) 作成し、インスタンスの最小数を任意の数に設定します。スケールアップ/ダウンするたびに、それをいくつかのインスタンスに保ちます)。

次に、LB のヘルスチェックを減らし、インスタンスの 1 つに SSH 接続します (nginx を停止します)。多くのインスタンスが開始され、新しい AMI を持つ新しいインスタンスが導入されます。

于 2014-03-11T05:57:55.250 に答える