Share
Embed
Slide 1
Slide 1 text
現実世界での
コンテナの運び方
@wata727
Mar 13, 2018 JAWS-UG コンテナ支部#11
Slide 2
Slide 2 text
Question
Slide 3
Slide 3 text
本番でコンテナ使ってますか？
Slide 4
Slide 4 text
なぜ我々は(苦労して)コンテナを運ぶのか
● コンテナを使うから、どうやってイメージをビルドするか、とか、
どうやってデプロイするのか、を考えなくてはいけなくなる
● rsyncでソースコードばらまく、じゃダメ？
Slide 5
Slide 5 text
なぜ我々は(苦労して)コンテナを運ぶのか
● コンテナを使うから、どうやってイメージをビルドするか、とか、
どうやってデプロイするのか、を考えなくてはいけなくなる
● rsyncでソースコードばらまく、じゃダメ？
⇛コンテナで解決する課題がある
Slide 6
Slide 6 text
アジェンダ
● デプロイに求められるもの
● Dockerイメージをどう作るか
● どうやってECSにコンテナを配置するか
Slide 7
Slide 7 text
デプロイに求められるもの
Slide 8
Slide 8 text
デプロイに求められるもの
● 信頼性
● ロールバックの容易さ
Slide 9
Slide 9 text
信頼性
● 安全に新しいアプリケーションを配置できること
○ その際に、サービスダウンなどを伴わないこと
● デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り
替わること
Slide 10
Slide 10 text
信頼性
● 安全に新しいアプリケーションを配置できること
○ その際に、サービスダウンなどを伴わないこと
● デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り
替わること
コンテナ以前: Graceful Restart
Slide 11
Slide 11 text
信頼性
● 安全に新しいアプリケーションを配置できること
○ その際に、サービスダウンなどを伴わないこと
● デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り
替わること
コンテナ以前: Graceful Restart
コンテナ時代: Rolling Deployment
Slide 12
Slide 12 text
ロールバックの容易さ
● 問題があったら、すぐに前のバージョンに戻せること
○ 言語やOSのバージョンを上げるとか
Slide 13
Slide 13 text
ロールバックの容易さ
● 問題があったら、すぐに前のバージョンに戻せること
○ 言語やOSのバージョンを上げるとか
コンテナ以前: Golden Image
Slide 14
Slide 14 text
ロールバックの容易さ
● 問題があったら、すぐに前のバージョンに戻せること
○ 言語やOSのバージョンを上げるとか
コンテナ以前: Golden Image
コンテナ時代: Rolling Deployment
Slide 15
Slide 15 text
デプロイに求められるもの
● 信頼性
● ロールバックの容易さ
Slide 16
Slide 16 text
現実世界でのデプロイに求められるもの
● 信頼性
● ロールバックの容易さ
● 早さ
● 簡単さ
● 管理の容易さ
Slide 17
Slide 17 text
早さ
● デプロイが遅いとデプロイに抵抗感が生まれる
○ デプロイに30分かかるとかだと「夜も遅いし、デプロイは明
日に...」とかなる
Slide 18
Slide 18 text
簡単さ
● デプロイの手順は簡単であるべき
○ 手順が増えると、デプロイできる人が限られてしまう
○ プルリクエストをマージしたり、git pushしたらすぐデプロイ
できるくらいの方が良い
Slide 19
Slide 19 text
管理の容易さ
● 快適なデプロイを維持するためのコストが高いと大変
● デプロイサーバとか持ち始めると、その面倒を見る必要があ
る...
Slide 20
Slide 20 text
Dockerイメージをどう作るか
Slide 21
Slide 21 text
Dockerイメージをどう作るか
● Jenkinsでビルド
● Travis CIとかCodeBuildでビルド
Slide 22
Slide 22 text
Jenkins
GitHubのWebhookを受けてジョブを実行
● Pros
○ サーバがあるので、大体なんでもできる
● Cons
○ サーバがあるので辛い
Slide 23
Slide 23 text
Jenkins
GitHubのWebhookを受けてジョブを実行
● Pros
○ サーバがあるので、大体なんでもできる
● Cons
○ サーバがあるので辛い
○ 管理の容易さ☓
Slide 24
Slide 24 text
Travis CIやCodeBuild
masterの更新をhookしてジョブを実行
● Pros
○ サーバ不要
● Cons
○ イメージのキャッシュが効かないのでビルドが遅い
Slide 25
Slide 25 text
Travis CIやCodeBuild
masterの更新をhookしてジョブを実行
● Pros
○ サーバ不要
● Cons
○ イメージのキャッシュが効かないのでビルドが遅い
○ 早さ☓
Slide 26
Slide 26 text
キャッシュが効かない？
実はいくつかやりようがある
Slide 27
Slide 27 text
docker save/load
● saveでtarを吐けるので、それをキャッシュしてloadすれば良い
● CodeBuildでもファイルキャッシュが使える
○ https://aws.amazon.com/jp/blogs/devops/how-to-enable-caching-for-aws-
codebuild/
Slide 28
Slide 28 text
docker build --cache-from
● 都度pullして--cache-fromで指定すれば、Jenkinsでbuildする
のと同じようにキャッシュを効かせられる
● 大きいイメージだとpullに時間がかかるのが問題だが...
$ docker pull your-app:latest
$ docker build -t ${TAG} --cache-from your-app:latest .
$ docker tag your-app:${TAG} your-app:latest
$ docker push your-app:${TAG}
$ docker push your-app:latest
Slide 29
Slide 29 text
どうやってECSにコンテナを配置するか
Slide 30
Slide 30 text
どうやってECSにコンテナを配置するか
● docker runとか直接できないのでAPI経由になる
● APIを叩くツールは山ほどある
● https://github.com/nathanpeck/awesome-ecs
○ ここにあるだけで14種類
○ ecs-deployという名前だけで4つある
○ みんなが使う定番っぽいものは無い...
Slide 31
Slide 31 text
Amazon ECS CLI (おすすめ)
● https://github.com/aws/amazon-ecs-cli
● docker-compose likeにデプロイできる
○ ローカルではdocker-composeで大体検証可能
● ecs-cli compose runでワンオフも可能
● スケールアウトもできる
$ ecs-cli compose service up
$ ecs-cli compose run oneoff bundle exec rake db:migrate
$ ecs-cli compose service scale 2
Slide 32
Slide 32 text
Cronジョブの配置
● サーバーは無いので、従来のcronは使えない
● Railsならresque-schedulerとかを使う手もある
○ https://github.com/resque/resque-scheduler
● ECSのScheduled Tasksが代わりに使える
○ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/schedu
led_tasks.html
Slide 33
Slide 33 text
Amazon ECS CLI + Elastic Whenever
● https://github.com/wata727/elastic_whenever
○ Rubyで書かれたschedule.rbからScheduled Tasksを生
成する
● ecs-cliで最新のTask Definitionを作って、それを元に
Scheduled Tasksを更新する
$ ecs-cli compose create cronjob
$ elastic_whenever -i myapp
Slide 34
Slide 34 text
より早いデプロイのために
● ALBのderegistration delay
○ https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/applicatio
n/load-balancer-target-groups.html#deregistration-delay
● ローリングデプロイ時に古いコンテナがALBから外れるのを待
つ時間
● デフォルト300秒だが、Herokuは50秒でタイムアウトするの
で、短くて良い場合も多い
○ https://devcenter.heroku.com/articles/request-timeout
Slide 35
Slide 35 text
大変じゃないですか？
● ここまでにアプリケーション独自の事情はほとんどなし
○ では、もっと汎用的な基盤を作れるのでは？
● 例えば...
○ git pushしたら雑にデプロイしてほしい
○ EC2足りないからスケールアウトできないとか考えたくない
Slide 36
Slide 36 text
Herogate
● https://github.com/wata727/herogate
○ Heroku + AWS Fargate
● Heroku likeな操作でAWSのマネージドなサービスを操作でき
るようになれば、裏側で何が起きているのか考えなくても済む
のでは？という実験
● herogate createでCFn経由でCodePipeline, CodeBuild,
CodeCommit, Fargate, ALBを全部作る
Slide 37
Slide 37 text
構成図
Slide 38
Slide 38 text
課題1: createが遅い
● herogate createの裏側はCFnのcreate stackなので5分くら
いかかる
● heroku createは5秒くらいで終わるよ！
Slide 39
Slide 39 text
課題2: デプロイが遅い
● git pushして変更検知して、CodeBuildが走って、ECSの更新
完了までにかかる時間が10分
● デプロイに10分はちょっと厳しいでしょ...
Slide 40
Slide 40 text
まとめ
● コンテナのデプロイは複雑だが、複雑さを受け入れるだけの
価値がコンテナにはある
● 現実的にはデプロイの早さやビルドサーバのメンテなど、考え
るべき問題もあるが、各位工夫して頑張りましょう
● 銀の弾丸は無いです