イメージの取得とビルド
イメージは2通りで手に入ります。1つは docker pull でレジストリ（Docker Hub など）から既成のイメージを取得する方法、もう1つは Dockerfile から docker build で自作する方法です。Dockerfile はベースイメージの指定（FROM）やファイルのコピー（COPY）、実行コマンド（RUN）などを順に書いたテキストで、各命令がレイヤとして積み重なります。-t でイメージに名前とタグを付けておくと後で扱いやすくなります。
コンテナを起動するには、もとになるイメージが必要です。そのイメージを手に入れる方法は大きく2通りあります。1つは、誰かが用意した既成のイメージをそのまま取ってくる方法。もう1つは、自分専用のイメージを自分で組み立てる方法です。前者は docker pull でレジストリから取得し、後者は Dockerfile を書いて docker build でビルドします。既成品で足りるならそれを使い、自分のアプリを入れた独自の環境が欲しいなら自作する——この2つを状況に応じて使い分けるのが基本です。
既成のイメージを取得する docker pull
イメージを保管・配布している置き場をレジストリと呼び、その代表が Docker Hub です。アプリの開発元が公式イメージを公開しており、私たちはそれを取得して使えます。取得には docker pull イメージ名 を使い、たとえば docker pull nginx で Web サーバの nginx を、docker pull alpine で数MBしかない超軽量な Linux イメージを取ってこられます。pull はあくまで「ダウンロードするだけ」で、コンテナの起動はしない点に注意してください(起動まで一気にやりたいなら、前に学んだ docker run がローカルに無いイメージを自動で pull してくれます)。
ここで覚えておきたいのがタグです。イメージ名にコロンで続けて nginx:1.25 のようにバージョンを指定するもので、これをタグと呼びます。docker pull nginx のようにタグを省くと、自動で :latest(最新版)が補われ、docker pull nginx:latest と書いたのと同じ扱いになります。本番運用では、いつの間にか中身が変わって挙動が変わるのを避けるため、latest 任せにせず nginx:1.25 のように版を固定するのが安全です。取得済みのイメージは docker images で一覧でき、名前・タグ・IMAGE ID・SIZE が並ぶので、alpine がいかに小さいかといったことも一目で分かります。
自作する Dockerfile と docker build
既成イメージに自分のアプリやファイルを足した独自イメージを作るには、その設計図にあたる Dockerfile を書きます。Dockerfile は「どの土台から始めて、何をインストールして、どのファイルを入れて、起動時に何を実行するか」を、上から順に並べたただのテキストファイルです。料理のレシピを手順どおりに書き下していくのに似ています。よく使う命令を押さえておきましょう。FROM は土台にするベースイメージの指定で、必ず最初に書きます。RUN はイメージを作る途中で実行するコマンド(パッケージのインストールなど)、COPY はホスト側のファイルをイメージの中へコピーする命令、WORKDIR は以降の作業ディレクトリの指定、CMD はコンテナ起動時に既定で実行するコマンドです。
具体例として、Python の小さなプログラムを動かすイメージを作ってみます。作業フォルダに app.py と、次の内容の Dockerfile を置きます(以下は Dockerfile の中身そのものなので、行頭にプロンプト記号は付きません)。FROM python:3.12-slim / WORKDIR /app / COPY app.py . / EXPOSE 8080 / CMD ["python", "app.py"] という5行です。意味は上から、「Python 3.12 の軽量版を土台にする」「作業フォルダを /app にする」「手元の app.py をそこへコピーする」「8080番ポートを使うと宣言する」「起動時に python app.py を実行する」となります。なお EXPOSE はあくまで「このポートを使う」という宣言(ドキュメント)であって、これだけで外部からアクセスできるようになるわけではない点に注意してください。実際に外へ公開するには、別トピックで扱う -p オプションが必要です。
ビルドの実行と末尾のドット
Dockerfile を置いたフォルダで、docker build -t myapp:1.0 . を実行するとイメージが作られます。-t は名前とタグを付けるオプションで、myapp:1.0 ならコロンの前が名前、後ろがバージョン(タグ)です。タグを省くと :latest が自動で付きます。そして最大の注意点が、コマンド末尾の .(ドット)です。これは「今いるフォルダをビルドの材料置き場(ビルドコンテキスト)として使う」という意味で、Dockerfile や COPY 対象のファイルをここから探します。このドットを書き忘れて docker build -t myapp:1.0 とだけ打つとエラーになるのは、初学者が最もよくやる失敗です。「最後のドットを忘れない」と覚えておきましょう。
レイヤとキャッシュの効きかた
Dockerfile の各命令は、それぞれが1つのレイヤを生み出します。FROM の層、COPY の層……と積み上がってイメージができあがる、というのが前のトピックで触れたレイヤ構造の正体です。ここで効いてくるのがキャッシュです。docker build をやり直したとき、上から見ていって変更のなかった命令の層は、前回の結果がそのまま再利用されます。だから、頻繁に変わるもの(自分のアプリのソースなど)を Dockerfile の後ろのほうに書き、めったに変わらないもの(依存ライブラリのインストールなど)を前に書くと、変更時に作り直す層が減ってビルドが速くなります。この順序の工夫は、ビルド時間を縮める実務の定番テクニックです。
実務の使いどころ
ビルドが終われば、自作イメージ myapp:1.0 も既成イメージとまったく同じく docker run myapp:1.0 で起動できます。一度イメージに固めてしまえば、配布先のどのマシンでも同じ環境で動く——これが「環境ごと配る」ことの威力です。実務では、まず公式のベースイメージを FROM で土台にし、その上に自分のアプリと依存物を載せて独自イメージを作る、という流れが基本になります。なお、誰でもレジストリにイメージを公開できるため、素性の怪しいイメージには注意が必要です。FROM で土台を選ぶときは、公式(official)マークの付いたものや、信頼できる発行元のものを選ぶのが鉄則です。作ったイメージは docker push でレジストリに登録すれば、チームや別のサーバと共有できます。