docker

Name: docker
Author: iuliandita

github.com/iulianditaクラウド・DevOps1063 回インストール今日更新

docker について

Docker コンテナを扱うチーム向けのスキルで、Dockerfile、Compose 構成、コンテナワークフローの作成・レビュー・設計を支援します。本番環境の強化、サプライチェーン保護、CI、ランタイム移行、検証チェックリストを扱います。

主な機能

01Dockerfile の作成とレビュー
02Docker Compose スタックの構成
03イメージサイズとビルドキャッシュの最適化
04コンテナの強化とコンプライアンス確認
05イメージ署名、SBOM 生成、脆弱性スキャン
06Docker、Podman などのランタイム移行

活用シーン

01アプリケーション用のマルチステージ Dockerfile の設計
02開発・本番用 Compose スタックの構築
03PCI-DSS または SOC 2 向けコンテナ強化の確認
04イメージビルドへの署名と SBOM 生成の追加

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/iuliandita/skills --skill docker

インストール後、Claude Code で/dockerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

agent-hygiene.md

alternative-runtimes.md

compose-patterns.md

dockerfile-patterns.md

output-contract.md

security-and-compliance.md

target-versions.md

詳細

Docker とコンテナー：本番環境のインフラストラクチャ

単一サービスの開発環境から、イメージ署名とコンプライアンスゲートを備えたマルチアーキテクチャの本番パイプラインまで、Dockerfile、Compose スタック、コンテナーワークフローの作成、レビュー、設計を行います。目標は、チームが保守でき、QSA が監査できる、最小限で安全かつ再現可能なイメージです。

対象バージョン：2026 年 10 月時点のスナップショットです。 Docker、Compose、BuildKit、containerd、Podman、Buildah、runc のバージョンを固定する前に、references/target-versions.md をお読みください。

このスキルでは、Dockerfile、Compose、コンテナーの強化、サプライチェーン、レジストリ／CI パターン、および Docker、Podman、Buildah、Skopeo、containerd 間のランタイム移行を扱います。

使用する場面

Dockerfile（単一ステージまたはマルチステージ）の作成やレビュー
Docker Compose スタック（開発、ステージング、本番環境）のセットアップ
イメージサイズ、ビルド速度、レイヤーキャッシュの最適化
本番環境やコンプライアンスに向けたコンテナーの強化
イメージ署名、SBOM 生成、脆弱性スキャンのセットアップ
AI／ML ワークロードのコンテナー化（Model Runner、GPU パススルー、モデルサービング）
Docker から Podman への移行、または Buildah によるビルド
PCI-DSS 4.0 または SOC 2 に向けたコンテナーのセキュリティ態勢のレビュー
コンテナーネットワーク、ボリューム、ビルドに関する問題のトラブルシューティング
docker init を使った新規プロジェクトのひな形作成

使用しない場面

Kubernetes マニフェスト、Helm チャート、クラスターアーキテクチャ（kubernetes を使用）
CI/CD パイプラインの設計（ci-cd を使用）
アプリケーションコードのセキュリティ監査（security-audit を使用）
Terraform によるインフラストラクチャのプロビジョニング（terraform を使用）

AI のセルフチェック

AI ツールは、同じ Docker のミスを繰り返し発生させます。生成した Dockerfile または Compose ファイルを返す前に、次のリストに照らして確認してください。

パフォーマンス

Dockerfile のレイヤーは安定したものから変わりやすいものへ順に並べ、BuildKit を利用できる場合はパッケージマネージャーのキャッシュにキャッシュマウントを使用します。
.dockerignore でビルドコンテキストを小さく保ちます。意図せずモノレポ全体がコンテキストに含まれると、ビルド時間が大幅に増加します。
マルチステージビルドとスリムなランタイムイメージを使用します。ただし、ツールを過度に削除する前に、起動やデバッグに必要なものを確認します。

ベストプラクティス

セキュリティ要件の厳しいワークロードではベースイメージのダイジェストを固定し、セキュリティ更新のための再ビルド頻度を管理します。
ワークロードで本当に必要な場合を除き、非 root ユーザーで実行し、ケイパビリティを削除します。
prune コマンドやボリューム削除コマンドは実行前に確認します。永続データを誤って削除してはいけません。

ワークフロー

このチェックリストをコピーして、進捗を記録します。

ステップ 1：ドメインを特定
ステップ 2：コンテキストを収集（ランタイム、環境、ベースイメージ、シークレット、コンプライアンス）
ステップ 3：Dockerfile、Compose、または設定を作成
ステップ 4：検証に合格（失敗した場合は修正してステップ 3 に戻る）
本番環境チェックリストと AI セルフチェックに合格

ステップ 1：ドメインを特定する

リクエストに基づいて判断します。

「Dockerfile を作成」／「このアプリをコンテナ化」 -> Dockerfile
「docker compose を設定」／「複数サービスのスタック」 -> Compose
「これを強化」／「PCI に準拠させる」／「脆弱性をスキャン」 -> セキュリティ
「イメージに署名」／「SBOM を生成」／「CI パイプライン」 -> レジストリと CI
「Podman を使用」／「rootless コンテナ」／「デーモンレスビルド」 -> ランタイム
「この Dockerfile／compose をレビュー」 -> 本番環境チェックリストと AI セルフチェックを適用

ステップ 2：コンテキストを収集する

作成を始める前に、次の内容を確認します。

アプリケーションの種類：言語、フレームワーク、ビルドシステム
ランタイム：Bun、Node.js、Python、Go、Rust、Java。ベースイメージとビルドパターンが決まります
環境：開発（ホットリロード、デバッグ）か本番（最小構成、強化済み）か
ベースイメージ：Alpine（小さい、musl）か Debian-slim（glibc 互換）か distroless（シェルなし）か Chainguard（CVE ゼロ）か scratch（静的バイナリ）か
シークレット：どのように注入しますか？（環境変数、マウントしたファイル、Docker secrets、vault）
コンプライアンス：PCI CDE ですか？規制対象ですか？どのようなスキャン／署名が必要ですか？
ターゲットレジストリ：Docker Hub、GHCR、プライベートレジストリ、OCI 準拠のレジストリのいずれですか？
AI／ML：GPU ワークロードですか？モデルサービングですか？Docker Model Runner を使用しますか？

ステップ 3：ビルドする

以下の該当ドメインのセクションに従います。完了する前に、ステップ 4、「## Production Checklist」、および AI セルフチェックを実施します。

ステップ 4：検証する

失敗した場合は修正してステップ 3 に戻り、すべてのチェックに合格し、未対応の HIGH／CRITICAL 検出事項が残らなくなるまで、docker build --check から再実行します。利用できなかったツールがあれば報告します。

# Dockerfile
docker build --check .                # lint without building
docker build -t test-build .          # Use --no-cache only when investigating stale cache or clean-build reproducibility
docker history test-build --format "{{.Size}}\t{{.CreatedBy}}" | head -15

# Compose
docker compose config                 # validate and render
docker compose --dry-run up           # dry-run startup (Compose v5)

# Security (Trivy default; Grype or Docker Scout if the repo already uses them)
if command -v trivy >/dev/null; then
  trivy image --severity HIGH,CRITICAL --exit-code 1 <image>   # use v0.74.0+; never v0.69.4-6
else
  echo "trivy not installed: image scan NOT run; report it as unverified"
fi
syft <image> -o spdx-json             # generate SBOM
cosign verify --key <key> <image>     # verify signature

Dockerfile

完全な本番環境対応 Dockerfile テンプレート（Node.js／Bun、Python、Go、Rust、静的サイト）と BuildKit 構文のリファレンスについては、references/dockerfile-patterns.md を参照してください。

ベースイメージの選択

シェルまたはパッケージマネージャーが必要な場合：slim Debian または Ubuntu のベースイメージを使用します。
最小の静的ランタイムが必要な場合：distroless または scratch を使用します。
強化された最小限のユーザー空間が必要な場合：Chainguard または検証済みの Wolfi 系ベースイメージを使用します。
ビルダーとランタイムは分離します。golang、rust などの重いツールチェーンイメージは、ビルドステージでのみ使用します。

言語ごとの実際のベースイメージの推奨事項とテンプレートについては、references/dockerfile-patterns.md を参照してください。

重要なパターン

マルチステージビルド — コンパイルまたはトランスパイルを行う言語では、必須のパターンです。

# syntax=docker/dockerfile:1
FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci
COPY . .
RUN npm run build && npm prune --omit=dev

FROM gcr.io/distroless/nodejs22-debian13
WORKDIR /app
COPY --from=build --chown=1001:1001 /app/dist ./dist
COPY --from=build --chown=1001:1001 /app/node_modules ./node_modules
USER 1001
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 \
  CMD ["/nodejs/bin/node", "-e", "fetch('http://localhost:3000/health').then(r=>r.ok||process.exit(1)).catch(()=>process.exit(1))"]
CMD ["dist/index.js"]

BuildKit の機能（# syntax=docker/dockerfile:1 または DOCKER_BUILDKIT=1 が必要です）：

キャッシュマウント：RUN --mount=type=cache,target=/root/.npm npm ci — ビルドをまたいでパッケージキャッシュを保持します
シークレットマウント：RUN --mount=type=secret,id=npmrc,target=/root/.npmrc npm ci — シークレットがレイヤーに書き込まれることはありません
ヒアドキュメント：バックスラッシュだらけにならずに複数行のスクリプトを記述できます

RUN <<EOF
set -e
apt-get update
apt-get install -y --no-install-recommends ca-certificates
rm -rf /var/lib/apt/lists/*
EOF

--check フラグ：docker build --check . はビルドせずに Dockerfile を検証します（ドライランのリント）
SLSA 来歴情報：docker build --provenance=true --sbom=true . はアテステーションを付加します

docker init：Dockerfile、compose.yaml、.dockerignore を生成します。出発点として適していますが、必ず内容を確認してください。

書いてはいけないもの

依存関係のインストール前に COPY . . を実行する（ソースが変更されるたびにキャッシュが無効になります）
ローカルファイルに ADD を使う（COPY を使用してください。ADD は .tar.gz アーカイブをイメージ内に自動展開する場合にのみ使います）
MAINTAINER（非推奨です。LABEL maintainer="..." を使用してください）
RUN cd /dir && ...（WORKDIR /dir を使用してください）
パッケージのインストールごとに RUN を分ける（&& で連結してください）
何に対しても chmod 777 を使う
ARG または ENV にシークレットを設定する
FROM node:latest または FROM python を使う（バージョンが固定されていません）
ENTRYPOINT と CMD を同時に使う。ただし、ENTRYPOINT がバイナリで、CMD が上書き可能なデフォルト引数の場合は除きます（例：ENTRYPOINT ["/app"] + CMD ["--config", "/etc/app.yaml"]）

Compose

Compose v5 の完全なテンプレート（web+db、dev のオーバーライド、本番環境向けの強化設定、AI/ML スタック）と、ネットワーク／ボリュームのパターンについては、references/compose-patterns.md をお読みください。

Compose v5

古い version: フィールドは使用しないでください。
Bake ベースのビルド、watch、ドライラン検証、新しいモデル指向のサービス接続に対応してください。
開発環境と本番環境の設定は分けてください。オーバーライドファイルを使うのが今も妥当な標準です。
ヘルスチェックと依存サービスの準備完了判定は、オプションの追加機能ではなく、通常の Compose 設計として扱ってください。

重要なパターン

オーバーライドファイルを使った開発環境と本番環境の分離：

# compose.yaml (base)
services:
  app:
    image: myapp:1.0.0
    healthcheck:
      test: ["CMD-SHELL", "wget -qO /dev/null http://localhost:3000/health || exit 1"]
      interval: 30s
      timeout: 5s
      start_period: 10s
      retries: 3

# compose.override.yaml (dev - auto-loaded)
services:
  app:
    build: .
    volumes:
      - .:/app
      - /app/node_modules
    environment:
      NODE_ENV: development
    ports:
      - "9229:9229"
    command: bun run dev

シークレット：トップレベルの secrets: で file: または external: true を使用し、_FILE 環境変数の規約で参照してください（例：POSTGRES_PASSWORD_FILE: /run/secrets/db_pass）。environment: にシークレットをハードコードしないでください。シークレットの設定を含む完全なテンプレートについては、references/compose-patterns.md をご覧ください。

ヘルスチェックに基づく依存関係：condition: service_healthy を指定した depends_on: を使用してください。depends_on のみでは起動順序を指定するだけで、準備完了は保証されません。例外はヘルスチェックを公開できない依存関係です。その場合は、該当箇所にインラインコメントを付けてください。

Compose のアンチパターン

version: "3.8" — 廃止されたフィールドなので削除してください
すべてのサービスに container_name を指定する（docker compose up --scale が機能しなくなります）
ヘルスチェックなしで restart: always を指定する（壊れたコンテナーが無限に再起動します）
ポートマッピングで対応できるのに network_mode: host を指定する（ユーザー定義のブリッジネットワークと明示的な ports: マッピングに置き換えてください）
condition: なしで depends_on を指定する（起動順序を指定するだけで、準備完了は保証されません）
本番環境でプロジェクトディレクトリ全体をマウントする volumes: を指定する（開発用のパターンが本番環境に漏れています）
ホストの LXC ではなく、Compose サービスに privileged: true を指定する
20 件以上の environment: エントリーをインラインで記述する（env_file: を使用してください）

セキュリティ

PCI-DSS 4.0 のコンテナー要件の完全な対応表、CVE リファレンス、ランタイム強化パターン、スキャンツールの比較については、references/security-and-compliance.md をお読みください。

重大な脆弱性（2025-2026）

Docker Desktop、runc、Trivy、Model Runner、BuildKit、Engine、Podman、go-archive の影響と修正版を含む CVE の完全な表は、references/security-and-compliance.md にあります。バージョンの確認時や CVE に関する質問への回答時に参照してください。

対応事項：runc を >= 1.4.0、BuildKit を >= 0.33.1、Docker Desktop を >= 4.71.0（現行の 4.93.0 スナップショットを推奨）、Docker Engine を >= 29.8.2、Podman を >= 6.1.3 または 5.8.8 にアップグレードしてください。Trivy v0.69.4/5/6 は絶対に取得しないでください。すべての CI ツールイメージを SHA256 ダイジェストで固定してください。

強化版 Compose ベースライン

本番環境のすべてのサービスは、まずこれを使用し、必要な箇所だけ緩和してください。

services:
  app:
    image: myapp:1.0.0          # pinned, never :latest
    read_only: true
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add: []                 # add ONLY what's needed (see note below)
    tmpfs:
      - /tmp
    user: "1001:1001"
    healthcheck:
      test: ["CMD-SHELL", "wget -qO /dev/null http://localhost:8080/health || exit 1"]
      interval: 30s
      timeout: 5s
      start_period: 15s
      retries: 3
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

cap_drop: ALL に関する警告：多くのイメージ（LSIO、HOTIO、公式の redis/postgres、および gosu/setpriv/su-exec を使用するもの）は、root として起動し、実行時に権限を降格します。最低限 cap_add: ["SETUID", "SETGID"] が必要で、起動時にファイルの所有者を変更するイメージでは "CHOWN" も必要です。一律に権限を削除する前に、イメージのエントリポイントを必ず確認し、必要なケーパビリティを判断してください。cap_add が空のまま無条件に cap_drop: ALL を適用すると、CrashLoopBackOff が発生します。詳しくは、security-audit スキルの「No blanket capability drops」ルールを参照してください。

強化された Dockerfile のパターンについては、references/dockerfile-patterns.md（Language Templates セクション）を参照してください。

サプライチェーンセキュリティ

cosign（Sigstore）でイメージに署名します：cosign sign --key cosign.key <image>@<digest>
ビルド時に SBOM を生成します：syft <image> -o spdx-json
デプロイ時に検証します：cosign verify --key cosign.pub <image>@<digest>
CI ツールのイメージは SHA256 ダイジェストで固定します。 可変タグは、攻撃に悪用されることが実証されています（Trivy 2026 年 3 月、tj-actions/reviewdog 2025 年 3 月）。
公開済みのイメージを、CI スキャナーまたはレジストリ側のスキャンで定期的に再スキャンします。
Trivy：新しくバージョンを固定する場合は、公式リリースの v0.74.0 以降を使用してください。v0.69.3 は 2026 年 3 月のロールバック版です。v0.69.4-6 には認証情報を窃取するマルウェアが含まれていました。2026 年 3 月 19～23 日の間に、侵害された Trivy を CI パイプラインで実行した場合は、すべてのシークレットをローテーションしてください。

PCI-DSS 4.0 のコンテナ要件（概要）

PCI-DSS 4.0.1 は唯一有効なバージョンです（4.0 は 2024 年 12 月 31 日に廃止）。コンテナに固有の主な要件は次のとおりです。

要件 1：ネットワークセグメンテーション — ユーザー定義のブリッジネットワークを使用し、バックエンドサービスには internal: true を設定します。CDE コンテナをデフォルトのブリッジネットワークに公開しないでください。
要件 2.2：コンテナを強化します — root 以外のユーザー、ケーパビリティの削除、読み取り専用のルートファイルシステム、コンテナごとに 1 プロセス
要件 4：通信を暗号化します — Compose 内の CDE コンテナ間に TLS を設定します（証明書をマウントする、TLS 対応イメージを使用する、または TLS 終端リバースプロキシの背後に配置する）。
要件 5.2/5.3：不変のイメージ（ダイジェストでデプロイ）、ランタイム検知には Falco を使用
要件 6.3：デプロイ前にすべてのイメージを脆弱性スキャンします（Docker Scout、Grype、Trivy v0.74.0 以降）。
要件 6.3.2：すべての本番イメージに SBOM を用意します。
要件 8.6.2：イメージ、compose ファイル、環境変数にハードコードされたシークレットを含めないでください。
要件 10：監査ログ — コンテナの stdout/stderr を不変のログストアに送信します。
要件 11.5：イメージダイジェストの固定と Falco の組み合わせで、コンテナの FIM を実現します。

詳細な対応表は references/security-and-compliance.md を参照してください。

レジストリと CI

CI パイプラインのパターン

まず docker build --check でビルドし、次に provenance と SBOM を出力する buildx を使用します。
デプロイ前にスキャンし、ダイジェストで署名します。また、レジストリにも SBOM が保存されている場合でも、SBOM アーティファクトを保持してください。
CI 側のツールとアクションは、可変タグではなく不変のダイジェストで固定します。

Docker Model Runner（AI/ML）

Docker Model Runner（Engine 29.x、Desktop 4.50+）は、OpenAI/Ollama 互換 API を通じて AI モデルを提供します。

# Compose integration with Model Runner (Compose injects the endpoint; no hardcoded host)
services:
  agent:
    build: .
    models:
      llm:
        endpoint_var: OPENAI_BASE_URL   # default would be LLM_URL (already ends in /v1/)
        model_var: OPENAI_MODEL
models:
  llm:
    model: ai/llama3.2:3B-Q4_K_M

GPU コンテナでは、capabilities: [gpu] を指定して deploy.resources.reservations.devices を使用します。単一 GPU では shm_size を 16gb、複数 GPU では 32gb から始めてください（vLLM はテンソル演算に共有メモリを必要とします）。AI/ML スタックの完全なテンプレートについては、references/compose-patterns.md を参照してください。

本番環境チェックリスト

ビルド時のチェックリスト全体（Dockerfile の正確性、Compose の構造、レイヤーキャッシュ、シークレット、root 以外のユーザー、ヘルスチェック、ベースイメージの固定）については、上記の AI Self-Check を参照してください。以下の項目では、デプロイ時および運用時に追加で必要となる項目のみを扱います。

デプロイ時の追加項目

コンプライアンス（PCI-DSS 4.0）

参照ファイル

references/dockerfile-patterns.md - Dockerfile テンプレートとビルドパターン
references/compose-patterns.md - Compose パターンと一般的なスタック構成
references/security-and-compliance.md - 2025～2026 年の CVE テーブル全体、Trivy の侵害から得た教訓、スキャンと署名、コンテナーの強化、コンプライアンスに関するガイダンス、および安全な公開カスタムイメージの公開
references/alternative-runtimes.md - Podman、Buildah、Skopeo、および関連するランタイムパターン
references/target-versions.md - Docker、Compose、BuildKit、containerd、Podman、Buildah、runc の 2026 年 10 月時点のバージョン一覧

出力要件

完全な要件については references/output-contract.md を参照してください。

スキル名： DOCKER
成果物の分類： audits
モード： 条件付き。既存のリポジトリの内容を分析、レビュー、監査、または改善するために呼び出された場合は、references/output-contract.md の報告量と証拠に関するルールを適用し、成果物を docs/local/audits/docker/<YYYY-MM-DD>-<slug>.md に書き込みます。質問への回答、概念の説明、新しい成果物の作成、またはコンテンツの生成のために呼び出された場合は、要件にかかわらず自由に回答します。
重大度の尺度： P0 | P1 | P2 | P3 | info（共通要件を参照。監査／レビューモードでのみ使用）

ルール

本番環境のイメージはダイジェストで指定します。 テンプレートタグはイメージファミリーを示すものであり、変更可能なため、再現性を保証しません。
コンパイルまたはトランスパイルが必要な言語では、マルチステージビルドを使用します。 ビルドツールを本番イメージに含めてはいけません。
非 root ユーザーを使用します。 本番環境のすべてのコンテナーは、非 root ユーザー（K8s との互換性のため、数値の UID）で実行する必要があります。
サービスの健全性を適切に確認します。 長時間稼働するサービスには、Dockerfile、Compose、またはオーケストレーターのプローブを使用します。単発のジョブでは終了ステータスを使用し、外部監視について記載します。
CI ツールは SHA256 ダイジェストで固定します。 変更可能なタグは、サプライチェーン侵害の原因となります（Trivy CVE-2026-33634、2026 年 3 月、tj-actions CVE-2025-30066（上流：reviewdog CVE-2025-30154）、2025 年 3 月）。
新たに固定する Trivy は v0.74.0 以降を使用します。 v0.69.3 は 2026 年 3 月のロールバック対象バージョンであり、v0.69.4-6 には認証情報を窃取するマルウェアが含まれていました。これを実行した場合は、シークレットをローテーションしてください。
本番環境のコンテナーにはリソース制限を設定します。 メモリと CPU の制限により、隣接するコンテナーへの影響や OOM の連鎖を防げます。

Markdown 対応

ログインしてコメント

基本情報

作者: iuliandita
リポジトリ: iuliandita/skills
カテゴリ: クラウド・DevOps
インストール数: 63
GitHub スター: 10

問題を報告

docker

docker について

主な機能

活用シーン

インストール

同梱ファイル

詳細

Docker とコンテナー：本番環境のインフラストラクチャ

使用する場面

使用しない場面

AI のセルフチェック

パフォーマンス

ベストプラクティス

ワークフロー

ステップ 1：ドメインを特定する

ステップ 2：コンテキストを収集する

ステップ 3：ビルドする

ステップ 4：検証する

Dockerfile

ベースイメージの選択

重要なパターン

書いてはいけないもの

Compose

Compose v5

重要なパターン

Compose のアンチパターン

セキュリティ

重大な脆弱性（2025-2026）

強化版 Compose ベースライン

サプライチェーンセキュリティ

PCI-DSS 4.0 のコンテナ要件（概要）

レジストリと CI

CI パイプラインのパターン

Docker Model Runner（AI/ML）

本番環境チェックリスト

デプロイ時の追加項目

コンプライアンス（PCI-DSS 4.0）

参照ファイル

出力要件

関連スキル

ルール

コメント