Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

JAWS-UG コンテナ支部 #11

Kazuma Watanabe

March 13, 2018
Tweet

More Decks by Kazuma Watanabe

Other Decks in Programming

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