Dockerとは
Docker（ドッカー）は、アプリを「動かすのに必要な環境ごと」一つの箱に詰めて、どのコンピューターでも同じように動かせるようにする道具です。この箱のことをコンテナと呼びます。
前の章で、統合テストでは本物のデータベースを使いたい、という話をしました。Dockerを使うと、テストのたびに本番と同じデータベースを数秒で用意して、終わったら捨てる、ということが簡単にできます。この章では、その仕組みを図を動かしながら見ていきます。
テスト駆動開発とは ／ 全5章
Dockerとは
- 発行
- かえで
- 版
- 第2版
- 改訂
- 分量
- 8コマ・1,792字
「自分のPCでは動くのに」はなぜ起きるのか。アプリを動く環境ごと箱（コンテナ）に詰めるDockerの考え方を、Dockerfile・イメージ・コンテナの関係、どこでも同じに動く理由、テスト用データベースへの活用まで、図が動く形で解説します。
- Dockerとは
- アプリを「動く環境ごと」箱に詰めて、どこへでも運ぶ
- 荷物
- コンテナ
「自分のPCでは動くのに……」
開発の現場でよく聞くのが「自分のPCでは動くのに、サーバーに置いたら動かない」という悩みです。原因の多くは、コード以外の部分、つまり環境の違いです。
アプリはコードだけで動いているわけではありません。Node.jsのような実行環境、たくさんのライブラリ、OSの設定などの上に乗って動いています。図のように、自分のPCではNode.js 20なのにサーバーは18、ライブラリのバージョンも少しずつ違う……となると、同じコードでも動かなくなることがあるのです。
- 「自分のPCでは動くのに…」問題
- ノートPC
- 自分のPC
- サーバー
- サーバー（本番）
- アプリのコード
- アプリのコード
- ライブラリ v2.1
- ≠
- ライブラリ v1.9
- Node.js 20
- ≠
- Node.js 18
- OSの設定・ツール
- ≠
- OSの設定・ツール（違う）
- OK
- 動く
- NG
- 動かない
- コードは同じでも、まわりの環境が少し違うだけで動かなくなる
環境ごと、箱に詰めてしまう
それなら、コードだけでなく、動かすのに必要なものを全部まとめて箱に詰めてしまえばいい。これがDockerの発想です。アプリのコード、ライブラリ、Node.jsのバージョン、OSの設定まで、自分のPCで動いていた環境をそのまま箱の中に閉じ込めます。
この箱がコンテナです。コンテナは、パソコンの中に「もう一台のパソコン」を丸ごと作るのとは違い、必要な部分だけを詰めた軽い箱なので、数秒で起動できます。
- 環境ごと、箱に詰めてしまう
- 荷物
- コンテナ（箱）
- アプリのコード
- ライブラリ v2.1
- Node.js 20
- OSの設定・ツール
- コードだけでなく、動かすのに必要なもの全部を一緒に詰める
Dockerfileからイメージを作る
箱に何を詰めるかは、Dockerfileというテキストファイルに手順として書きます。「Node.js 20の土台から始めて」「ライブラリをインストールして」「アプリのコードをコピーする」というように、上から順に書いていきます。
この手順書をもとに docker build というコマンドを実行すると、イメージができあがります。イメージは、環境が全部詰まった「型」のようなものです。左の手順の一行一行が、右のイメージの層（レイヤー）に対応しています。同じ色どうしを見比べてみてください。
- 手順書（Dockerfile）から「イメージ」を作る
- Dockerfile
- 荷物
- イメージ（環境の型）
- FROM node:20
- COPY package.json .
- アプリのコード
- RUN npm install
- ライブラリ v2.1
- COPY . .
- docker build
- Node.js 20
- CMD ["npm", "start"]
- OSの設定・ツール
- 手順の1行1行が、イメージの層（レイヤー）になる
イメージからコンテナを起動する
イメージはあくまで型なので、それ自体は動きません。docker run というコマンドでイメージから起動したものが、実際に動くコンテナです。
たい焼きで例えると、イメージが焼き型で、コンテナが焼き上がったたい焼きです。一つの型から同じたい焼きがいくつでも作れるように、一つのイメージから、まったく同じ中身のコンテナをいくつでも起動できます。右の箱が、型から飛び出してきたのが分かるでしょうか。
- イメージから、同じコンテナをいくつでも起動
- 荷物
- 荷物
- イメージ（型）
- コンテナ① 起動中
- アプリのコード
- ライブラリ v2.1
- 荷物
- docker run
- コンテナ② 起動中
- Node.js 20
- OSの設定・ツール
- 荷物
- コンテナ③ 起動中
- 1つのイメージ（型）から、同じ中身のコンテナを何個でも作れる
どこに運んでも同じように動く
同じイメージから起動したコンテナは、自分のPCでも、テストを自動で流すCIのマシンでも、本番のサーバーでも、中身がまったく同じです。Dockerさえ入っていれば、どのコンピューターの上でも同じように動きます。
だから「自分のPCでは動いたのに」という問題が起きにくくなります。テストに合格した環境と、本番で動く環境が同じであることを、仕組みとして保証できるようになるのです。
- どこに運んでも、同じように動く
- ノートPC
- 自分のPC
- 更新
- CI（自動テスト）
- サーバー
- 本番サーバー
- 荷物
- 同じイメージ
- 荷物
- 同じイメージ
- 荷物
- 同じイメージ
- OK
- OK
- OK
- 中身がまったく同じなので「自分のPCでは動いたのに」が起きにくい
テスト用のデータベースもコンテナで
Dockerは自分のアプリだけでなく、データベースも同じようにコンテナで動かせます。docker composeという機能を使うと、「アプリのコンテナ」と「PostgreSQL 16のコンテナ」をまとめて起動し、つなげることができます。
統合テストでは、テストのたびに新品のデータベースを起動して、本物どうしをつないで確かめ、終わったら箱ごと捨てます。毎回まっさらな状態から始まるので、前のテストのデータが残っていて結果が変わる、ということも防げます。
- テスト用のデータベースもコンテナで
- 更新
- CIのマシン（docker compose でまとめて起動）
- 荷物
- アプリのコンテナ
- 本物どうしでつなぐ
- データベース
- PostgreSQL 16 のコンテナ
- テストのたびに新品のDBを起動 → 終わったら箱ごと捨てる（毎回まっさら）
- 更新
- 統合テストで「本物のDB」を、手軽に・何度でも使える
合格した箱を、そのまま本番へ
Dockerのいちばんの強みは、「テストに合格した箱」と「本番で動く箱」を同じものにできることです。イメージを一度だけ作り、そのイメージでテストを流し、合格したら同じイメージを本番に置きます。途中で作り直さないので、テストのときと本番のときで中身が変わることがありません。
この「作る → テストする → 本番に出す」という流れを、変更のたびに機械が自動で回してくれる仕組みが、次の章で紹介するCI/CDです。
- テストに合格した箱を、そのまま本番へ
- ① イメージを作る
- ② CIでテスト
- ③ 本番に置く
- （1回だけ）
- （DBもコンテナで）
- （作り直さない）
- 荷物
- 同じ箱
- 荷物
- 同じ箱
- OK
- 荷物
- 同じ箱
- テストした箱と本番で動く箱が同じ ＝ 本番でも同じように動く
- → この流れを自動で回すのが、次の章「CI/CD」
