現実世界でのコンテナの運び方

JAWS-UG コンテナ支部 #11

Transcript

1. 現実世界での
   コンテナの運び方
   @wata727
   Mar 13, 2018 JAWS-UG コンテナ支部#11
   

   View Slide

2. Question
   

   View Slide

3. 本番でコンテナ使ってますか？
   

   View Slide

4. なぜ我々は(苦労して)コンテナを運ぶのか
   ● コンテナを使うから、どうやってイメージをビルドするか、とか、
   どうやってデプロイするのか、を考えなくてはいけなくなる
   ● rsyncでソースコードばらまく、じゃダメ？
   

   View Slide

5. なぜ我々は(苦労して)コンテナを運ぶのか
   ● コンテナを使うから、どうやってイメージをビルドするか、とか、
   どうやってデプロイするのか、を考えなくてはいけなくなる
   ● rsyncでソースコードばらまく、じゃダメ？
   ⇛コンテナで解決する課題がある
   

   View Slide

6. アジェンダ
   ● デプロイに求められるもの
   ● Dockerイメージをどう作るか
   ● どうやってECSにコンテナを配置するか
   

   View Slide

7. デプロイに求められるもの
   

   View Slide

8. デプロイに求められるもの
   ● 信頼性
   ● ロールバックの容易さ
   

   View Slide

9. 信頼性
   ● 安全に新しいアプリケーションを配置できること
   ○ その際に、サービスダウンなどを伴わないこと
   ● デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り
   替わること
   

   View Slide

10. 信頼性
    ● 安全に新しいアプリケーションを配置できること
    ○ その際に、サービスダウンなどを伴わないこと
    ● デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り
    替わること
    コンテナ以前: Graceful Restart
    

    View Slide

11. 信頼性
    ● 安全に新しいアプリケーションを配置できること
    ○ その際に、サービスダウンなどを伴わないこと
    ● デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り
    替わること
    コンテナ以前: Graceful Restart
    コンテナ時代: Rolling Deployment
    

    View Slide

12. ロールバックの容易さ
    ● 問題があったら、すぐに前のバージョンに戻せること
    ○ 言語やOSのバージョンを上げるとか
    

    View Slide

13. ロールバックの容易さ
    ● 問題があったら、すぐに前のバージョンに戻せること
    ○ 言語やOSのバージョンを上げるとか
    コンテナ以前: Golden Image
    

    View Slide

14. ロールバックの容易さ
    ● 問題があったら、すぐに前のバージョンに戻せること
    ○ 言語やOSのバージョンを上げるとか
    コンテナ以前: Golden Image
    コンテナ時代: Rolling Deployment
    

    View Slide

15. デプロイに求められるもの
    ● 信頼性
    ● ロールバックの容易さ
    

    View Slide

16. 現実世界でのデプロイに求められるもの
    ● 信頼性
    ● ロールバックの容易さ
    ● 早さ
    ● 簡単さ
    ● 管理の容易さ
    

    View Slide

17. 早さ
    ● デプロイが遅いとデプロイに抵抗感が生まれる
    ○ デプロイに30分かかるとかだと「夜も遅いし、デプロイは明
    日に...」とかなる
    

    View Slide

18. 簡単さ
    ● デプロイの手順は簡単であるべき
    ○ 手順が増えると、デプロイできる人が限られてしまう
    ○ プルリクエストをマージしたり、git pushしたらすぐデプロイ
    できるくらいの方が良い
    

    View Slide

19. 管理の容易さ
    ● 快適なデプロイを維持するためのコストが高いと大変
    ● デプロイサーバとか持ち始めると、その面倒を見る必要があ
    る...
    

    View Slide

20. Dockerイメージをどう作るか
    

    View Slide

21. Dockerイメージをどう作るか
    ● Jenkinsでビルド
    ● Travis CIとかCodeBuildでビルド
    

    View Slide

22. Jenkins
    GitHubのWebhookを受けてジョブを実行
    ● Pros
    ○ サーバがあるので、大体なんでもできる
    ● Cons
    ○ サーバがあるので辛い
    

    View Slide

23. Jenkins
    GitHubのWebhookを受けてジョブを実行
    ● Pros
    ○ サーバがあるので、大体なんでもできる
    ● Cons
    ○ サーバがあるので辛い
    ○ 管理の容易さ☓
    

    View Slide

24. Travis CIやCodeBuild
    masterの更新をhookしてジョブを実行
    ● Pros
    ○ サーバ不要
    ● Cons
    ○ イメージのキャッシュが効かないのでビルドが遅い
    

    View Slide

25. Travis CIやCodeBuild
    masterの更新をhookしてジョブを実行
    ● Pros
    ○ サーバ不要
    ● Cons
    ○ イメージのキャッシュが効かないのでビルドが遅い
    ○ 早さ☓
    

    View Slide

26. キャッシュが効かない？
    実はいくつかやりようがある
    

    View Slide

27. docker save/load
    ● saveでtarを吐けるので、それをキャッシュしてloadすれば良い
    ● CodeBuildでもファイルキャッシュが使える
    ○ https://aws.amazon.com/jp/blogs/devops/how-to-enable-caching-for-aws-
    codebuild/
    

    View Slide

28. 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
    

    View Slide

29. どうやってECSにコンテナを配置するか
    

    View Slide

30. どうやってECSにコンテナを配置するか
    ● docker runとか直接できないのでAPI経由になる
    ● APIを叩くツールは山ほどある
    ● https://github.com/nathanpeck/awesome-ecs
    ○ ここにあるだけで14種類
    ○ ecs-deployという名前だけで4つある
    ○ みんなが使う定番っぽいものは無い...
    

    View Slide

31. 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
    

    View Slide

32. 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
    

    View Slide

33. 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
    

    View Slide

34. より早いデプロイのために
    ● 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
    

    View Slide

35. 大変じゃないですか？
    ● ここまでにアプリケーション独自の事情はほとんどなし
    ○ では、もっと汎用的な基盤を作れるのでは？
    ● 例えば...
    ○ git pushしたら雑にデプロイしてほしい
    ○ EC2足りないからスケールアウトできないとか考えたくない
    

    View Slide

36. Herogate
    ● https://github.com/wata727/herogate
    ○ Heroku + AWS Fargate
    ● Heroku likeな操作でAWSのマネージドなサービスを操作でき
    るようになれば、裏側で何が起きているのか考えなくても済む
    のでは？という実験
    ● herogate createでCFn経由でCodePipeline, CodeBuild,
    CodeCommit, Fargate, ALBを全部作る
    

    View Slide

37. 構成図
    

    View Slide

38. 課題1: createが遅い
    ● herogate createの裏側はCFnのcreate stackなので5分くら
    いかかる
    ● heroku createは5秒くらいで終わるよ！
    

    View Slide

39. 課題2: デプロイが遅い
    ● git pushして変更検知して、CodeBuildが走って、ECSの更新
    完了までにかかる時間が10分
    ● デプロイに10分はちょっと厳しいでしょ...
    

    View Slide

40. まとめ
    ● コンテナのデプロイは複雑だが、複雑さを受け入れるだけの
    価値がコンテナにはある
    ● 現実的にはデプロイの早さやビルドサーバのメンテなど、考え
    るべき問題もあるが、各位工夫して頑張りましょう
    ● 銀の弾丸は無いです
    

    View Slide