イメージの作り方をファイルへ残す

完成したWebサイトをイメージへ入れる作業を毎回手で行うと、ファイルを入れ忘れたり、担当者によって手順が変わったりします。 作業を順番どおりに記録しておけば、Dockerに同じ手順を実行させられます。

その手順を書くファイルがDockerfileです。 DockerはDockerfileを上から順に読み、アプリを動かすためのイメージを作ります。

小さなWebサイトの作り方を書く

次のDockerfileは、NginxのイメージへWebサイトのファイルを追加します。

FROM nginx:1.29-alpine
COPY public/ /usr/share/nginx/html/
EXPOSE 80

EXPOSEを書くだけでは、手元のPCのポートは開きません。 手元のPCから接続するときは、コンテナの起動時に-pを指定します。

イメージを作って起動する

Dockerfileとpublic/index.htmlがあるディレクトリで、次のシェルコマンドを実行します。

docker build -t awamori-site:local .
docker run --rm -p 127.0.0.1:8080:80 awamori-site:local

docker buildはDockerfileの手順を実行してイメージを作ります。 -t awamori-site:localは、作ったイメージへ名前とタグを付けます。 最後の.は、イメージへ入れるファイルを探す範囲として、現在のディレクトリを渡す指定です。

このファイルの範囲をビルドコンテキストと呼びます。 秘密情報や不要な大きいファイルをDockerへ渡さないように、.dockerignoreへ除外するファイルを書きます。

Dockerは変更していないビルド結果を再利用する

Dockerfileの各命令から作られるファイルの差分をレイヤーと呼びます。 命令と入力ファイルが前回から変わっていなければ、Dockerは以前の結果をキャッシュとして再利用できます。

次の例では、ライブラリの一覧を先にコピーしてインストールします。 アプリのコードだけを変更した場合、npm ciまでの結果を再利用できます。

COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

タグやダイジェストで土台のイメージを指定する

FROMへタグを書くと、使うイメージの版をある程度絞れます。 ただし、同じタグが指す内容を配布元が更新する場合があります。

毎回まったく同じ土台を使う必要がある場合は、イメージの内容から計算されるダイジェストを記録します。 更新を止めたままにせず、新しい土台を試して安全に入れ替える手順も用意します。

作るためだけのファイルを完成品から外す

アプリを作るためのコンパイラや開発用ファイルは、完成したアプリを動かすときには不要です。 マルチステージビルドを使うと、最初の段階でアプリを作り、最後の段階へ完成品だけをコピーできます。

FROM node:24-alpine AS build
WORKDIR /src
COPY . .
RUN npm ci && npm run build

FROM nginx:1.29-alpine
COPY --from=build /src/dist /usr/share/nginx/html

完成したイメージから不要なプログラムを外すと、ダウンロードするデータ量と、管理するプログラムの数を減らせます。

コンテナの起動後にアプリの応答を確認する

コンテナ内のプロセスには、必要なファイルだけを変更できる権限を与えます。 アプリ専用の一般ユーザーで動かせる場合は、管理者権限を使わずに起動します。

ヘルスチェックは、アプリへ軽い要求を送り、新しい通信を受けられる状態か確認する処理です。 プロセスを再起動する条件と、サービス全体の異常を担当者へ知らせる条件は分けて決めます。

docker build -t awamori-site:local .
docker run --rm -p 127.0.0.1:8080:80 awamori-site:local

次に学ぶもの

複数のコンテナを一台のコンピューターで一緒に動かすときは、Docker Composeを使えます。 複数のコンピューターへコンテナを配置し、停止したコンテナを自動で作り直す仕組みとして、Kubernetesなどがあります。