コンテナとDocker入門｜CKAD対策 第1回

新卒インフラエンジニア向け「Kubernetes 実践教科書① CKAD アプリケーション開発編」の第1回です。本シリーズは全 19 回で、コンテナの基礎から自社プロダクトを Kubernetes 上にデプロイしてブラウザで動作確認できるレベルまでを段階的に扱います。初回となる本記事では、コンテナ技術の概念を仮想マシンと対比しながら整理し、検証環境となる AlmaLinux 10 に Docker CE を導入して最初のコンテナを起動するところまでを実機手順で解説します。

今ここマップ（全 19 回中の現在地）

本シリーズは 6 部構成です。現在地は第 1 部「コンテナと Docker」の第 1 回です。

• 第 1 部 コンテナと Docker（第 1〜4 回）← 今ここ
• 第 2 部 Kubernetes 基礎（第 5〜6 回）
• 第 3 部 アプリリソース（第 7〜11 回）
• 第 4 部 ワークロード戦略（第 12〜14 回）
• 第 5 部 セキュリティ基礎（第 15〜16 回）
• 第 6 部 パッケージ管理と HTTPS 公開（第 17〜19 回）

この回のゴール

本記事を終えると、次の 3 点ができるようになります。記事末尾の「やってみよう」と「理解度チェック」で到達を確認してください。

• 仮想マシンとコンテナの違いを、プロセス隔離（namespace・cgroups）の観点から説明できる。
• AlmaLinux 10 に Docker CE をインストールできる。
• docker version と docker run hello-world で導入結果を確認できる。

なぜコンテナなのか — 仮想マシンとの違い

Kubernetes はコンテナを動かすための基盤です。そのため Kubernetes を学ぶ前に、まずコンテナとは何かを理解しておく必要があります。コンテナを一言でいうと「ホスト OS のカーネルを共有しながら、プロセスを隔離して動かす仕組み」です。比較対象として、従来から使われてきた仮想マシン（VM）と並べると違いが明確になります。

ハードウェア仮想化（VM）とプロセス隔離（コンテナ）

仮想マシンはハイパーバイザーが物理ハードウェアを仮想化し、その上でゲスト OS（カーネルを含む完全な OS）を丸ごと起動します。1 台の物理サーバー上に独立した OS が複数立ち上がるため隔離性は高い一方、各 VM がカーネルとシステム全体を抱えるぶん重くなります。

コンテナはホスト OS のカーネルを共有し、Linux カーネルの namespace（名前空間）でプロセス・ネットワーク・ファイルシステムの見え方を分離し、cgroups（コントロールグループ）で CPU やメモリの使用量を制限します。OS を丸ごと起動するわけではなくプロセスを隔離して動かすため、起動が速く軽量です。

起動速度・リソース効率・ポータビリティの比較

観点	仮想マシン（VM）	コンテナ
隔離の単位	ゲスト OS ごと（カーネルを含む）	プロセス（カーネルはホストと共有）
起動時間	数十秒〜分	秒以下〜数秒
イメージサイズ	GB 単位になりやすい	数十 MB〜数百 MB
リソース消費	OS ぶんのオーバーヘッドが大きい	オーバーヘッドが小さい
ポータビリティ	ハイパーバイザー依存	OCI 準拠ならどこでも動く

コンテナはカーネルを共有するぶん VM ほど強い隔離ではありません。マルチテナントで強い分離が必要な場面では VM と組み合わせる、あるいは後の巻で扱う追加のサンドボックス技術を使うといった判断になります。本シリーズでは、まずコンテナの軽量さとポータビリティを土台として活用します。

コンテナ技術の歴史と OCI 標準

chroot から cgroups / namespaces、そして Docker へ

コンテナの考え方は突然生まれたものではなく、Unix 系 OS の隔離技術の積み重ねの上にあります。流れを整理すると次のようになります。

1. chroot：プロセスから見えるルートディレクトリを切り替え、ファイルシステムを隔離する仕組み。隔離の出発点となった。
2. namespaces：プロセス ID・ネットワーク・マウントなどの見え方をプロセスごとに分離する Linux カーネルの機能。
3. cgroups：CPU・メモリなどのリソース使用量をグループ単位で制限・計測する仕組み。
4. Docker：上記のカーネル機能を組み合わせ、イメージのビルド・配布・実行を一連のコマンドで扱えるようにし、コンテナを広く普及させた。

OCI（Open Container Initiative）という標準

Docker の普及後、コンテナの形式やランタイムを特定の製品に縛られない標準として定めるために OCI（Open Container Initiative）が設立されました。OCI は大きく次の 3 つの仕様で構成されます。

• Image Specification：コンテナイメージの形式（レイヤー構成・メタデータ）の仕様。
• Runtime Specification：イメージを展開してコンテナとして実行する方法の仕様。参照実装が runc。
• Distribution Specification：レジストリでイメージを配布する方法の仕様。

AlmaLinux 10 に Docker CE を導入する

ここからは実機作業です。本シリーズの作業端末となる VM「k8s-ops」には、AlmaLinux 10.2 が最小構成でインストールされている前提とします。AlmaLinux 10 はパッケージ管理に dnf5 を採用しており、Docker CE の導入手順は従来の AlmaLinux 9 までとは一部異なります。

検証環境のプロキシ（alma-proxy）について

本シリーズの検証環境は、企業ネットワークを再現する目的で、外部接続を alma-proxy（Squid の whitelist 方式プロキシ）経由に限定しています。whitelist 方式とは、あらかじめ許可したドメインだけに通信を通す方式です。プロキシを設けていない環境ではこの節は読み飛ばして構いません。

プロキシの設定先は 2 系統あります。1 つは OS のパッケージ取得（dnf）や curl が使うプロキシで、これは AlmaLinux の初期設定（本シリーズ開始前の環境構築）で構成済みである前提です。これが未設定だと、後述の curl によるリポジトリ取得や dnf install 自体が失敗します。もう 1 つが本節で設定する Docker デーモンがイメージを取得する際に使うプロキシで、こちらは Docker 固有の設定が必要です。いずれの場合も、取得先ドメイン（download.docker.com やイメージレジストリ）が whitelist に登録されている必要があります。

Docker デーモンへのプロキシ設定は、systemd のドロップインファイルで行います。次の内容で /etc/systemd/system/docker.service.d/http-proxy.conf を作成します（実際のプロキシのホスト名・ポートに置き換えてください）。

設定ファイル：

[Service]
Environment="HTTP_PROXY=http://alma-proxy:3128"
Environment="HTTPS_PROXY=http://alma-proxy:3128"
Environment="NO_PROXY=localhost,127.0.0.1,k8s-registry"

このデーモン用プロキシ設定は、後段で docker run がイメージを取得する際に必要です。設定しないままだと docker run hello-world が Docker Hub（registry-1.docker.io）へ到達できずイメージ取得に失敗します（プロキシ環境で確認済み）。ドロップインを先に作成しておけば、後で Docker を起動した時点でこのプロキシが反映されます。OS のパッケージ取得に使う dnf 側プロキシ（前述）とは別系統である点に注意してください。

Docker CE のリポジトリを登録する（dnf5 の注意点）

AlmaLinux は RHEL / CentOS 系のため、Docker 公式が提供する CentOS 向けリポジトリを利用します。AlmaLinux 9 までは dnf config-manager --add-repo でリポジトリを追加できましたが、dnf5 ではこの --add-repo フラグが廃止されています。代替の dnf config-manager addrepo --from-repofile も、Docker のリポジトリ定義ファイルでは解析エラーになる既知の不具合があります。そこで本シリーズでは、リポジトリ定義ファイルを curl で取得して配置します。

ここで 1 点注意があります。検証環境はプロキシ経由で外部接続するため、ログインシェルにはプロキシ環境変数（https_proxy など）が設定済みですが、sudo はこれを引き継ぎません。そのため sudo curl では download.docker.com へ到達できません。一般ユーザーで取得してから sudo で所定の場所へ配置します。

実行コマンド：

$ curl -fsSL https://download.docker.com/linux/centos/docker-ce.repo -o /tmp/docker-ce.repo
$ sudo install -m 0644 /tmp/docker-ce.repo /etc/yum.repos.d/docker-ce.repo

プロキシの無い環境では sudo curl -fsSL https://download.docker.com/linux/centos/docker-ce.repo -o /etc/yum.repos.d/docker-ce.repo で直接配置して構いません。

Docker CE をインストールして起動する

リポジトリを登録したら、Docker 本体と関連パッケージをまとめてインストールします。

実行コマンド：

# dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

インストールが終わったら、Docker サービスを有効化して起動します。--now を付けると、サービスの自動起動設定（enable）と即時起動（start）を 1 回のコマンドで実行できます。プロキシを設定した場合は、設定を反映するため先に daemon-reload を実行します。

実行コマンド：

# systemctl daemon-reload
# systemctl enable --now docker

一般ユーザーで docker を実行できるようにする

Docker デーモンは root 権限で動作するため、初期状態では一般ユーザーが docker コマンドを実行するたびに sudo が必要です。作業ユーザー（ここでは developer）を docker グループに追加すると、sudo なしで実行できます。グループの変更を反映するには、追加後に一度ログインし直してください。

実行コマンド：

# usermod -aG docker developer

初めてのコンテナを起動する

docker version でクライアントとサーバーを確認する

導入が成功したか、まずバージョンを確認します。docker version は、コマンドを実行するクライアントと、実際にコンテナを動かすサーバー（Docker Engine）の双方のバージョンを表示します。

実行コマンド：

$ docker version

実行結果（抜粋・バージョン番号は導入時期により異なります）：

Client: Docker Engine - Community
 Version:           29.6.0
 API version:       1.55
 ...
Server: Docker Engine - Community
 Engine:
  Version:          29.6.0
  API version:      1.55 (minimum version 1.40)
 containerd:
  Version:          v2.2.5
 runc:
  Version:          1.3.6
 docker-init:
  Version:          0.19.0

Client（コマンド側）と Server（Docker Engine 側）の両方に Version が表示されている点が重要です。Server 側が表示されれば、デーモンが起動し、現在のユーザーから接続できています。Server 側が表示されず権限エラーになる場合は、docker グループ追加後にログインし直せているかを確認してください。

docker run hello-world で動作を確認する

最後に、動作確認用の小さなイメージ hello-world を実行します。ローカルにイメージが無い場合、Docker はレジストリから自動で取得（pull）してからコンテナを起動します。この一連の流れがコンテナ実行の基本です。

実行コマンド：

$ docker run hello-world

実行結果：

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
4f55086f7dd0: Pull complete
Digest: sha256:96498ffd522e70807ab6384a5c0485a79b9c7c08ca79ba08623edcad1054e62d
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

「Hello from Docker!」が表示されれば、イメージの取得・コンテナの起動・実行・終了までが一通り動作しています。これでコンテナを動かす準備ができました。

やってみよう

本記事の内容を実機で再現します。次の手順を順に実行してください。

1. AlmaLinux 10 の k8s-ops に、curl で Docker CE のリポジトリ定義ファイルを配置する。
2. dnf install で Docker CE 関連パッケージをインストールする。
3. systemctl enable --now docker でサービスを起動する。
4. 作業ユーザーを docker グループに追加し、ログインし直す。
5. docker version でサーバー側のバージョンが表示されることを確認する。
6. docker run hello-world を実行し、「Hello from Docker!」が表示されることを確認する。

理解度チェック

次の各文が正しいか（○）誤りか（×）を判断してください。解答は下にまとめています。

1. コンテナはゲスト OS のカーネルを VM と同様に丸ごと起動して隔離する。
2. コンテナの隔離は Linux カーネルの namespace と cgroups によって実現されている。
3. OCI は Image / Runtime / Distribution の各仕様でコンテナの標準を定めている。
4. Kubernetes はコンテナランタイムとして Docker を必須とする。
5. AlmaLinux 10 の dnf5 では dnf config-manager --add-repo がそのまま使える。
6. systemctl enable --now docker は自動起動設定と即時起動をまとめて行う。
7. docker グループにユーザーを追加すると sudo なしで docker を実行できる。

解答

• 1. ×：コンテナはホスト OS のカーネルを共有する。カーネルを丸ごと起動するのは VM。
• 2. ○：namespace で見え方を分離し、cgroups でリソースを制限する。
• 3. ○：OCI は 3 つの仕様でコンテナの形式・実行・配布を標準化している。
• 4. ×：Kubernetes は containerd 等を使い、Docker は必須ではない。ただし Docker の知識は OCI 標準を介して通用する。
• 5. ×：dnf5 では --add-repo が廃止されている。本記事では curl でリポジトリ定義ファイルを配置した。
• 6. ○：--now により enable と start を 1 回で実行できる。
• 7. ○：docker グループ追加後にログインし直すと sudo なしで実行できる。

まとめ

本記事では、コンテナと仮想マシンの違いをプロセス隔離の観点から整理し、コンテナ技術の歴史と OCI 標準を確認しました。そのうえで AlmaLinux 10 に Docker CE を導入し、docker run hello-world で最初のコンテナを起動しました。dnf5 でのリポジトリ登録方法の変更点と、whitelist プロキシ環境での注意点もあわせて押さえました。これでコンテナを動かす土台が整い、次回以降の Docker 操作に進む準備ができています。

次回予告

次回（第 2 回）は Docker の基本操作を扱います。イメージの取得、コンテナの起動・停止・削除、ログ確認、ポート公開によるブラウザからのアクセスまでを実機で確認し、コンテナのライフサイクルを実機で習得します。

シリーズ一覧

第1部：コンテナと Docker

• 第1回 コンテナ技術概念 + Docker 環境準備 ← 今ここ
• 第2回 Docker 基本操作
• 第3回 Dockerfile + マルチステージ + JDK 25 / Payara Micro イメージビルド
• 第4回 コンテナレジストリ + イメージタグ戦略 + Trivy スキャン

第2部：Kubernetes 基礎

• 第5回 Kubernetes の全体像 + kind で軽量 K8s
• 第6回 kubectl 基本操作 + Observability・Debug

第3部：アプリリソース

• 第7回 Pod + Multi-container パターン
• 第8回 Service とネットワーキング
• 第9回 ストレージ（PVC + StatefulSet）+ PostgreSQL DB 追加
• 第10回 ConfigMap + Secret + ServiceAccount 基礎
• 第11回 Job + CronJob + DaemonSet

第4部：ワークロード戦略

• 第12回 Deployment + 3 Probe + Rolling Update + Probe デバッグ実践
• 第13回 Deployment 戦略補完（Blue/Green + Canary + Recreate）
• 第14回 ResourceQuota + LimitRange + Multi-tenant Namespace

第5部：セキュリティ基礎

• 第15回 RBAC + SecurityContext + Admission Controller 概念 + CRD 利用
• 第16回 NetworkPolicy 基礎

第6部：パッケージ管理 + HTTPS 公開

• 第17回 Helm v4 + chart 化 + フルサイクル
• 第18回 Gateway API + HTTPRoute + Ingress 対比 + Traefik + cert-manager
• 第19回 fanclub-api 全機構連携の実技総ざらい総合演習 + 第1巻完走宣言 ★