タグ付けされた質問 「autoscaling」

AutoScalingグループの状態のスケーリングポリシーによるTerraformの望ましい容量の変更をどのように管理できますか？ 具体的には、I提供仮定aws_autoscaling_groupリソースとテラフォームとdesired_capacity 4のと高いCPU使用率にスケールアップポリシー。その後、自動スケーリンググループはスケーリングポリシーを介して希望の容量6に更新されましたが、この状態はterraform .tfstateにキャプチャされません。 テラフォームを介して自動スケーリンググループの状態を後で変更したい場合、（。tfで変更されていないため）desired_capacityをリセットせずに変更するにはどうすればよいですか？どういうわけか、現在のグループサイズと一致するようにdesired_capacityの更新を自動化できますか、それとも、desired_capacityをまったく設定しないでください。

9 amazon-web-services  terraform  autoscaling  capacity-planning 

モノリシックアーキテクチャから自動スケーリンググループに移行しようとしていますが、データベースの移行をどのように実行すればよいかわかりません（Laravel）。 新しいボックスがオンラインになったときにスクリプトが実行されると思います。これにより、最新のコードがgit pullされます。このスクリプトでデータベースの移行も実行する必要がありますか？1つのボックスだけで実行する方法がわかりませんか？

8 amazon-web-services  autoscaling 

私たちはサービスの発見にConsulを使用する自動スケーリングDocker環境を持っています。これらの環境では、数分ごとに1つのインスタンスを追加または削除できます。 初期のConsulテストでは、Consulが定足数を失うのは非常に簡単であることがわかりました。おそらく単純に、最初の実験は、すべてのインスタンスでConsulサーバーを起動し、そのConsulサーバーをクラスターに参加させるセットアップでした。その部分はうまく機能していました。 ただし、非常にスケーラブルな環境では、Consulは到達不能なノードを迅速に（約72時間かかりますか？）定足数を失います。 GitHub：https : //github.com/hashicorp/consul/issues/454#issuecomment-125767550のこの問題に関するほぼ2年前からのarmonの応答を見てきました。 これらの問題のほとんどは、正常な休暇をとるというデフォルトの動作が原因です。私たちのメンタルモデルでは、サーバーは長命であり、予期しない停電、または正常なメンテナンス（クラスターを離れる必要がある場合）以外の理由でシャットダウンしません。振り返ってみると、それは悪いデフォルトでした。これはほとんどすべて、Consulサーバーを-9で強制終了することで回避でき、電力損失のシミュレーションに影響を与えます。 専用の長期間有効なノードを実行しないようにしようとしていました。どの時点でも、自動スケーリンググループからN / 2 + 1インスタンスを削除しないことに注意してください。EC2クラスターは、ほとんどのノードにいつでも到達でき、ノードをConsul（または他のツール）クラスターから削除するかどうかを投票できる必要があります。

8 autoscaling  consul 

特定のKafkaトピックに表示されるラグの量に基づいて動的にスケールアップ/ダウンしたい自動スケーリンググループがあります。スケーリングする必要があるトピックと自動スケーリンググループの間には1対1の関係があります。CloudWatchメトリクスを使用してこれに対処することはできないと確信しています。 競合状態やその他の問題を発生させることなく、ジェンキンスを使用してこれを達成できる方法はありますか？ 注：アプリケーションは、CPU、ディスクI / O、またはCloudWatchによって提供されるその他のメトリックによって制約されていません。制約は、着信するKafkaトピックから処理するアプリケーションの機能です。

7 jenkins  amazon-web-services  autoscaling