Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
現実世界でのコンテナの運び方
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Kazuma Watanabe
March 13, 2018
Programming
1.2k
3
Share
現実世界でのコンテナの運び方
JAWS-UG コンテナ支部 #11
Kazuma Watanabe
March 13, 2018
More Decks by Kazuma Watanabe
See All by Kazuma Watanabe
Terraform言語の静的解析 / static analysis of Terraform language
wata727
1
160
SmartHRにおけるBiTemporal Data Modelの実践のその後 / After the practice of BiTemporal Data Model in SmartHR
wata727
1
3.8k
PHPを検査するPHPを書く / Write PHP inspection by PHP
wata727
1
2.4k
快適なコードレビューを目指して / For a comfortable code review
wata727
1
700
Lintの付き合い方とPahoutのご紹介
wata727
0
210
Querlyで始めるコードレビューの自動化
wata727
2
480
コンテナをSpot Fleetで起動するという選択肢
wata727
2
1.1k
エンジニア向けSaaSを支えるInfrastructure as Code
wata727
5
2.5k
SideCIのインフラ構築を自動化した話
wata727
1
2.2k
Other Decks in Programming
See All in Programming
キャリア迷子上等 ─ "ない道"は自分で作ればいい
16bitidol
2
230
「エンジニアインターン、どうやって取った?」準備のリアルを語るLT会 Progate BAR
akiomatic
0
120
Copilot CLI の継戦能力を高める コンテキスト管理
nozomutu
1
1.2k
PHPで使える日時の表現と、その知り方 #frontend_phpcon_do
o0h
PRO
0
180
Migrations : C'est une question d'hygiène !
vinceamstoutz
0
3.2k
TSKaigi 2026 TypeScriptバックエンドのオブザーバビリティ戦略 — Datadog × NestJSの実践
taiseiyamamotoan
2
270
jQueryをバージョンアップする前に使いたいjQuery Migrate
matsuo_atsushi
0
170
SPMマルチモジュールで テストカバレッジを取得する技法
yosshi4486
0
140
AI 時代のソフトウェア設計の学び方
masuda220
PRO
29
12k
CLIであることを活かしたGitHub Copilot CLI活用術 / GitHub Copilot CLI Pro Tips & Tricks
nao_mk2
1
1.2k
AIエージェントと協働するCLI開発 — BunとOpenClawで学んだこと
yoshikouki
1
230
技術記事、AIに書かせるか、自分で書くか? 〜それでも私が自分の手で書く理由〜 / #QiitaConference
jnchito
2
1.3k
Featured
See All Featured
Between Models and Reality
mayunak
4
320
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.3k
HTML-Aware ERB: The Path to Reactive Rendering @ RubyCon 2026, Rimini, Italy
marcoroth
1
140
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
1.1k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
160
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
160
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
1.1k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
430
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
30k
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
0
310
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Transcript
現実世界での コンテナの運び方 @wata727 Mar 13, 2018 JAWS-UG コンテナ支部#11
Question
本番でコンテナ使ってますか?
なぜ我々は(苦労して)コンテナを運ぶのか • コンテナを使うから、どうやってイメージをビルドするか、とか、 どうやってデプロイするのか、を考えなくてはいけなくなる • rsyncでソースコードばらまく、じゃダメ?
なぜ我々は(苦労して)コンテナを運ぶのか • コンテナを使うから、どうやってイメージをビルドするか、とか、 どうやってデプロイするのか、を考えなくてはいけなくなる • rsyncでソースコードばらまく、じゃダメ? ⇛コンテナで解決する課題がある
アジェンダ • デプロイに求められるもの • Dockerイメージをどう作るか • どうやってECSにコンテナを配置するか
デプロイに求められるもの
デプロイに求められるもの • 信頼性 • ロールバックの容易さ
信頼性 • 安全に新しいアプリケーションを配置できること ◦ その際に、サービスダウンなどを伴わないこと • デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り 替わること
信頼性 • 安全に新しいアプリケーションを配置できること ◦ その際に、サービスダウンなどを伴わないこと • デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り 替わること コンテナ以前: Graceful
Restart
信頼性 • 安全に新しいアプリケーションを配置できること ◦ その際に、サービスダウンなどを伴わないこと • デプロイしたら、ちゃんとすぐに新しいアプリケーションに切り 替わること コンテナ以前: Graceful
Restart コンテナ時代: Rolling Deployment
ロールバックの容易さ • 問題があったら、すぐに前のバージョンに戻せること ◦ 言語やOSのバージョンを上げるとか
ロールバックの容易さ • 問題があったら、すぐに前のバージョンに戻せること ◦ 言語やOSのバージョンを上げるとか コンテナ以前: Golden Image
ロールバックの容易さ • 問題があったら、すぐに前のバージョンに戻せること ◦ 言語やOSのバージョンを上げるとか コンテナ以前: Golden Image コンテナ時代: Rolling
Deployment
デプロイに求められるもの • 信頼性 • ロールバックの容易さ
現実世界でのデプロイに求められるもの • 信頼性 • ロールバックの容易さ • 早さ • 簡単さ •
管理の容易さ
早さ • デプロイが遅いとデプロイに抵抗感が生まれる ◦ デプロイに30分かかるとかだと「夜も遅いし、デプロイは明 日に...」とかなる
簡単さ • デプロイの手順は簡単であるべき ◦ 手順が増えると、デプロイできる人が限られてしまう ◦ プルリクエストをマージしたり、git pushしたらすぐデプロイ できるくらいの方が良い
管理の容易さ • 快適なデプロイを維持するためのコストが高いと大変 • デプロイサーバとか持ち始めると、その面倒を見る必要があ る...
Dockerイメージをどう作るか
Dockerイメージをどう作るか • Jenkinsでビルド • Travis CIとかCodeBuildでビルド
Jenkins GitHubのWebhookを受けてジョブを実行 • Pros ◦ サーバがあるので、大体なんでもできる • Cons ◦ サーバがあるので辛い
Jenkins GitHubのWebhookを受けてジョブを実行 • Pros ◦ サーバがあるので、大体なんでもできる • Cons ◦ サーバがあるので辛い
◦ 管理の容易さ☓
Travis CIやCodeBuild masterの更新をhookしてジョブを実行 • Pros ◦ サーバ不要 • Cons ◦
イメージのキャッシュが効かないのでビルドが遅い
Travis CIやCodeBuild masterの更新をhookしてジョブを実行 • Pros ◦ サーバ不要 • Cons ◦
イメージのキャッシュが効かないのでビルドが遅い ◦ 早さ☓
キャッシュが効かない? 実はいくつかやりようがある
docker save/load • saveでtarを吐けるので、それをキャッシュしてloadすれば良い • CodeBuildでもファイルキャッシュが使える ◦ https://aws.amazon.com/jp/blogs/devops/how-to-enable-caching-for-aws- codebuild/
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
どうやってECSにコンテナを配置するか
どうやってECSにコンテナを配置するか • docker runとか直接できないのでAPI経由になる • APIを叩くツールは山ほどある • https://github.com/nathanpeck/awesome-ecs ◦ ここにあるだけで14種類
◦ ecs-deployという名前だけで4つある ◦ みんなが使う定番っぽいものは無い...
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
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
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
より早いデプロイのために • 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
大変じゃないですか? • ここまでにアプリケーション独自の事情はほとんどなし ◦ では、もっと汎用的な基盤を作れるのでは? • 例えば... ◦ git pushしたら雑にデプロイしてほしい
◦ EC2足りないからスケールアウトできないとか考えたくない
Herogate • https://github.com/wata727/herogate ◦ Heroku + AWS Fargate • Heroku
likeな操作でAWSのマネージドなサービスを操作でき るようになれば、裏側で何が起きているのか考えなくても済む のでは?という実験 • herogate createでCFn経由でCodePipeline, CodeBuild, CodeCommit, Fargate, ALBを全部作る
構成図
課題1: createが遅い • herogate createの裏側はCFnのcreate stackなので5分くら いかかる • heroku createは5秒くらいで終わるよ!
課題2: デプロイが遅い • git pushして変更検知して、CodeBuildが走って、ECSの更新 完了までにかかる時間が10分 • デプロイに10分はちょっと厳しいでしょ...
まとめ • コンテナのデプロイは複雑だが、複雑さを受け入れるだけの 価値がコンテナにはある • 現実的にはデプロイの早さやビルドサーバのメンテなど、考え るべき問題もあるが、各位工夫して頑張りましょう • 銀の弾丸は無いです