はじめに
第1回では「なぜ今コンテナなのか」を、VMとの違いを軸に整理しました。
第2回では、実務で必ず登場するDockerの基本要素を、運用・保守の観点で解説します。
Dockerを触り始めた直後に、多くの人がつまずくのは次の点です。
- 「イメージ」と「コンテナ」の違いが直感的に分からない
- コンテナを消したらデータも消えた
- ログや設定ファイルがどこにあるか分からない
- ネットワークが急に繋がらなくなった
これらはすべて、Dockerの構造を知らないまま「動いたからOK」で進めてしまうことで起きます。
今回は、Dockerを運用で使うための土台を固めます。
Dockerを構成する4つの要素
Dockerは一見シンプルですが、実務では次の4要素を理解しておく必要があります。
- イメージ（image）
- コンテナ（container）
- ボリューム（volume）
- ネットワーク（network）
この4つを、運用目線で正しく整理できると、コンテナ環境のトラブル対応が一気に楽になります。
イメージとは何か：環境の「設計図」
イメージとは、アプリケーション実行に必要な環境をまとめた「雛形」です。
OSそのものではなく、正確には「アプリが動くためのファイル群と設定が入ったもの」と考えるとよいです。
イメージは原則「変更しない」
Docker運用で重要な思想は、イメージは基本的に不変（immutable）であるという点です。
たとえば、次のような運用はDockerでは推奨されません。
- コンテナにログインしてapt installする
- 本番コンテナで設定ファイルを直接編集する
- 動いているコンテナに後からPHP拡張を入れる
これをやると、コンテナごとに状態が変わり、再現性が崩れます。
Dockerを使う意味が薄れてしまいます。
Dockerfileは「構築手順書」ではなく「構築の実体」
従来の手順書は「読む→人が実行」でした。 Dockerfileは「書く→Dockerが実行」です。
つまりDockerfileは、運用引継ぎにおける最重要資産になります。
何をインストールしたか
どの設定が必要か
どの順序で構築したか
がコードとして残るため、属人性を大きく減らせます。
コンテナとは何か：イメージから作る「実行体」
コンテナは、イメージから作られる実行環境です。 イメージが設計図なら、コンテナは実際に動いているインスタンスです。
コンテナは「消して作り直す」のが基本
Docker運用では、コンテナは使い捨てに近い考え方をします。 例えば次のような流れが一般的です。
- Dockerfileを更新して新しいイメージを作る
- 古いコンテナを停止・削除する
- 新しいイメージから新しいコンテナを起動する
この運用が成立することで、環境が常にクリーンになり、
「いつの間にかサーバーが汚れて動かない」という事故が減ります。
コンテナ内部は「永続領域ではない」
ここが最大の落とし穴です。 コンテナの中に保存したデータは、コンテナ削除で消える可能性があります。
特に業務システムでは、次のようなものをコンテナ内に置くと事故になります。
- DBデータ
- アップロードファイル
- バッチ処理の中間成果物
- アプリの永続ログ
これを解決するのが、次に説明するボリュームです。
ボリュームとは何か：データを守る「金庫」
ボリュームは、コンテナとは別の場所にデータを保存する仕組みです。 コンテナを消しても、ボリュームが残っていればデータは保持されます。
なぜボリュームが必要なのか
Docker運用では「コンテナは作り直す」が基本です。 しかし業務システムでは、次のデータが消えると致命的です。
- 顧客データ（DB）
- 添付ファイル・帳票
- アップロード画像
このため、DBやファイルストレージはボリュームで永続化します。
つまり「コンテナ＝処理」「ボリューム＝資産」と役割分担することが重要です。
bind mountは便利だが運用事故が起きやすい
ボリュームには、厳密には2種類あります。
- Dockerが管理するvolume
- ホストのディレクトリを直接マウントするbind mount
bind mountは、開発環境では便利です。
しかし本番環境で安易に使うと、次の事故につながります。
- ホスト側の権限が崩れてアプリが動かない
- ディレクトリ構成が属人化する
- バックアップ対象が曖昧になる
本番運用では、基本はDocker volumeを優先し、
必要な場合のみbind mountを採用するのが安全です。
ネットワークとは何か：コンテナ同士を繋ぐ仕組み
Dockerでは、コンテナ同士はネットワークで通信します。 特にWebアプリ構成では、次のような構成が典型です。
- Web（Nginx）
- App（PHP）
- DB（MariaDB）
Dockerのネットワークは「名前解決」が前提
Docker Composeを使う場合、 コンテナ名（サービス名）で通信できる仕組みがあります。
つまり、IPアドレス固定で運用する必要がありません。
これは運用上かなり重要で、クラウド時代の設計思想にも合致します。
ポート公開は最小限にする
Dockerでは、ホストのポートをコンテナに公開する設定ができます。 しかし本番運用では、むやみに公開すべきではありません。
基本方針は次の通りです。
- 外部公開するのはWeb（Nginx）のみ
- DBはホストに公開しない
- 管理用ポートも必要最小限
特に情シス目線では、ポート公開の設計はそのままセキュリティ事故に直結します。
運用目線で押さえるべき「3つの分離」
Dockerを運用で扱うなら、次の3つを分離して考えるのがコツです。
分離1：環境（イメージ）と実行（コンテナ）
環境はイメージで管理し、実行はコンテナで行います。 運用変更は「コンテナを触る」のではなく「イメージを更新する」が基本です。
分離2：処理（コンテナ）とデータ（ボリューム）
データはコンテナの外に置く。 これを守るだけで、Docker運用の事故の多くを回避できます。
分離3：内部通信（ネットワーク）と外部公開（ポート）
内部はDockerネットワークで閉じ、外部公開は最小限にします。 これが、セキュリティと運用安定性を両立させる基本です。
次回予告
次回は、実務で最も利用される形である Docker Compose（複数コンテナ構成）をテーマにします。
- なぜComposeが必要なのか
- docker-compose.ymlで何を管理するのか
- 「動いた」で終わらせないための設計ポイント
を、情シス・現役エンジニア双方に刺さる形で解説します。
