mcpField
A
aif-dockerize

aif-dockerize

github.com/lee-toクラウド・DevOps1.1k95 回インストール今日更新
リポジトリ

aif-dockerize について

aif-dockerizeは、プロジェクトを分析してDocker設定を生成・改善するAI Factoryスキルです。既存ファイルをセキュリティチェックリストに照らして監査します。

主な機能

  1. 01マルチステージDockerfileの生成
  2. 02開発・本番用Composeファイルの作成
  3. 03プロジェクトのランタイムと依存関係の検出
  4. 04セキュリティ基準に沿ったDocker設定の監査
  5. 05既存のローカルDocker設定の改善

活用シーン

  1. 01プロジェクト用Dockerファイルの作成
  2. 02ローカル設定への本番構成の追加
  3. 03既存設定のセキュリティ上の不足の確認

インストール

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

$npx skills add https://github.com/lee-to/ai-factory --skill aif-dockerize

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

同梱ファイル

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

references/
ANGIE-ACME.md
AUDIT-GUIDE.md
BEST-PRACTICES.md
COMPOSE-LIFECYCLE-HOOKS.md
COMPOSE-PATTERNS.md
DEPLOY-SCRIPTS.md
FILE-ORGANIZATION.md
SECURITY-CHECKLIST.md
SUMMARY-FORMAT.md
templates/
backup.sh
compose-base.yml
compose-override-dev.yml
compose-production.yml
deploy.sh
dockerfile-go
dockerfile-node
dockerfile-php
dockerfile-python
dockerignore
health-check.sh
logs.sh
rollback.sh
update.sh

詳細

Dockerize — Docker 設定ジェネレーター

プロジェクトを分析し、本番環境向けの完全な Docker 設定を生成します。マルチステージ Dockerfile、開発環境および本番環境用の Docker Compose、.dockerignore、生成結果のセキュリティ監査が含まれます。

既存の構成に応じた 3 つのモード：

既存の構成モードアクション
何もないgenerate対話形式のセットアップで、すべてをゼロから作成
ローカル用 Docker のみ（本番用ファイルなし）enhanceローカル環境を監査・改善してから、本番用の設定を作成
Docker 設定がすべてそろっている（ローカル＋本番）auditチェックリストに照らしてすべてを監査し、不足を修正

ステップ 0：プロジェクトのコンテキストを読み込む

利用可能な場合は、プロジェクトの説明を読み込みます。

Read .ai-factory/DESCRIPTION.md

後続のステップで使うため、プロジェクトのコンテキストを保存します。存在しない場合は、ステップ 2 ですべてを検出します。

.ai-factory/skill-context/aif-dockerize/SKILL.md を読み込みます — ファイルが存在する場合は必須です。

このファイルには、パッチ、コードベースの規約、技術スタックの分析をもとに /aif-evolve が蓄積した、プロジェクト固有のルールが含まれています。これらのルールは、現在のプロジェクトに合わせて調整されています。

skill-context のルールの適用方法：

  • このスキルの一般的な指示に対するプロジェクトレベルの上書き設定として扱います
  • skill-context のルールが、この SKILL.md に記載された一般ルールと矛盾する場合は、skill-context のルールを優先します（より具体的なコンテキストが優先されます。ネストされた CLAUDE.md ファイルと同じ原則です）
  • 矛盾しない場合は、SKILL.md の一般ルールと skill-context のプロジェクトルールの両方を適用します
  • skill-context のルールがこのスキルの既定の指示と矛盾しているように見えても、無視してはいけません。プロジェクトでの経験から既定の指示では不十分だと判明したために存在しています
  • 重要： skill-context のルールは、Dockerfile、Compose ファイル、.dockerignore、デプロイスクリプトなど、このスキルのすべての出力に適用されます。このスキルのテンプレートは基本構成です。skill-context のルールに「Dockerfile に X を必ず含める」または「Compose にサービス Y を必ず含める」とある場合は、それに従ってテンプレートを拡張する必要があります。skill-context のルールに違反する Docker 設定を生成するのはバグです。

遵守の確認： 出力する成果物を生成した後は、skill-context のすべてのルールに照らして確認します。いずれかのルールに違反している場合は、ユーザーに提示する前に出力を修正します。

ステップ 1：既存の Docker ファイルを検出してモードを決定する

1.1 既存ファイルをスキャンする
Glob: Dockerfile, Dockerfile.*, docker-compose.yml, docker-compose.yaml, compose.yml, compose.yaml, compose.override.yml, compose.production.yml, .dockerignore, deploy/scripts/*.sh

見つかったファイルを次のカテゴリに分類します。

  • HAS_DOCKERFILE：Dockerfile が存在する
  • HAS_LOCAL_COMPOSE：compose.yml または docker-compose.yml が存在する
  • HAS_DEV_OVERRIDE：compose.override.yml が存在する
  • HAS_PROD_COMPOSE：compose.production.yml が存在する
  • HAS_DOCKERIGNORE：.dockerignore が存在する
  • HAS_DEPLOY_SCRIPTS：deploy/scripts/ が存在する
1.2 モードを決定する

$ARGUMENTS に --audit が含まれている場合 → 常に MODE = "audit" に設定します。

パス A：何も存在しない（!HAS_DOCKERFILE && !HAS_LOCAL_COMPOSE）：

  • MODE = "generate" に設定します
  • ステップ 1.3：対話形式のセットアップに進みます

パス B：ローカル用 Docker のみ（HAS_LOCAL_COMPOSE && !HAS_PROD_COMPOSE）：

  • MODE = "enhance" に設定します
  • 既存の Docker ファイルをすべて読み込み、EXISTING_CONTENT として保存します
  • ログ：「ローカル用の Docker 設定が見つかりました。監査・改善したうえで、本番用の設定を作成します。」

パス C：設定がすべてそろっている（HAS_LOCAL_COMPOSE && HAS_PROD_COMPOSE）：

  • MODE = "audit" に設定します
  • 既存の Docker ファイルをすべて読み込み、EXISTING_CONTENT として保存します
  • ログ：「Docker 設定がすべてそろっています。セキュリティチェックリストに照らして監査し、不足を修正します。」
1.3 対話形式のセットアップ（Generate モードのみ）

ゼロから作成する場合は、インフラストラクチャの要件についてユーザーに質問します。

AskUserQuestion: Which database does this project use?

Options:
1. PostgreSQL (Recommended)
2. MySQL / MariaDB
3. MongoDB
4. SQLite (no container needed)
5. None

AskUserQuestion: Does this project need a reverse proxy / web server?

Options:
1. Angie (Recommended) — Modern Nginx fork with enhanced features
2. Nginx
3. Traefik
4. None (app serves directly)

注: Nginx より Angie を優先してください。Angie は Nginx と置き換えてそのまま使える、モジュールサポートの強化、動的な設定、活発な開発が特徴のソフトウェアです。参照先：https://en.angie.software/angie/docs/configuration/

AskUserQuestion: Which cache / message broker does this project need? (select all)

Options:
1. Redis
2. Memcached
3. RabbitMQ
4. None

選択内容を USER_INFRA_CHOICES に保存します。

  • database：postgres | mysql | mongodb | sqlite | none
  • reverse_proxy：angie | nginx | traefik | none
  • cache：redis | memcached | none
  • queue：rabbitmq | none
1.4 既存ファイルの読み込み（Enhance / Audit モード）

既存の Docker 関連ファイルをすべて読み込み、EXISTING_CONTENT として保存します。

  • Dockerfile(s)
  • すべての compose ファイル（local + override + production）
  • .dockerignore
  • deploy/scripts/*.sh（存在する場合）

Step 2: プロジェクトの詳細分析

プロジェクトを徹底的にスキャンします。生成するファイルに関するすべての判断は、このプロファイルに基づきます。

2.1 言語とランタイム
ファイル言語ベースイメージ
go.modGogolang:<version>-alpine / distroless/static
package.jsonNode.jsnode:<version>-alpine
pyproject.toml / setup.pyPythonpython:<version>-slim
composer.jsonPHPphp:<version>-fpm-alpine
Cargo.tomlRustrust:<version>-slim / distroless

<version> = プロジェクトファイルから読み取ります（Step 4.1 を参照）。バージョンを固定値にしてはいけません。プロジェクトが必要とするバージョンに必ず合わせてください。

2.2 フレームワークと開発サーバー

依存関係ファイルを読み込み、フレームワークを検出します。

Node.js（package.json の依存関係）：

  • next → Next.js（ポート 3000、next dev / next start）
  • nuxt → Nuxt（ポート 3000、nuxt dev / nuxt start）
  • express → Express（ポート 3000、nodemon / node）
  • fastify → Fastify（ポート 3000）
  • @nestjs/core → NestJS（ポート 3000、nest start --watch / node dist/main）
  • hono → Hono（ポート 3000）

Python（pyproject.toml / requirements）：

  • fastapi → FastAPI（ポート 8000、uvicorn --reload / uvicorn）
  • django → Django（ポート 8000、manage.py runserver / gunicorn）
  • flask → Flask（ポート 5000、flask run --debug / gunicorn）

PHP（composer.json の require）：

  • laravel/framework → Laravel（ポート 8000、artisan serve / php-fpm）
  • symfony/framework-bundle → Symfony（ポート 8000、symfony serve / php-fpm）

Go（go.mod の require）：

  • gin-gonic/gin、labstack/echo、gofiber/fiber、go-chi/chi →（ポート 8080、air / コンパイル済みバイナリ）
2.3 パッケージマネージャーとロックファイル

/aif-build-automation の Step 2.2 と同じ方法で検出します。

保存する値：PACKAGE_MANAGER、LOCK_FILE。

2.4 エントリーポイントの検出

アプリケーションのエントリーポイントを特定します。

# Go
Glob: cmd/*/main.go, main.go

# Node.js
Read package.json → "main" or "scripts.start"
Glob: src/index.ts, src/index.js, src/main.ts, src/main.js, index.ts, index.js, server.ts, server.js

# Python
Glob: main.py, app.py, src/main.py, src/app.py
Read pyproject.toml → [project.scripts] or [tool.uvicorn]

# PHP
Glob: public/index.php, artisan, bin/console
2.5 インフラストラクチャの依存関係

アプリケーションに必要なサービスを検出します。

# Database
Grep: postgres|postgresql|pg_|mysql|mariadb|mongo|mongodb|sqlite
Glob: prisma/schema.prisma, drizzle.config.*, alembic/, migrations/

# Cache
Grep: redis|memcached|ioredis

# Queue
Grep: rabbitmq|amqp|bullmq|celery|sidekiq

# Reverse Proxy / Web Server
Grep: nginx|angie|proxy_pass|upstream
Glob: nginx.conf, nginx/, angie.conf, angie/
# PHP projects (Laravel, Symfony) always need a reverse proxy → default to Angie

# Search
Grep: elasticsearch|opensearch|meilisearch|typesense|algolia

# Object Storage
Grep: minio|s3|aws-sdk.*S3|boto3.*s3

# Email
Grep: nodemailer|sendgrid|mailgun|postmark|smtp|MAIL_HOST

検出された依存関係ごとに、以下を記録します。

  • サービスタイプ（postgres、redis、rabbitmq など）
  • 具体的な種類（MySQL と PostgreSQL、Redis と Memcached など）
  • コード内で見つかった接続文字列の形式

USER_INFRA_CHOICES と統合します（Generate モードの Step 1.3 で指定した内容）。

  • データベースとリバースプロキシについては、ユーザーの選択を自動検出より優先します。
  • ユーザーが明示的に「None」を選択していない限り、自動検出されたサービスを追加します。

リバースプロキシの優先設定： リバースプロキシが必要な場合は、Nginx より Angie を優先してください。Angie は Nginx と完全な互換性を持つフォークであり、活発に開発されているほか、動的なアップストリーム管理と Prometheus メトリクスの組み込み機能を備えています。参照先：https://en.angie.software/angie/docs/configuration/

2.6 公開ポート

既存の設定を確認します。

Grep: PORT|port|listen|EXPOSE
Read package.json → scripts.dev, scripts.start (look for --port)
2.7 ビルド出力
# Node.js
Read package.json → scripts.build, check for dist/, build/, .next/, out/
Read tsconfig.json → outDir

# Go
Glob: cmd/*/main.go → binary name from directory

# Python
Check for pyproject.toml [build-system]

# PHP
Check for public/ directory (web root)
2.8 既存の .env 構造
Glob: .env.example, .env.sample, .env.template

見つかった場合は、必要な環境変数を把握するために読み込みます。これを基に env_file、environment:（計算値）、.env.example の生成内容を決定します。

概要

PROJECT_PROFILE を構築します。

  • language、language_version
  • framework、dev_command、prod_command
  • package_manager、lock_file
  • entry_point、build_output_dir
  • port（アプリのプライマリポート）
  • debug_port（言語固有のデバッグポート）
  • services：インフラ依存関係のリスト（postgres、redis、rabbitmq など）
  • has_build_step：ブール値
  • env_vars：.env.example から取得したリスト

ステップ 3：ベストプラクティスとテンプレートを読む

Read skills/dockerize/references/BEST-PRACTICES.md
Read skills/dockerize/references/SECURITY-CHECKLIST.md

本番環境のリバースプロキシや Compose の権限に関する特殊なケースについて、以下の詳細なリファレンスも利用できます。

  • references/ANGIE-ACME.md — Angie の HTTPS／ACME 設定を生成または監査するときに読みます。組み込みの ACME 設定、永続証明書ボリューム、acme_client_path、リゾルバーの要件、および不要な Certbot コンテナを避ける方法について参照します。
  • references/COMPOSE-LIFECYCLE-HOOKS.md — 本番環境の Compose サービスが非 root で実行される一方、名前付きボリュームの所有権修正やベストエフォートの停止フックを必要とするときに読みます。post_start／pre_stop の構文、Docker Compose 2.30.0 以降の要件、およびフックのタイミングに関する注意事項について参照します。

言語に合った Dockerfile テンプレートを選択します。

言語テンプレート
Gotemplates/dockerfile-go
Node.jstemplates/dockerfile-node
Pythontemplates/dockerfile-python
PHPtemplates/dockerfile-php

選択したテンプレートと Compose テンプレートを読みます。

Read skills/dockerize/templates/dockerfile-<language>
Read skills/dockerize/templates/compose-base.yml
Read skills/dockerize/templates/compose-override-dev.yml
Read skills/dockerize/templates/compose-production.yml
Read skills/dockerize/templates/dockerignore

ステップ 4：ファイルを生成する（生成モード）

プロジェクトプロファイルとテンプレートを基に、プロジェクトに合わせてカスタマイズしたファイルを生成します。

4.1 Dockerfile を生成する

言語固有のテンプレートをベースとして使用します。

カスタマイズ：

  • テンプレートのデフォルトではなく、プロジェクトのベースイメージのバージョンを指定します。
    • Go：go.mod の go ディレクティブを読みます → 例：go 1.24 → golang:1.24-alpine
    • Node.js：package.json の engines.node、.nvmrc、または .node-version を読みます → 例：node:22-alpine
    • Python：pyproject.toml の requires-python または .python-version を読みます → 例：python:3.13-slim
    • PHP：composer.json の require.php を読みます → 例：php:8.4-fpm-alpine
    • Rust：Cargo.toml の rust-version または rust-toolchain.toml を読みます → 例：rust:1.82-slim
  • entry_point に合わせてエントリーポイントを設定します
  • プロジェクトの実際のビルドスクリプトに合わせてビルドコマンドを設定します
  • ホットリロードを有効にした開発コマンドを設定します（フレームワーク固有）
  • 本番環境用コマンドを設定します（フレームワーク固有）
  • 公開するポートを設定します（開発ステージではアプリのポートとデバッグポート）
  • パッケージマネージャーのコマンドを設定します（npm ci、pnpm install、yarn install、bun install のいずれか）
  • COPY でロックファイル名を指定します

ステージ：

  1. deps — 本番環境用の依存関係のみをインストールします
  2. builder — すべての依存関係をインストールしてビルドします
  3. development — ホットリロードとデバッグポートを備えた開発環境一式
  4. production — 非 root ユーザーで実行する最小限のイメージ。実行時に必要な成果物のみを含めます

インフライメージのバージョンをオンラインで確認します。

インフライメージ（PostgreSQL、Redis、Angie、Nginx など）のバージョンは、プロジェクトのファイルには記載されていません。compose.yml を生成する前に、WebSearch を使用して各インフライメージの最新の安定バージョンを確認します。

  • <service> docker official image latest version を検索します（例：angie docker image latest version）
  • 最新の安定した major.minor タグを使用し、:latest は決して使用しません
  • 例：docker.angie.software/angie:1.11-alpine、postgres:17-alpine、redis:7-alpine

これにより、docker compose pull の失敗につながる、存在しないイメージタグの生成を防げます。

4.2 compose.yml を生成（基本）

共有設定：

  • トップレベルの name: ${COMPOSE_PROJECT_NAME} — .env から取得するプロジェクト名であり、フォルダー名からは取得しません
  • build.target: production、ヘルスチェック、service_healthy を指定した depends_on を含む app サービス
  • PROJECT_PROFILE.services + USER_INFRA_CHOICES に基づくインフラストラクチャサービス：
    • PostgreSQL / MySQL / MongoDB → ヘルスチェックと名前付きボリュームを設定
    • Redis / Memcached → ヘルスチェック、maxmemory 設定、名前付きボリュームを設定
    • RabbitMQ → ヘルスチェックを設定し、開発環境では管理 UI ポートを設定
    • Angie / Nginx / Traefik → SSL 終端設定を備えたリバースプロキシとして設定
    • Elasticsearch → ヘルスチェック、JVM メモリ、ulimits を設定
    • MinIO → ヘルスチェックを設定

リバースプロキシ（Angie/Nginx）： docker.angie.software/angie:<version>-alpine（Angie）または nginx:<version>-alpine（Nginx）を使用します。現在のバージョンはオンラインで確認してください。docker/angie/ から設定をマウントします。frontend ネットワークに接続し、backend ネットワーク上の app にプロキシします。本番環境では、read_only と cap_add NET_BIND_SERVICE を設定します。

環境変数の方針とサービス設定パターン — references/COMPOSE-PATTERNS.md を参照してください。

サービスの追加は条件付きです — Step 2.5 で検出されたサービスのみを追加してください。

4.3 compose.override.yml を生成（開発環境）

開発環境のオーバーライド：build.target: development、ソースコードのバインドマウント（.:/app）、すべてのポートを公開、開発用環境変数、開発用コマンドのオーバーライド、メールが検出された場合は mailpit サービス（profile: dev）。データベース管理 UI は使用しません — 公開した DB ポートを使い、ネイティブの GUI クライアントを使用してください。

ホットリロード： 開発ステージで air（Go）または nodemon（Node.js）を使用する場合は、その設定ファイルが存在し、正しいエントリーポイントを指定していることを確認してください。ファイルが存在せず、エントリーポイントが標準的でない場合は、設定を生成してください。

4.4 compose.production.yml を生成（堅牢化）

本番環境の堅牢化オーバーレイ：

  • build: ではなく、レジストリのビルド済みイメージを使用
  • すべてのサービスに read_only: true を設定
  • security_opt: [no-new-privileges:true] を設定
  • cap_drop: [ALL] と、サービスごとの選択的な cap_add を設定
  • user: "1001:1001" を設定
  • noexec,nosuid,size=100m を指定した /tmp 用の tmpfs
  • リソース制限（CPU、メモリ、PIDs）— 参考資料の推奨値を使用
  • すべてのサービスでログローテーションを設定（max-size: 20m, max-file: 5）
  • restart: unless-stopped を設定
  • internal: true を指定した backend ネットワーク
  • 機密値は .env ファイル（gitignore 対象）で管理し、compose にハードコードしない
  • YAML アンカー（x-logging、x-security）を使い、重複を削減
  • インフラストラクチャサービス（DB、Redis、RabbitMQ）には ports: を設定しません — Docker ネットワーク経由でのみ通信します
  • ホストにポート 80 / 443 を公開するのは、リバースプロキシ（プロキシがない場合は app）のみです
  • ポートの公開が必須の場合は、localhost のみにバインドします：127.0.0.1:5432:5432
  • デバッグ用ポート（9229、5005 など）は使用しません
  • 開発ツールは使用しません
4.5 .dockerignore を生成

テンプレートをベースに、言語固有の除外項目を追加します：

  • Go：bin/、*.exe
  • Node.js：node_modules/、.next/、out/
  • Python：__pycache__/、.venv/、*.pyc、.mypy_cache/
  • PHP：vendor/、storage/、bootstrap/cache/
品質チェック（作成前）

ステップ 6 に進む前に、生成した内容を確認してください。

正確性：

  • Dockerfile に 4 つのステージ（deps、builder、development、production）がすべて含まれている
  • production ステージで非 root ユーザーを使用している
  • production ステージで最小構成のベースイメージを使用している
  • 依存関係のインストールに BuildKit のキャッシュマウントを使用している
  • compose.yml のすべてのサービスにヘルスチェックが設定されている
  • compose.yml で depends_on と condition: service_healthy を使用している
  • compose.production.yml のすべてのサービスにセキュリティ強化が設定されている
  • compose.production.yml のすべてのサービスにリソース制限が設定されている
  • compose.production.yml のすべてのサービスにログローテーションが設定されている
  • .dockerignore で .git、依存関係、.env*、Docker ファイルが除外されている

過剰な設計のチェック（references/SECURITY-CHECKLIST.md →「過剰設計チェックリスト」を参照）：

  • コードでインポートまたは使用されていないサービスが追加されていない
  • SSL が不要な単一サービスのアプリにリバースプロキシが追加されていない
  • CI/CD でデプロイするプロジェクトにデプロイスクリプトが追加されていない
  • マネージド DB（RDS、Cloud SQL）を使用している場合にバックアップスクリプトが追加されていない
  • アプリと DB しかない場合にフロントエンド用とバックエンド用のネットワークが分けられていない
  • 複雑さがプロジェクトの規模に見合っている（個人 → 最小限、チーム → 標準、本番環境 → 完全構成）

ステップ 5：既存ファイルの監査と拡張（拡張／監査モード）

MODE = "enhance" または MODE = "audit" の場合、EXISTING_CONTENT をセキュリティチェックリストとベストプラクティスに照らして分析します。

拡張モード（MODE = "enhance"）：ローカル用の Docker 設定は存在するものの、本番環境用の設定がない場合です。ローカルファイルを監査した後、本番環境用の設定を作成します。本番環境用のファイルを生成する前に、不足しているインフラストラクチャについて対話形式で質問します（ステップ 1.3 と同様）。

監査手順、レポート形式、修正の流れ、拡張モードの手順については、references/AUDIT-GUIDE.md を参照してください。

監査項目：

  • Dockerfile：イメージのバージョン固定、最小構成のベースイメージ、マルチステージ、非 root ユーザー、ENV/ARG にシークレットが含まれていないこと、.dockerignore、BuildKit の機能、HEALTHCHECK
  • Compose のサービスごとの設定：read_only、no-new-privileges、cap_drop ALL、user、tmpfs、リソース制限、ヘルスチェック、ログローテーション、再起動ポリシー
  • ネットワーク：内部バックエンド、host ネットワークを使用していないこと、Docker ソケットを使用していないこと
  • シークレット：値が .env にあり、ハードコードされていないこと、.env が .gitignore に含まれていること、.env.example が存在すること
  • 不足項目：コード内で検出されたものの Compose に含まれていないサービス

結果は ✅/❌/⚠️ を使った表で提示します。ユーザーに、すべて修正、重大な項目のみ修正、詳細を表示、レポートをエクスポート、のいずれかを尋ねます。

ステップ 6：ファイルの作成

ディレクトリ構成、モードごとのファイル一覧、.env.example のテンプレート、ボリュームマウントの例など、ファイルの詳細な構成については references/FILE-ORGANIZATION.md を参照してください。

6.0 概要
  • ルート：Dockerfile、compose.yml、compose.override.yml、compose.production.yml、.dockerignore
  • docker/：サービス設定（angie、postgres、php、redis）—必要なものだけを作成
  • deploy/scripts/：本番環境の運用スクリプト（ステップ 8）
6.1 生成モード — ルートの全ファイル、条件に応じた docker/ ディレクトリ、deploy/scripts/ を作成
6.2 監査／拡張モード — 変更または新規作成するファイルのみを作成し、既存の構成を尊重
6.3 .env.example がない場合は作成 — セクションを含む単一のファイルとし、本番環境用の変数はコメントアウトします。.env が .gitignore に含まれていることを確認してください。

ステップ 7：セキュリティチェックリスト（常に実行）

モードにかかわらず、最終的な compose.production.yml に対して本番環境用のセキュリティチェックリストを実行します。

references/SECURITY-CHECKLIST.md を読み、すべての項目を確認してください。次のカテゴリをチェックします：コンテナの分離（read_only、no-new-privileges、cap_drop、非 root、tmpfs）、ネットワークとポート（内部バックエンド、host ネットワークを使用していないこと、Docker ソケットを使用していないこと、インフラストラクチャのポートが公開されていないこと）、リソース（メモリ／CPU／PID の制限）、シークレット（.env にハードコードされていないこと、.gitignore、.env.example）、ヘルスチェックとログ（ヘルスチェック、ログローテーション、再起動ポリシー）、イメージ（バージョン固定、最小構成のベースイメージ）。

項目ごとの [x]/[ ] とスコアを含むコンパクトなチェックリストを表示します。チェックに不合格がある場合は、その場での修正を提案します。

ステップ 8：デプロイスクリプトの生成（本番環境）

テンプレートから本番環境用のデプロイスクリプトを deploy/scripts/ に生成します。

スクリプトのカスタマイズ箇所と生成ルールについては、references/DEPLOY-SCRIPTS.md を参照してください。

テンプレート：templates/deploy.sh、templates/update.sh、templates/logs.sh、templates/health-check.sh、templates/rollback.sh、templates/backup.sh

ステップ 9：概要とフォローアップ

references/SUMMARY-FORMAT.md の形式を使用して、作成・更新したすべてのファイルの概要を表示します。

フォローアップとして、Docker ターゲットには /aif-build-automation、ドキュメントには /aif-docs を提案してください。

成果物の所有権と設定ポリシー

  • 主な所有対象：Docker 成果物（Dockerfile、compose*.yml、.dockerignore、docker/*、deploy/scripts/*、およびこのスキルによって作成される関連する .env.example のひな形）。
  • 付随する更新の許可範囲：デフォルトでは、Docker とデプロイメントの成果物以外はありません。
  • 設定ポリシー：設計上、設定に依存しません。このスキルでは、リポジトリの検出、明示的なインフラストラクチャの選択、config.yaml ではなく固定された AI Factory コンテキストファイルを使用します。

コメント

Markdown 対応