Docker Compose の構成について
Docker は image が手元にあれば一瞬でサービスを立ち上げることができるので主に開発環境として便利に使ってます。
Docker のベストプラクティスとして “one process per container” が上げられており、一つのシステムを立ち上げるのにコンテナが複数必要になることもよくありますね。コンテナ間の連携は、レガシーな Link 機能で一つずつ繋げていた時代から進化し、Docker Network 機能で独自のネットワークを構成できるようになりました。そして、Docker Compose でコンテナを一気に立ち上げ、システムを構成できます。
で、今この Docker Compose の構成について悩んでいます。こんなとこかなという案をいくつか上げておくので、運用してみて後日談を後ほどまとめたいと思います。机上の空論なので、間違ってるところがあるかも。
- Dockerfile 置き場案
- Docker プロジェクト内包案
- Image 取り込み案
a. Dockerfile 置き場案
SPA なシステムで MySQL にデータを突っ込むようなものを想定しています。
. ├── README.md ├── docker-compose.yml ├── dockerfiles/ │ ├── Dockerfile_api # <- API 実行環境 │ ├── Dockerfile_front # <- フロントエンドアプリビルド環境 │ ├── Dockerfile_proxy # <- Web サーバ │ └── Dockerfile_mysql # <- MySQL (公式の MySQL イメージでいいかも) └── volumes/ ├── app_source/ # <- API のソースコード ├── front_dist/ # <- ビルドされたフロントエンドアプリの出力先 └── data_volume/ # MySQL のデータディレクトリ
- Dockerfile 1枚だけのコンテナばかりならこれでよさそう
- ソースコードは別途 Git 管理されてて
git clone http://github/ikosin/some-app volumes/app_source
する想定
b. Docker プロジェクト内包案
. ├── README.md ├── docker-compose.yml ├── api/ │ ├── Dockerfile # <- API 実行環境 │ └── source/ # <- API のソースコード ├── front/ │ ├── Dockerfile # <- フロントエンドアプリビルド環境 │ └── dist/ # <- ビルドされたフロントエンドアプリの出力先 ├── proxy/ │ └── Dockerfile # <- Web サーバ └── mysql/ ├── Dockerfile # <- MySQL (公式の MySQL イメージでいいかも) └── data/ # MySQL のデータディレクトリ
- だいたいどんなコンテナでも対応できるように分けた構成で、これが王道な気がする
- ソースコードはどう管理しましょうかね……。Git のサブモジュールにしておくと次の Image 取り込み案に移行するのも簡単でいいかもしれません
(追記)
こちらのブログではこのパターンを採用してそうですね。ソースコードもモノリポで一緒に管理してるんでしょうか。 複数の rails プロジェクトが共存する開発環境を Docker 化した話を晒してみる · カウル Tech Blog
c. Image 取り込み案
. ├── README.md └── docker-compose.yml
- ソースコード管理しているリポジトリに Dockerfile も突っ込んでそっちで Image ビルドしてしまいましょう案
- Docker イメージのプライベートリポジトリが欲しくなるけど、無くても各サーバで各イメージをビルドすればなんとかなる
- すごい薄い機能のコンテナをわざわざ切り離すのも面倒かもしれないけど、汎用性を意識するようになっていいかも
やってみる
上からお手軽な順にあげてみたつもりです。
現在、CONBU は CONBU-API の実行環境を Docker 化しようと現在進めている所なので、ひとまず上からやってみてフィードバックもらいたいと思います。