コンテナ技術の基礎とDockerコンテナ管理・Dockerfile構築【201試験 主題2.06】



LinuCレベル2（201試験）の主題2.06「コンテナ管理」では、第7回で解説した従来の仮想マシン（KVM等のハイパーバイザ型仮想化）とコンテナ型仮想化のアーキテクチャの違い、Linuxカーネルが提供する名前空間（Namespaces）やコントロールグループ（cgroups）の役割、およびDocker／Podmanを用いたコンテナ操作やDockerfileによるイメージ構築技術が出題範囲に指定されています。

クラウドネイティブ環境やマイクロサービスアーキテクチャの普及に伴い、コンテナ技術は現代のシステム運用において不可欠なインフラ基盤技術となりました。本記事では、AlmaLinux 9.8の実機環境においてOCI準拠のコンテナランタイムを操作し、カーネルレベルの分離機構からコンテナライフサイクル管理、Dockerfileによるイメージビルド、ストレージマウント、ネットワーク構成までを実機検証ログとともに体系的に解説します。

1. Linuxコンテナ技術の動作原理（Namespacesとcgroups）#

コンテナを単なる「軽量な仮想マシン」として表層的に理解するのではなく、Linuxカーネルが提供するプロセス分離技術の集合体として捉えることが、LinuC 201試験の設問や障害切り分けにおいて極めて重要です。

図1: ハイパーバイザ仮想化とコンテナ仮想化のアーキテクチャ比較

1.1 ハイパーバイザ仮想化とコンテナ仮想化の違い#

KVMやVMware ESXiなどのハイパーバイザ型仮想化では、物理ハードウェアの上にハイパーバイザ（またはホストOS）を介して仮想ハードウェア（CPU、メモリ、ディスクコントローラ、NIC）をエミュレートし、その上で個別の「ゲストOS（独立したLinuxカーネルやWindowsカーネル）」を動作させます。

これに対し、DockerやPodmanに代表されるコンテナ型仮想化では、ホストOSの単一のLinuxカーネルをすべてのコンテナで共有します。コンテナとは、独立したOSが起動しているのではなく、「カーネルの分離機能によって隔離された単一または複数のプロセス群」に過ぎません。

1.2 Linuxカーネル機能: Namespaces（名前空間分離）#

コンテナプロセスに対して「自分専用の独立したシステム環境が存在している」と認識させるためのカーネル機能が名前空間（Namespaces）です。Linuxカーネルは以下の6系統の名前空間を提供しています。

実機のホストOSにおいて、現在のシェルプロセスが参照している各名前空間のリンク構造を /proc/self/ns で確認します。

[user01@linuc-node01 ~]$ ls -l /proc/self/ns
合計 0
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 cgroup -> cgroup:[4026531835]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 ipc -> ipc:[4026531839]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 mnt -> mnt:[4026531841]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 net -> net:[4026531840]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 pid -> pid:[4026531836]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 pid_for_children -> pid:[4026531836]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 time -> time:[4026531834]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 time_for_children -> time:[4026531834]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 user -> user:[4026531837]
lrwxrwxrwx. 1 user01 user01 0  9月  7 08:23 uts -> uts:[4026531838]

1.3 Linuxカーネル機能: cgroups（リソース制限）とルート変更#

名前空間が「プロセスの視界の分離（どのリソースが見えるか）」を担うのに対し、プロセスの「リソース使用量の上限制御（どれだけリソースを使えるか）」を担うのがコントロールグループ（cgroups: Control Groups）です。

AlmaLinux 9や最新のLinuxディストリビューションでは、単一の階層ツリー構造でリソースを統合管理する cgroups v2 が標準で有効化されています。cgroupsにより以下の制限が実現されます。

• CPU制限: コンテナが使用可能なCPUコア数（quota/period）、およびCPU相対シェア（weight）の指定。
• メモリ制限: コンテナプロセスが消費可能な物理RAM上限値（memory.max）。上限超過時はOOM Killer（Out of Memory Killer）によりプロセスが強制終了されます。
• Block I/O制限: ディスクデバイスへの読み書きスループット（IOPSやバイトレート）の上限設定。
• プロセス数（pids）制限: フォークボムなどによるプロセス枯渇攻撃を防ぐための最大PID数制御。

[user01@linuc-node01 ~]$ stat -fc %T /sys/fs/cgroup
cgroup2fs

さらに、コンテナプロセスのルートディレクトリは chroot または pivot_root システムコールによって隔離され、コンテナ外のホストファイルシステム階層への直接アクセスが遮断されます。

2. Docker / Podmanコンテナの基本操作とライフサイクル#

LinuC 201試験では、Dockerコマンド体系（Podmanでも完全互換）によるコンテナイメージの管理、起動・停止、実行中コンテナへの介入操作が頻出します。OCI（Open Container Initiative）標準に準拠したコマンドライン操作の基礎を整理します。

図2: DockerコンテナのライフサイクルとDockerfileビルドの流れ

2.1 コンテナイメージの取得・検索・削除（pull, search, rmi）#

コンテナを実行するための静的なテンプレートファイルが「コンテナイメージ」です。イメージはDocker HubやQuay.ioなどのリモートレジストリから取得します。

• docker search <キーワード>: レジストリ上に存在する公開イメージを検索します。
• docker pull <イメージ名>:[タグ]: レジストリから指定したイメージをローカルストレージへダウンロードします。タグを省略した場合はデフォルトで latest が適用されます。
• docker images（または docker image ls）: ローカルにダウンロードされているイメージの一覧、イメージID、作成日時、サイズを表示します。
• docker rmi <イメージIDまたは名前>（または docker image rm）: 不要になったローカルイメージを削除します。コンテナから参照されているイメージは直接削除できません。

[user01@linuc-node01 ~]$ sudo podman images
REPOSITORY           TAG         IMAGE ID      CREATED        SIZE
localhost/mini-base  latest      29ab9e14ca99  5 minutes ago  6.18 MB

2.2 コンテナの起動・実行・停止・削除（run, ps, stop, rm）#

コンテナの起動には docker run コマンドを用います。docker run は内部的に「イメージ取得（ローカルにない場合） ➔ コンテナ作成（create） ➔ コンテナ開始（start）」を一括実行します。

実行中のコンテナを確認するには docker ps を実行します。停止中のコンテナも含めて全状態を表示するには -a（--all）オプションを指定します。

[user01@linuc-node01 ~]$ sudo podman run -d --name web01 -p 8080:80 localhost/mini-base:latest /bin/sh -c "while true; do sleep 10; done"
f2398d4b582a6626157cfd01899f69fa5cfed556f6855a35fd3a822d13f8f357

[user01@linuc-node01 ~]$ sudo podman ps
CONTAINER ID  IMAGE                        COMMAND               CREATED        STATUS            PORTS                 NAMES
f2398d4b582a  localhost/mini-base:latest   /bin/sh -c while ...  3 seconds ago  Up 3 seconds ago  0.0.0.0:8080->80/tcp  web01

コンテナを停止する際は docker stop <コンテナ名> を実行します。このときコンテナのメインプロセス（PID 1）に対して SIGTERM シグナルが送信され、一定時間（既定10秒）内に終了しない場合は SIGKILL により強制終了されます。停止したコンテナは docker rm <コンテナ名> で安全に破棄します。

2.3 稼働中コンテナへのアタッチとコマンド実行（exec, logs）#

運用保守やトラブルシューティングにおいて、稼働中のコンテナ内部で対話的シェルを起動したり、設定ファイルを確認したりする操作が不可欠です。

• docker exec -it <コンテナ名> <コマンド>: 稼働中のコンテナ環境内で新しいプロセスを立ち上げます。-i（標準入力を開く）および -t（疑似端末TTYを割り当てる）を指定することで、対話的なシェル操作が可能となります。
• docker logs [-f] <コンテナ名>: コンテナのメインプロセスが出力した標準出力（stdout）および標準エラー出力（stderr）を閲覧します。-f（follow）オプションでログの継続監視が可能です。
• docker top <コンテナ名>: コンテナ内で動作しているプロセス一覧を表示します。
• docker stats [--no-stream]: 稼働中コンテナのCPU使用率、メモリ消費量、ネットワークI/Oをリアルタイム表示します。

[user01@linuc-node01 ~]$ sudo podman exec web01 uname -a
Linux web01 5.14.0-503.40.1.el9_5.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jan 15 17:09:47 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

[user01@linuc-node01 ~]$ sudo podman exec web01 cat /etc/hosts
127.0.0.1   localhost localhost.localdomain
10.88.0.12  web01

3. Dockerfileによるコンテナイメージの構築#

コンテナイメージは手動で起動したコンテナをコミット（docker commit）して作成することも可能ですが、インフラのコード化（IaC: Infrastructure as Code）の観点から、テキストファイルである Dockerfile に記述して docker build コマンドで自動生成するのが業界標準です。

3.1 Dockerfileの基本構文と主要命令#

Dockerfileは上から順に解釈され、各命令が実行されるごとにキャッシュ可能な「読み取り専用イメージレイヤー」が積み上げられます。LinuC 201試験で問われる主要な命令の一覧は以下の通りです。

3.2 CMDとENTRYPOINTの決定的な挙動差異#

LinuC 201試験で最も頻出かつ失点しやすいポイントが、CMD と ENTRYPOINT の組み合わせルールです。

• CMD単体の場合: docker run <イメージ> <追加引数> を実行すると、Dockerfileに書かれたCMD全体が指定された引数で完全に上書きされます。
• ENTRYPOINT単体の場合: docker run の追加引数はENTRYPOINTに指定されたコマンドの「末尾の引数」として結合されます（上書きされません）。固定バイナリを実行するCLIツールのイメージに適します。
• ENTRYPOINTとCMDの併用: ENTRYPOINT に基本コマンド（実行バイナリ）を指定し、CMD に既定のデフォルトオプションを記述します。docker run 実行時に引数を渡すと、CMDのデフォルト引数部分のみが上書きされます。

3.3 docker buildによるイメージ作成とレイヤー構造#

実機環境において実際にDockerfileを作成し、ビルド処理の進行ログとイメージレイヤーの生成挙動を確認します。

[user01@linuc-node01 build-demo]$ cat Dockerfile
FROM localhost/mini-base:latest
ENV APP_ENV=production
WORKDIR /app
RUN echo "Hello LinuC Level 2 Container" > app.txt
CMD ["/bin/sh", "-c", "cat /app/app.txt && sleep 3600"]

[user01@linuc-node01 build-demo]$ sudo podman build -t localhost/demo-app:1.0 .
STEP 1/5: FROM localhost/mini-base:latest
STEP 2/5: ENV APP_ENV=production
--> df97df4ee35f
STEP 3/5: WORKDIR /app
--> c99e2dc05d31
STEP 4/5: RUN echo "Hello LinuC Level 2 Container" > app.txt
--> ebdee59f8cd2
STEP 5/5: CMD ["/bin/sh", "-c", "cat /app/app.txt && sleep 3600"]
COMMIT localhost/demo-app:1.0
--> 32acc1af239b
Successfully tagged localhost/demo-app:1.0

ビルドログから、各ステップ（STEP 1/5〜5/5）が実行されるたびに一意のレイヤーハッシュ（df97df4ee35f, c99e2dc05d31, ebdee59f8cd2）が順次コミットされ、最終的に 32acc1af239b としてタグ付けされていることが確認できます。

4. コンテナストレージとネットワーク#

コンテナの内部ストレージ（最上位の書き込み可能レイヤー）は揮発性であり、コンテナが削除（docker rm）されると変更されたデータはすべて消滅します。本番環境でデータベースやログファイルを永続化するためには、外部ストレージマウント機構の理解が不可欠です。

4.1 バインドマウント（Bind Mount）と名前付きボリューム（Volume）#

DockerおよびPodmanが提供する主なデータ永続化方式には、バインドマウントと名前付きボリュームが存在します。

ボリュームの作成およびコンテナへのマウントコマンドは以下の通りです。

• docker volume create <ボリューム名>: Docker管理下の新しいボリューム領域を初期化します。
• docker volume ls: 作成済みボリュームの一覧を表示します。
• docker volume inspect <ボリューム名>: ボリュームの物理マウント先パスやメタデータをJSONで表示します。
• docker run -v <ボリューム名>:<コンテナ内パス>: 指定したボリュームをコンテナ内に接続します。
• docker run -v <ホスト絶対パス>:<コンテナ内パス>[:ro]: バインドマウントを実施します。末尾に :ro を付与するとコンテナ側から読み取り専用（Read-Only）としてマウントされます。

[user01@linuc-node01 ~]$ sudo podman volume create app-data
app-data

[user01@linuc-node01 ~]$ sudo podman volume ls
DRIVER      VOLUME NAME
local       app-data

[user01@linuc-node01 ~]$ sudo podman volume inspect app-data --format '{{.Mountpoint}}'
/var/lib/containers/storage/volumes/app-data/_data

4.2 コンテナネットワーク（bridge, host, none）とポート転送#

コンテナのネットワーク通信は、Dockerデーモンが作成する仮想ブリッジ（docker0）やCNIプラグインによって制御されます。コンテナ起動時に --network（または --net）でネットワークドライバを指定します。

[user01@linuc-node01 ~]$ sudo podman network ls
NETWORK ID    NAME        DRIVER
2f259bad93b7  podman      bridge

5. 複数コンテナの連携（実務拡張：Docker Compose基礎）#

Webアプリケーション、APIサーバー、データベース、キャッシュストア（Redis等）など、複数のコンテナを協調動作させる場合、個別に docker run を実行してネットワーク接続を管理するのは煩雑です。これをYAML形式の定義ファイルで一括制御するツールが Docker Compose（compose.yaml または docker-compose.yml）です。

5.1 docker-compose.yml の基本構造#

Composeファイルでは、構成要素を「サービス（services）」として定義します。以下は代表的な2層構成（Webサーバー＋DB）の構成記述例です。

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    depends_on:
      - db
    restart: always

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: app_db
      POSTGRES_USER: app_user
      POSTGRES_PASSWORD: SecretPassword123
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

5.2 サービスの起動・停止（compose up / down）#

Docker ComposeはLinuC試験の公式出題範囲外ですが、現場の実務では単一コンテナのみで完結するシステムは稀であり、複数コンテナを一括オーケストレーションするDocker Composeの運用知識は不可欠です。現場で頻用される基本コマンドを以下にまとめます。

• docker compose up -d: カレントディレクトリの compose.yaml を読み込み、必要なイメージのビルド・取得、ネットワーク生成、ボリューム割り当てを行い、全サービスをバックグラウンドで一括起動します。
• docker compose ps: Composeによって管理されているコンテナ群の稼働ステータスを表示します。
• docker compose logs [-f] [サービス名]: 定義されたサービス群の標準出力を集約して時系列で表示します。
• docker compose stop: コンテナを削除せずにサービスを一時停止します。
• docker compose start: 停止中のサービスコンテナを再開します。
• docker compose down: 稼働中の全コンテナと作成された仮想ネットワークを停止・一括削除します（ボリュームは -v を明示しない限り保持されます）。

6. LinuC 201試験（主題2.06）重要ポイント総整理#

主題2.06「コンテナ管理」における記述式問題（コマ問）対策および引数・命令の混同防止ポイントを総整理します。

6.1 記述式（コマ問）頻出コマンド・Dockerfile命令一覧#

6.2 CMD vs ENTRYPOINT、COPY vs ADD の取り違えやすい盲点#

試験において受験者が最も誤答しやすい比較項目を2点整理します。

7. 201試験総括：システム基盤と運用管理の体系的理解を完了する#

本記事をもって、LinuCレベル2の第1関門である「201試験」の全出題範囲（第1回〜第8回）の体系的な実機検証解説が完了しました。

• ブート・カーネル基盤（第1回・第2回）: GRUB2の起動プロセス、systemdのターゲット管理、カーネルモジュール（modprobe/lsmod）、sysctlによるカーネルパラメータの動的・恒久チューニング。
• ストレージ・ファイルシステム（第3回）: mdadmによるソフトウェアRAIDの障害復旧、LVM（PV/VG/LV）の動的リサイズ、xfs/ext4の保守管理。
• ネットワーク・インフラ運用（第4回・第5回）: nmcliによるネットワーク設定、チャネルボンディング（Mode 1/4）、階層的障害切り分け、ソースコードビルド手順（configure/make）、リソース監視（vmstat/iostat/sar）。
• 仮想化とコンテナ（第6回・第7回・第8回）: Ansibleによる構成管理自動化、KVM・libvirt・virshによる仮想マシン管理、Namespaces/cgroupsによるコンテナ分離とDockerfileによるイメージ構築。

201試験で問われる技術は、サーバー1台が正常に起動し、ストレージとネットワークが構成され、仮想化環境や自動化基盤の上で健全にリソースが管理されるための「システム基盤レイヤー」の知見です。机上の知識暗記だけでなく、本シリーズで示した実機ログと照らし合わせてコマンドを叩いた経験が、本番試験の記述式問題や実務での障害対応において確固たる力となります。

続く第9回からは、LinuCレベル2の後半である「202試験編」がスタートします。202試験では、ネットワークサーバーの構築とセキュリティ運用（LDAP、DNS、Web、Proxy、Mail、Samba/NFS、VPN/ファイアウォール、HAクラスタ）がテーマとなります。第9回では、エンタープライズ認証基盤の要である「PAM（Pluggable Authentication Modules）認証とOpenLDAPディレクトリサーバー」の構築・実機検証に進みます。

リンク