web-dev-qa-db-ja.com

Elastic Beanstalkがインスタンスにコマンドを発行するたびに常にタイムアウトになるのはなぜですか？

PHPアプリケーションがAmazon Elastic Beanstalkにデプロイされています。しかし、git aws.Pushを介してコード変更をElastic Beanstalkにプッシュするたびに、デプロイされたアプリケーションが選択されないという問題に気付きます。私はアプリケーションBeanstalk環境のイベントログをチェックし、Beanstalkが発行するたびに次のことに気付きます。

インスタンスへの新しいバージョンの展開

常に後に続きます：

次のインスタンスは、許可されたコマンドタイムアウト時間内に応答しませんでした（それらは最終的には独自に終了する可能性があります）：[i-d5xxxxx]

スナップショットログを要求しようとすると、同じことが起こります。 Beanstalkの問題：

requestEnvironmentInfoが開始しています

その後、数分後に再び続きます：

次のインスタンスは、許可されたコマンドタイムアウト時間内に応答しませんでした（それらは最終的には独自に終了する可能性があります）：[i-d5xxxxx]。

amazon-web-serviceselastic-beanstalk
37
ardfard

この問題は何度かありました。特定のインスタンスにのみ影響があるようです。そのため、EC2インスタンスを終了することで解決できます（管理コンソールのEC2ページで行います）。その後、Elastic Beanstalkは正常なインスタンスが0個あることを検出し、新しいインスタンスを自動的に起動します。

これが実稼働環境であり、インスタンスが1つだけで、ダウンタイムを最小限にしたい場合

  1. 最小インスタンスを2に設定すると、Beanstalkが別のインスタンスを起動します。
  2. eC2タブを介して問題のあるインスタンスを終了すると、Beanstalkは最小インスタンスが2であるため別のインスタンスを起動します
  3. 最小インスタンスを1に戻すと、Beanstalkは2つのインスタンスのいずれかを削除します。
41
chongzixin

デフォルトでは、コマンドが時間内に完了しなかった場合、Elastic Beanstalkは8分（設定で480秒に定義）後に「タイムアウト例外をスロー」します。 30分（1800秒）までのより長い時間を設定できます。

{
    "Namespace": "aws:elasticbeanstalk:command",
    "OptionName": "Timeout",
    "Value": "1800"
}

ここをお読みください： http://docs.aws.Amazon.com/elasticbeanstalk/latest/dg/command-options.html

5
daveoncode

Beanstalkデプロイメント（およびログ取得などの他の機能）は、SQSコマンドをインスタンスに送信することで機能します。 SQSクライアントはインスタンスにデプロイされ、約20秒ごとにキューをチェックします（/var/log/cfn-hup.logを参照）：2018-05-30 10：42：38,605 [DEBUG]キューのメッセージの受信 https： //sqs.us-east-2.amazonaws.com/124386531466/93b60687a33e19 ...

SQSクライアントがクラッシュするか、t1/t2インスタンスでネットワークに問題がある場合、Beanstalkからコマンドを受信できず、展開がタイムアウトします。インスタンスを再起動すると、SQSクライアントが再起動し、コマンドを再度受信できるようになります。

SQSクライアントを修正する簡単な方法は、cfn-hupサービスを再起動することです。

Sudo service cfn-hup restart
2
Victor Gavrilenko

ここにも同じ問題がありました（単一のt1.microインスタンス）。

（EBページからではなく）管理コンソールのEC2ページからEC2インスタンスを再起動することで問題を解決しました。

1
mirzik

デプロイの場合、EC2インスタンスをシャットダウンしてElastic Beanstalkが反応するのを待つ、または最小インスタンスと最大インスタンスをいじる代わりに、ターゲット環境でRebuild environmentを実行するだけです。

タイムアウトにより以前の展開が失敗した場合、新しいバージョンは引き続き環境に対して登録されますが、タイムアウトのために動作していないように見えます（私の経験では、インスタンスはまだ古いバージョンを実行しているように見えます）。

環境を再構築すると、使用されている新しいバージョンで問題がリセットされるようです。

明らかに、ダウンタイムの期間にはマイナス面があります。

0
Dan Gravell

これに対処する正しい方法だと思います。これに対処する正しい方法は、 この回答が示唆する を実行してタイムアウトの原因を突き止めることだと思います。

chongzixin's answer は、タイムアウトの理由を調査する前にこの修正されたASAPが必要な場合に実行する必要があるものです。

ただし、タイムアウトを増やす必要がある場合doは、次を参照してください。

.ebextensionsという名前のフォルダー内のソースコードに構成ファイルを追加し、アプリケーションソースバンドルにデプロイします。

例：

option_settings:
  "aws:elasticbeanstalk:command":
    Timeout: 2400

*「値」は、タイムアウトするまでの時間を秒単位で表します。

参照： https://serverfault.com/a/747800/49635

0
Pranay Majmundar

Elastic Beanstalk管理ダッシュボードの[アクション]メニューから[アプリケーションサーバーを再起動]に続いてeb deployは私のためにそれを修正します。

最初の命令の視覚的キュー

0
Anuj Verma