Docker: CI/CD 統合
最終更新:2026-08-26
コードプッシュ → 自動テスト → 自動イメージビルド → 自動デプロイ——CI/CD はリリースプロセスを手動運用から自動パイプラインへと変えます。
1. 学べること
- GitHub Actions の基本ワークフロー
- Docker buildx のクロスプラットフォームビルド
- CI キャッシュ戦略
- 複数環境デプロイの流れ
- 自動タグ付けとイメージのバージョン管理
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 の構造
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 がネイティブでサポートします。📖 まとめ
- GitHub Actions ワークフロー: on(トリガー) → jobs → steps の 3 層構造
docker buildxはマルチアーキテクチャビルドと高度なキャッシュエクスポートをサポートcache-from: type=ghaで GitHub Actions キャッシュを使ったビルド高速化- 自動タグ: Git SHA + semver + latest のマルチタグ戦略
- SSH デプロイ:
secretsで機密情報を管理、compose pull + upでゼロダウンタイム更新を実現 - 完全なパイプライン: test → ビルド → プッシュ → デプロイ。「プッシュ = 公開完了」
📝 練習問題
- 基本練習 (難易度 ⭐): 第 12 課の Flask アプリ用に GitHub Actions のビルドワークフローを作成し、main ブランチへのコミットプッシュで自動的にイメージがビルド・プッシュされるようにしてください。
- 応用練習 (難易度 ⭐⭐):
buildxで amd64 + arm64 のデュアルアーキテクチャイメージをビルドし Docker Hub にプッシュしてください。 - 挑戦 (難易度: ⭐⭐⭐): 完全な CI/CD パイプライン(test → ビルド → SSH デプロイ)を構築し、GitHub Secrets でサーバーキーを管理、プッシュ後にデプロイが自動実行されることを確認してください。