Docker Composeによるローカル環境構築をやめた理由5選

概要

データベース、API、フロントエンドサーバーという標準的な三層アーキテクチャの構成のアプリケーションにおいて
Docker Composeを使って一発でローカル環境構築ができるようにしていたが、それをやめた理由を紹介する。

1番大きな理由はこれである。

まず、Docker Composeを用いて本番環境を運用することは稀である。

AWSを例に取ると、1つのDockerfileを使って1つのECSにデプロイすることがほとんどである。

つまり
Docker Composeをいくら頑張って作ったとしても、本番環境でその設定を活かすことができない。

後述するコストがかかるにも関わらず、
本番環境の運用や品質に何も貢献することがないので、無駄だと判断した。

※本番環境でDocker Composeを使う構成は可能だが、無停止リリース作業が複雑になるなど他の問題があるのであまり実用的ではない。

普通にローカル環境で立ち上げたアプリケーションと、ローカル環境にDockerコンテナを使って立ち上げたアプリケーションでは
デバッガーの設定に関して複雑さが全く異なる。

ローカル環境で npm run devして起動するようなアプリケーションでは
複雑な設定は不要でVSCodeからブレークポイントを貼ることができる。
（せいぜい拡張機能のインストールくらい）

一方で、コンテナ内で起動しているアプリケーションにブレークポイントを貼るためには

という新たな追加手順が必要になる。

「ローカル開発時にブレークポイントを貼る」という作業は
全エンジニアが開発時にやりたい作業だと思うが、それに対して追加の手間が必要になるわけである。

Dockerコンテナの前提として「コンテナ上で動いているコードは、ローカルPCにあるコードのコピー」である。

つまり、何も設定しない状態では
ローカルのコードを修正してもDockerコンテナで動いているアプリケーションには反映されない。

これによって、ホットリロードを行うためにはどちらかの工夫が必要になる。

ただし、それぞれ以下のような課題がある。

Docker Composeでは

を行うためには、専用の設定が必要である。

ローカルで npm run devして立ち上げたアプリケーションには、 localhostで大体接続可能であるが
Docker Composeを使っている場合はそうはいかない。

コンテナ同士の通信を行うためには、 Docker Compose.yml に公開ポートの明記が必要であり、
コンテナからホストマシンへ接続する場合は host.docker.internalを用いて接続する必要がある。

普通にアプリケーションを立ち上げることと比較して
Dockerイメージのダウンロードやコンテナの起動などが発生するため、処理が重くなることは当然である。

開発中に必ずPCのファンの音が聞こえる状態である。

上記の理由が適用されるのはアプリケーションに関してであり、
データベースに関してはDocker単体もしくはDocker Composeを使っている。

理由は以下の通りだ。

とはいえ、
「Dockerコンテナを使うとpyenv、nvm、rbenv、sdkmanなどの環境構築や、
それを使ったバージョン切り替えをわざわざ行わなくていいので、それが嬉しいんだ！」という人もいると思う。

そんな人は Home | mise-en-place を使ってみてはいかがだろうか。

Docker Composeは複数コンテナをまとめて取り扱える素晴らしい技術であるが、
ローカル環境構築のために利用するには、費用対効果が見合っていないと感じた。