2025年時点で、コンテナ化は現代のソフトウェア開発とデプロイの業界標準になっている。
以下の開発コンテナ化に関する主張は、シンプルかつ率直です。
個人的なフィードバック
- 制御された再現可能な環境でコードを実行することで、いわゆる“works on my machine”問題によるズレをなくす。
- OSを汚さずに、本番やチームメイトと同じスタックを使える。
- 競合するバージョンの複数プロジェクトもクリーンに切り替えて扱える。
docker compose up -d は、データベース、キュー、Webサーバーを手作業でインストール・設定するより速い。- ラップトップやOSを替えても関係ない。イメージをプルして実行するだけ。
これまでのやり方での問題を解決する点
- 環境ドリフト: 本番にはないローカルでの隠れた調整、IDEプラグインの自動インストール、または本番に存在しない開いているポート。
- ホスト上の依存関係地獄: ツールチェーンの衝突、パッケージのアップグレードが他のプロジェクトを壊す。
- オンボーディングの摩擦: 設定手順の抜け、古いドキュメント、属人的な知識。
- 再現の難しさ: 散らかったホストでは、テスト/本番のバグ再現は当てにならない。
- 企業の制約: デスクトップにビルドツールをインストールする権限が限られている。
- クリーンな終了:
containers stop。ポートやCPUを占有し続けるデーモンが残らない。
tale