Mima Design MemottoWEB DESIGNER · mima

初めてのDockerfileで押さえる基本構文と書き方

Dockerfileは、アプリケーションを動かすための環境をコードとして定義するファイルです。使用するOS、ランタイム、依存パッケージ、起動コマンドを順番に記述できるため、開発環境と本番環境の差を小さくできます。初めてのDockerfileを書くときは、命令の意味と実行される順序を理解することが大切です。

Dockerイメージは、Dockerfileに書かれた命令を上から順番に処理して作成されます。各命令はレイヤーとして保存されるため、記述方法によってビルド時間やキャッシュの効き方も変わります。単にコンテナを起動できればよいのではなく、再現性や保守性も意識すると実用的な構成になります。

Web制作やアプリ開発の学習では、ローカル環境を何度も作り直す場面があります。筆者の制作や技術記録をまとめた個人ブログのように、開発環境の手順を後から追える形にしておくと、学習内容の整理にも役立ちます。

Dockerfileの役割を理解する

Dockerfileは、Dockerイメージを自動生成するための設計図です。たとえばNode.jsアプリケーションなら、Node.jsの公式イメージを土台にし、作業ディレクトリを作り、依存関係をインストールしてからソースコードを配置します。

ファイル名は拡張子を付けず、通常はプロジェクトのルートにDockerfileとして保存します。ビルドはdocker build、作成したイメージからコンテナを起動する処理はdocker runで行います。Docker Composeを使う場合でも、個々のサービスのイメージ作成にはDockerfileが利用されます。

最初に覚える基本命令

もっとも重要な命令はFROM、WORKDIR、COPY、RUN、CMDです。FROMでベースイメージを指定し、WORKDIRで以降の作業場所を決めます。COPYはホスト側のファイルをイメージへ追加し、RUNはイメージ作成中にコマンドを実行します。

FROM node:20-alpine

WORKDIR /app

COPY package*.json ./
RUN npm ci

COPY . .
CMD ["npm", "start"]

CMDのJSON配列形式は、シェルを経由しないため意図しない文字列解釈が起こりにくい書き方です。依存ファイルを先にコピーしてからnpm ciを実行しているのは、ソースコードを変更しても依存関係のレイヤーを再利用しやすくするためです。

環境変数と命令の使い分け

ENVはイメージやコンテナの実行時にも利用できる環境変数を設定します。一方、ARGは主にビルド中だけ使う変数です。公開してはいけないパスワードやAPIキーを、ARGやENVに直接書き込むのは避けてください。

命令 主な役割 利用されるタイミング
FROM ベースイメージを指定 ビルド
WORKDIR 作業ディレクトリを指定 ビルド・実行
COPY ファイルを追加 ビルド
RUN パッケージ導入などを実行 ビルド
ENV 環境変数を設定 ビルド・実行
CMD 標準の起動コマンドを指定 実行

命令を増やしすぎるとイメージの構造が複雑になります。関連するパッケージのインストールと不要なキャッシュ削除を同じRUNにまとめるなど、レイヤー数と再利用性のバランスを考えます。

起動コマンドとポートを定義する

EXPOSEは、コンテナが利用するポートを説明するための命令です。ポートを実際にホストへ公開するには、起動時に-p 3000:3000のようなオプションを指定します。EXPOSEを書いただけで、ブラウザからアクセスできるようになるわけではありません。

CMDはデフォルトの起動処理を示し、ENTRYPOINTはコンテナの主目的となる実行ファイルを固定したい場合に使います。WebアプリではまずCMDから始め、起動方法を利用者に上書きされたくないケースでENTRYPOINTを検討すると理解しやすいでしょう。

ビルドコンテキストとキャッシュを整える

docker build .の末尾にある.は、ビルドコンテキストとして現在のディレクトリを指定しています。コンテキスト内のファイルはDockerfileから参照できるため、不要な画像、ログ、依存フォルダを含めないことが重要です。.dockerignoreにnode_modulesや.gitを記述すると、転送量とビルド時間を抑えられます。

開発環境を使った実践例として、PhoneGap開発記録のようなアプリ制作の記録を読むと、ツールや実行環境を整理する視点も得られます。Dockerfileでは、変更されにくい命令を前半に、頻繁に変わるソースコードのコピーを後半に置くと、キャッシュを活用しやすくなります。

書き終えた後の確認ポイント

Dockerfileは動けば完成ではなく、不要なファイルを含めていないか、意図したポートで起動するか、他の環境でも同じ結果になるかを確認します。ベースイメージのタグを曖昧にせず、チームで使うバージョンを明示すると、将来的な予期せぬ更新も避けられます。

ビルド前には、次の点を確認しておくとエラーの切り分けが簡単です。

  • FROMのイメージ名とタグが正しい
  • COPY元のファイルがコンテキスト内にある
  • WORKDIRと実行コマンドのパスが一致している

起動後は、ログとコンテナ内の状態を調べます。特にポート設定や環境変数は、Dockerfileだけでなくdocker runやCompose側の指定も合わせて確認します。

  • docker buildの実行場所を確認する
  • docker logsでアプリのエラーを見る
  • .dockerignoreで必要なファイルを除外していないか調べる

まずは小さなNode.jsや静的サイトでDockerfileを書き、FROMからCMDまでの流れを体験してみましょう。構文の意味を意識しながら自分の制作環境へ取り入れ、再現可能な開発環境づくりに役立ててください。