Docker: CI/CD 統合

最終更新:2026-08-26

コードプッシュ → 自動テスト → 自動イメージビルド → 自動デプロイ——CI/CD はリリースプロセスを手動運用から自動パイプラインへと変えます。

1. 学べること



2. 開発者の実話

(1) 悩み: デプロイごとに手動 SSH 操作が必要

デプロイのたびに、Alice は手動でサーバーに SSH し、コードをプルし、イメージをビルドし、コンテナを再起動しなければなりません。手順は: ssh server → git pull → docker build → docker stop → docker run。1 回のデプロイに 15 分かかり、週 3〜4 回リリースするので毎週合計 1 時間を繰り返し作業に費やします。さらには深夜のリリースで誤ったコマンドを入力してしまったこともあります。

(2) GitHub Actions CI/CD によるソリューション

Bob が GitHub Actions でワークフローを作成しました: コードプッシュ → 自動テスト → イメージビルド → レジストリプッシュ → SSH デプロイ。

YAML
# .github/workflows/deploy.yml
name: Build and Deploy
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v5
        with:
          push: true
          tags: myorg/myapp:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

(3) 時間: 週 1 時間 → 0 分

デプロイは完全に自動化されました——Alice がコードをプッシュするだけで、5 分以内に自動的に公開されます。手作業は週 1 時間から 0 へ、人間のミスもゼロになりました。



3. GitHub Actions ワークフローの構造

(1) ワークフロー YAML の構造

100%
graph LR
    PUSH["git push"] --> TRIGGER["on: push"]
    TRIGGER --> JOB1["ジョブ: test"]
    JOB1 --> JOB2["ジョブ: build"]
    JOB2 --> JOB3["ジョブ: deploy"]
フィールド 用途
name ワークフロー名 Build and Deploy
on トリガー条件 push, pull_request
jobs ジョブ定義 build, test, deploy
runs-on 実行環境 ubuntu-latest
steps 実行ステップ checkout, build, push

(2) 3 つの CI/CD 戦略の比較

プラットフォーム 特徴 ユースケース
GitHub Actions GitHub ネイティブ統合、月 2,000 分無料 オープンソース + GitHub ホスティング
GitLab CI GitLab ネイティブ、セルフホスト Runner オンプレ GitLab
Jenkins 老舗 CI/CD プラットフォーム、プラグイン豊富 従来型エンタープライズ + 複雑なパイプライン


4. Docker buildx のクロスプラットフォームビルド

▶ サンプル: buildx でマルチアーキテクチャビルド (難易度: ⭐⭐⭐)

BASH
# buildx ビルダーインスタンスを作成
docker buildx create --name multiarch --use

# amd64 + arm64 を同時にビルド
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myorg/myapp:latest \
  --push .

# ビルド済みプラットフォームを確認
docker buildx imagetools inspect myorg/myapp:latest

(1) buildx と通常の ビルド の比較

比較項目 docker ビルド docker buildx
マルチアーキテクチャ ❌ 現在のアーキテクチャのみ ✅ 複数アーキテクチャを同時ビルド
キャッシュエクスポート ❌ ローカルキャッシュのみ ✅ gha / registry / s3
出力形式 ローカルイメージ イメージ / OCI / tar / registry
並列ビルド


5. CI キャッシュ戦略

(1) キャッシュタイプの比較

タイプ 構文 配置場所 用途
gha cache-from: type=gha GitHub Actions キャッシュ GitHub Actions CI
registry cache-from: type=registry Docker Registry 任意の CI プラットフォーム
local cache-from: type=local ローカルファイルシステム セルフホスト Runner

▶ サンプル: CI キャッシュ設定 (難易度: ⭐⭐⭐)

YAML
# ビルドキャッシュ付き GitHub Actions
- uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: myorg/myapp:${{ github.sha }}
    cache-from: type=gha
    cache-to: type=gha,mode=max

▶ サンプル: 自動タグ付けポリシー (難易度: ⭐⭐)

YAML
# Docker metadata action で自動タグ付け
- uses: docker/metadata-action@v5
  id: meta
  with:
    images: myorg/myapp
    tags: |
      type=sha,prefix=
      type=ref,event=branch
      type=semver,pattern={{version}}
      type=raw,value=latest,enable={{is_default_branch}}


6. SSH デプロイの手順

▶ サンプル: SSH でサーバーへデプロイ (難易度: ⭐⭐⭐)

YAML
# GitHub Actions のデプロイステップ
- name: Deploy to server
  uses: appleboy/ssh-action@v1
  with:
    host: ${{ secrets.SERVER_HOST }}
    username: ${{ secrets.SERVER_USER }}
    key: ${{ secrets.SSH_PRIVATE_KEY }}
    script: |
      cd /opt/myapp
      docker compose pull
      docker compose up -d --remove-orphans
      docker image prune -f
🔒 セキュリティ: サーバーアドレスや SSH キーなどの機密情報は GitHub Secrets に保存し、YAML ファイルに直接書かないでください。Settings → Secrets and variables → Actions で追加します。**



7. 完全なサンプル: Node.js アプリの CI/CD

YAML
# ============================================
# .github/workflows/deploy.yml
# 完全な CI/CD: test → build → push → deploy
# ============================================

name: CI/CD Pipeline

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

env:
  REGISTRY: docker.io
  IMAGE_NAME: myorg/myapp

jobs:
  # ---------- ジョブ 1: テスト ----------
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: テストを実行
        run: |
          docker build --target builder -t test-image .
          docker run test-image npm test

  # ---------- ジョブ 2: ビルド & プッシュ ----------
  build:
    needs: test
    runs-on: ubuntu-latest
    if: github.event_name == 'push'
    steps:
      - uses: actions/checkout@v4

      - uses: docker/setup-buildx-action@v3

      - uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

      - uses: docker/metadata-action@v5
        id: meta
        with:
          images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
          tags: |
            type=sha,prefix=
            type=raw,value=latest

      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

  # ---------- ジョブ 3: デプロイ ----------
  deploy:
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - name: SSH 経由でデプロイ
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /opt/myapp
            docker compose pull
            docker compose up -d --remove-orphans
            docker image prune -f
            echo "Deployed at $(date)"


❓ よくある質問

Q buildx と通常の build の違いは何ですか?
A buildx は Docker BuildKit の CLI 拡張です。主な利点は: ① 複数アーキテクチャ(amd64 + arm64)の同時ビルド; ② 高度なキャッシュエクスポート(gha / registry); ③ 並列ビルド。GitHub Actions では常に buildx の使用を推奨します。
Q CI で Docker レイヤーキャッシュを共有するには?
A cache-from: type=gha(GitHub Actions)または type=registry(汎用)を使います。GHA キャッシュは GitHub Actions キャッシュに保存され、同じリポジトリのワークフローで自動共有されます。Registry キャッシュはレジストリ内の特別なマニフェストに保存され、任意の CI プラットフォームから使えます。
Q マルチアーキテクチャイメージをどうビルドしますか?
A docker buildx build --platform linux/amd64,linux/arm64 -t myapp:latest --push .。QEMU エミュレーター(docker/setup-qemu-action)と buildx ビルダーが必要です。ビルド結果はマニフェストリストとなり、docker pull 時に現在のアーキテクチャ用のイメージが自動選択されます。
Q CI/CD で機密資格情報はどう管理しますか?
A GitHub Secrets(Settings → Secrets)を使います。SSH キー、データベースパスワード、レジストリ資格情報はすべて Secrets に保存し、YAML では ${{ secrets.XXX }} で参照します。Secrets は暗号化して保存され、ログでは自動的にマスクされます。
Q デプロイ失敗時に自動ロールバックするには?
A 2 つの方法があります: ① デプロイスクリプトにヘルスチェックを追加し、失敗時は docker compose rollback(Swarm)または手動で前バージョンに戻す; ② イメージに最新 N バージョンのタグを保持し、ロールバック時は単に docker compose up -d myapp:previous-sha。自動ロールバックは Swarm と K8s がネイティブでサポートします。

📖 まとめ


📝 練習問題

  1. 基本練習 (難易度 ⭐): 第 12 課の Flask アプリ用に GitHub Actions のビルドワークフローを作成し、main ブランチへのコミットプッシュで自動的にイメージがビルド・プッシュされるようにしてください。
  2. 応用練習 (難易度 ⭐⭐): buildx で amd64 + arm64 のデュアルアーキテクチャイメージをビルドし Docker Hub にプッシュしてください。
  3. 挑戦 (難易度: ⭐⭐⭐): 完全な CI/CD パイプライン(test → ビルド → SSH デプロイ)を構築し、GitHub Secrets でサーバーキーを管理、プッシュ後にデプロイが自動実行されることを確認してください。
Web-Tutorial.com

Web-Tutorial 技術チーム

複数の開発者によって共同維持されているプログラミングチュートリアルプラットフォーム。各チュートリアルは専門分野の開発者が執筆・レビューしています。正確で信頼性の高いコンテンツを目指しています — 問題を見つけた場合はお知らせください。

100%