Dockerをどうやって使うべきか？また、使わないべきか

Dockerコンテナはどのように使うべきか悩みます。

①すべてDockerfileでデプロイ部分まで記述してしまう。 -> コンテナビルドする度に最新のアプリケーションをビルドして起動する 一番シンプルかつやりやすそうなパターン。Dockerコンテナをそのままプロダクション環境にデプロイすることが可能なのであればこのパターンを取るのが一番楽そうな気がします。現環境だと、Dockerはまだプロダクションで使うべきでないと、Dockerが公式で言っているので(去年の話だけど)まだ早い感じ。

②コンテナは環境構築だけですまして、Capistoranoなどのデプロイツールを使ってコンテナにデプロイする。 ->まあいわゆるステージング環境としてDockerコンテナを使うパターンでしょうか。アプリケーションに必要なプロビジョニングなんかはDockerfileに書いて済ましてしまう。アプリケーションはあとからデプロイツールで受け入れるような形にして、プロダクション環境には、デプロイツールでコンテナ使わずにデプロイする。

③コンテナはssh接続だけの最小構成にして、Chefなんかでプロビジョニングして、Capistoranoなどのデプロイツールでデプロイする。 ->めんどくさいことこの上ない。却下。Chefとか使ってまでべき等性を保つ必要性が感じられない。

問題点とか

①Dockerコンテナに静的にIPを割り振れないことかな？pipeworkとか使用すれば、特定のIPを割り振ることも可能だけども、Dockerが正式にサポートしていないし、DockerのMLでも非推奨だという記述を見かけたような気がする。開発環境において、Mysql,Redis,Solrなんかを別々のコンテナで起動して、Railsがそのコンテナのサーバーをバックエンドサービスとして使用する。みたいな構成にしようかと思っていたんだけど(これは、開発環境と本番環境をほぼ同一の環境にしたいという願望ゆえの試み)、静的にIP決めれないとなるとRailsの設定ファイルにIPべた書きも出来ないよなと。

解決策としては、まだ実験してないけれどもコンテナ起動時のオプションで-linkオプションを指定すると、環境変数にリンクされたコンテナのIPアドレスやらもろもろが現れるという仕様らしいので、RailsのIPの指定する部分を環境変数で割り当てるように変更するといった解決策か、と思案中。ただ、そうなってくると複雑になってしまいそうなのでそれもそれで本末転倒になってしまいますよね、と。

②Dockerコンテナ１つに全てのサービスを詰め込むべきか、それとも別々のコンテナに分離するべきか。

①とも関連してきますが、Mysql,Redis,Solr,Railsなんかを１つのコンテナに全部インストールして動かす戦略を取るべきか。それとも別々のコンテナにいれて動かすべきか。悩んでいます。 Twelve-Factor Appの考え方が素晴らしいと思っていて、その通りに実装をして行きたいと考えているので、それを考えると後者の戦略が適当になってくるはずだと思っています。しかしそうすると、開発を始めるってだけで色々と設定やら準備やら大変になってくるし、そもそもそんなにスケールするようなアプリあんた作れんの？（）みたいな話も出て来て、それなら普通にDocker使わずに開発環境構築した方が楽だしDocker使うメリット少ない。

もっとスマートな解決策がないか思案中。