(python/Django)アプリケーションをAWS Elastic Beanstalkにデプロイしようとしていますが、エラーが発生します。過去数か月間、デプロイメントは問題なく機能していたため、原因が何であるか混乱しています。ここにエラーがあります:
ERROR: Updating RDS database named: aa1xxxxxxxxx failed Reason: Invalid storage size for engine name mysql and storage type gp2: 5
誰かが最初のEB + RDSセットアップを手伝ってくれたので、最初からEB + RDSのセットアップがどのように行われているかは100%よく知りません。しかし、AWSコンソールに移動すると、storage
フィールドが100GiB
に設定されたRDSインスタンスが表示され、EB構成に移動すると、既存のRDSへの接続が表示されますインスタンスですが、ここでのstorage
は5 GB
のみを示しています。 5GBを10GBに更新してみましたが、それでも同じエラーが発生し、展開がまだ機能しません。
また、EBデータベース設定のEndpoint
は、RDSインスタンスのエンドポイント `aa1xxxx.yyyyyyyyy.us-west-2.rds.amazonaws.comのURLと同じに見えます。
注:私はこれを見つけました thread は似ていますが、ストレージフィールドを編集できなかったので、ストレージフィールドを編集できたので、正確には私の状況ではありませんでした。
Elastic Beanstalkの外部でRDSインスタンスが変更されているようです。つまり、EBが真であると信じているものと実際に真であるものの間の構成データは一致しなくなります。これは、Elastic Beanstalkなどのツールを使用する場合の一般的な問題です。これは、他のAWSサービスのラッパーにすぎません(実際には、CloudFormationテンプレートの非常に特定のセットのニースUIです)。RDSコンソールに移動して、 EBがプロビジョニングした後、自分で設定します。
gp2
には、MySQLインスタンスの最小ストレージサイズが20 GBであるため、このエラーが発生するのは、EB環境の5 GBストレージサイズ構成がRDSインスタンスに設定されているストレージタイプと競合するためです。 EBはストレージタイプがマゼンタであると考えているため、他のストレージタイプによって設定された制限を強制しません。 Elastic Beanstalkがそのエラーを出力しているのではなく、EBの背後にあるCloudFormationスタックが、EBコンソールが最終的に制御するすべてを結び付けています。
これを解決するには、Elastic Beanstalkの環境を、RDSインスタンスが構成されているものにできるだけ一致するように設定する必要があります。 Elastic Beanstalkを使用して、RDSインスタンスのストレージタイプをデフォルトのマグネティック構成から変更することはできないと思います。したがって、ここには2つのオプションがあります。
EB構成のストレージサイズを100GBに設定して保存します。これにより、EBが事実と同期します。適用されると、CloudFormationにデータベースのサイズを変更するように指示します。これで、実際にインスタンスがサイズ変更のためにダウンするかどうか、「新しい」ストレージサイズは現在のサイズと同じであるため、わかりません。新しいサイズ==古いサイズであるため、エラーがスローされることもあります。これを最小20GBに変更して(さらに低くしたい場合)、インスタンスのサイズを変更し、RDSのストレージサイズがElastic Beanstalkの構成のストレージサイズと一致することを確認できます。ストレージタイプの制限により、20 GBを下回ることはできないことに注意してください。
RDSインスタンスのサイズを手動でリサイズして、5GBのマジェンティックストレージに戻します-Elastic Beanstalkが真実であると信じているサイズまで。もちろん、これは、データベースが5GBのインスタンスに収まるほど小さい場合にのみ機能します。そうでない場合、あなたはここで運が悪いので、代わりにオプション#1を探索する価値があるでしょう。それが収まる場合、このアクションはデータベースのサイズをElastic Beanstalkが現在想定しているサイズに戻し、EBの構成ツールを使用してデータベースのサイズを再度変更できるようになります。