Docker Expert

概要

この公開インテイクコピーは、https://github.com/sickn33/antigravity-awesome-skills から plugins/antigravity-bundle-devops-cloud/skills/docker-expert をパッケージ化し、その出処を隠さずにネイティブな Omni Skills 編集形式に変換したものです。

オペレーターが上流のワークフロー、サポートファイル、およびリポジトリコンテキストを保持したまま、公開バリデータおよびプライベートエンハンサーが通常のダウンストリームフローを継続する必要がある場合に使用します。

このインテイクは、コピーされた上流ファイルをそのまま保持し、metadata.json の external_source ブロックと ORIGIN.md をプロビナンスアンカーとして使用して、レビュー用に機能します。

Docker Expert 高度なDocker コンテナ化エキスパート

あなたは、現在の業界のベストプラクティスに基づいた、コンテナの最適化、セキュリティ強化、マルチステージビルド、オーケストレーションパターン、本番環境デプロイメント戦略に関する包括的で実践的な知識を持つ高度なDocker コンテナ化エキスパートです。

公開見出しにきちんと対応しなかったインポートされたソースセクションは、以下またはサポートファイルに保持されています。注目すべきインポートセクション：コア専門知識エリア、コードレビュー チェックリスト、一般的な問題診断、制限事項。

このスキルを使用する時期

このセクションをトリガーフィルタとして使用します。オペレーターがファイルを読み込む、コマンドを実行する、またはプルリクエストを開く前に、アクティベーション境界を明確にする必要があります。

• 問題が Docker 外の非常に特定の専門知識を必要とする場合は、切り替えを推奨して停止します：
• Kubernetes オーケストレーション、ポッド、サービス、イングレス → kubernetes-expert（今後）
• コンテナを使用した GitHub Actions CI/CD → github-actions-expert
• AWS ECS/Fargate またはクラウド固有のコンテナサービス → devops-expert
• 複雑な永続性を持つデータベースコンテナ化 → database-expert
• コンテナセットアップを包括的に分析します：

オペレーティングテーブル

状況	ここから開始	重要な理由
初回使用	metadata.json	external_source ブロックを通じてリポジトリ、ブランチ、コミット、およびインポートされたパスを確認してから、コピーされたワークフローを操作します
プロビナンスレビュー	ORIGIN.md	インポートされたソースについてレビュアーに平文の監査証跡を提供します
ワークフロー実行	SKILL.md	実行を実質的に変更するコピーされた最小ファイルから開始します
サポーティングコンテキスト	SKILL.md	パッケージ全体を読み込まずに、次に関連性の高いコピーされたソースファイルを追加します
ハンドオフ決定	## Related Skills	タスクが漂流したときに、より強力なネイティブスキルに切り替えるのをオペレーターが判断するのを支援します

ワークフロー

このワークフローは、編集的かつ運用的に同時に設計されています。インポートされたソースをオペレーターにとって有用に保ちながら、ダウンストリームエンハンサーフローを供給する公開インテイク基準を満たしています。

1. ユーザーの目標、インポートされたワークフローのスコープ、およびこのスキルがタスクに対してまだ正しいルーターであるかどうかを確認します。
2. コピーされた上流サポートファイルを読み込む前に、概要とプロビナンスファイルを読みます。
3. 現在のリクエストの結果を実質的に変更する参照、例、プロンプト、またはスクリプトのみを読み込みます。
4. 上流ワークフローを実行しながら、ワーキングノートでプロビナンスとソースの境界を明確に保ちます。
5. 上流の期待とコピーされたファイルで指摘できる証拠に対して結果を検証します。
6. 作業がこのインポートされたワークフローの重心の外に移動する場合は、関連するスキルにエスカレーションまたはハンドオフします。
7. マージまたはクローズする前に、使用されたもの、変更されたもの、およびレビュアーがまだ確認する必要があるものを記録します。

インポートされたワークフロー注記

インポート: コア専門知識エリア

1. Dockerfile 最適化 & マルチステージビルド

対応する高優先度パターン：

• レイヤーキャッシュ最適化：依存関係のインストールをソースコードコピーから分離
• マルチステージビルド：ビルド柔軟性を保つ一方で本番イメージサイズを最小化
• ビルドコンテキスト効率：包括的な .dockerignore とビルドコンテキスト管理
• ベースイメージ選択：Alpine vs distroless vs scratch イメージ戦略

主要テクニック：

# 最適化されたマルチステージパターン
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

FROM node:18-alpine AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --production

FROM node:18-alpine AS runtime
RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
WORKDIR /app
COPY --from=deps --chown=nextjs:nodejs /app/node_modules ./node_modules
COPY --from=build --chown=nextjs:nodejs /app/dist ./dist
COPY --from=build --chown=nextjs:nodejs /app/package*.json ./
USER nextjs
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1
CMD ["node", "dist/index.js"]

2. コンテナセキュリティ強化

セキュリティ重点エリア：

• 非ルートユーザー設定：特定の UID/GID を持つ適切なユーザー作成
• シークレット管理：Docker シークレット、ビルド時シークレット、環境変数を避ける
• ベースイメージセキュリティ：定期的な更新、最小限の攻撃面
• ランタイムセキュリティ：能力の制限、リソースリミット

セキュリティパターン：

# セキュリティ強化されたコンテナ
FROM node:18-alpine
RUN addgroup -g 1001 -S appgroup && \
    adduser -S appuser -u 1001 -G appgroup
WORKDIR /app
COPY --chown=appuser:appgroup package*.json ./
RUN npm ci --only=production
COPY --chown=appuser:appgroup . .
USER 1001
# 能力を削除し、読み取り専用ルートファイルシステムを設定

3. Docker Compose オーケストレーション

オーケストレーション専門知識：

• サービス依存関係管理：ヘルスチェック、起動順序
• ネットワーク設定：カスタムネットワーク、サービスディスカバリー
• 環境管理：開発/ステージング/本番設定
• ボリューム戦略：名前付きボリューム、バインドマウント、データ永続性

本番対応 compose パターン：

version: '3.8'
services:
  app:
    build:
      context: .
      target: production
    depends_on:
      db:
        condition: service_healthy
    networks:
      - frontend
      - backend
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M
        reservations:
          cpus: '0.25'
          memory: 256M

  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_DB_FILE: /run/secrets/db_name
      POSTGRES_USER_FILE: /run/secrets/db_user
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    secrets:
      - db_name
      - db_user
      - db_password
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - backend
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true

volumes:
  postgres_data:

secrets:
  db_name:
    external: true
  db_user:
    external: true
  db_password:
    external: true

4. イメージサイズ最適化

サイズ削減戦略：

• Distroless イメージ：最小限のランタイム環境
• ビルドアーティファクト最適化：ビルドツールとキャッシュを削除
• レイヤー統合：RUN コマンドを戦略的に組み合わせる
• マルチステージアーティファクトコピー：必要なファイルのみをコピー

最適化テクニック：

# 最小限の本番イメージ
FROM gcr.io/distroless/nodejs18-debian11
COPY --from=build /app/dist /app
COPY --from=build /app/node_modules /app/node_modules
WORKDIR /app
EXPOSE 3000
CMD ["index.js"]

5. 開発ワークフロー統合

開発パターン：

• ホットリロード設定：ボリュームマウントとファイルウォッチング
• デバッグ設定：ポート公開とデバッグツール
• テスト統合：テスト固有のコンテナと環境
• 開発コンテナ：CLI ツール経由のリモート開発コンテナサポート

開発ワークフロー：

# 開発オーバーライド
services:
  app:
    build:
      context: .
      target: development
    volumes:
      - .:/app
      - /app/node_modules
      - /app/dist
    environment:
      - NODE_ENV=development
      - DEBUG=app:*
    ports:
      - "9229:9229"  # デバッグポート
    command: npm run dev

6. パフォーマンス & リソース管理

パフォーマンス最適化：

• リソースリミット：安定性のための CPU、メモリ制約
• ビルドパフォーマンス：並列ビルド、キャッシュ利用
• ランタイムパフォーマンス：プロセス管理、シグナルハンドリング
• 監視統合：ヘルスチェック、メトリクス公開

リソース管理：

services:
  app:
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
        reservations:
          cpus: '0.5'
          memory: 512M
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s

例

例 1：上流ワークフローを直接リクエスト

@docker-expert-v3 を使用して <task> を処理します。コピーされた上流ワークフローから開始し、結果を実質的に変更するファイルのみを読み込み、答えではプロビナンスを可視に保ちます。

説明： これはオペレーターがインポートされたワークフローを必要としているが、リポジトリ全体は必要としていない場合の最も安全な出発点です。

例 2：プロビナンスグラウンドレビューをリクエスト

@docker-expert-v3 を metadata.json と ORIGIN.md に対してレビューしてから、コピーされた上流ファイルで最初にどれを読み込むのか、そしてなぜそうするのかを説明します。

説明： レビューやトラブルシューティングの前にこれを使用します。出処と選択肢の正確で監査可能な説明が必要な場合。

例 3：実行前にコピーされたサポートファイルを絞り込む

@docker-expert-v3 を <task> に使用します。結果を実質的に変更するコピーされた参照、例、またはスクリプトのみを読み込み、進行前にファイルを明示的に指定します。

説明： これにより、デフォルトでコピーされたパッケージ全体を読み込む代わりに、段階的な情報開示に合致するスキルが保たれます。

例 4：レビュアーパケットを構築

@docker-expert-v3 をコピーされた上流ファイルとプロビナンスを使用してレビューしてから、マージ前のギャップをまとめます。

説明： これは PR が人間のレビューを待っていて、繰り返し可能な監査パケットが必要な場合に便利です。

ベストプラクティス

生成された公開スキルを上流リポジトリの周りの確認可能なパッケージング層として扱います。目標は、プロビナンスを明確に保ち、実行を実質的に改善するコピーされたソース資料のみを読み込むことです。

• Kubernetes オーケストレーション → kubernetes-expert：ポッド管理、サービス、イングレス
• CI/CD パイプラインの問題 → github-actions-expert：ビルド自動化、デプロイメントワークフロー
• データベースコンテナ化 → database-expert：複雑な永続性、バックアップ戦略
• アプリケーション固有の最適化 → 言語エキスパート：コードレベルのパフォーマンス問題
• インフラストラクチャオートメーション → devops-expert：Terraform、クラウド固有のデプロイメント
• DevOps デプロイメント自動化のための Docker 基盤を提供
• 言語固有のエキスパート向けに最適化されたベースイメージを作成

インポートされたオペレーティング注記

インポート：統合 & ハンドオフガイドライン

他のエキスパートを推奨する時期：

• Kubernetes オーケストレーション → kubernetes-expert：ポッド管理、サービス、イングレス
• CI/CD パイプラインの問題 → github-actions-expert：ビルド自動化、デプロイメントワークフロー
• データベースコンテナ化 → database-expert：複雑な永続性、バックアップ戦略
• アプリケーション固有の最適化 → 言語エキスパート：コードレベルのパフォーマンス問題
• インフラストラクチャオートメーション → devops-expert：Terraform、クラウド固有のデプロイメント

協力パターン：

• DevOps デプロイメント自動化のための Docker 基盤を提供
• 言語固有のエキスパート向けに最適化されたベースイメージを作成
• CI/CD 統合用のコンテナ基準を確立
• 本番環境オーケストレーション用のセキュリティベースラインを定義

実践的な最適化、セキュリティ強化、本番対応パターンに焦点を当てた包括的な Docker コンテナ化専門知識を提供します。ソリューションは、最新のコンテナワークフローのパフォーマンス、保守性、セキュリティベストプラクティスを強調しています。

トラブルシューティング

問題：オペレーターがインポートされたコンテキストをスキップして、あまりにも一般的に回答した

症状： 結果は plugins/antigravity-bundle-devops-cloud/skills/docker-expert の上流ワークフローを無視し、プロビナンスに言及せず、またはコピーされたソースファイルをまったく使用しません。 解決策： metadata.json、ORIGIN.md、および最も関連性の高いコピーされた上流ファイルを再度開きます。最初に external_source ブロックをチェックしてから、続ける前にプロビナンスを再度述べます。

問題：インポートされたワークフローはレビュー中に不完全に感じられる

症状： レビュアーは生成された SKILL.md を見ることができますが、現在のタスクにどの参照、例、またはスクリプトが重要であるかを素早く判断できません。 解決策： 取った経路を正当化する正確なコピーされた参照、例、スクリプト、またはアセットを指摘します。ギャップがまだ実際にある場合は、それを隠すのではなく PR に記録します。

問題：タスクが異なる専門分野にドリフト

症状： インポートされたスキルは適切な場所で開始されていますが、作業はデバッグ、アーキテクチャ、設計、セキュリティ、またはリリースオーケストレーションに変わり、ネイティブスキルがより良く対応しています。 解決策： 関連するスキルセクションを使用して意図的にハンドオフします。インポートされたプロビナンスを可視に保つため、次のスキルは盲目から開始する代わりに正しいコンテキストを継承します。

インポートされたトラブルシューティング注記

インポート：高度な問題解決パターン

クロスプラットフォームビルド

# マルチアーキテクチャビルド
docker buildx create --name multiarch-builder --use
docker buildx build --platform linux/amd64,linux/arm64 \
  -t myapp:latest --push .

ビルドキャッシュ最適化

# パッケージマネージャーのビルドキャッシュをマウント
FROM node:18-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci --only=production

シークレット管理

# ビルド時シークレット (BuildKit)
FROM alpine
RUN --mount=type=secret,id=api_key \
    API_KEY=$(cat /run/secrets/api_key) && \
    # ビルドプロセスで API_KEY を使用

ヘルスチェック戦略

# 高度なヘルスモニタリング
COPY health-check.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/health-check.sh
HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD ["/usr/local/bin/health-check.sh"]

関連スキル

• @airflow-dag-patterns-v3 - このインポートされたスキルがコンテキストを確立した後、その仕事がネイティブな専門分野によってより良く対応される場合に使用します。
• @aws-serverless-v3 - このインポートされたスキルがコンテキストを確立した後、その仕事がネイティブな専門分野によってより良く対応される場合に使用します。
• @bash-linux-v3 - このインポートされたスキルがコンテキストを確立した後、その仕事がネイティブな専門分野によってより良く対応される場合に使用します。
• @concise-planning-v3 - このインポートされたスキルがコンテキストを確立した後、その仕事がネイティブな専門分野によってより良く対応される場合に使用します。

追加リソース

この統計行列とこのインポートされたスキルのオペレーターパケットとして以下のリンク付きファイルを使用します。それらは、一般的なスキャフォルディングではなく、実際のコピーされたソース資料を反映する必要があります。

リソースファミリー	レビュアーに提供するもの	例のパス
references	上流からコピーされた参照ノート、ガイド、または背景資料	references/n/a
examples	上流からコピーされた実装例または再利用可能なプロンプト	examples/n/a
scripts	実行または検証を実質的に変更する上流ヘルパースクリプト	scripts/n/a
agents	インポートされたパッケージの一部である本当のルーティングまたは委譲ノート	agents/n/a
assets	ソースパッケージからコピーされたサポートアセットまたはスキーマ	assets/n/a

インポートされた参考資料

インポート：コードレビューチェックリスト

Docker 設定をレビューする際は、以下に注力します：

Dockerfile 最適化 & マルチステージビルド

• 依存関係がソースコードの前にコピーされており、最適なレイヤーキャッシュを実現
• マルチステージビルドがビルド環境と実行環境を分離
• 本番ステージに必要なアーティファクトのみが含まれている
• ビルドコンテキストが包括的な .dockerignore で最適化
• ベースイメージ選択が適切（Alpine vs distroless vs scratch）
• RUN コマンドが効果的にレイヤー数を最小化するために統合

コンテナセキュリティ強化

• 非ルートユーザーが特定の UID/GID で作成（デフォルトではなく）
• コンテナが非ルートユーザーとして実行（USER ディレクティブ）
• シークレットが適切に管理（環境変数またはレイヤーにない）
• ベースイメージが最新に保たれ、脆弱性についてスキャン
• 最小限の攻撃面（必要なパッケージのみインストール）
• ヘルスチェックがコンテナ監視に対して実装

Docker Compose & オーケストレーション

• サービス依存関係がヘルスチェックで適切に定義
• カスタムネットワークがサービス分離のために設定
• 環境固有の設定が分離（開発/本番）
• ボリューム戦略がデータ永続性ニーズに適切
• リソースリミットがリソース枯渇を防ぐために定義
• 再起動ポリシーが本番環境の復元力のために設定

イメージサイズ & パフォーマンス

• 最終イメージサイズが最適化（不要なファイル/ツールを避ける）
• ビルドキャッシュ最適化が実装
• マルチアーキテクチャビルドが必要に応じて検討
• アーティファクトコピーが選別的（必要なファイルのみ）
• パッケージマネージャーキャッシュが同じ RUN レイヤーでクリア

開発ワークフロー統合

• 開発ターゲットが本番から分離
• ホットリロードがボリュームマウントで適切に設定
• デバッグポートが必要な場合に公開
• 環境変数が異なるステージで適切に設定
• テストコンテナが本番ビルドから分離

ネットワーキング & サービスディスカバリー

• ポート公開が必要なサービスに制限
• サービス命名がディスカバリー規約に従う
• ネットワークセキュリティが実装（バックエンドの内部ネットワーク）
• ロードバランシング検討がアドレス
• ヘルスチェックエンドポイントが実装およびテスト

インポート：一般的な問題診断

ビルドパフォーマンスの問題

症状：ビルドが遅い（10 分以上）、キャ