独立した環境でアプリケーションを実行する手段がコンテナだ。後述するコンテナイメージを作成することで、その指定に基づいたコンテナを起動できる。Dockerでコンテナを起動するには「docker run」コマンドを使用する。

　コンテナは障害が発生してクラッシュするか、停止処理を実行するまで稼働し続ける。どれだけ長くコンテナを実行しても、基になるコンテナイメージは変化しない。コンテナイメージを変更した場合、そのコンテナイメージを基にしたコンテナを停止、削除した上で再起動しない限り、コンテナイメージの変更はコンテナに反映されない。言い換えると実行中のコンテナは、基本的には生成時のオプションのまま稼働し続ける。

　1つのコンテナイメージを基に生成した、複数の同じコンテナを実行することには幾つかの利点がある。その一つがコンテナ内で運用するアプリケーションの可用性確保だ。1つのコンテナに障害が発生しても、別のコンテナでアプリケーションの実行を継続できる。需要の増加時にアプリケーションを冗長化することも可能だ。

コンテナイメージとは

　カーネル（OSの中核要素）を除いたOSの一連のファイル群と、コンテナの内容に関する定義ファイルのパッケージがコンテナイメージだ。通常、コンテナイメージを一から作成することはなく、ベースとなる既存のコンテナイメージを使用し、目的に応じて変更する。

　一般的に、コンテナイメージの作成時には定義ファイルに以下を指定する。

• ベースとなる既存のコンテナイメージ
  • コンテナイメージを一から作成する場合は指定しない。
• コンテナ起動時に実行するコマンド
• コンテナ内のディレクトリ構造
• コンテナで開くポート

　コンテナイメージは、コンテナを生成して起動するための設計図の役割を果たす。1つのコンテナイメージから複数のコンテナを生成できる。Dockerで扱うコンテナイメージ「Dockerイメージ」を作成する際は、上記の情報を専用の定義ファイル「Dockerfile」に記述する。「docker build」コマンドを使用することで、Dockerfileの内容に基づいたDockerイメージを生成可能だ。

　Dockerfileの代わりに、自動化ツール「Ansible」およびAnsibleが実行する自動処理を定義したファイル群「Playbook」を使ってDockerイメージを生成する方法もある。だがこの方法は複雑だ。Dockerのコマンドラインインタフェース（CLI）を使いたくない何らかの理由がない限りは、Dockerfileを使用する方が望ましい。

コンテナとコンテナイメージの違いを「ケーキ」の例で考える

　コンテナをケーキに例えるとすれば、コンテナイメージはケーキのレシピに該当する。「ケーキの材料を記述したレシピ」がコンテナイメージだ。レシピだけではケーキを食べることができない。コンテナは「レシピに従って焼いたケーキ」だと言える。ケーキを食べたければ、レシピ通りにケーキを焼く必要がある。これと同じように、アプリケーションを実行できるコンテナを起動するには、コンテナイメージに記述されている指定内容に従ってコンテナを生成する必要がある。

　ケーキの場合、1つのレシピを使って同じものを何個でも焼くことができる。ただしレシピに変更を加えても、焼き終えたケーキは変化しない。レシピの更新は、これから焼くケーキにのみ反映される。同様にコンテナイメージを変更しても、それを基に生成した既に実行中のコンテナは変わらない。