esc勉強会の内容

a.md

事例一覧

• https://t.co/up37dE4ngQ
• http://t.co/KWIJQklY8B
• https://twitter.com/jawsugcontainer/status/643372636869783552

aa.md

🍺🍖👍

Amazon ECSのケーススタディとユースケース、Amazon ECSの将来像

コンテナ

コンテナ

• ポータブル
• プラットフォームをまたいでコンテナを移動
• 柔軟性
• クリーンで再現可能でモジュール化された環境
• 高速
• 開発のライフサイクルを高速化
• 効率的
• 計算機リソースのより高い利用率

フリート管理

• 利用率の監視が必要
• キャパシティの成長
• セキュリティや管理が重要
• 状態の管理

スケジューリング

• 制約を把握
• 制約に合うリソースを見つける
• リソースをリクエスト
• リソースを確認

ecs

アーキテクチャ

• Container Instance
• Docker Container
• ESC Agent
• いろいろな管理をしてる
• Amazon ESCとDocker Containerを連携
• Amazon ESC
• Agent Communication Service
• API
• スケジューラからAPIを叩くことができる

移管る規模でも簡単にクラスタ管理

• 何も走らせなくてもいい
• 状態を完全に把握
• 制御と監視
• スケール

スケーラブル

• EC2だとInstanceがどんどんスケールしてしまう
• Latencyが発生
• ESCだと問題ない

柔軟なコンテナの配置

• 複数のスケジューラでバッチジョブを起動することができる

他のAWSが利用デザインされている

連携可能サービス

• ELB
• EBS
• VPC
• IAM
• CloudTrail

拡張性

• 包括的なAPI
• ESCのエージェントはopen sourceなエージェントが使える
• カスタムスケジューラ

キーコンポーネント: Container Instances

• EC2 Instance
• Docker daemon

Cluster

• リージョン毎
• リソースプール
• COntainer Instancesをグループ化

Tasks

• 関連するコンテナをグループ化
• Container Instances で実行

Task Definitions

定義を指定して、インスタンスに載せる

• volume
• container

Run a task

バッチジョブのような短い時間のコンテナ向け

Services

• アプリケーションやサービス向け
• コンテナ間にわたって負荷分散
• サービスディスカバリ
• コンテナの自動復旧
• scale up/down
• 新しいバージョンのデプロイ

use case

• バッチジョブ
• CI/CD
• 分散アプリケーション/マイクロサービス
• Platform as a Service
• ECSが多数の独立したリソーうのデプロイをモジュール化したやり方で管理
• PaaS提供者のエンドユーザとリソースの分離を手助け

EC2からECSへ

EC2でやってたことをECSでやってみた案件

ECSの状況と使った例

• アプリがdocker前提とした開発/対応してないと、docker対応が難しい:poop:
• ECSで少ないEC2で分離レベルを高く複数の同一なアプリケーションを構築できる
• 同一Instanceにprod, staging, test:smirk:
• リソース制限が可能で嬉しい:clap:
• 利用技術(EC2の場合)

• CloudFormation

• VPCなどのawsコンポーネント構築する仕組み

• Packer

• amiを作成
• amiの中身はaisibleで構築

• Ansible

• packerでamiを作ってcloudformationで全体システム構築
• amiを作るplaybookと全体システムを構築するPlaybook
• CloudFormationのstack作成完了までまってくれる
• 冪等性がstackのupdateを使っていい感じ:thumbsup:
• 利用技術(ECS)

• CloudFormation

• ECSに対応済み:congratulations::tada:

• Docker

• イメージを作成するために利用
• Dockerfileに記述
• DockerHubで実施

• Ansible

• CloudFormationで全体のシステムおｗ構築
• ECS構築後ECSが勝手にDockerHubからDockerイメージを取得

内容調整中

blue green deployment with ecs

immutable infrastructure

• immutable server
• stateless / disposable
• サーバを使い捨てていく
• 設定変更する歳は再作成する
• 環境差分・設定差分をなくせる

blue-green deployment

新しいhostを作ってLBで向き先を変えて、古いhostを捨てる

pattern1

• 2 auto scale as ECS
• elbでグループを切替
• blueに新しいのをdeploy
• リソースの無駄、暖気が必要

pattern 2

• 1 auto scale 2 ECS task
• elbでtaskを切替
• ポートが衝突するのでずらす
• delte/createloadbalancerListeners
• 一瞬Listenがなくなる
• アトミックな操作ではない
• 各Instanceにnginxを配置
• ポートフォワーダー
• 新旧アトミックな切替ができる
• 全インスタンスに操作が必要

docker(cgroup) statistics

詳細を知りたいならkernelをggrks:facepunch:

• ホスト側からモニタリング
• cgroupのレポートを利用(/sys/fs/cgroup)
• blkio,cpu,deviesなどのサブシステム
• cpu使用率
• /sys/fs/cgroup/cpuacct/docker/{container id}/cpuacct.stat
• メモリ使用率
• /sys/fs/cgroup/memory/docker/{container id}/memory.stat
• Mackerel
• 営業内容:ghost:

LTのスライド

http://jawsug-container.connpass.com/event/18943/presentation/

LT 1 「Dockerマトリョーシカ」

❗❗❗後でスライドが公開される❗❗❗

Docker + CI

• 依存関係や管理がめちゃくちゃになる
• docker素晴らしい:two_hearts:

LT 2 「同じサービスをECSとOpsWorksで運用してみた」

docker-compose

• awsでdocker使うならESCでしょ:exclamation:

• ECS構築

• docker起動が早い

• build,push,pullが遅い

• CIはJenkins

• コンテナのメトリクスは自分でやらないといけない

• インスタンスのスケールは自動だけど、サービスのスケールは自前じゃないといけない