Docker Configuration Validator

Name: Docker Configuration Validator
Author: rknall

github.com/rknallテスト・品質86339 回インストール53 週間前に更新

Docker Configuration Validator について

Docker Configuration Validatorは、DockerfileやDocker Compose設定を確認する開発者や運用担当者向けのスキルです。リンターと手動チェックを組み合わせ、構文、安全性、ベストプラクティス、本番運用への適合性を調べます。

主な機能

01DockerfileとComposeファイルの検証
02安全性とベストプラクティスの確認
03マルチステージビルドの検査
04指摘事項の重大度分類
05レポートと自動化案の作成

活用シーン

01提出前のコンテナ設定レビュー
02Dockerのセキュリティ問題の調査
03最新のCompose構文の確認
04CI/CD検証スクリプトの準備

インストール

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

$npx skills add https://github.com/rknall/claude-skills --skill docker-configuration-validator

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

同梱ファイル

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

README.md

tool-installation.md

validation-checklist.md

詳細

Docker 設定バリデーター

このスキルでは、Dockerfile と Docker Compose ファイルを包括的に検証し、ベストプラクティス、セキュリティ標準、最新の構文要件への準拠を確認します。

このスキルを使用するタイミング

ユーザーから次の依頼があった場合に、このスキルを有効にします。

Dockerfile または Docker Compose ファイルを検証する
ベストプラクティスに照らして Docker 設定をレビューする
Docker のセキュリティ上の問題を確認する
マルチステージビルドの実装を検証する
本番環境に対応できるか Docker の設定を監査する
最新の Docker Compose 構文に準拠していることを確認する
Docker 設定の問題を修正する
検証スクリプトまたは CI/CD との統合を作成する

基本的なワークフロー

フェーズ 1：初期評価

ユーザーから Docker の検証を依頼されたら、まず対象範囲を把握します。

検証対象を特定する
- Dockerfile は 1 つですか、複数ですか？
- Docker Compose ファイルはありますか？
- プロジェクトディレクトリ全体ですか？
- 特定の懸念事項や重点項目はありますか？
- 本番環境と開発環境のどちらですか？
要件を把握する
- 必要なセキュリティ準拠レベルはどの程度ですか？
- マルチステージビルドは必要ですか？
- パフォーマンス上の制約はありますか？
- CI/CD との統合は必要ですか？
- 自動検証スクリプトが必要ですか？
利用可能なツールを確認する
- Hadolint は利用できますか？（Dockerfile リンター）
- DCLint は利用できますか？（Docker Compose リンター）
- Docker CLI は利用できますか？
- 作業の一環としてツールをインストールしますか？

フェーズ 2：Dockerfile の検証

ステップ 1：Dockerfile を検索する

プロジェクト内のすべての Dockerfile を検索します。

find . -type f \( -name "Dockerfile*" ! -name "*.md" \)

ステップ 2：Hadolint による検証を実行する

Hadolint が利用できる場合：

# Validate each Dockerfile
hadolint Dockerfile

# JSON output for programmatic analysis
hadolint --format json Dockerfile

# Set failure threshold
hadolint --failure-threshold error Dockerfile

Hadolint が利用できない場合：

組み込みチェックを使って手動で検証します（ステップ 3 を参照）
Hadolint のインストールを推奨します
インストール手順を提示します

ステップ 3：Dockerfile を手動で検証する

各 Dockerfile に重大な問題がないか確認します。

1. ベースイメージのベストプラクティス

✅ 確認：:latest タグを使用していない
✅ 確認：特定のバージョンを固定している
✅ 確認：最小限のベースイメージ（alpine/slim 系）を使用している
✅ 確認：信頼できるレジストリを使用している

2. マルチステージビルドの確認

# Count FROM statements (should be >= 2 for multi-stage)
FROM_COUNT=$(grep -c "^FROM " Dockerfile)

# Check for named stages
NAMED_STAGES=$(grep -c "^FROM .* AS " Dockerfile)

# Check for inter-stage copies
COPY_FROM=$(grep -c "COPY --from=" Dockerfile)

分析：

FROM_COUNT >= 2 の場合：マルチステージビルドを検出 ✅
COPY_FROM == 0 かつ FROM_COUNT >= 2 の場合：警告 — 成果物が転送されていない可能性があります
FROM_COUNT == 1 の場合：シングルステージビルドです — 最適化のためマルチステージビルドを推奨します

3. セキュリティチェック

✅ 確認：USER ディレクティブがある（root 以外）
✅ 確認：最後の USER が root ではない
✅ 確認：Dockerfile にシークレットが含まれていない
✅ 確認：WORKDIR に絶対パスを使用している
✅ 確認：不要な権限がない

4. レイヤーの最適化

✅ 確認：RUN コマンドをまとめている
✅ 確認：パッケージマネージャーのキャッシュを削除している
✅ 確認：キャッシュ効率を高めるため、RUN より前に COPY を実行している
✅ 確認：.dockerignore ファイルがある

5. ベストプラクティス

✅ 確認：HEALTHCHECK が定義されている
✅ 確認：cd ではなく WORKDIR を使用している
✅ 確認：ADD より COPY を優先している
✅ 確認：CMD/ENTRYPOINT に JSON 形式を使用している
✅ 確認：ラベル（メンテナー、バージョン）が含まれている

ステップ 4：Dockerfile の問題を分類する

検出事項を重大度別に分類します。

CRITICAL（必ず修正）：

root ユーザーとして実行している
:latest タグを使用している
イメージ内でシークレットが公開されている
構文が無効である

HIGH（修正を推奨）：

適用可能な場合にマルチステージビルドを使用していない
HEALTHCHECK がない
パッケージのバージョンが固定されていない
セキュリティ上の脆弱性がある

MEDIUM（推奨）：

COPY ではなく ADD を使用している
パッケージキャッシュを削除していない
ラベルが不足している
レイヤー構成が非効率である

LOW（あると望ましい）：

さらにスリムなベースイメージを使用できる
RUN コマンドをさらにまとめられる
コメントを改善できる

フェーズ 3：Docker Compose の検証

ステップ 1：Compose ファイルを検索する

すべての Docker Compose ファイルを検索します。

find . -maxdepth 3 -type f \( -name "docker-compose*.yml" -o -name "docker-compose*.yaml" -o -name "compose*.yml" \)

ステップ 2：廃止されたバージョンフィールドを確認する

重要な確認事項： 最新の Docker Compose（v2.27.0 以降）では version フィールドを使用しません。

# Check for obsolete version field
if grep -q "^version:" docker-compose.yml; then
    echo "❌ ERROR: Found obsolete 'version' field"
    echo "Remove 'version:' line - it's obsolete in Compose v2.27.0+"
fi

旧形式（非推奨）：

version: '3.8'  # ❌ REMOVE THIS
services:
  web:
    image: nginx:latest

新形式（最新）：

# No version field!
services:
  web:
    image: nginx:1.24-alpine

ステップ 3：組み込みの Docker Compose 検証

# Syntax validation
docker compose config --quiet

# Show resolved configuration
docker compose config

# Validate specific file
docker compose -f docker-compose.prod.yml config --quiet

ステップ 4：DCLint による検証（利用可能な場合）

# Lint compose file
dclint docker-compose.yml

# Auto-fix issues
dclint --fix docker-compose.yml

# JSON output
dclint --format json docker-compose.yml

ステップ 5：手動 Compose 検証

1. イメージのベストプラクティス

✅ 確認：:latest タグを使用していない
✅ 確認：具体的なバージョンを指定している
✅ 確認：信頼できるソースのイメージを使用している

2. サービス設定

✅ 確認：再起動ポリシーを定義している
✅ 確認：ヘルスチェックを設定している
✅ 確認：リソース制限を設定している（任意ですが推奨）
✅ 確認：サービス間の依存関係（depends_on）が適切である

3. ネットワーク

✅ 確認：カスタムネットワークを定義している
✅ 確認：ネットワーク分離を実装している
✅ 確認：適切なネットワークドライバーを使用している

4. ボリュームと永続化

✅ 確認：永続化に名前付きボリュームを使用している
✅ 確認：ボリュームドライバーを指定している
✅ 確認：バインドマウントで絶対パスを使用している
✅ 確認：ボリュームに機密データが含まれていない

5. 環境変数とシークレット

✅ 確認：環境変数を適切に管理している
✅ 確認：シークレットをハードコードしていない
✅ 確認：.env ファイルの使用を推奨している
✅ 確認：シークレット管理を設定している

6. セキュリティ

✅ 確認：必要な場合を除き、特権モードを使用していない
✅ 確認：ケイパビリティを適切に設定している
✅ 確認：ユーザー／グループを指定している
✅ 確認：該当する場合、ルートファイルシステムを読み取り専用にしている

フェーズ 4：マルチステージビルドの詳細確認

マルチステージビルドを検証する際は、次の点を確認してください。

1. ステージ構造

# Build stage
FROM node:20-bullseye AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm run test

# Production stage
FROM node:20-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/dist ./dist
USER node
CMD ["node", "dist/index.js"]

2. 検証チェックリスト

✅ 少なくとも 2 つのステージ（ビルド＋ランタイム）がある
✅ すべてのステージに AS キーワードを使って名前を付けている
✅ COPY --from を使ってステージ間で成果物をコピーしている
✅ 最終ステージで最小限のベースイメージを使用している
✅ 最終ステージにビルドツールが含まれていない
✅ 最終イメージに必要なファイルのみが含まれている
✅ 最終ステージが非 root ユーザーで実行される

3. 確認する一般的なパターン

Node.js のマルチステージ構成：

ビルドステージ：すべての依存関係をインストールし、ビルドとテストを実行する
ランタイムステージ：本番用の依存関係とビルド済みの成果物のみを含める

Python のマルチステージ構成：

ビルドステージ：依存関係をコンパイルし、wheel をビルドする
ランタイムステージ：ビルド済みの wheel とアプリのみをインストールする

Go のマルチステージ構成：

ビルドステージ：完全な Go ツールチェーンでバイナリをコンパイルする
ランタイムステージ：scratch／distroless とバイナリのみを使用する

フェーズ 5：セキュリティ監査

包括的なセキュリティチェックを実施します。

1. ユーザーと権限

# Check for USER directive
USER_COUNT=$(grep -c "^USER " Dockerfile)
LAST_USER=$(grep "^USER " Dockerfile | tail -1 | awk '{print $2}')

if [ "$USER_COUNT" -eq 0 ]; then
    echo "❌ CRITICAL: No USER specified (runs as root!)"
elif [ "$LAST_USER" == "root" ] || [ "$LAST_USER" == "0" ]; then
    echo "❌ CRITICAL: Final USER is root"
fi

2. 公開されたシークレット

ENV 内のパスワードを確認する
COPY／ADD 内の API キーを確認する
RUN コマンド内の認証情報を確認する
シークレット管理ソリューションを推奨する

3. 脆弱なベースイメージ

ベースイメージの経過期間とサポート状況を確認する
セキュリティスキャン（Trivy、Snyk）を推奨する
バージョンを固定した、サポート対象のものを提案する

4. ネットワークへの露出

EXPOSE ディレクティブを確認する
不要なポートが公開されていないか確認する
Compose のポートマッピングを検証する

フェーズ 6：検証レポートの作成

検証レポートを次の構成にします。

# Docker Configuration Validation Report

## Executive Summary
- **Total Dockerfiles Analyzed**: X
- **Total Compose Files Analyzed**: X
- **Critical Issues**: X
- **High Priority Issues**: X
- **Medium Priority Issues**: X
- **Low Priority Issues**: X
- **Overall Status**: ✅ PASS / ⚠️ WARNINGS / ❌ FAIL

## Dockerfile Analysis

### [Dockerfile Path]

#### Validation Results
✅ **PASSED**: Multi-stage build implemented
✅ **PASSED**: Running as non-root user
⚠️  **WARNING**: Using ADD instead of COPY (line 15)
❌ **FAILED**: Base image uses :latest tag (line 1)

#### Security Assessment
- **User**: nodejs (non-root) ✅
- **Base Image**: node:latest ❌
- **Secrets**: None detected ✅
- **Health Check**: Present ✅

#### Multi-Stage Build Analysis
- **Stages**: 2 (builder, runtime)
- **Named Stages**: Yes ✅
- **Inter-Stage Copies**: 1 ✅
- **Final Base**: node:20-alpine ✅
- **Build Tools in Final**: No ✅

#### Issues Found

**CRITICAL:**
1. Line 1: Using :latest tag
   - Issue: `FROM node:latest`
   - Fix: `FROM node:20-bullseye`
   - Impact: Unpredictable builds, security risk

**HIGH:**
2. Line 45: Package cache not cleaned
   - Issue: `RUN apt-get install -y curl`
   - Fix: Add `&& rm -rf /var/lib/apt/lists/*`
   - Impact: Larger image size

**MEDIUM:**
3. Line 15: Using ADD instead of COPY
   - Issue: `ADD app.tar.gz /app/`
   - Fix: `COPY app.tar.gz /app/` (or extract separately)
   - Impact: Less explicit behavior

## Docker Compose Analysis

### [Compose File Path]

#### Validation Results
❌ **FAILED**: Obsolete 'version' field present
⚠️  **WARNING**: 3 services using :latest tags
✅ **PASSED**: Custom networks defined
✅ **PASSED**: Named volumes configured

#### Modern Syntax Compliance
- **Version Field**: Present ❌ (MUST REMOVE)
- **Specific Tags**: 2 of 5 services ⚠️
- **Restart Policies**: All services ✅
- **Health Checks**: 3 of 5 services ⚠️

#### Issues Found

**CRITICAL:**
1. Obsolete 'version' field
   - Issue: `version: '3.8'`
   - Fix: Remove the entire line
   - Impact: Using deprecated syntax

**HIGH:**
2. Service 'web' uses :latest tag
   - Issue: `image: nginx:latest`
   - Fix: `image: nginx:1.24-alpine`
   - Impact: Unpredictable deployments

3. No restart policy on 'cache' service
   - Issue: Missing `restart:` directive
   - Fix: Add `restart: unless-stopped`
   - Impact: Service won't auto-recover

## Recommendations

### Immediate Actions (Critical)
1. Pin all Docker image versions (remove :latest)
2. Remove obsolete 'version' field from Compose files
3. Ensure all services run as non-root users
4. Clean package manager caches in all Dockerfiles

### High Priority (Before Production)
1. Implement health checks for all services
2. Add restart policies to all Compose services
3. Set up resource limits (memory, CPU)
4. Implement proper secrets management

### Medium Priority (Best Practices)
1. Use COPY instead of ADD unless extracting archives
2. Add labels for better organization
3. Implement logging drivers
4. Add metadata to images

### Low Priority (Optimizations)
1. Consider slimmer base images where possible
2. Optimize layer caching with better ordering
3. Add comprehensive comments
4. Implement .dockerignore files

## Next Steps

1. **Fix Critical Issues** (Estimated: 30 minutes)
   - Pin image versions
   - Remove version field from Compose
   - Add USER directives

2. **Address High Priority** (Estimated: 1-2 hours)
   - Add health checks
   - Configure restart policies
   - Set resource limits

3. **Re-validate** (Estimated: 10 minutes)
   - Run validation again after fixes
   - Ensure all critical issues resolved

4. **Set Up Automation** (Estimated: 1 hour)
   - Add pre-commit hooks
   - Integrate into CI/CD
   - Schedule regular security scans

## Validation Tools Recommendations

### Install Required Tools
```bash
# Hadolint (Dockerfile linter)
brew install hadolint  # macOS
# or
wget -O /usr/local/bin/hadolint https://github.com/hadolint/hadolint/releases/download/v2.12.0/hadolint-Linux-x86_64

# DCLint (Docker Compose linter)
npm install -g docker-compose-linter

# Trivy (Security scanner)
brew install aquasecurity/trivy/trivy

自動検証スクリプト

[プロジェクトの要件に応じたカスタム検証スクリプトを提供する]

CI/CD 統合

[GitHub Actions／GitLab CI の設定を提供する]


## Deliverables

At the end of validation, provide:

1. **Comprehensive Validation Report**
   - Executive summary with overall status
   - Detailed findings per file
   - Issue classification (Critical → Low)
   - Specific fixes for each issue
   - Recommendations prioritized

2. **Fixed Configuration Files** (if requested)
   - Corrected Dockerfiles
   - Updated Compose files
   - .hadolint.yaml configuration
   - .dclintrc.json configuration

3. **Validation Script** (if requested)
   - Custom bash script for automated validation
   - Checks for project-specific requirements
   - Color-coded output
   - Exit codes for CI/CD

4. **CI/CD Integration** (if requested)
   - GitHub Actions workflow
   - GitLab CI configuration
   - Pre-commit hooks
   - Integration with existing pipeline

5. **Documentation**
   - How to run validation locally
   - Tool installation instructions
   - Best practices guide
   - Common issues and solutions

## Validation Script Template

When user requests automated validation, create this script:

```bash
#!/bin/bash
# docker-validation.sh

set -e

# Color codes
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
BLUE='\033[0;34m'
NC='\033[0m'

ERRORS=0
WARNINGS=0

echo -e "${BLUE}╔══════════════════════════════════════════╗${NC}"
echo -e "${BLUE}║   Docker Configuration Validator        ║${NC}"
echo -e "${BLUE}╚══════════════════════════════════════════╝${NC}"

# 1. Prerequisites check
echo -e "\n${BLUE}━━━ Checking Prerequisites ━━━${NC}"
command -v docker >/dev/null || { echo "❌ Docker not found"; exit 1; }
command -v hadolint >/dev/null || echo "⚠️  Hadolint not installed"

# 2. Dockerfile validation
echo -e "\n${BLUE}━━━ Validating Dockerfiles ━━━${NC}"
find . -name "Dockerfile*" -type f | while read df; do
    echo "Checking: $df"
    # [Validation logic here]
done

# 3. Multi-stage build check
echo -e "\n${BLUE}━━━ Checking Multi-Stage Builds ━━━${NC}"
# [Multi-stage validation logic]

# 4. Compose validation
echo -e "\n${BLUE}━━━ Validating Docker Compose ━━━${NC}"
find . -name "*compose*.yml" | while read cf; do
    # Check for obsolete version field
    if grep -q "^version:" "$cf"; then
        echo -e "${RED}❌ $cf: Obsolete version field${NC}"
        ERRORS=$((ERRORS + 1))
    fi

    # Validate syntax
    docker compose -f "$cf" config --quiet || ERRORS=$((ERRORS + 1))
done

# 5. Security checks
echo -e "\n${BLUE}━━━ Security Audit ━━━${NC}"
# [Security validation logic]

# Final report
echo -e "\n${BLUE}╔══════════════════════════════════════════╗${NC}"
echo -e "${BLUE}║         Validation Summary               ║${NC}"
echo -e "${BLUE}╚══════════════════════════════════════════╝${NC}"

if [ $ERRORS -eq 0 ]; then
    echo -e "${GREEN}✅ All checks passed!${NC}"
    exit 0
else
    echo -e "${RED}❌ Found $ERRORS error(s), $WARNINGS warning(s)${NC}"
    exit 1
fi

CI/CD 統合テンプレート

GitHub Actions

name: Docker Validation

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  validate:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Lint Dockerfiles
        uses: hadolint/[email protected]
        with:
          dockerfile: ./Dockerfile
          failure-threshold: error

      - name: Validate Compose files
        run: |
          for f in $(find . -name "*compose*.yml"); do
            docker compose -f "$f" config --quiet
          done

      - name: Check for obsolete version field
        run: |
          if grep -r "^version:" . --include="*compose*.yml"; then
            echo "ERROR: Found obsolete version field"
            exit 1
          fi

GitLab CI

stages:
  - validate

docker-validation:
  stage: validate
  image: hadolint/hadolint:latest-debian
  script:
    - find . -name "Dockerfile*" -exec hadolint {} \;
    - |
      for f in $(find . -name "*compose*.yml"); do
        if grep -q "^version:" "$f"; then
          echo "ERROR: Obsolete version field in $f"
          exit 1
        fi
      done

コミュニケーションスタイル

検証を実施する際は、次の点に留意してください。

徹底する
- あらゆる項目を体系的に確認する
- ツールを利用できない場合も、手動確認を省略しない
- 構文とベストプラクティスの両方を検証する
優先順位を明確にする
- まず重大な問題（セキュリティ、機能性）に対応する
- 次に優先度の高い問題（本番環境への対応）に取り組む
- 中程度および低い優先度の項目は改善点として扱う
具体的な修正方法を示す
- 正確な行番号を示す
- 修正前と修正後のコードを提示する
- 修正が必要な理由を説明する
- 影響評価を含める
知識を共有する
- Docker のベストプラクティスを説明する
- 公式ドキュメントを参照する
- 学習リソースを提供する
- 現行の構文要件を共有する
実行に移せる内容にする
- 段階的な修正手順を提示する
- 自動化スクリプトを提供する
- CI/CD 統合を提案する
- 修正に必要な作業量を見積もる

一般的な検証パターン

パターン 1：簡易構文チェック

Hadolint と DCLint を実行する
廃止された version フィールドがないか確認する
Docker Compose config で検証する
重大な構文エラーのみを報告する

パターン 2：本番環境の包括的な監査

Dockerfile を完全に検証
マルチステージビルドを検証
セキュリティ監査
Compose のベストプラクティス
包括的なレポートを生成
自動化スクリプトを提供

パターン 3：セキュリティに重点を置いたレビュー

ユーザー権限を確認
シークレットの漏えいをスキャン
ベースイメージのセキュリティ
ネットワーク公開範囲を監査
セキュリティスキャンを統合

パターン 4：最適化レビュー

マルチステージビルドの有効性
レイヤーの最適化
イメージサイズの分析
ビルド時間の改善
キャッシュ戦略

適用すべき主なルール

Dockerfile のルール（重要）

✅ :latest タグを使用しない（DL3006）
✅ 最後の USER を root にしない（DL3002）
✅ 絶対パスの WORKDIR を使用する（DL3000）
✅ パッケージのバージョンを固定する（DL3008、DL3013）
✅ パッケージキャッシュをクリーンアップする（DL3009）

Docker Compose のルール（重要）

✅ version フィールドを使用しない（v2.27.0 以降、廃止）
✅ :latest タグを使用しない
✅ 再起動ポリシーを定義する
✅ ヘルスチェックを設定する
✅ 永続化には名前付きボリュームを使用する

マルチステージビルドのルール

✅ ステージを 2 つ以上にする
✅ AS を使ってステージに名前を付ける
✅ 成果物には COPY --from を使用する
✅ 最終段階では最小限のベースイメージを使用する
✅ 最終段階にビルドツールを含めない

セキュリティルール（重要）

✅ 非 root の USER として実行する
✅ イメージにシークレットを含めない
✅ 最小限のベースイメージを使用する
✅ 定期的にセキュリティスキャンを実施する
✅ 最小権限の原則に従う

参考リソース

推奨事項を提示する際は、以下を参照してください。

Docker のベストプラクティス：Docker 公式ドキュメント
Hadolint のルール：ルールの完全なリファレンス
Compose 仕様：最新の Compose 仕様
セキュリティ標準：CIS Docker Benchmark
マルチステージビルド：公式ガイドとサンプル

Docker の検証は、信頼性が高く、安全で効率的なコンテナ化アプリケーションを実現するためのものです。開発者の利便性を維持しながら、常にセキュリティと本番環境への対応を優先してください。

Markdown 対応

ログインしてコメント

基本情報

作者: rknall
リポジトリ: rknall/claude-skills
カテゴリ: テスト・品質
インストール数: 339
GitHub スター: 86

問題を報告