コンテナとは何か＋Docker環境構築【CKAD第1回】

第1回スコープ・学習目標・今ここマップ

動作確認バージョン: Docker CE 29.4.3 / containerd 2.2.3 / runc 1.3.5 / AlmaLinux 10.1 (Heliotrope Lion・kernel 6.12.0-124.55.3.el10_1) / alma-proxy Squid 6.10（2026-05-09 時点・k8s-ops 実機検証済・SP_ops-clean 起点）

本回は Kubernetes 実践教科書 第1巻（CKAD 対応・全 19 回）の第1回です。第1部「コンテナと Docker」の全 4 回のうち、第1回でコンテナの基礎概念と Docker CE のインストールを扱います。

今ここマップ（第1巻 19 回中の現在位置）：

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

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

第1回を終えると、以下を習得した状態になります。

• VM とコンテナの違い（プロセス隔離 vs ハードウェア仮想化）を説明できる
• OCI 標準（イメージ仕様 / ランタイム仕様）の意義を説明できる
• AlmaLinux 10 の k8s-ops に Docker CE をインストールできる
• alma-proxy 経由でのインターネット接続の仕組みを把握している
• docker version / docker run hello-world で Docker の初動確認を完了している

シリーズ全体オリエンテーション

このシリーズは技術書三部作として設計されています。第1巻（全 19 回・CKAD 対応）でコンテナ基礎から Kubernetes 上へのアプリデプロイまでを習得し、第2巻（CKA 対応）では本番 kubeadm HA クラスタの構築・運用、第3巻（CKS + SRE 対応）ではセキュリティ・可用性・DR を扱います。

三部作完走後は CKAD + CKA + CKS + KCNA + KCSA の 5 冠を目指す「Kubestronaut」が次の目標となります。

第1巻 19 回の構成：

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

第1巻の完走マイルストーン（第19回）：模擬アプリ「fanclub-api」（Java JDK 25 + Payara Micro 7.2026.4 + PostgreSQL 18）の全 14 機構を通しで連携させ、https://fanclub.local から CRUD 操作（会員登録・一覧・編集・削除）が動作することを確認します。この状態が「CKAD 受験準備完了」の目安です。

この回での模擬アプリ進捗：第1回はコンテナ概念と Docker 環境準備が主題です。fanclub-api 本体は第3回（Dockerfile 作成）で初登場します。

コンテナとは何か

コンテナとは、Linux カーネルの「cgroups（コントロールグループ）」と「namespaces（名前空間）」を組み合わせてプロセスを隔離する技術です。コンテナの実体は「隔離されたプロセス」であり、VM のように独立した OS カーネルを持ちません。

• cgroups：CPU・メモリ・I/O リソースを制限する仕組み。コンテナが使用できるリソース量を OS カーネルレベルで管理する
• namespaces：PID・ネットワーク・ファイルシステム・ユーザーなどの「見え方」を隔離する仕組み。コンテナから見えるリソースの範囲を限定する

VM との比較：

比較項目	VM（仮想マシン）	コンテナ
隔離の仕組み	ハードウェア仮想化（Hypervisor）	OS カーネル機能（cgroups + namespaces）
OS カーネル	独立した OS カーネルを持つ	ホスト OS のカーネルを共有
起動時間	分単位	秒単位（多くは 1 秒以内）
イメージサイズ	GB 単位	MB〜数百 MB 単位
メモリオーバーヘッド	大（Guest OS 分）	小（プロセス分のみ）
隔離の強度	強い（カーネルレベル）	中（カーネル共有のためゼロデイ攻撃に注意）
主な用途	OS レベルの隔離が必要な場面	アプリのパッケージングと配布

構造を図で確認します。

namespaces の主要 3 種（コンテナ運用で頻出・本書必修）：

namespace 種別	隔離する内容
PID namespace	プロセス ID の見え方（コンテナ内の PID 1 はホスト上では別の PID）
Network namespace	ネットワークインタフェース・IP アドレス・ルーティングテーブル
Mount namespace	ファイルシステムのマウントポイント

残り 3 種（補足・教養レベル）：UTS namespace（ホスト名・ドメイン名）/ User namespace（UID/GID マッピング・コンテナ内 root とホスト root は異なる）/ IPC namespace（System V IPC・POSIX メッセージキュー）。CKAD 試験では主要 3 種を把握していれば十分です。

コンテナ技術の歴史

コンテナ技術は数十年かけて積み重なった技術の産物です。歴史的な流れを把握しておくと、「なぜ Docker が登場したか」「なぜ OCI 標準が必要になったか」が理解しやすくなります。

時期	技術・出来事	意義
1979年	chroot	ファイルシステムのルートディレクトリを変更する最初の隔離技術
2000年代初頭	FreeBSD Jails / Solaris Zones	OS レベルの完全な隔離環境
2008年	cgroups Linux カーネルに統合	リソース制限の基盤が OS に組み込まれた
2008年	LXC（Linux Containers） 登場	cgroups + namespaces の組み合わせによる最初のコンテナランタイム
2013年	Docker 登場	LXC の複雑さをラップし、イメージ管理・配布を統合。コンテナを一般普及させた
2014年	Kubernetes 登場（Google 内部の Borg が原点）	コンテナのオーケストレーション
2015年	OCI（Open Container Initiative） 設立	Docker が独占しないよう標準化を推進
2016年	containerd Docker から切り出し	OCI 準拠のコンテナランタイムとして独立
2020年	Kubernetes が Docker を CRI から廃止予告	CRI-O / containerd が主流へ
2022年	Kubernetes v1.24 で dockershim 完全削除	containerd・CRI-O が K8s の標準ランタイムに

現在（2026年）の文脈：Kubernetes は Docker を使わず containerd を直接使用します。しかし Docker のイメージ形式（OCI Image Spec）は業界標準として生き続けています。Docker の知識は OCI 標準経由で Kubernetes でも有効です。

CRI（Container Runtime Interface）補足：kubelet とコンテナランタイム（containerd / CRI-O 等）の通信を標準化した API です。Kubernetes が特定のランタイムに依存しないように設計されており、第5回以降の kind でも CRI 経由で containerd を呼び出します。

OCI 標準とは

OCI（Open Container Initiative）は、2015 年に Linux Foundation のもとで設立されたコンテナ技術の標準化団体です。Docker・Google・CoreOS・Red Hat 等が参加し、「ベンダー中立なコンテナ標準」を定めました。

OCI が定める 2 つの仕様：

仕様	正式名称	内容
OCI Image Spec	OCI Image Format Specification	コンテナイメージのファイル形式・レイヤー構造・マニフェスト
OCI Runtime Spec	OCI Runtime Specification	コンテナを起動・停止・削除する方法（runc が実装）

Docker / containerd / Kubernetes の関係図：

Docker CLI でビルドした OCI イメージは、Kubernetes 上の containerd でもそのまま使用できます。「Docker で学んだイメージのノウハウが K8s でも活きる」のは OCI 標準があるためです。

本シリーズの環境設計

第1巻で使用する VM は 2 台のみです。kind クラスタは k8s-ops 上の Docker 内で動作するため、Kubernetes 学習用の追加 VM は不要です。

第1巻で使用する VM（全 2 台）：

VM名	IP	スペック（vCPU / RAM / Disk）	役割	導入回
k8s-ops	192.168.1.122	2 / 6 GB / 40 GB	作業端末（Docker CE・kubectl・Helm v4・JDK 25・Maven・kind）	第1回（今回）
k8s-registry	192.168.1.123	2 / 4 GB / 50 GB	コンテナレジストリ（Docker Registry）	第4回

alma-proxy（192.168.1.121・Squid 6.10・whitelist 方式）は第1巻では任意です。企業ネットワーク環境の教育的再現として本回で紹介します。第2巻以降では必須となります。

接続経路（alma-proxy 経由の場合）：

k8s-ops（作業端末 192.168.1.122）
  ↓ Squid 経由
alma-proxy（192.168.1.121）
  ↓
インターネット（Docker Hub・download.docker.com 等）

第2巻以降の拡張予告：第2巻では、この 2 VM 環境に k8s-lb・k8s-cp-01〜03・k8s-wl-01〜02 を追加した合計 9 VM 環境で、本番規模の kubeadm HA クラスタを構築します。第1巻の kind 環境で学んだ知識はそのまま移転できます。

やってみよう ① k8s-ops に Docker CE をインストールする

前提状態：k8s-ops（AlmaLinux 10.1）はインストール済み・基本設定済み

アンチパターン警告：Web 上で広く紹介されている curl -fsSL https://get.docker.com | sudo bash 形式のワンライナーは本シリーズでは採用しません。理由は 3 点あります。(1) 配布スクリプトが想定する OS 判定ロジックが AlmaLinux 10 / dnf5 環境を完全にカバーしているとは限らない。(2) 実行されるコマンドが事前に確認できず監査が困難。(3) 企業環境のプロキシ・whitelist 制約と相性が悪い。

本書では dnf install で公式リポジトリ経由の正攻法を採用します。

ステップ1：プロキシ設定の確認

alma-proxy を使用する場合、/etc/environment または /etc/profile.d/proxy.conf にプロキシ設定を恒久設定しておきます。確認コマンドを実行します。

実行コマンド：

$ echo $http_proxy

実行結果：

http://192.168.1.121:3128

空白が返る場合はプロキシ未設定です。alma-proxy を使用する場合は以下を /etc/environment に追記してください（直接接続の場合はこの手順をスキップ）。

実行コマンド：

$ sudo tee -a /etc/environment <<'EOF'
http_proxy=http://192.168.1.121:3128
https_proxy=http://192.168.1.121:3128
no_proxy=localhost,127.0.0.1,192.168.1.0/24
EOF

sudo -E の注記：sudo dnf install を実行するとき、sudo のセキュアパスで環境変数が剥ぎ取られる場合があります。確実にプロキシ設定を子プロセスに継承するには sudo -E dnf install ... のように -E オプションを付与してください。

ステップ2：Docker CE 公式リポジトリを追加

AlmaLinux 10 は dnf5 を採用しており、dnf config-manager --from-repofile オプションは廃止されています。curl で .repo ファイルを直接配置します。

実行コマンド：

$ sudo -E curl -o /etc/yum.repos.d/docker-ce.repo \
    https://download.docker.com/linux/rhel/docker-ce.repo

実行結果：

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  2025  100  2025    0     0   3456      0 --:--:-- --:--:-- --:--:--  3453

ステップ3：Docker CE をインストール

実行コマンド：

$ sudo -E dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

実行結果（インストール完了部分抜粋）：

パッケージのダウンロード:
(1/2): docker-ce-29.4.3-1.el10.x86_64.rpm        48 MB/s |  24 MB     00:00
(2/2): docker-ce-cli-29.4.3-1.el10.x86_64.rpm    14 MB/s | 8.6 MB     00:00
--------------------------------------------------------------------------------
合計                                             54 MB/s |  32 MB     00:00
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
（トランザクション実行詳細はインストール完了部分まで省略）
インストール済み:
  container-selinux-4:2.240.0-10.el10_1.noarch
  containerd.io-2.2.3-1.el10.x86_64
  docker-buildx-plugin-0.33.0-1.el10.x86_64
  docker-ce-3:29.4.3-1.el10.x86_64
  docker-ce-cli-1:29.4.3-1.el10.x86_64
  docker-ce-rootless-extras-29.4.3-1.el10.x86_64
  docker-compose-plugin-5.1.3-1.el10.x86_64
  passt-0^20250512.g8ec1341-5.el10_1.x86_64
  passt-selinux-0^20250512.g8ec1341-5.el10_1.noarch
  tar-2:1.35-9.el10_1.x86_64

完了しました!

ステップ4：Docker サービスを起動・自動起動設定

実行コマンド：

$ sudo systemctl enable --now docker

実行結果：

Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /usr/lib/systemd/system/docker.service.

ステップ5：developer ユーザーを docker グループに追加

実行コマンド：

$ sudo usermod -aG docker developer

グループへの追加を現在のシェルセッションに反映します。

実行コマンド：

$ newgrp docker

グループ所属を確認します。

実行コマンド：

$ id -nG developer

実行結果：

developer wheel docker

docker グループが含まれていれば、sudo なしで docker コマンドを実行できます。

ステップ6：Docker サービス稼働確認

実行コマンド：

$ sudo systemctl is-active docker

実行結果：

active

続いて docker info でシステム情報を確認します。

実行コマンド：

$ docker info

実行結果：

Client: Docker Engine - Community
 Version:    29.4.3
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.33.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.1.3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 1
  Running: 0
  Paused: 0
  Stopped: 1
 Images: 1
 Server Version: 29.4.3
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
 runc version: v1.3.5-0-g488fc13e
 init version: de40ad0
 Security Options:
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.12.0-124.55.3.el10_1.x86_64
 Operating System: AlmaLinux 10.1 (Heliotrope Lion)
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 5.53GiB
 Name: k8s-ops
 ID: d573c668-a78f-4ade-a76c-c39e5484eae8
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 HTTP Proxy: http://192.168.1.121:3128
 HTTPS Proxy: http://192.168.1.121:3128
 No Proxy: localhost,127.0.0.1,192.168.1.0/24,10.0.10.0/24
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
  ::1/128
 Live Restore Enabled: false
 Firewall Backend: iptables+firewalld

Cgroup Version: 2 と Cgroup Driver: systemd が表示されれば、AlmaLinux 10（cgroup v2）での Docker CE 動作確認完了です。

Docker 29.x では Storage Driver が従来の overlay2 から overlayfs（driver-type: io.containerd.snapshotter.v1）に変更されており、containerd snapshotter ベースのストレージ管理に移行しています。また Firewall Backend: iptables+firewalld は AlmaLinux 10 の firewalld 連携を反映した新しい表示項目です。

alma-proxy 経由の接続体験（企業ネットワーク再現）

注意: 第1巻で alma-proxy は 任意 です。直接インターネット接続で進める場合は本セクションをスキップして H2「やってみよう ② docker version + hello-world で初体験」へ進んでください。本セクションは「企業ネットワーク再現の教育的補講」として、alma-proxy 経由構成を選択した読者向けに提供します。第2巻以降では alma-proxy が必須となります。

alma-proxy（Squid 6.10）は「whitelist 方式」で運用しています。許可リスト（/etc/squid/whitelist.txt）に登録されたドメインのみ通信が通り、それ以外は 403 Forbidden となります。

whitelist 方式の意図：本シリーズで使用する alma-proxy は、多くの日本企業の情報システム環境で見られる「出口制御プロキシ」を再現しています。新卒エンジニアが現場に入った際、「なぜ curl が失敗するのか」「なぜ dnf install が失敗するのか」という問題に直面したとき、プロキシの挙動を理解していることは実務上重要です。

第1回で使用する whitelist ドメイン：

ドメイン	用途
download.docker.com	Docker CE リポジトリ
index.docker.io	Docker Hub インデックス
registry-1.docker.io	Docker Hub（イメージ pull）
auth.docker.io	Docker Hub 認証
production.cloudflare.docker.com	Docker Hub CDN
*.r2.cloudflarestorage.com	Docker Hub Cloudflare R2 ストレージ

プロキシ設定の確認：

実行コマンド：

$ cat /etc/environment

実行結果（例）：

http_proxy=http://192.168.1.121:3128
https_proxy=http://192.168.1.121:3128
no_proxy=localhost,127.0.0.1,192.168.1.0/24

Docker daemon にもプロキシ設定が必要です。systemd ドロップインファイルで設定します。確認コマンドを実行します。

実行コマンド：

$ cat /etc/systemd/system/docker.service.d/http-proxy.conf

実行結果：

[Service]
Environment="HTTP_PROXY=http://192.168.1.121:3128"
Environment="HTTPS_PROXY=http://192.168.1.121:3128"
Environment="NO_PROXY=localhost,127.0.0.1,192.168.1.121,192.168.1.123"

Docker daemon のプロキシ設定がなければ、docker pull 時に Docker Hub への通信が通らず「Error response from daemon: Get "https://registry-1.docker.io/..."」となります。Docker daemon 側のプロキシ設定は /etc/environment のユーザー環境変数とは別に管理する点に注意が必要です。

NO_PROXY の差異について: /etc/environment の no_proxy はユーザー環境変数（dnf や curl 等のクライアントツール用）で、Docker daemon の NO_PROXY（systemd ドロップイン）はコンテナ間通信や image pull 用と用途が異なります。

第2巻以降では Docker daemon 側に Kubernetes Pod CIDR（10.244.0.0/16）や Service CIDR（10.96.0.0/16）等の追加エントリも必要になるため、docker info の出力で No Proxy セクションを確認する習慣をつけることを推奨します。

やってみよう ② docker version + hello-world で初体験

Docker のインストールが完了したら、最終確認として docker version と docker run hello-world を実行します。

ステップ1：Docker バージョン確認

実行コマンド：

$ docker version

実行結果：

Client: Docker Engine - Community
 Version:           29.4.3
 API version:       1.54
 Go version:        go1.26.2
 Git commit:        055a478
 Built:             Wed May  6 17:11:02 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.4.3
  API version:      1.54 (minimum version 1.40)
  Go version:       go1.26.2
  Git commit:       56be731
  Built:            Wed May  6 17:07:08 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.3
  GitCommit:        77c84241c7cbdd9b4eca2591793e3d4f4317c590
 runc:
  Version:          1.3.5
  GitCommit:        v1.3.5-0-g488fc13e
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Client と Server の両方が表示されれば、Docker CLI と Docker デーモンが正常に通信できています。

ステップ2：hello-world コンテナを起動

実行コマンド：

$ docker run hello-world

実行結果：

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
4f55086f7dd0: Pulling fs layer
d5e71e642bf5: Download complete
4f55086f7dd0: Download complete
4f55086f7dd0: Pull complete
Digest: sha256:f9078146db2e05e794366b1bfe584a14ea6317f44027d10ef7dad65279026885
Status: Downloaded newer image for hello-world:latest

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

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (amd64)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

Hello from Docker! が表示されれば第1回の演習は完了です。alma-proxy 経由で Docker Hub からイメージを取得できたことを意味します。

ステップ3：イメージの確認

実行コマンド：

$ docker images

実行結果：

IMAGE                ID             DISK USAGE   CONTENT SIZE   EXTRA
hello-world:latest   f9078146db2e       21.8kB         9.49kB   U
WARNING: This output is designed for human readability. For machine-readable output, please use --format.

hello-world イメージが表示されれば、Docker Hub からのイメージ取得と保存が正常に機能しています。Docker 29.x では docker images の出力フォーマットが変更され、従来の REPOSITORY/TAG/IMAGE ID/CREATED/SIZE 形式から DISK USAGE・CONTENT SIZE・EXTRA 列を含む新形式になっています。

スクリプトなどで機械可読な出力が必要な場合は docker images --format "{{.Repository}}:{{.Tag}}" のように --format オプションを使用してください。

現場ヒヤリハット：rootless Docker と rootful Docker の混在で sudo 権限が混乱した

入社 2 ヶ月目の新人エンジニア A さんは、ローカル開発環境に Docker をインストールしました。調べながら進めた結果、一部の手順は sudo docker で、別の手順は docker（sudo なし）で実行するという状況になりました。

docker info は通るのに docker ps がエラーになる、sudo docker pull は成功するのに docker run は「permission denied」になる、という問題が頻発しました。

原因は 2 つの Docker が混在していたことです。sudo dnf install docker-ce で rootful Docker（/var/run/docker.sock を使う通常の Docker）をインストールした後、別の手順で dockerd-rootless-setuptool.sh を実行して rootless Docker（ユーザー権限で動く Docker）もインストールしてしまいました。

2 つの Docker デーモンが異なる socket を使って並走していたため、コマンドによって「どちらの Docker に繋いでいるか」が変わっていたのです。

教訓と対処法：

• 本シリーズでの採用：学習・検証目的のため、rootful Docker（通常の Docker CE）を採用します。developer ユーザーを docker グループに追加することで sudo なしで実行できます
• rootless Docker の本来の用途：本番サーバーや CI/CD 環境でセキュリティ要件が高い場合に採用します。kind との組み合わせも可能ですが、設定が複雑になります
• 混在を防ぐ：docker context ls で現在どのコンテキスト（socket の向き先）を使っているかを確認する習慣をつけてください

実行コマンド：

$ docker context ls

実行結果：

NAME        DESCRIPTION                               DOCKER ENDPOINT
default *   Current DOCKER_HOST based configuration   unix:///var/run/docker.sock

default * で unix:///var/run/docker.sock が表示されれば、rootful Docker を使用中です。

補足：cgroup v1 vs v2 の互換性：AlmaLinux 10 は cgroup v2 のみをサポート（cgroup v1 は廃止）。Docker CE 23.0 以降は cgroup v2 に正式対応しているため本シリーズでは問題ありません。旧来の手順書で --cgroup-parent や cgroup v1 前提のスクリプトを使う場合は注意が必要です。

第1巻の完走マイルストーン予告

第1巻の完走マイルストーンは第19回（最終回）です。第1回で Docker をインストールした k8s-ops 上で、模擬アプリ「fanclub-api」を段階的に構築していきます。

第3回:  Dockerfile で Java + Payara Micro バックエンドをビルド（v0.1.0）
第4回:  コンテナレジストリ（k8s-registry）にイメージを push（v0.2.0）
第5回:  kind で Kubernetes クラスタを起動
第7〜10回: Pod → Service → StatefulSet（PostgreSQL）+ ConfigMap/Secret で 3 層構成完成（第3部 アプリリソース）
第11回:    Job + CronJob + DaemonSet（バッチワークロード追加）
第12〜14回: Deployment + 3 Probe + Rolling Update / Blue-Green + Canary 戦略 / ResourceQuota（第4部 ワークロード戦略）
第15〜16回: RBAC + SecurityContext + Admission / NetworkPolicy（第5部 セキュリティ基礎）
第17回:    Helm v4 chart 化フルサイクル（v1.0.0）
第18回:    Gateway API + Traefik + cert-manager で https://fanclub.local を HTTPS 公開
第19回:    ★ 全 14 機構を通しで連携 → ブラウザで CRUD 操作 = CKAD 受験準備完了

第19回完走時点で、https://fanclub.local にアクセスしてファンクラブ会員の「登録・一覧・編集・削除」がブラウザから動作することを確認します。これが第1巻の完走宣言です。

詳しくは 第19回 fanclub-api 全機構連携の実技総ざらい総合演習（完走マイルストーン） を参照してください。

今回のまとめ + 理解度チェック

第1回では以下を実施しました。

• コンテナの仕組み（cgroups + namespaces によるプロセス隔離）と VM との違いを確認した
• コンテナ技術の歴史（chroot → LXC → Docker → OCI）の流れを把握した
• OCI 標準（Image Spec / Runtime Spec）が Docker と Kubernetes をつなぐ共通基盤であることを理解した
• AlmaLinux 10 の k8s-ops に Docker CE をインストールし、alma-proxy 経由で Docker Hub からイメージを pull できた
• docker run hello-world でコンテナの初起動を完了した

理解度チェック（○×形式・全 7 問）

問	問題文	解答
1	コンテナは VM と同様に、それぞれ独立した OS カーネルを持つ	×
2	Linux の cgroups は、プロセスの CPU やメモリリソースを制限する仕組みである	○
3	OCI（Open Container Initiative）は、コンテナのイメージ形式と起動方式を標準化する団体である	○
4	Kubernetes v1.24 以降、dockershim は Kubernetes から削除され、containerd が標準ランタイムとして使われる	○
5	AlmaLinux 10 の Docker CE 環境では、cgroup v1 が使用される	×
6	docker run hello-world でエラーが出た場合、Docker デーモンが起動していない可能性がある	○
7	rootless Docker は Docker デーモンを root 権限なしで起動でき、セキュリティが高いが設定が複雑になる	○

解説（重要問のみ）

• 問1：コンテナはホスト OS のカーネルを共有します。独立したカーネルを持つのは VM です。
• 問5：AlmaLinux 10 は cgroup v2 のみをサポートしています。Docker CE 23.0 以降は cgroup v2 に対応済みのため問題ありません。

次回予告：第2回「Docker 基本操作」では、インストールした Docker を使い、イメージの pull・コンテナの起動・停止・削除・ログ確認を一通り習得します。docker pull / docker run / docker stop / docker rm のコマンド操作から、Nginx コンテナを起動してホストのブラウザからアクセスする演習まで実施します。

シリーズ一覧

第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巻完走宣言 ★