# AWS EKS の場合の構成例
# EC2 インスタンス (VM) が Kubernetes ワーカーノードとして動作
# その上で Pod (コンテナ) が実行される
 
# ワーカーノード (VM) の確認
kubectl get nodes -o wide
# NAME                         STATUS   ROLES    AGE   VERSION
# ip-10-0-1-100.ec2.internal   Ready    <none>   5d    v1.28.3
# ip-10-0-2-200.ec2.internal   Ready    <none>   5d    v1.28.3
 
# Pod (コンテナ) の確認
kubectl get pods -o wide
# NAME                    READY   STATUS    NODE
# web-7d8f9c-abc12        1/1     Running   ip-10-0-1-100.ec2.internal
# api-5b6c7d-def34        1/1     Running   ip-10-0-2-200.ec2.internal

# ===================================
# 1. PID namespace - プロセスIDの分離
# ===================================
# コンテナ内ではPID 1から始まる独立したプロセスツリー
docker run --rm alpine ps aux
# PID   USER     COMMAND
#   1   root     ps aux
 
# ホスト側から見るとコンテナプロセスは別のPIDを持つ
docker run -d --name test-pid alpine sleep 3600
docker inspect --format '{{.State.Pid}}' test-pid
# 例: 45678 (ホスト側のPID)
 
# コンテナ内から見たPID
docker exec test-pid ps aux
# PID   USER     COMMAND
#   1   root     sleep 3600
 
# /proc ファイルシステムでnamespaceを確認
docker exec test-pid ls -la /proc/1/ns/pid
# lrwxrwxrwx 1 root root 0 /proc/1/ns/pid -> 'pid:[4026532456]'
 
docker rm -f test-pid
 
# ===================================
# 2. Network namespace - ネットワークスタックの分離
# ===================================
# 各コンテナは独自のネットワークインターフェース、IPアドレス、
# ルーティングテーブル、iptablesルールを持つ
docker run --rm alpine ip addr
# 1: lo: <LOOPBACK,UP,LOWER_UP>
#     inet 127.0.0.1/8 scope host lo
# 2: eth0@if123: <BROADCAST,MULTICAST,UP,LOWER_UP>
#     inet 172.17.0.2/16 brd 172.17.255.255
 
# ネットワーク名前空間の一覧（ホスト側）
sudo ip netns list
 
# コンテナのネットワーク設定を詳細確認
docker run --rm alpine sh -c "ip route && echo '---' && ip addr && echo '---' && cat /etc/resolv.conf"
 
# ===================================
# 3. Mount namespace - ファイルシステムの分離
# ===================================
# コンテナは独自のマウントポイントを持つ
docker run --rm alpine ls /
# bin    etc    lib    mnt    proc   run    srv    tmp    var
# dev    home   media  opt    root   sbin   sys    usr
 
# ホストのファイルシステムとは完全に分離されている
docker run --rm alpine cat /etc/os-release
# NAME="Alpine Linux"
 
# マウントポイントの確認
docker run --rm alpine mount
# overlay on / type overlay (...)
# proc on /proc type proc (...)
# tmpfs on /dev type tmpfs (...)
 
# ===================================
# 4. UTS namespace - ホスト名の分離
# ===================================
# 各コンテナは独自のホスト名を持つ
docker run --rm --hostname my-container alpine hostname
# my-container
 
docker run --rm alpine hostname
# ランダムな12文字のコンテナID
 
# ===================================
# 5. IPC namespace - プロセス間通信の分離
# ===================================
# 共有メモリ、セマフォ、メッセージキューの分離
docker run --rm alpine ipcs
# ------ Message Queues --------
# ------ Shared Memory Segments --------
# ------ Semaphore Arrays --------
 
# ===================================
# 6. User namespace - ユーザーIDの分離
# ===================================
# コンテナ内のroot(UID 0)をホストの非特権ユーザーにマッピング
docker run --rm alpine id
# uid=0(root) gid=0(root) groups=0(root)
 
# rootless モードでの実行
# コンテナ内のroot -> ホストの非特権ユーザー
docker run --rm --userns=host alpine cat /proc/self/uid_map
#          0       1000          1
 
# ===================================
# 7. Cgroup namespace (Linux 4.6+)
# ===================================
# cgroupファイルシステムの仮想化
docker run --rm alpine cat /proc/self/cgroup
# 0::/
 
# ===================================
# 8. Time namespace (Linux 5.6+)
# ===================================
# CLOCK_MONOTONIC と CLOCK_BOOTTIME の仮想化
# コンテナごとに異なるブート時間を設定可能

# ===================================
# cgroups v1 と v2 の確認
# ===================================
# cgroups バージョンの確認
stat -fc %T /sys/fs/cgroup/
# cgroup2fs -> cgroups v2
# tmpfs     -> cgroups v1
 
# Docker が使用している cgroup driver の確認
docker info | grep -i cgroup
# Cgroup Driver: systemd
# Cgroup Version: 2
 
# ===================================
# メモリ制限
# ===================================
# メモリを256MBに制限
docker run --memory=256m --rm alpine free -m
 
# メモリ + スワップの制限
docker run --memory=256m --memory-swap=512m --rm alpine free -m
 
# メモリ予約（ソフトリミット）
docker run --memory=512m --memory-reservation=256m --rm nginx
 
# OOM (Out Of Memory) の挙動制御
docker run --memory=64m --oom-kill-disable --rm stress-ng --vm 1 --vm-bytes 128m
# OOM Killer を無効化（危険: ホスト全体に影響する可能性）
 
# ===================================
# CPU 制限
# ===================================
# CPUを1コアに制限
docker run --cpus=1.0 --rm alpine cat /proc/cpuinfo
 
# CPU シェア（相対的な重み付け）
docker run --cpu-shares=1024 --rm nginx   # デフォルト
docker run --cpu-shares=512 --rm nginx    # 半分の重み
 
# 特定のCPUコアに固定（CPU ピニング）
docker run --cpuset-cpus="0,1" --rm nginx  # CPU 0 と 1 のみ使用
docker run --cpuset-cpus="0-3" --rm nginx  # CPU 0〜3 を使用
 
# CPU クォータ（周期ベースの制限）
docker run --cpu-period=100000 --cpu-quota=50000 --rm nginx
# 100ms あたり 50ms の CPU 時間 = 0.5 CPU
 
# ===================================
# I/O 制限
# ===================================
# ブロックデバイスの読み書き速度制限
docker run --device-read-bps=/dev/sda:1mb --rm alpine dd if=/dev/zero of=/tmp/test bs=1M count=10
docker run --device-write-bps=/dev/sda:1mb --rm alpine dd if=/dev/zero of=/tmp/test bs=1M count=10
 
# I/O ウェイト（相対的な重み付け）
docker run --blkio-weight=500 --rm nginx  # デフォルト: 500, 範囲: 10-1000
 
# ===================================
# プロセス数制限 (pids cgroup)
# ===================================
docker run --pids-limit=100 --rm alpine sh -c "ulimit -u"
# Fork Bomb 対策として重要
 
# ===================================
# リソース使用状況の確認
# ===================================
docker stats --no-stream
# CONTAINER ID   NAME     CPU %   MEM USAGE / LIMIT   MEM %   NET I/O       BLOCK I/O    PIDS
# abc123def456   web      0.50%   45.2MiB / 256MiB    17.66%  1.2kB / 0B    8.19kB / 0B  5
 
# 特定のコンテナの詳細なリソース情報
docker stats --no-stream --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.PIDs}}"
 
# cgroup ファイルシステムから直接情報を取得
docker run -d --name cgroup-test --memory=256m nginx
CONTAINER_ID=$(docker inspect --format '{{.Id}}' cgroup-test)
# cgroups v2 の場合
cat /sys/fs/cgroup/system.slice/docker-${CONTAINER_ID}.scope/memory.max
# 268435456 (256MB)
docker rm -f cgroup-test

# イメージのレイヤー情報を確認
docker history nginx:1.25-alpine
# IMAGE          CREATED       CREATED BY                                      SIZE
# 1234abcd5678   2 weeks ago   CMD ["nginx" "-g" "daemon off;"]                0B
# <missing>      2 weeks ago   EXPOSE map[80/tcp:{}]                           0B
# <missing>      2 weeks ago   STOPSIGNAL SIGQUIT                              0B
# <missing>      2 weeks ago   RUN /bin/sh -c set -x && addgroup ...           5.14MB
# <missing>      2 weeks ago   /bin/sh -c #(nop) ADD file:... in /            7.38MB
 
# レイヤーの詳細を JSON で確認
docker inspect nginx:1.25-alpine | python3 -m json.tool | head -50
 
# overlay2 ストレージドライバの情報
docker info --format '{{.Driver}}'
# overlay2
 
# イメージの保存先を確認
docker info --format '{{.DockerRootDir}}'
# /var/lib/docker
 
# 特定コンテナの OverlayFS マウント情報
docker run -d --name overlay-test nginx
docker inspect overlay-test --format '{{.GraphDriver.Data.MergedDir}}'
# /var/lib/docker/overlay2/<hash>/merged
 
docker inspect overlay-test --format '{{.GraphDriver.Data.UpperDir}}'
# /var/lib/docker/overlay2/<hash>/diff  (Read-Write 層)
 
docker inspect overlay-test --format '{{.GraphDriver.Data.LowerDir}}'
# /var/lib/docker/overlay2/<hash1>/diff:/var/lib/docker/overlay2/<hash2>/diff  (Read-Only 層)
 
docker rm -f overlay-test
 
# レイヤーの共有を確認（同じベースイメージを使うコンテナはレイヤーを共有）
docker pull nginx:1.25-alpine
docker pull nginx:1.25  # alpine と non-alpine で共通レイヤーがあれば共有される
 
# ディスク使用量の確認
docker system df
# TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
# Images          15        5         3.258GB   2.1GB (64%)
# Containers      5         3         120MB     45MB (37%)
# Local Volumes   8         3         500MB     200MB (40%)
# Build Cache     20        0         1.5GB     1.5GB
 
docker system df -v  # 詳細表示

# Docker のデフォルト seccomp プロファイルを確認
# 約300以上のシステムコールのうち、約50が制限される
docker run --rm alpine cat /proc/self/status | grep Seccomp
# Seccomp:  2
# Seccomp_filters:  1
 
# seccomp プロファイルなしで実行（危険 - デバッグ目的のみ）
docker run --rm --security-opt seccomp=unconfined alpine cat /proc/self/status | grep Seccomp
# Seccomp:  0
 
# カスタム seccomp プロファイルの例
cat > /tmp/my-seccomp.json << 'SECCOMP_EOF'
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    {
      "names": ["chmod", "fchmod", "fchmodat"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1
    },
    {
      "names": ["ptrace"],
      "action": "SCMP_ACT_ERRNO",
      "errnoRet": 1
    }
  ]
}
SECCOMP_EOF
 
docker run --rm --security-opt seccomp=/tmp/my-seccomp.json alpine chmod 777 /tmp
# chmod: /tmp: Operation not permitted

# Linux capabilities の一覧（コンテナに関連するもの）
# Docker はデフォルトで限定的な capabilities のみ付与する
 
# デフォルトで付与される capabilities
docker run --rm alpine sh -c 'cat /proc/self/status | grep Cap'
# CapPrm:  00000000a80425fb
# CapEff:  00000000a80425fb
 
# capsh で人間が読める形式に変換
docker run --rm alpine sh -c 'apk add -q libcap && capsh --decode=00000000a80425fb'
# 0x00000000a80425fb=cap_chown,cap_dac_override,cap_fowner,...
 
# 全ての capabilities を削除
docker run --rm --cap-drop=ALL alpine id
# uid=0(root) gid=0(root)  # root だが実質的に権限なし
 
# 必要最小限の capabilities のみ追加
docker run --rm --cap-drop=ALL --cap-add=NET_BIND_SERVICE alpine sh -c 'id'
 
# 危険な capabilities の例
# --cap-add=SYS_ADMIN  # ほぼ root 相当（避けるべき）
# --cap-add=NET_ADMIN  # ネットワーク設定変更可能
# --cap-add=SYS_PTRACE # 他プロセスのデバッグ可能

# ===================================
# 起動時間の比較実験
# ===================================
 
# コンテナの起動時間を計測
time docker run --rm alpine echo "Hello"
# real    0m0.432s  # 約0.4秒
 
time docker run --rm nginx sh -c "echo started"
# real    0m0.512s  # 約0.5秒
 
# 100コンテナの同時起動
time for i in $(seq 1 100); do
  docker run -d --rm --name "bench-${i}" alpine sleep 30
done
# real    0m12.345s  # 約12秒で100コンテナ起動
 
# クリーンアップ
docker stop $(docker ps -q --filter "name=bench-") 2>/dev/null
 
# ===================================
# イメージサイズの比較
# ===================================
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}" | sort -k3 -h
# REPOSITORY   TAG              SIZE
# alpine       3.19             7.38MB
# busybox      1.36             4.26MB
# debian       12-slim          74.8MB
# ubuntu       22.04            77.9MB
# node         20-alpine        127MB
# python       3.12-slim        130MB
# golang       1.22-alpine      256MB
# node         20               1.1GB
# ubuntu       22.04 (VM OVA)   約2.5GB (参考: VM イメージ)
 
# ===================================
# メモリ使用量の比較
# ===================================
# コンテナ: アプリ分のメモリのみ
docker run -d --name mem-test nginx
docker stats --no-stream mem-test
# CONTAINER   MEM USAGE / LIMIT     MEM %
# mem-test    3.5MiB / 16GiB        0.02%
 
# VM: OS + アプリのメモリが必要
# 最小構成の Ubuntu VM でも 512MB〜1GB のメモリが必要

# Docker のバージョン確認（クライアントとサーバー）
docker version
# Client:
#  Version:           24.0.7
#  API version:       1.43
#  Go version:        go1.21.3
#  Built:             Thu Oct 26 09:07:41 2023
#  OS/Arch:           linux/amd64
#
# Server:
#  Engine:
#   Version:          24.0.7
#   API version:      1.43 (minimum version 1.12)
#   Go version:       go1.21.3
#   Built:            Thu Oct 26 09:07:41 2023
#   OS/Arch:          linux/amd64
#   containerd:       1.7.6
#   runc:             1.1.10
#   docker-init:      0.19.0
 
# Docker システム情報の確認
docker info
# Containers: 5
#  Running: 3
#  Paused: 0
#  Stopped: 2
# Images: 25
# Server Version: 24.0.7
# Storage Driver: overlay2
# Logging Driver: json-file
# Cgroup Driver: systemd
# Cgroup Version: 2
# Kernel Version: 6.5.0-14-generic
# Operating System: Ubuntu 22.04.3 LTS
 
# Docker デーモンのプロセス構成を確認
ps aux | grep -E "(dockerd|containerd|shim)"
# root  1234  dockerd --group docker
# root  1235  containerd
# root  5678  containerd-shim-runc-v2 -namespace moby -id abc123
 
# Docker ソケットの確認
ls -la /var/run/docker.sock
# srw-rw---- 1 root docker 0 /var/run/docker.sock
 
# Docker API に直接アクセス
curl --unix-socket /var/run/docker.sock http://localhost/v1.43/info 2>/dev/null | python3 -m json.tool | head -20

# runc でOCIバンドルを手動で作成・実行する例
# (Docker の内部動作を理解するためのデモ)
 
# 1. ルートファイルシステムを準備
mkdir -p /tmp/oci-demo/rootfs
docker export $(docker create alpine) | tar -C /tmp/oci-demo/rootfs -xf -
 
# 2. OCI 設定ファイル (config.json) を生成
cd /tmp/oci-demo
runc spec
# config.json が生成される
 
# 3. config.json の内容（主要部分）
cat config.json
# {
#   "ociVersion": "1.0.2",
#   "process": {
#     "terminal": true,
#     "user": { "uid": 0, "gid": 0 },
#     "args": ["sh"],
#     "env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],
#     "cwd": "/"
#   },
#   "root": {
#     "path": "rootfs",
#     "readonly": true
#   },
#   "linux": {
#     "namespaces": [
#       { "type": "pid" },
#       { "type": "network" },
#       { "type": "ipc" },
#       { "type": "uts" },
#       { "type": "mount" }
#     ],
#     "resources": {
#       "memory": { "limit": 268435456 }
#     }
#   }
# }
 
# 4. runc でコンテナを実行
sudo runc run my-container
# -> alpine の sh が起動する

# イメージのマニフェストを確認
docker manifest inspect nginx:1.25-alpine
# {
#   "schemaVersion": 2,
#   "mediaType": "application/vnd.oci.image.index.v1+json",
#   "manifests": [
#     {
#       "mediaType": "application/vnd.oci.image.manifest.v1+json",
#       "digest": "sha256:abc123...",
#       "size": 1234,
#       "platform": {
#         "architecture": "amd64",
#         "os": "linux"
#       }
#     },
#     {
#       "mediaType": "application/vnd.oci.image.manifest.v1+json",
#       "digest": "sha256:def456...",
#       "size": 1234,
#       "platform": {
#         "architecture": "arm64",
#         "os": "linux"
#       }
#     }
#   ]
# }
 
# skopeo でイメージの詳細情報を取得
skopeo inspect docker://nginx:1.25-alpine
# {
#   "Name": "docker.io/library/nginx",
#   "Tag": "1.25-alpine",
#   "Digest": "sha256:...",
#   "RepoTags": ["1.25-alpine", "1.25.3-alpine", ...],
#   "Created": "2024-01-15T...",
#   "DockerVersion": "24.0.7",
#   "Labels": {},
#   "Architecture": "amd64",
#   "Os": "linux",
#   "Layers": [
#     "sha256:abc123...",
#     "sha256:def456...",
#     "sha256:ghi789..."
#   ]
# }
 
# イメージを OCI フォーマットで保存
docker save nginx:1.25-alpine -o nginx-alpine.tar
mkdir -p /tmp/oci-image && tar -xf nginx-alpine.tar -C /tmp/oci-image
ls /tmp/oci-image/
# blobs/  index.json  manifest.json  oci-layout

# ===================================
# runc - OCI ランタイムリファレンス実装
# ===================================
runc --version
# runc version 1.1.10
# spec: 1.0.2-dev
 
# ===================================
# crun - C 言語実装の高速 OCI ランタイム
# ===================================
crun --version
# crun version 1.8.7
# runc より起動が高速 (約2倍)
 
# ===================================
# Podman - Docker互換のデーモンレスコンテナエンジン
# ===================================
podman run --rm alpine echo "Hello from Podman"
 
# Docker CLI との互換性
alias docker=podman  # これだけで多くのコマンドが動く
 
# Podman の特徴: デーモンレス + rootless がデフォルト
podman info | grep -A5 "host"
# rootless: true
 
# Pod (Kubernetes 互換のグルーピング)
podman pod create --name my-pod -p 8080:80
podman run -d --pod my-pod nginx
podman run -d --pod my-pod redis
 
# ===================================
# Buildah - OCI イメージビルドツール
# ===================================
# Dockerfile なしでイメージを構築
container=$(buildah from alpine)
buildah run $container apk add --no-cache nginx
buildah config --port 80 $container
buildah config --cmd "nginx -g 'daemon off;'" $container
buildah commit $container my-nginx:latest
 
# Dockerfile からビルド (docker build 互換)
buildah bud -t my-app:v1 .
 
# ===================================
# Skopeo - コンテナイメージ操作ツール
# ===================================
# レジストリ間でイメージをコピー（ローカルに pull 不要）
skopeo copy docker://nginx:1.25 docker://myregistry.example.com/nginx:1.25
 
# イメージの詳細情報を取得（pull 不要）
skopeo inspect docker://alpine:latest
 
# レジストリのタグ一覧
skopeo list-tags docker://nginx
 
# イメージの削除
skopeo delete docker://myregistry.example.com/old-image:v1
 
# ===================================
# nerdctl - containerd ネイティブ CLI
# ===================================
# Docker CLI 互換の containerd クライアント
nerdctl run --rm alpine echo "Hello from nerdctl"
nerdctl build -t my-app:v1 .
nerdctl compose up -d
 
# Docker にない機能
nerdctl image encrypt --recipient=jwe:public.pem my-app:v1  # イメージ暗号化
nerdctl run --cosign-key=cosign.pub verified-image:v1        # 署名検証

# Kubernetes のコンテナランタイムを確認
kubectl get nodes -o wide
# NAME       STATUS   ROLES    VERSION   CONTAINER-RUNTIME
# node-1     Ready    <none>   v1.28.3   containerd://1.7.6
# node-2     Ready    <none>   v1.28.3   containerd://1.7.6
 
# containerd の設定確認
cat /etc/containerd/config.toml
# [plugins."io.containerd.grpc.v1.cri"]
#   [plugins."io.containerd.grpc.v1.cri".containerd]
#     default_runtime_name = "runc"
#     [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
#       runtime_type = "io.containerd.runc.v2"
 
# crictl (CRI デバッグツール) でコンテナ情報を取得
crictl ps
# CONTAINER   IMAGE    CREATED    STATE    NAME          POD ID
# abc123...   nginx    10m ago    Running  web-server    def456...
 
crictl images
# IMAGE                     TAG       SIZE
# docker.io/library/nginx   1.25      41.2MB

# gVisor のインストールと使用
# Docker に gVisor ランタイムを登録
cat > /etc/docker/daemon.json << 'EOF'
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc"
    }
  }
}
EOF
sudo systemctl restart docker
 
# gVisor でコンテナを実行
docker run --runtime=runsc --rm alpine uname -a
# Linux ... 4.4.0 ... gVisor
 
# Kata Containers でコンテナを実行
docker run --runtime=kata --rm alpine uname -a
# Linux ... 5.15.0 ... (軽量VMのカーネル)
 
# ランタイムごとのパフォーマンス比較
# runc:    起動 ~300ms, メモリ +0MB (ベースライン)
# gVisor:  起動 ~500ms, メモリ +50MB (Sentry プロセス分)
# Kata:    起動 ~1.5s,  メモリ +128MB (軽量VM分)

# 各サービスを独立したコンテナとして実行
docker network create microservices
 
# API Gateway
docker run -d --name api-gateway \
  --network microservices \
  -p 8080:8080 \
  -e UPSTREAM_SERVICES="user-service:8081,order-service:8082,payment-service:8083" \
  api-gateway:v1
 
# ユーザーサービス
docker run -d --name user-service \
  --network microservices \
  -e DB_HOST=user-db \
  -e DB_PORT=5432 \
  user-service:v1
 
# 注文サービス
docker run -d --name order-service \
  --network microservices \
  -e DB_HOST=order-db \
  -e KAFKA_BROKERS=kafka:9092 \
  order-service:v1
 
# 決済サービス
docker run -d --name payment-service \
  --network microservices \
  -e STRIPE_API_KEY_FILE=/run/secrets/stripe_key \
  payment-service:v1
 
# データベース群
docker run -d --name user-db \
  --network microservices \
  -v user-db-data:/var/lib/postgresql/data \
  postgres:16-alpine
 
docker run -d --name order-db \
  --network microservices \
  -v order-db-data:/var/lib/postgresql/data \
  postgres:16-alpine
 
# メッセージキュー
docker run -d --name kafka \
  --network microservices \
  -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 \
  confluentinc/cp-kafka:7.5

# docker-compose.yml による マイクロサービス構成
services:
  api-gateway:
    image: api-gateway:v1
    ports:
      - "8080:8080"
    depends_on:
      - user-service
      - order-service
      - payment-service
    environment:
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://jaeger:4317
    networks:
      - frontend
      - backend
 
  user-service:
    image: user-service:v1
    deploy:
      replicas: 3
      resources:
        limits:
          cpus: "0.5"
          memory: 256M
    depends_on:
      user-db:
        condition: service_healthy
    environment:
      - DB_HOST=user-db
    networks:
      - backend
 
  user-db:
    image: postgres:16-alpine
    volumes:
      - user-db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - backend
 
  jaeger:
    image: jaegertracing/all-in-one:1.52
    ports:
      - "16686:16686"  # UI
      - "4317:4317"    # OTLP gRPC
    networks:
      - backend
 
networks:
  frontend:
  backend:
 
volumes:
  user-db-data:

# docker-compose.yml による開発環境定義
services:
  app:
    build:
      context: .
      dockerfile: Dockerfile.dev
    volumes:
      - .:/app
      - /app/node_modules  # node_modules はコンテナ内のものを使用
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development
      - DATABASE_URL=postgresql://devuser:devpass@db:5432/devdb
      - REDIS_URL=redis://redis:6379
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
 
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: devuser
      POSTGRES_PASSWORD: devpass
      POSTGRES_DB: devdb
    volumes:
      - postgres-data:/var/lib/postgresql/data
      - ./db/init.sql:/docker-entrypoint-initdb.d/init.sql
    ports:
      - "5432:5432"
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U devuser -d devdb"]
      interval: 5s
      timeout: 3s
      retries: 10
 
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    command: redis-server --maxmemory 128mb --maxmemory-policy allkeys-lru
 
  mailhog:
    image: mailhog/mailhog:v1.0.1
    ports:
      - "1025:1025"  # SMTP
      - "8025:8025"  # Web UI
 
  minio:
    image: minio/minio:latest
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin
    ports:
      - "9000:9000"
      - "9001:9001"  # Console
    volumes:
      - minio-data:/data
 
volumes:
  postgres-data:
  minio-data:

# GitHub Actions でのコンテナ活用例
name: CI/CD Pipeline
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]
 
env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}
 
jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16-alpine
        env:
          POSTGRES_USER: test
          POSTGRES_PASSWORD: test
          POSTGRES_DB: testdb
        ports:
          - 5432:5432
        options: >-
          --health-cmd "pg_isready -U test"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
      redis:
        image: redis:7-alpine
        ports:
          - 6379:6379
 
    steps:
      - uses: actions/checkout@v4
 
      - name: Build test image
        run: docker build --target test -t myapp:test .
 
      - name: Run unit tests
        run: |
          docker run --rm \
            --network host \
            -e DATABASE_URL=postgresql://test:test@localhost:5432/testdb \
            -e REDIS_URL=redis://localhost:6379 \
            myapp:test npm test
 
      - name: Run integration tests
        run: |
          docker run --rm \
            --network host \
            -e DATABASE_URL=postgresql://test:test@localhost:5432/testdb \
            myapp:test npm run test:integration
 
  build-and-push:
    needs: test
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    permissions:
      contents: read
      packages: write
 
    steps:
      - uses: actions/checkout@v4
 
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3
 
      - name: Login to GHCR
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
 
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: |
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
 
  deploy:
    needs: build-and-push
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to production
        run: |
          # Kubernetes にデプロイ
          kubectl set image deployment/myapp \
            myapp=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
          kubectl rollout status deployment/myapp --timeout=300s

# ML 開発環境の docker-compose.yml
services:
  jupyter:
    image: jupyter/scipy-notebook:latest
    ports:
      - "8888:8888"
    volumes:
      - ./notebooks:/home/jovyan/work
      - ./data:/home/jovyan/data
    environment:
      - JUPYTER_ENABLE_LAB=yes
      - GRANT_SUDO=yes
    user: root
 
  mlflow:
    image: ghcr.io/mlflow/mlflow:v2.9.0
    ports:
      - "5000:5000"
    command: >
      mlflow server
      --backend-store-uri postgresql://mlflow:mlflow@mlflow-db:5432/mlflow
      --default-artifact-root s3://mlflow-artifacts/
      --host 0.0.0.0
    depends_on:
      - mlflow-db
 
  mlflow-db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: mlflow
      POSTGRES_PASSWORD: mlflow
      POSTGRES_DB: mlflow
    volumes:
      - mlflow-db-data:/var/lib/postgresql/data
 
  gpu-training:
    build:
      context: .
      dockerfile: Dockerfile.gpu
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    volumes:
      - ./models:/app/models
      - ./data:/app/data
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
      - CUDA_VISIBLE_DEVICES=0,1
 
volumes:
  mlflow-db-data:

# Dockerfile.gpu - GPU 対応の ML 環境
FROM nvidia/cuda:12.2.0-runtime-ubuntu22.04
 
RUN apt-get update && apt-get install -y \
    python3-pip python3-dev && \
    rm -rf /var/lib/apt/lists/*
 
RUN pip3 install --no-cache-dir \
    torch torchvision torchaudio \
    transformers datasets accelerate \
    mlflow scikit-learn pandas numpy
 
WORKDIR /app
COPY . .
 
CMD ["python3", "train.py"]

# 一時的なデータベースの起動（開発・テスト用）
docker run --rm -d \
  --name temp-postgres \
  -p 5432:5432 \
  -e POSTGRES_PASSWORD=mypassword \
  postgres:16-alpine
 
# 一時的な Redis の起動
docker run --rm -d \
  --name temp-redis \
  -p 6379:6379 \
  redis:7-alpine
 
# 静的サイトのプレビュー
docker run --rm -p 8080:80 \
  -v $(pwd)/dist:/usr/share/nginx/html:ro \
  nginx:alpine
 
# データベースのマイグレーション実行
docker run --rm \
  --network host \
  -v $(pwd)/migrations:/migrations \
  migrate/migrate \
  -path=/migrations -database "postgresql://user:pass@localhost:5432/mydb?sslmode=disable" up
 
# セキュリティスキャン
docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy:latest image nginx:1.25
 
# コードフォーマット（言語に依存しない実行環境）
docker run --rm -v $(pwd):/work -w /work \
  golangci/golangci-lint:latest golangci-lint run
 
# PlantUML による図の生成
docker run --rm -v $(pwd):/data \
  plantuml/plantuml:latest /data/diagram.puml

# NG: 1コンテナに複数サービスを詰め込む
# SSH, cron, アプリ, DB を全部1コンテナに入れる
docker run -d my-monolith-container
# -> メンテナンス困難、スケール不可、ログ管理が複雑
 
# OK: 1コンテナ1プロセスの原則
docker run -d --name app my-app
docker run -d --name db postgres:16
docker run -d --name cache redis:7
# -> 個別にスケール・更新・監視が可能

# NG: バージョンを指定しない
docker run -d nginx:latest
# -> 再現性がない。ある日突然動かなくなる可能性
# -> CI で通ったバージョンと本番で異なるバージョンが動く危険
 
# OK: 具体的なバージョンを指定
docker run -d nginx:1.25.3-alpine
# -> いつ実行しても同じイメージが使われる
 
# さらに厳密: ダイジェストで固定
docker run -d nginx@sha256:abc123def456...
# -> タグが上書きされても影響を受けない

# NG: ホストネットワークを常用
docker run --network host my-app
# -> ポート衝突、セキュリティリスク、ポータビリティ低下
 
# OK: ブリッジネットワークでポートマッピング
docker run -p 8080:80 my-app
# -> 明示的なポート制御、分離されたネットワーク

# NG: コンテナ内にデータを保存
docker run -d my-app
# コンテナ再作成でデータが消失する
 
# OK: ボリュームを使用
docker run -d -v app-data:/data my-app
# コンテナを破棄してもデータは永続化される
 
# OK: バインドマウントを使用（開発環境向け）
docker run -d -v $(pwd)/data:/data my-app

# NG: root で実行（デフォルト）
docker run -d my-app
# コンテナエスケープ時にホストの root 権限を取得されるリスク
 
# OK: 非特権ユーザーで実行
# Dockerfile で指定:
# RUN addgroup -S app && adduser -S app -G app
# USER app
 
# または実行時に指定:
docker run -d --user 1000:1000 my-app
 
# rootless Docker を使用:
dockerd-rootless.sh

# NG: 環境変数でシークレットを渡す
docker run -e API_KEY=sk-12345secret my-app
# -> docker inspect で丸見え、ログに漏洩する可能性
 
# NG: Dockerfile にハードコード
# ENV API_KEY=sk-12345secret
# -> イメージに永続的に保存される
 
# OK: Docker Secrets を使用（Swarm mode）
echo "sk-12345secret" | docker secret create api_key -
docker service create --secret api_key my-app
# コンテナ内で /run/secrets/api_key として読める
 
# OK: 外部シークレット管理ツールとの連携
docker run -d \
  -e VAULT_ADDR=https://vault.example.com \
  -e VAULT_TOKEN_FILE=/run/secrets/vault_token \
  my-app

# Docker + Wasm の実行例
# containerd の Wasm shim を使用
docker run --runtime=io.containerd.wasmedge.v1 \
  --platform wasi/wasm \
  ghcr.io/example/wasm-app:latest
 
# Wasm コンテナの特徴:
# - 起動時間: ~1ms (通常のコンテナ: ~300ms)
# - サイズ: ~KB単位 (通常のコンテナ: ~MB単位)
# - セキュリティ: サンドボックスモデルが標準
# - ポータビリティ: CPU アーキテクチャに依存しない

# eBPF ベースのコンテナセキュリティツール
# Falco - ランタイムセキュリティ検知
docker run --rm -i -t \
  --privileged \
  -v /var/run/docker.sock:/host/var/run/docker.sock \
  -v /proc:/host/proc:ro \
  falcosecurity/falco:latest
 
# Cilium - eBPF ベースのコンテナネットワーク
# NetworkPolicy を eBPF で実装（iptables より高速）
# L7 レベルのトラフィック可視化