Vagrantから脱出せよ!!Docker化 Go!!Go!!(2)
コンテナの振り分け
Vagrant環境でmobiconnectは実装されたもの以外にもいろんなデーモン(daemon)やサービスで構成されている。
- Java言語で実装された大きく3種類のサービス
- Ruby言語で実装された大きく2種類のサービス
- DB
- memcached
- DNS(bind9)
- nginx
- activemq
このサービスを全部別々のコンテナにするとリソースの無駄と、個人的な意見であるが逆に管理の利便性がなくなるところもあると考えている。
考慮点
実装バージョンの観点
JavaとRubyで実装された各サービスはメジャーリリースでは同じバージョン番号でリリースされるのが一般的で、検証では特に他バージョンとの整合性をテストする必要もない。
現在Vagrant環境ではホストOSでgit管理されているソースをゲストOSと同期することでVMで動いているバージョンを管理するので、Dockerイメージを提供する時のみを考慮すれば良い。
リソースの観点
前の記事で話した様にVagrantでは一つのVMで動いているので、サービス毎にどのくらいのCPUやメモリが必要なのかが分からない。🤦
現在利用中のVagrantの設定はこちら。👀👀👀
config.vm.provider :virtualbox do |vb|
# Customize the amount of memory on the VM:
vb.cpus = 2
vb.memory = 6144
...
end
Docker Composeの設定ではCPUを少数点で設定出来た認識。
cpus: 0.5
Dockerの使用観点
公開されたDockerイメージを利用して各自サービスを別コンテナにした場合、構築する時の時間短縮やリソースの細かい管理、endpointとログの利用利点を活かせるが、以下の問題点もあるので検討が必要。
- 適切なDockerイメージがあるか
- endpointやdepends_onで各サービスの起動チェックや依存関係の操作が可能か
- Dockerでもコンテナが多くなるとメモリなどの使用量が増える
- 作成されるイメージをregistryで管理する場合、イメージ数が少ない方が良い
最終的な構成案
mobiconnectコンテナ
含めるサービス
- Java言語で実装された大きく3種類のサービス
- Ruby言語で実装された大きく1種類のサービス
理由
サービスの起動順を調整する必要があり、コンテナ自体の起動調整(depends_on
)だけではなく内部サービスでの調整が必要。現在Vagrantでは手動で起動している。
また、イメージしてregistryを利用した管理やイメージ配布することを考えると同じイメージに入れるのが良い。
DBコンテナ
含めるサービス
- Mysql
理由
DBのバージョンの変更する可能性もあり、他のサービスに依存されないため。
ただ、Appleチップも対応することでdocker-compose.ymlやイメージの選別が必要。
Daemonコンテナ
以下の開発対象外のサービスを一つのコンテナで構成する。
含めるサービス
- memcached
- DNS(bind9)
- nginx(reverse-proxy)
- activemq
理由
バージョンや役割の変更が低い物で、イメージ管理する観点で一つにまとめた方が利便性が良い、かつサービス自体のバックアップが特に必要ない。
でも、ベースはnginxのイメージにする想定でOSがalpineかdebianになると思うので、そのOSで他のdaemonがインストール可能かの検証が必要。
Discussion