はじめに
セルフホストサービスの多くが「Dockerで動かしてください」という形で配布されています。コマンド自体はコピペで動かせても、「イメージ」「コンテナ」「Docker Compose」がそれぞれ何を指しているのかが曖昧なままだと、トラブル時に対処しづらくなります。
本記事では、Dockerを構成する基本概念を整理します。コマンドの使い方そのものは扱いませんので、実際の操作は別途チートシート等を参照してください。
コンテナとは何か
コンテナは、アプリケーションとその実行に必要なファイル・ライブラリ・設定をひとまとめにし、ホストOSから隔離された環境で実行する技術です。仮想マシン(VM)のようにOS全体を仮想化するのではなく、ホストのカーネルを共有しながら、プロセス空間やファイルシステムだけを隔離するという点が特徴です。
これにより、VMと比べて起動が高速で、リソースの消費も少なく済みます。
LXCコンテナとの違いについて：Proxmox VE等で使われるLXCコンテナは「OS全体を模した環境(システムコンテナ)」を提供するのに対し、Dockerコンテナは基本的に「1つのアプリケーションプロセスを動かすための環境(アプリケーションコンテナ)」を提供するという思想の違いがあります。そのため、LXCコンテナの中でDockerを動かし、その中でさらに個々のアプリケーションをコンテナ化する、という2階建ての構成もよく見られます。
イメージとコンテナの関係
Dockerを理解する上で最も重要なのが、イメージ(Image) と コンテナ(Container) の違いです。
- イメージ：コンテナを作成するための「読み取り専用のテンプレート」。アプリケーションの実行に必要なファイル・バイナリ・ライブラリ・設定がすべて含まれている
- コンテナ：イメージを元に実際に起動された「実行中のインスタンス」
関係性としては、プログラミングにおける「クラス」と「インスタンス」に近いイメージです。同じイメージから複数のコンテナを起動することもできます。
イメージ(テンプレート) --起動--> コンテナ(実行中のインスタンス)
--起動--> コンテナ(別のインスタンス)
イメージはどう作られるか
イメージはDockerfileという設定ファイルに書かれた手順に従って構築されます。Dockerfileの各命令(FROM・RUN・COPY等)は、それぞれイメージの「レイヤー」を1つずつ作ります。レイヤーは差分管理されており、Dockerfileの一部だけを変更して再ビルドした場合、変更のなかったレイヤーはキャッシュとして再利用されるため、ビルドが高速化されます。
自分でDockerfileを書かなくても、Docker Hub等のレジストリで公開されている既成のイメージ(例：postgres、nginx)をそのまま使うことも多く、多くのセルフホストサービスは「公式イメージを指定してすぐ動かす」形で配布されています。
Docker Composeとは
実際のアプリケーションは、Webサーバー・アプリケーション本体・データベースのように複数のコンテナが連携して動くことがほとんどです。これらを個別にdocker runコマンドで起動・管理するのは煩雑になりがちです。
Docker Composeは、複数のコンテナから構成されるアプリケーションを、1つのYAMLファイル(docker-compose.yml)にまとめて定義し、まとめて起動・停止できるようにするツールです。
services:
app:
image: my-app:latest
ports:
- "3000:3000"
depends_on:
- db
db:
image: postgres:17
volumes:
- db-data:/var/lib/postgresql/data
volumes:
db-data:
このように、各コンテナ(services配下)がどのイメージを使い、どのポートを公開し、どのボリュームをマウントし、どのコンテナに依存するかを宣言的に記述できます。設定ファイルを1つのコマンド(docker compose up)で丸ごと起動できるため、構成の再現性・可搬性が高まります。
覚えておきたい周辺概念
ボリューム(永続化)
コンテナ自体は、削除されるとその中に書き込んだデータも一緒に失われる「使い捨て」の存在として扱うのが基本です。データベースのデータのように失われては困る情報は、ボリュームとしてホスト側の領域(またはDocker管理領域)にマウントし、コンテナの再作成後もデータが残るようにします。
ネットワーク
Docker Composeで定義した複数のコンテナは、デフォルトで同一の仮想ネットワークに所属し、サービス名をホスト名としてお互いに通信できます(例：appコンテナからdbという名前でデータベースコンテナに接続できる)。
再起動ポリシー
restart: unless-stoppedのような設定により、コンテナが異常終了した場合やホストの再起動後に、Dockerが自動的にコンテナを再起動してくれるようになります。手動で毎回起動し直す必要がなくなるため、常駐させたいサービスでは必ず設定しておきたい項目です。
環境変数変更後の反映
docker-compose.ymlのenvironment項目を変更しただけでは、既存のコンテナは新しい値を認識しません。restart(コンテナの再起動)ではなく、設定を反映させたコンテナを作り直す操作(再作成)が必要になる点はよくハマるポイントです。
まとめ
| 用語 | 内容 |
|---|---|
| コンテナ | ホストのカーネルを共有しつつ、アプリケーションの実行環境を隔離する技術 |
| イメージ | コンテナ作成用の読み取り専用テンプレート |
| Dockerfile | イメージのビルド手順を定義するファイル。命令ごとにレイヤーが作られる |
| Docker Compose | 複数コンテナから成るアプリケーションをYAMLでまとめて定義・起動するツール |
| ボリューム | コンテナ再作成後もデータを残すための永続化領域 |
| 再起動ポリシー | コンテナ異常終了時やホスト再起動後に自動再起動させる設定 |