他のデプロイ戦略と比較したAWS Elastic Beanstalkの長所と短所は何ですか？

私はNetflix OSSスタック全体と展開全般についてはかなり新しいです。私の現在の知識レベルの背景として、私の主な役割はフロントエンドアプリケーションエンジニアとしてです。しかし、私は物事の運用面を楽しんでいるので、新しい展開戦略と新しいプロジェクトのツールをセットアップしようとしています。

私たちの目標

• 非常に簡単な展開（ボタンを押して生産を更新したい）
• テスト環境への自動展開（Jenkinsを使用）
• メンテナンスの容易さ（作成するアプリがあるため、本番の問題をいじるのに時間を費やしたくない）
• サービス指向アーキテクチャ（多くの小さなアプリ、さまざまな言語、データストア）を処理する機能
• すぐに戦略を変更する必要がないことを保証する十分な柔軟性（すでにRightScaleから脱出しようとしています）

初期セットアップ時間をもう少し長くしても大丈夫です。そうすることで、将来の頭痛の種が減ります。

そのため、これらの方針に沿って、ポッドキャストを聞いたり、Opsのトークを見たり、たくさんのブログ投稿を読んだりして、目標とベストプラクティスを形成するために取ったものに基づいて、計画を立て始めました。 Asgard、パッケージをjarに丸め、AMIに丸めます。

これはすべて計画されていて、Chefサーバーを使用してインスタンスをオンザフライで収束するよりもプロセスの利点が好きでした（限られたタイムラインとChefサーバーワークフローに関する理解不足のため、これはエラーが発生しやすいと感じました）。しかし、同僚は自分で少し見回して、Elastic Beanstalkが私たちのニーズを満たしているように感じました。

私はそれを調べて、WARファイルとアタッチされたRDSデータベースを使用してテスト環境を作成しました。物事はうまくいくようで、Jenkinsを使用してAWS API経由でテスト環境へのデプロイを自動化できると思います。十分に単純に思えます...おそらく単純すぎます。

私が思っているのは、キャッチは何ですか？Elastic Beanstalkが非常にシンプルで効果的な場合、なぜそれ以上話されないのですか？2つの異なる展開戦略について十分な客観的な意見や事実を見つけるのに苦労しているので、周りに尋ねると思いました。

Elastic Beanstalkを使用していますか？もしそうなら、なぜ、どのような要因がその決定につながりますか？何が好きで嫌いですか？

Elastic Beanstalkを使用せずに検討した場合、何を使用し、なぜElastic Beanstalkを使用しなかったのですか？

SOAのElastic Beanstalkベースの展開戦略の長所と短所は何ですか？つまり、Elastic Beanstalkは、互いに依存して動作する多くの小さなアプリケーションでうまく機能しますか？

手持ちのAWSインスタンスを改善しようとしながら、他のAWS製品に加えてElastic Beanstalkを評価しました。使用しないことにした理由は、オファリング自体ではなく、既存のアプリケーションの移行を引き起こす複雑さによるものです。難点は、サーバーのアプリケーションの展開/構成についてあまり制御できないことです。新しいアプリケーションを開始する場合は、それらのことをすぐに処理しないことが役立つ場合があります。既存のアプリケーションがある場合は、Beanstalkモデルに適合させることはより困難です。

Beanstalkは、Herokuや他のPaaSベンダーに同様の製品を提供していますが、アプリケーションの作成に集中したいだけの人にはあまりメリットがありません。少なくとも、他のPaaSベンダーよりも大幅に仮想化リソースを決定できます。

私のアプリケーションで遭遇した問題：

• Gitベースの展開-それらは大好きですが、レポは1 GB以上です。定期的にプッシュするにはかなり大きい。このレポジトリには約40個のアプリケーション（実際には分割する必要があります）も含まれていますが、それには時間がかかります。あらゆる種類のパッケージをアップロードすることはできますが、ほとんどのアプリケーションはパッケージを作成するために大量の作業を必要とします。

• 他のサービスとの統合-Beanstalkで見たように、接続しているものはすべて単一のサービスであると想定しています。これは、サービスがELBの背後にあり、ELBが別のノードであり、各アプリケーションサーバーで実行されているHAProxyを介してヒットする場合に有効です。データストアと他のサービスを単一のエンドポイントとして実行している場合は、問題ないはずです。

私の評価では、OpsWorksとCloudFormationも含めました。OpsWorksには、既存の自動化がこれらのアプリケーションでどのように機能していたかと同様の統合の問題があります。CloudFormationは、一部のPythonスクリプトとChefがすでに処理してくれた以上のことはしませんでした。

Asgardが提供する一部の自動化ではなく、AWS Autoscaling Groupsを使用することにしました。これは、既存の構成/アプリケーションコードに対する最小の変更であり、AWS APIを介して利用できる複数のサーバーのシンプルな管理を求めていた利点を提供しました。

Elastic Beanstalkによってアプリケーションに設定された制限は非常に役立ちます。アプリケーションの大部分がステートレスであり、サービスのエンドポイントを提供し、状態を他のサービスに依存していることを確認する必要があります。再利用可能なスタンドアロンサービスを作成しようとしている場合、Beanstalkの複数のアプリケーションは素晴らしいスタートです。

OpsWorksをさらに構成する必要がある場合は、次のステップとして最適です。事前定義されたロールにより、移行を簡単に開始でき、複数のサーバーのプロビジョニングの調整に役立つChefの自動化フレームワークが提供されます。

私はコントロールの喪失のポイントを見ますが、義務付けられた無国籍を必ずしも見るとは限りません。ebが実際に行うのは、自動化を展開することだけです。大規模なリポジトリのポイントを見ています。一般的に、論理アプリ機能を個別のBeanアプリに分離し、その下に「ステージング」環境と「プロッド」環境を配置するのは本当に素晴らしいと思います。アップローダーのようなモジュール環境がありますが、それはあまり効果的ではなく、理論的には多くのコストを追加しますが、それよりも小さなインスタンスを使用しています。一元化されたnginxを実行し、自動スケールポリシーの変更をngnixに通知するためにカスタムのsnsメッセージハンドルを大量に記述する必要がありました。もう1つの大きなebの問題は、ngnixを使用しているため、負荷分散を停止できないことです。なぜですか？elbはwebsocketをサポートしていません。