Dockerを本番で使おうとして死んだ話

1. Docker in Production
PIZZA_JP #3
@rs_wisteria

2. Agenda
● Docker in Production
● Challenging Amazon ECS (2 years ago)
● Docker base blue-green deployment

3. Docker in Production

4. 夢の環境

5. 物理構成に
依存しない
とか

6. 環境構築が
楽そうだとか

7. サーバー資源
節約できそう
とか

8. デプロイが
簡単そうとか

9. 冗長化とか
強そうとか

10. そんな
イメージ

11. でした

12. 考え方の誤りに気づく
docker container = program + environment
なんだけど、なんとなく
lightweightなVMくらいの感じでいた

13. Docker化による影響
プログラムの副作用が見えなくなる
● ログとか
● 中間生成物のファイルとか
● その他環境に及ぼす影響など
明確に出力として定義する必要がある

14. 定義すること
● プログラムに渡す引数
● 公開するport番号
● 共有するファイル・ディレクトリ
● etc...

15. 本番環境で困ること
● 管理系のプログラムとの連携
○ 性能監視とか
○ ログローテートとか
○ etc.

16. Challenging Amazon
ECS
(2 years ago)

17. Amazon ECS
AWSのdockerコンテナサービス
● クラスターによるEC2インスタンスの管理
○ docker-machine, docker-swarmのお仕事
● タスク定義によるアプリケーションのdocker設定まとめ
○ docker-composeのお仕事
● AWS他サービスのインテグレーション
○ コンテナのLB対応等

18. Blue-Green Deployments
● 無停止デプロイ方法の一つ
○ Blue: 現在稼働しているインフラ系統
○ Green: デプロイ対象のインフラ系統
○ デプロイ完了後、LB等で稼働しているインフラをBlueから
Greenに切り替える
○ Blueはそのうち捨てる

19. DockerでのBlue-Green Deployment
コンテナレベルでBlue-Green Deploymentを実行
● デプロイ時に新しいコンテナを作成・起動
● 起動後にLBでアクセスを新しいコンテナへ向ける
● 古いコンテナを削除

20. Amazon ECSでの問題点
● コンテナ外での操作が多い
○ ECS上で制御する方法が無い
● デプロイ時にリソースを2倍必要とする
○ インスタンス上にデプロイ時のためだけに、常にリソースを
半分空けておく必要がある

21. 結局
ECSの利用を諦めた
● 全部シェルスクリプトで書いた
● そのうちリベンジしたい

22. Docker base
blue-green
deployments

23. 方針
● docker-composeでblue/greenを定義
○ デプロイ時にシェルスクリプトで頑張る
■ 現在起動している系統を調べる (blue or green)
■ 現在起動していない系統を立ち上げる
■ 立ち上げたコンテナのポート番号調べる
■ nginxの設定書き換えて再起動する
■ 古い系統を消す

24. ログローテート
ローテート前にプロセスにシグナル送ることが多い
→ pidが分からない問題
→ pidがコンテナ毎に独立しているため、pidファイル見ても意味が
無い
→ さらにローテートにプロセス再起動が必要な場合、コンテナが
終了する

25. ログローテート
● 諦めてcopytruncateで動かす
○ そもそもrailsのpuma使うと、シグナル渡しても駄目だし…
● 厳密さが必要ならばcloudwatch logsの採用を検
討しましょう

26. 冗長化
サーバー毎にblue-green deploymentする必要
● とても面倒
● リソース (EC2 instance)とコンテナを独立して管理するのが大
変
○ docker-swarmを使わざるを得ない
○ LB対応も自力で行う必要があり

27. Contribution

28. Docker in Production?
● 茨の道ではあるが出来る
○ 発想とシェルスクリプトの勝利
■ プロダクト毎に考えるのはさすがに面倒
○ 今ならECSでがっつり頑張る
■ ECRもサービスインしたことだし、privateなdocker registryからpullする仕
組みを作るのは格段に楽になった
■ 監視とかログとか全部AWSのサービスに投げよう
○ どちらにせよ、docker周辺の知識は結構いる
■ 無いなら無理にやらなくてもいいと思う