現実世界でのコンテナの運び方
by
Kazuma Watanabe
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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
まとめ ● コンテナのデプロイは複雑だが、複雑さを受け入れるだけの 価値がコンテナにはある ● 現実的にはデプロイの早さやビルドサーバのメンテなど、考え るべき問題もあるが、各位工夫して頑張りましょう ● 銀の弾丸は無いです