Edited at

Amazon ECS(EC2 Container Service)についての簡単なメモ


はじめに

今更ながらAmazon ECSをちょっと使おうと思って調べたことのメモです。


概要・ぱっとみ感想


  • AWSのEC2上に Dockerコンテナを配備するためのサービス

  • コンテナ同士の管理・連携などはAWS独自の仕様・仕組みで作られている(んだと思っている)

  • Web Consoleがあるので、初心者にはより使いやすいかも

  • コンテナ毎のメモリやCPUリソースの分配ルールが指定可能

  • Docker Imageは Docker Hubから指定可能(独自Dockerリポジトリも可能? ここimage について You can also specify other repositories with repository-url/image:tag. と書いてあるので可能なように思える。SSL証明書とかがOKなものなら少なくともいけそう。)

  • コンテナインスタンスはVPC内にたてることが可能


紛らわしい用語整理


  • コンテナインスタンス: EC2 Instanceのこと

  • (Docker)コンテナ: Dockerにデプロイされる Docker Image のこと


    • つまり、1つのコンテナインスタンス(EC2)の中に複数のコンテナ(Docker)が稼働可能、という関係




ECSの概念

ドキュメントとWebConsoleを触った感じから、自分の理解をちょっと図にしてみた。

aws_ecs_pptx.png


タスク定義(Task Definitions)


  • 「タスク定義」は複数の「コンテナ定義」を持つ

  • 「コンテナ定義」では、どのDocker Imageをどう実行するか(PortMap, VolumeMap, CPU/Memory割り当て) を決める。

  • Memoryは上限値を定めるが、CPUは上限値ではなく「コンテナがお互いに窮屈になったら融通しあう割合」を指定する。つまりコンテナインスタンスのCPUが余っていたらCPUは100%使われる。

タスク定義は大事なので詳細はここを見ると良い。

http://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definition_parameters.html


クラスタ(Cluster)


  • 1つのクラスタ は 複数のサービス(Service)を持つ

  • 1つのクラスタ は 複数のコンテナインスタンス(EC2 Instance)を持つことができる


  • 1つのサービス は 1つのタスク定義 を持つ


    • この時その「タスク定義」を「いくつ実行するか」を決める(タスク数を指定する)

    • ただし、十分なリソース(コンテナインスタンス内の)がないと指定したタスク数にならないことがある


      • CPU/Memoryが不足、Portが重複、など






  • コンテナインスタンスは、EC2 Instanceで、デフォルトではDockerに最適化されたOS Imageである


    • (Amazon Linux に Docker Agentとかいうのが入っているっぽい).



  • EC2 InstanceにSSH鍵を指定して起動しておけば、そのコンテナインスタンスにSSH Loginも可能。



ECSの操作


コンテナインスタンスの追加

少なくとの以下の2つの方法で追加できた。


  • コンテナインスタンスのEC2インスタンスを EC2のコンソールから Launch More Like This すると、ECSのクラスターの対象に追加される(された)。

  • AutoScaling Groupがある場合は(適当にやったら自動的に追加されてた)、「最大」「希望」Instance数を上げれば追加される(された)。


サービスのデプロイ


  • タスク定義をして、クラスタ(サービス+コンテナインスタンス)を定義すれば自動的にサービスのTask定義が開始される。

  • ただし、コンテナインスタンスのリソースが不足する場合は、指定したタスク数が起動しないことがある。


サービスの更新

デプロイしたコンテナの更新や設定を変更する場合は、タスク定義を更新する形で行う。


  • タスク定義には Revision番号 がある。

  • タスク定義の更新のときに「新しいRevisionの作成」という機能から、新たなタスク定義を行う。

  • サービスが実行するタスク定義を指定するときも 実は「タスク定義+Revision番号」で指定するので、その番号を更新することで、サービスの更新を行う。

つまり、「新たなタスク定義Revision追加」→「サービスが実行するタスク定義Revisionを更新」 という流れになる。

注意事項として、サービスを更新しても、古いRevisionのタスクは動いたままになるので、手動で古いタスクを停止しないといけない(勝手に止まったりしないという意味)。停止すると、(指定されたTask数に満たないし、コンテナリソースが余っているので)しばらくしたら新しいRevisionのタスクが起動することになる。


さいごに

最初ややこしかったですが、多少なりとも理解できると、便利そうだなーと思えてきました。