この記事では、インフラストラクチャでAWS ECSを使用した経験を共有し、この製品の長所と短所、およびこれに関連する問題の解決方法について説明します。 定義から始めましょう：
Amazon EC2 Container Serviceは、高性能で拡張性の高いコンテナー管理サービスです。
本質的に、ECSは、 Kubernetes 、 Mesos / Marathon 、Docker Swarmなどが現在存在するコンテナ管理市場に参入しようとするAmazonの試みです。 ただし、それらとは異なり、AmazonはAPIを使用してサービスを提供するため、最も近い類似物はGoogle Container Engine （別名kubernetes-as-a-service）です。 ECS自体は無料であり、EC2インスタンスに対してのみ料金を支払うことに注意してください。
ECSの操作は次のとおりです。
- 複数のEC2インスタンスを作成し、それらにECSエージェントをインストールし、それらをクラスターに結合します
- コンテナの説明とその実行方法（数量、展開戦略、環境変数など）を含むファイルを作成します
- このファイルをAPI経由でクラスターに転送します
- ECSは、コンテナを起動するインスタンスを選択し、クラッシュした場合に再起動します
- ???
- 利益
すでにKubernetesを使用している読者にとって、このスキームは非常に馴染みのあるものです。 APIを介した作業に加えて、これらの同じアクションをWebインターフェースを介して実行できます。 図で明らかに：
バランシングとサービス発見の問題
通常、コンテナを起動するだけでは十分ではありません。外部からコンテナに手を差し伸べる必要があります。 これを行うには、コンテナが実行されているインスタンスとポートを知る必要があります。 この問題を解決するために、AWSはELBとの統合を提供します。ELBでは、コンテナーの静的ポートを指定し、このポートでELBクラスターに接続する必要があります。 このアプローチはPaaS Empireで使用されています。
注：私は新しいAWS ALBを見ていないので、おそらくすべてが異なっています。
この方法には欠点がないわけではありません。たとえば、 サービスへのトラフィックがない場合でも、 各タイプのサービスに対して各ELBを支払う必要があります。 この問題は、サービスを動的に作成する場合に特に深刻です。 また、 ポートの競合のため、1つのインスタンスで複数のサービスを実行することはできません 。 これはすべて、リソースの非効率的な利用と使用の不便につながります。 これは私たちのやり方ではありません。
サービス発見のためのツールを探した後、私たちの選択はハシコープの領事に委ねられました。 consulでコンテナを登録するには、 registratorを使用します。 したがって、インスタンスでは、ECSエージェントに加えて、領事エージェントと登録者をインストールします。 図では：
ランダムポートでECSエージェントを使用してコンテナーを開始した後、登録者はdocker apiを介して通知を受け取り、consulにサービスを登録します。 登録機能を使用すると、マジック環境変数を使用して、consulのサービスのヘルスチェックを決定したり、タグを指定したりできます。
次に、領事サービス間でトラフィックのバランスをとるという問題を解決する必要があり、 fabioを試してみることにしました 。その主な利点は設定の欠如です。 Fabioは、領事館からサービスのリストを読み取ることによって自身を構成し、タグに従ってルーティングテーブルを作成します。 サービスのステータスを変更したり、新しいサービスを追加すると、fabioは即座にルーティングテーブルを再構築します。 Fabioには、現在のルートと特定のコンテナにリダイレクトされたトラフィックの量を確認できるインターフェイスもあります。
簡略化した図では、クラスター全体で1つのELBしか使用できなかったことがわかります。
サービス
ECSでは、 Dockerコンテナにラップされた標準のステートレス12ファクターアプリケーションを展開します。 ECS用のAWS APIに独自のラッパーを使用して、サービスをさらに簡単かつ便利にデプロイしました。 そのため、ECSが受け入れるJSONの代わりに、Kubernetes形式に似た単純化されたymlを使用します。
demo-service.yml
--- - name: demo-service image: test-image version: 4.2 region: eu-central-1 cluster: ecs-cluster cpu: 128 memory: 256 port: 8080 instances: 2 custom_env: SOMEVAR: somevalue
このようなファイルは、ECSに展開されている各サービスのすべてのリポジトリにあります。 AWSを受け入れるJSONと比較できます 。 同時に、デプロイにはラッパーとAWS APIキーのみが必要です。
また、Jenkinsを介してECSとgithubを統合し、オープン時に各プルリクエストをECSに展開します。開発者にとっては次のようになります。
そのため、コードレビューを行うことで、誰でもすぐに提案されたサービスの変更を確認し、統合テストを実行できます。 また、「クラウド内」ですぐにアプリケーションを起動することは非常に便利です。
長所
私の意見では、ECSはコンテナーオーケストレーションのタスクに十分に対処でき、ユーザーはそれに耐えることができます。 次のような明らかな利点があります。
- 無料-EC2料金のみ。
- フォールトトレランスについて考える必要のないホスト型ソリューション。
- 低エントリのしきい値、すべてがWebインターフェイスを介してクリックできます。
- EC2およびECSとの統合により、インスタンスがいつ利用できないかがすぐにわかります。
- CloudWatchおよびAutoScalingGroupとの統合 。実行中のコンテナーの数に応じて、ECSクラスター内のEC2インスタンスの数を調整できます。
短所
そして今、不足しているものと次のプロジェクトのためにKubernetesを使用します。
- AWSのベンダーロック。
- 製品としてのECSの開発の遅さ、および他のサービスとの統合。 そのため、eu-central-1では、OpsWorksとの統合はまだありません。
- AWS SDKには、1回限りのタスクを実行するときにコンテナの終了コードを直接チェックする方法はありません。 Kubernetesにはそれがあります。
- ECSは別名AZとも呼ばれていますが、AZ間でのコンテナーの配布は期待したものではありません。 したがって、たとえば、1つのAZが利用できない場合、すべてのコンテナは別のコンテナに移動されますが、このAZを上げると、コンテナは戻されなくなります。 また、リソース全体が最も多いインスタンスが存在するため、サービス全体が1つのAZのみで展開された展開中に、奇妙な点も観察しました。
- ECSはヘルスチェックとコンテナについて何も知りません。起動されたサービスはコンテナが開始されたサービスです。 Kubernetesにはそれがあります。
- ステートフルアプリケーションが必要な場合-ECSはあなたに向いていません。 同時に、Kubernetesにはすでに適切なサポートがあり、リリースごとに状況は改善されています。
- パッチを送信できない独自の製品。
おわりに
ECSの使用を開始したとき（2015年末）、競合他社と比較して非常に優れていました。 しかし、時間の経過とともに、ECSは市場に追いつかず、この製品は将来成功する可能性がほとんどないと言えます。 たとえば、 最もアクティブなecs-agent開発者がコミットしている場所を確認できます。 ECSは、コンテナオーケストレーションの世界に没頭し始めたばかりの人に適していますが、長期的に深刻なプロジェクトを計画している場合は、KubernetesまたはMesos / Marathonに注目してください。