コミケの列に並んでたあたりのころから Docker 本格的に使ってます。このサイトもさっき Docker でデプロイするような感じにしました。
Docker の利点と欠点で
みたいな意見をわりと頻繁にみかけるのですが、逆じゃねえかと思ってます。これ開発環境の配布に使うの無理でしょ。各コンテナ使い捨て前提なんだし。
Docker をデプロイに使う際の問題点としては以下があります
一個目に関しては頑張ってください。僕はセットアップ用やデプロイ用のシェルスクリプトを ADD して RUN させるようにしてます。シェルスクリプトセットアップ + デプロイとかまだ恐竜が歩いていたころのやり方のような気がしますが、コンテナは使い捨てという前提の Docker ではこのやり方が至って実用的です。
ビルドに時間がかかる問題はビルドを分割 + 差分ビルドの導入で実現できます。
にをそれぞれ作ります。ベースコンテナは一週間に 1 回ぐらいビルドして、アプリケーションコンテナは毎日ビルドして、差分コンテナはデプロイのタイミングでビルドします。
そうすればアプリコンテナのビルドは数分で、差分コンテナは bundle update してなければ数十秒ぐらいでビルドできるようになるのでストレスが減ります。
コンテナの管理は普通 docker-registry を使うんでしょうがあれなんかセットアップダルい割に利点を感じない(上記の差分ビルドの仕組みがあると特に)ので特にやってません。
リバースプロキシの設定は docker inspect の結果から nginx の設定を生成して送りつけるというのをやってます。
あとは「差分のビルド + nginx の設定」みたいのを CI ツールにテストの成功後にやらせるようにすればよい感じです。
シェルスクリプトでセットアップとデプロイが実用的に出来るようになるというのがデカいと感じます。
chef やら puppet やらのプロビショニングツールや、 Capistrano のようなデプロイツールは同じサーバーをずっと使い続けることを前提に複雑な仕組みが採られています。しかし Docker では各コンテナは短いサイクルで使い捨てられていきますから、上記のような差分ビルドのような仕組みを導入した場合にしてもだいたい全部シェルスクリプトセットアップでなんとかなります。
Chef と Capistrano で頑張ってたときより見通しよくなってると思います。