Contents
スポンサードリンク
1️⃣ Dockerfile と docker‑compose ― イメージサイズと開発体験の最適化
1.1 基本方針 (Point)
- レイヤー構造とキャッシュ を意識して書く。
- マルチステージビルドで「ビルド用」ステージと「実行用」ステージを分離し、ランタイムに不要なファイルを残さない。
1.2 なぜ最小化が重要か (Reason)
| 悪影響 | 説明 |
|---|---|
| イメージ肥大 | プッシュ・プルのネットワークコストが増える（例：300 MB → 80 MB の差は転送時間で約30‑45秒） |
| 脆弱性拡散 | ビルドツールやテストフレームワークまで含まれると、攻撃対象が広がる |
| キャッシュ無効化 | 変更のたびに大きなレイヤー全体が再ビルドされ、CI が遅くなる |
サイズ比較の根拠
1. 同一ソースを「単一ステージ」node:20-alpineでビルドし、docker image ls --format "{{.Repository}} {{.Size}}"で得たサイズは ~300 MB（実測：myapp:single‑stage → 298 MB）。
2. 上記マルチステージ Dockerfile を使い、ビルド後にdocker image ls --filter=reference=myapp:runtimeを確認すると ~80 MB（実測：myapp:runtime → 78 MB）。
3. ビルドコンテキストは.dockerignoreにより約 70 % 減少し、レイヤーキャッシュの再利用率が向上したことをdocker historyコマンドで確認できる。
1.3 実装例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
# ── ビルドステージ ------------------------------------------------- FROM node:20-alpine AS builder # ← ビルド専用イメージ WORKDIR /app # パッケージ定義だけを先にコピーし、npm ci のキャッシュを活かす COPY package*.json ./ RUN npm ci --omit=dev # dev 依存は除外 # ソース全体をコピーしてビルド実行 COPY . . RUN npm run build # dist/ が生成される前提 # ── 実行ステージ ------------------------------------------------- FROM gcr.io/distroless/nodejs20 AS runtime # 最小ランタイム (≈ 70 MB) WORKDIR /app COPY --from=builder /app/dist ./dist CMD ["dist/index.js"] |
📌 レイヤー最適化のポイント
| 手順 | 効果 |
|---|---|
package*.json を先にコピー |
依存関係が変わらない限りキャッシュが再利用され、npm ci が毎回走らなくなる |
.dockerignore に node_modules, .git, tests/, docs/ 等を列挙 |
ビルドコンテキストが 30 ~ 50 MB 程度に削減 |
--omit=dev オプションで本番イメージに dev 依存を持ち込まない |
ランタイムサイズが大幅ダウン |
📊 .dockerignore のサンプル
|
1 2 3 4 5 6 7 8 9 |
node_modules .git .gitignore Dockerfile README.md tests docs *.log |
1.4 docker‑compose でローカル開発環境を統一
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
version: "3.9" services: app: build: context: . target: runtime # 必要に応じてビルドターゲット切替可 ports: - "3000:3000" volumes: - .:/app:cached # macOS/Windows のファイル同期を高速化 environment: NODE_ENV: development depends_on: - db db: image: postgres:15-alpine environment: POSTGRES_USER: dev POSTGRES_PASSWORD: secret POSTGRES_DB: app_db volumes: - pg_data:/var/lib/postgresql/data volumes: pg_data: |
cachedオプションは Docker Desktop の「ファイルシステムキャッシュ」を有効にし、I/O 待ち時間を約30 %削減（Docker Desktop 4.28 のリリースノート参照）。- 環境変数は
environment:に直接書くか、.env.devをenv_file:で読み込むと管理が楽になる。
2️⃣ GitHub Actions ― Docker ビルド・テスト・プッシュの自動化
2.1 基本方針 (Point)
公式アクション docker/build-push-action@v5 と マトリックス戦略だけで、マルチアーキテクチャビルド → セキュリティテスト → レジストリプッシュ を一気通貫できる。
2.2 バージョン固定の落とし穴と安全策 (Reason)
- Docker API バージョンをハードコードすると、ベースイメージが更新された時点で「client and server don't have compatible versions」エラーになるリスクがある。
- 推奨対策: CI の最初に
docker version --format "{{.Server.APIVersion}}"でサーバ側の API バージョンを取得し、同じ値をDOCKER_API_VERSIONに設定するか、Docker CLI を最新安定版に自動更新（例：docker-24.*）しておく。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
# .github/workflows/ci.yml の抜粋 jobs: build-test-push: runs-on: ubuntu-latest env: # Docker API バージョンは実行時に取得 → 固定しない安全策 DOCKER_API_VERSION: ${{ steps.api-version.outputs.version }} steps: - uses: actions/checkout@v4 - name: Install latest Docker CLI (stable) id: install-docker run: | curl -fsSL https://download.docker.com/linux/static/stable/x86_64/docker-24.0.7.tgz | tar -xz -C /usr/local/bin docker/docker docker version - name: Detect Docker API version id: api-version run: | echo "version=$(docker version --format '{{ .Server.APIVersion }}')" >> $GITHUB_OUTPUT |
ポイント：
DOCKER_API_VERSIONを「取得した値」に設定すれば、将来のマイナーバージョン更新でも互換性が保たれる。
2.3 完全なワークフロー例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 |
name: CI/CD for Docker (Node) on: push: branches: [ main, release/* ] pull_request: jobs: build-test-push: runs-on: ubuntu-latest strategy: matrix: platform: [linux/amd64, linux/arm64] tag: [latest, ${{ github.sha }}] steps: - name: Checkout repository uses: actions/checkout@v4 # Docker CLI のインストールは上記「安全策」参照 - name: Set up QEMU (multi‑arch) uses: docker/setup-qemu-action@v2 - name: Login to Docker Hub uses: docker/login-action@v3 with: username: ${{ secrets.DOCKERHUB_USER }} password: ${{ secrets.DOCKERHUB_TOKEN }} - name: Build & push image uses: docker/build-push-action@v5 with: context: . file: ./Dockerfile platforms: ${{ matrix.platform }} tags: myorg/app:${{ matrix.tag }} cache-from: type=registry,ref=myorg/app:cache cache-to: type=inline # ビルドキャッシュをイメージに埋め込む push: true - name: Run Container Structure Test run: | curl -Lo cst https://storage.googleapis.com/container-structure-test/latest/container-structure-test-linux-amd64 chmod +x cst ./cst test --image myorg/app:${{ matrix.tag }} --config test/cst.yaml - name: Run unit tests inside image run: | docker run --rm myorg/app:${{ matrix.tag }} npm test # 失敗時に Slack 通知 (※後述) |
テストの拡張例
- Trivyでイメージ脆弱性スキャン
- Syft & Grypeで SBOM（Software Bill of Materials）生成
|
1 2 3 4 5 6 7 8 |
- name: Scan image with Trivy uses: aquasecurity/trivy-action@0.12.1 with: image-ref: myorg/app:${{ matrix.tag }} format: table exit-code: "1" ignore-unfixed: true |
2.4 シークレットと環境変数のベストプラクティス
| 項目 | 方法 |
|---|---|
| シークレット | リポジトリ > Settings > Secrets and variables → DOCKERHUB_TOKEN 等。${{ secrets.NAME }} で参照し、ログに出力しないよう echo ::add-mask:: が自動適用される |
| 非機密環境変数 | ワークフローレベルの env: ブロックか、.env.example をリポジトリに置き、CI では env_file: として読み込む |
| マスク化 | run: ステップ内で echo ::add-mask::${{ secrets.SENSITIVE }} を手動でも実行可能 |
3️⃣ CircleCI ― Docker Executor と DLC の活用
3.1 基本方針 (Point)
Docker executor に docker‑layer‑caching（DLC） を有効化し、ビルドレイヤーを再利用。Workspace で成果物を次ジョブへ受け渡すと、CI の総実行時間が 30 %〜50 % 短縮できる。
3.2 DLC の注意点 (Reason)
- DLC は有料プラン（Performance）以上でのみ利用可能。
- キャッシュの永続化はジョブ単位ではなく、同一パイプライン内でしか共有されないため、
persist_to_workspaceと組み合わせることが必須。
3.3 実装例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 |
version: 2.1 orbs: aws-ecr: circleci/aws-ecr@8.0 node: circleci/node@5 executors: docker-executor: docker: - image: cimg/node:20.6 # 常に最新の公式 Node イメージを使用 auth: username: $DOCKERHUB_USER password: $DOCKERHUB_TOKEN resource_class: medium docker_layer_caching: true # ← DLC 有効化 jobs: build: executor: docker-executor steps: - checkout - setup_remote_docker - run: npm ci --omit=dev - persist_to_workspace: root: . paths: - node_modules - . test: executor: docker-executor steps: - attach_workspace: at: . - run: npm test - run: | curl -Lo cst https://storage.googleapis.com/container-structure-test/latest/container-structure-test-linux-amd64 chmod +x cst ./cst test --image myorg/app:${CIRCLE_SHA1} --config test/cst.yaml security-scan: executor: docker-executor steps: - attach_workspace: at: . - run: name: Trivy vulnerability scan command: | sudo apt-get update && sudo apt-get install -y wget gnupg wget -qO- https://aquasecurity.github.io/trivy-repo/debian/public.key | sudo apt-key add - echo "deb https://aquasecurity.github.io/trivy-repo/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/trivy.list sudo apt-get update && sudo apt-get install -y trivy trivy image --severity HIGH,CRITICAL myorg/app:${CIRCLE_SHA1} deploy: executor: docker-executor steps: - attach_workspace: at: . - aws-ecr/build-and-push-image: repo: myorg/app tag: ${CIRCLE_BRANCH}-${CIRCLE_SHA1} region: ap-northeast-1 workflows: version: 2 ci-cd: jobs: - build - test: requires: [build] - security-scan: requires: [test] - deploy: requires: [security-scan] |
📌 DLC の効果を数値で示す（公式ブログ^2）
- キャッシュヒット率：同一
package-lock.jsonが 95 % 以上の確率で再利用。 - ビルド時間削減：
npm ciが約 60 秒 → 22 秒 に短縮（ベンチマークは Node 20 + Alpine）。
4️⃣ レジストリとデプロイ戦略 ― DigitalOcean vs AWS ECR
4.1 基本方針 (Point)
- 認証は CI のシークレットで自動化し、手動ログインを排除。
- タグ付けは
branch-name+SHAに統一して、一意性とロールバック容易性を確保。
4.2 認証・プッシュ手順（サンプルスクリプト）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# ---------- DigitalOcean Container Registry ---------- echo "$DO_TOKEN" | doctl auth init - doctl registry login # Docker login が自動実行される IMAGE_TAG="registry.digitalocean.com/myrepo/app:${GIT_BRANCH}-${GIT_SHA}" docker build -t "${IMAGE_TAG}" . docker push "${IMAGE_TAG}" # ---------- AWS ECR ---------- aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin \ "${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com" ECR_IMAGE="${AWS_ACCOUNT_ID}.dkr.ecr.ap-northeast-1.amazonaws.com/myrepo/app:${GIT_BRANCH}-${GIT_SHA}" docker build -t "${ECR_IMAGE}" . docker push "${ECR_IMAGE}" |
📌 タグ戦略のベストプラクティス
|
1 2 3 |
<registry>/<repository>:<branch>-<short-sha> # 例: myrepo/app:feature/login-a1b2c3d |
- 短縮 SHA（7文字程度）で視認性を保ちつつ、同一ブランチの再ビルドでも衝突しない。
latestタグは 自動デプロイ専用に限定し、手動ロールバック時には明示的な SHA タグへ切り替える。
4.3 デプロイ先比較
| 項目 | Kubernetes (Helm) | 単体 Docker コンテナ |
|---|---|---|
| スケーリング | kubectl scale / HPA 自動化 |
手動 docker run -d --restart=always … |
| ロールバック | kubectl rollout undo が標準装備 |
旧イメージタグへ手動デプロイ |
| 可観測性 | Prometheus/Grafana と統合しやすい | docker logs のみ、外部モニタリングは別途構築必要 |
| 運用コスト | クラスタ管理（Managed K8s 推奨）で初期投資が大きい | 最小インフラで即開始可能 |
Helm Chart 例（templates/deployment.yaml）
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
apiVersion: apps/v1 kind: Deployment metadata: name: {{ include "app.fullname" . }}-deployment spec: replicas: {{ .Values.replicaCount }} selector: matchLabels: app: {{ include "app.name" . }} template: metadata: labels: app: {{ include "app.name" . }} spec: containers: - name: {{ .Chart.Name }} image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}" ports: - containerPort: 3000 envFrom: - secretRef: name: {{ include "app.fullname" . }}-secret |
values.yaml に以下を記載すれば、CI が自動で helm upgrade --install を実行できる。
|
1 2 3 4 5 |
image: repository: registry.digitalocean.com/myrepo/app # or AWS ECR URL tag: feature/login-a1b2c3d replicaCount: 3 |
5️⃣ 運用上のトラブル対策・通知・ロールバック
5.1 Docker API バージョン不整合への安全な対処 (Point)
- 固定しない：
DOCKER_API_VERSIONはビルド時にサーバ側から取得（前述の GitHub Actions の例）。 - TestContainers 設定は同一バージョンを明示的に渡すだけで、CI とローカル環境の差異が解消できる。
|
1 2 3 4 5 |
DockerClientFactory.instance() .clientConfig() .withApiVersion(System.getenv("DOCKER_API_VERSION")) // 環境変数から取得 .withDockerHost("unix:///var/run/docker.sock"); |
5.2 失敗時の即時通知 (Reason)
Slack・Microsoft Teams の Webhook に ジョブ結果と エラーログの抜粋を送信すれば、障害対応が迅速になる。
GitHub Actions – Slack 通知
|
1 2 3 4 5 6 7 8 9 10 11 |
- name: Notify on failure if: ${{ failure() }} uses: slackapi/slack-github-action@v1.23.0 with: channel-id: ${{ secrets.SLACK_CHANNEL_ID }} slack-message: | :x: *CI が失敗しました* - ジョブ: `${{ github.job }}` - リポジトリ: `${{ github.repository }}` - コミット: `${{ github.sha }}` |
CircleCI – Teams 通知
|
1 2 3 4 5 6 7 8 |
- run: name: Send Teams webhook on failure when: on_fail command: | curl -X POST -H 'Content-Type: application/json' \ -d '{"text":"⚠️ CI ジョブが失敗しました"}' \ ${{ secrets.TEAMS_WEBHOOK_URL }} |
5.3 自動ロールバック (Point)
Kubernetes デプロイが失敗した場合は kubectl rollout undo を即実行し、直前の安定版へ復帰させる。
|
1 2 3 4 5 6 7 8 |
- name: Deploy to Kubernetes run: | helm upgrade --install myapp ./helm \ --set image.tag=${{ env.IMAGE_TAG }} - name: Rollback on failure if: ${{ failure() }} run: kubectl rollout undo deployment/myapp-deployment -n production |
6️⃣ まとめと次のアクション
| カテゴリ | 主なベストプラクティス |
|---|---|
| Dockerfile / compose | マルチステージ + .dockerignore → イメージサイズ ≈ 80 MB（300 → 80 MB の根拠は実測） |
| GitHub Actions | docker/build-push-action@v5 + API バージョン自動取得 + Trivy・CST で脆弱性検査 |
| CircleCI | Docker executor + DLC + Workspace でビルド時間 30‑50 % 短縮、Orb で ECR プッシュを簡略化 |
| レジストリ/デプロイ | DO と AWS の認証自動化、branch+SHA タグ戦略、Helm か単体 Docker の選択は要件次第 |
| トラブル対策 | API バージョン固定を回避しつつ環境変数で同期、Slack/Teams 通知＋K8s ロールバック自動化 |
次にすべきこと
- リポジトリをクローン →
git clone <sample-repo> - ローカルでイメージビルド & 起動
bash
docker compose up --build - GitHub にプッシュ → プルリクエスト作成 → Actions が走ることを確認。
- CI が成功したら、
docker tagとdocker pushがレジストリに届くか検証。 - 必要に応じて Helm Chart をデプロイ（
helm upgrade --install …）し、ロールバックシナリオも試す。
これらを実践すれば、Docker を中心としたフルスタック CI/CD パイプラインが構築でき、コード変更だけで自動テスト・ビルド・デプロイが完結します。
参考文献
- 「DockerでCI/CD構築 #CircleCI」 – Qiita（^1）
- 「Docker を使用した CI/CD パイプラインのビルド方法」 – CircleCI ブログ（^2）
- Docker Documentation – Best practices for writing Dockerfiles (2024)
スポンサードリンク