CHAPTER8 Deployment and Operation
Container Service
前提として、AWSではコンテナオーケストレーションの方法としてECSとKubanetes両方を提供している。ECSの方が先に提供され、また管理も遥かに自動化されている。その後後発としてAWS ManagedのKubanetesが提供されたが、これはKubanetesがHybrid Cloudな環境でオーケストレーションを行うことを念頭においている。
AWSはなぜ、ECSがあるのにKubernetesのサービスを始めたのか、コックロフト氏に聞いた：AWSとオープンソース（1） - ＠IT
【Kubernetes】 addons
KubanetesではKubanetes側が各コンテナの管理に必要なアプリケーションをアドオンとして付与して稼働させている。
WebUIはKubanetesの管理に利用するWeb画面をKubanetes側でホストして表示してくれる(Web UI (Dashboard) | Kubernetes)。
リソースモニタは各コンテナからリソースの消費状況の情報を収集して監視に利用する。
ロギングは実行中のコンテナで発生したログをコンテナの外部に吐き出し保存させる。ロギングをコンテナ内部で完結した場合、コンテナで障害が発生した場合にトラブルシューティングが出来なくなる。
この他にコンテナからの(またはコンテナ間の)ネットワークを制御する様々な3rd Party製のアドオンが公開されている。
【ECS】Service Discovery
ECSのサービスディスカバリーが東京にやってきて、コンテナ間通信の実装が簡単になりました！ | DevelopersIO
コンテナ間で通信を実施するにあたり、各コンテナは相手のコンテナが立てているサーバの名前を知った上で名前解決が必要になる。 Service Discoveryはこうした起動中の環境にあるコンテナを把握したうえで、各コンテナの名前解決を支援するための仕組みである。
ECSといえど結局はコンテナ間の名前解決にはRoute53が利用されているらしく、他のコンテナがURLを元に同じ環境にいるはずの別コンテナが立てているサーバーを探し出すには、Route53にコンテナが立てているサーバー(またはELB)のURLとPrivateAddressを登録しておく必要がある。
ServiceDiscoveryは文字通り、「ECS実行環境に立っているサーバーを見つけ出し、そのIpAddress(と起動時に指定したURL)を他のコンテナが参照するRoute53のDNSレコードとして登録しておいてくれる」サービスである。
Code Deploy
CodeDeployではElastic Beanstalkなどと異なり実行環境の構築は行ってくれない。
原則として既にコードが実行可能な環境に対するConitniuous Deploymentとして機能することになる。 他方、CodeDeployはAutoScalingやELBとの協調が可能である。
これはAutoScalingが新規にインスタンスを立ち上げるタイミングで、そのインスタンスに対して新しいCodeをDeployするための仕組みである。
CloudFormation
※Labを実施してから執筆します。
