web-dev-qa-db-ja.com

Application Elastic LoadBalancerを使用した代替ポートでのAWSElasticBeanstalkヘルスチェック

Saved Configs を使用して、ElasticBeanstalkアプリケーションの構成を自動化しようとしています。

Elastic Beanstalkから作成されたアプリケーションロードバランサーを取得して別のヘルスチェックポートを使用する方法の例はありますか?

そうでない場合は、基になるリソースにアクセスして、カスタムHealthCheckPort: 8081をターゲットグループに適用できるようにする方法はありますか?


これまでの詳細と試み:

このアプリケーションは、単純なDropWizardベースのJavaアプリケーションであり、ポート8080でHTTP APIを提供し、ポート8081でヘルスチェックAPIを提供します。

次のOptionSettingsを使用して、ClassicELBを使用して環境を構成することに成功しました。

OptionSettings:
  aws:elasticbeanstalk:environment:
    EnvironmentType: LoadBalanced
    LoadBalancerType: classic
  aws:elasticbeanstalk:application:
    Application Healthcheck URL: HTTP:8081/healthcheck
  aws:elasticbeanstalk:environment:process:default:
    MatcherHTTPCode: '200'
    Port: '8080'
    Protocol: HTTP
  aws:elb:healthcheck:
    HealthyThreshold: '3'
    Interval: '10'
    Timeout: '5'
    UnhealthyThreshold: '5'
  aws:elb:listener:80:
    ListenerProtocol: HTTP
    InstancePort: '8080'
    InstanceProtocol: HTTP
    ListenerEnabled: true
  aws:elb:loadbalancer:
    CrossZone: true

ただし、アプリケーションELBを使用するように構成を更新すると、ターゲットグループに関連付けられているヘルスチェックがヘルスチェックポート(8081)ではなくアプリケーションポート(8080)に設定されます。これにより、アプリケーションが失敗状態で起動します。これは、ターゲットグループのヘルスチェックポートを手動で変更することによってのみ修正できます。

OptionSettings:
  aws:elasticbeanstalk:environment:
    EnvironmentType: LoadBalanced
    LoadBalancerType: application
  aws:elasticbeanstalk:application:
    Application Healthcheck URL: HTTP:8081/healthcheck
  aws:elasticbeanstalk:environment:process:default:
    MatcherHTTPCode: '200'
    Port: '8080'
    Protocol: HTTP
  aws:elbv2:listener:default:
    DefaultProcess: default
    ListenerEnabled: true
    Protocol: HTTP
  aws:elbv2:loadbalancer:
    AccessLogsS3Enabled: false
    IdleTimeout: '60'

AWS ElasticBeanstalkコマンドオプションのドキュメントに他の関連フィールドが見つかりません。

カスタムリソースの変更 を実行することも考えましたが、参照されるELBは、古典的なロードバランサーであるタイプAWS::ElasticLoadBalancing::LoadBalancerAWSEBLoadBalancerだけですが、変更する必要がありますmakeは、アプリケーションロードバランサーのタイプAWS::ElasticLoadBalancingV2::TargetGroupです。

3
J Messenger

TerraformまたはCloudFormationを使用して、必要なロードバランサー、EC2インスタンス、およびその他のリソースを管理します。 ElasticBeanstalkよりも前もって多くの作業が必要ですが、リソースのあらゆる側面を正確に制御することは可能です。 .ebextensionsからのソフトウェアのインストールとインスタンス設定は、AWS::CloudFormation::InitとAWSのcfn-initヘルパースクリプトに置き換えることができます。

CloudFormationテンプレートの生成には troposphere もお勧めします。構文はCloudFormationのリソース構文に対して1対1でマップされますが、スペルミスのあるプロパティ名または無効なプロパティタイプのエラーが生成されます。 botoと組み合わせると、単純なpythonコマンドラインユーティリティを使用して、アプリケーションの展開ライフサイクルを完全に自動化することができました。

0
J Messenger