AWS Elastic Beanstalkの長所と短所は他のデプロイ戦略と比較してどうですか？
私は、Netflix OSSスタック全体とデプロイメント全般にかなり慣れています。私の現在の知識レベルのオプスとしての背景として、私の主な役割はフロントエンドのアプリケーションエンジニアです。ただし、運用面では楽しいので、新しいデプロイメント戦略と新しいプロジェクトのツールをセットアップしようとしています。
私たちの目標
- 超簡単なデプロイ（ボタンを押すだけでプロダクションを更新したい）
- テスト環境への自動デプロイ（Jenkinsを使用）
- メンテナンスのしやすさ（作成するアプリがあるので、本番の問題をいじるのに時間をかけたくない）
- サービス指向アーキテクチャー（多くの小さなアプリ、さまざまな言語、データストア）を処理する機能
- すぐに戦略を変更する必要がないように十分な柔軟性（すでにRightScaleから離れようとしている）
初期設定に少し時間をかけても、将来的に問題が発生しなければ問題ありません。
したがって、これらの流れに沿って、私はポッドキャストを聞いたり、Opsの話を見たり、たくさんのブログ投稿を読んだり、私たちの目標やベストプラクティスを形成するために取ったことに基づいて、アスガルド、私たちのパッケージをjarにローリングし、それをAMIにローリングします。
私たちはこれをすべて計画し、Chefサーバーを使用してインスタンスを即座に収束することに対するプロセスの利点と同様に（限られたタイムラインとChefサーバーのワークフローに関する理解の欠如を考えると、これはエラーが発生しやすいと感じました）。しかし、同僚は自分で少し周りを見て、Elastic Beanstalkが私たちのニーズを満たしているように感じました。
私はそれを調べて、WARファイルと接続されたRDSデータベースでテスト環境をスピンアップしました。うまくいっているようで、AWS APIを介してJenkinsを使用してテスト環境へのデプロイを自動化できると思います。十分にシンプルに思える...おそらくシンプルすぎる。
何が問題なのか、何が問題なのか？ 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以上です。定期的にPushするよりはかなり大きい。このリポジトリには約40のアプリケーション（実際には分割する必要があります）も含まれていますが、これにはしばらく時間がかかります。どのような種類のパッケージでもアップロードできますが、ほとんどのアプリケーションでは、パッケージにするために大量の作業が必要になります。
他のサービスとの統合-私がBeanstalkを見てきたことから、接続しているものはすべて単一のサービスであると想定しています。これは、サービスがELBの背後にある場合に適切に機能しますが、各アプリケーションサーバーで実行されているHAProxyを介してヒットした個別のノードでした。データストアと他のサービスを単一のエンドポイントとして実行している場合は、問題ありません。
私の評価では、OpsWorksとCloudFormationも含めました。 OpsWorksには、既存の自動化がこれらのアプリケーションに対してどのように機能していたかに関する同様の統合問題があります。 CloudFormationは、一部のPython=スクリプトとChefがすでに処理してくれていたものよりも多くのことを行いませんでした。
Asgard によって提供されるいくつかの自動化で、代わりにAWS Autoscaling Groupsを使用することを選択しました。これは、既存の構成/アプリケーションコードに対する最小の変更であり、AWS APIを介して利用できる複数のサーバーの簡単な管理という、私たちが求めていた利点を提供してくれました。
Elastic Beanstalkによってアプリケーションに設定された制限は非常に役立ちます。アプリケーションがほとんどステートレスであり、サービスのエンドポイントを提供し、状態が他のサービスに依存していることを確認する必要があります。 Beanstalkの複数のアプリケーションが再利用可能なスタンドアロンサービスを作成しようとしている場合は、すばらしいスタートです。
追加の構成が必要になったら、OpsWorksは素晴らしい次のステップです。事前定義された役割により、移行を簡単に開始でき、複数のサーバーのプロビジョニングの調整に役立つChefの自動化フレームワークが提供されます。
私はコントロールの喪失のポイントを見ていますが、私が義務付けられた無国籍を必ずしも見ているわけではありません。 ebが実際に行うのは、展開の自動化だけです。大規模なリポジトリのポイントがわかります。一般的に、論理的なアプリ機能を個別のBeansアプリに分離し、その下に「ステージング」環境と「製品」環境を配置することは、本当に素晴らしいと思います。アップローダーのようなモジュール環境がありますが、あまり機能せず、理論的には多くのコストがかかりますが、小さなインスタンスを使用しているだけです。一元化されたnginxを実行し、自動スケールポリシーの変更をngnixに通知するために、多くのカスタムsnsメッセージハンドルを作成する必要がありました。もう1つの大きなebの問題は、ngnixを使用しているため、ロードバランスをオフにできないことです。なぜですか？ elbはwebsocketをサポートしていません。