DockerとCI/CDの基本と主要ツール別設定ガイド

Contents

1 Docker が CI/CD にもたらす価値 {#docker-が-cicd-にもたらす価値}
2 主要 CI ツールの比較と選定ポイント {#主要-ci-ツールの比較と選定ポイント}
3 実装パターン別サンプルコード {#実装パターン別サンプルコード}
- 3.1 3‑1. CircleCI でのイメージビルド & Docker Hub へのプッシュ
- 3.2 3‑2. Jenkins + マルチステージ Dockerfile + docker‑compose
4 セキュリティと運用上のベストプラクティス {#セキュリティと運用上のベストプラクティス}
5 トラブルシューティング集 {#トラブルシューティング集}
6 高度な活用例（マルチアーキテクチャ・キャッシュ戦略） {#高度な活用例}
- 6.1 1. マルチプラットフォームイメージのビルド
- 6.2 2. 高度キャッシュ：外部レジストリへのキャッシュ保存
7 参考文献・出典確認要項 {#参考文献}
8 まとめ

スポンサードリンク

Docker が CI/CD にもたらす価値 {#docker-が-cicd-にもたらす価値}

Docker は 「開発環境と本番環境のギャップをなくす」 ことに特化した軽量仮想化技術です。
- 再現性：同一 Dockerfile から生成されたイメージは、ローカル・CI ランナー・本番サーバいずれでも同じ動作を保証する。
- 高速化：レイヤーキャッシュとマルチステージビルドにより、不要なビルド工程が除外されるためビルド時間が平均 20–30 % 短縮されることが報告されている[^1]。
- スケーラビリティ：コンテナは軽量で起動が数秒程度、CI パイプラインの並列実行に適している。

ポイント
Docker を CI/CD に組み込む最大のメリットは「環境依存バグを根本から削減」できる点です。

主要 CI ツールの比較と選定ポイント {#主要-ci-ツールの比較と選定ポイント}

以下では、代表的なクラウド／オンプレミス CI ツールを 「Docker との親和性」「設定コスト」「拡張性」 の観点でまとめました。

2‑1. CircleCI

項目	内容
特徴	クラウドベース。`setup_remote_docker` と `docker_layer_caching` が標準装備され、Docker ビルドに最適化されたランナーを提供。
設定コスト	YAML 1 ファイルで完結。キャッシュ有効化はオプションフラグだけで済む。
拡張性	Orbs（再利用可能なモジュール）が豊富。Docker Hub、ECR、GCR など複数レジストリへ直接プッシュ可能。
留意点	無料プランは同時実行数に制限があるため、大規模チームでは有償プランの検討が必要。

ポイント：キャッシュと Orbs により、Docker パイプラインを最小構成で高速化できる。

2‑2. GitHub Actions

項目	内容
特徴	リポジトリに密結合。GitHub が提供する公式 Docker アクション (`docker/build-push-action`) が利用可能。
設定コスト	`.github/workflows/*.yml` に記述し、シークレットは UI で管理できるため手順が単純。
拡張性	Marketplace のサードパーティアクションが多数あり、テストフレームワークやデプロイツールと連携しやすい。
留意点	ランナーはセルフホストか GitHub が提供する Ubuntu/macOS/Windows に限定される（自前の Windows 環境が必要な場合はセルフホスト推奨）。

ポイント：GitHub エコシステムをそのまま活用でき、シークレット管理が一元化されている点が強み。

2‑3. Jenkins

項目	内容
特徴	オンプレミス・クラウド両方で動作。プラグイン (`docker-workflow`, `Blue Ocean`) によって Docker ビルドをコード化できる。
設定コスト	初期構築はやや手間がかかるが、既存の Jenkins 環境がある場合はプラグイン追加だけで即座に Docker 対応可能。
拡張性	パイプライン DSL (`Jenkinsfile`) がフルカスタマイズでき、複雑なジョブ構成や外部システム連携も柔軟。
留意点	プラグインのバージョン管理が必要で、セキュリティパッチ適用を怠ると脆弱性リスクが高まる。

ポイント：レガシー環境や大規模組織で既に Jenkins が導入済みの場合は、プラグインだけで Docker 化できる点が大きなメリット。

実装パターン別サンプルコード {#実装パターン別サンプルコード}

3‑1. CircleCI でのイメージビルド & Docker Hub へのプッシュ

# .circleci/config.yml
version: 2.1
orbs:
  docker: circleci/docker@2.4   # 公式 Orbs（バージョンは随時更新要確認）[^2]

jobs:
  build-and-push:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - setup_remote_docker:
          version: 20.10.14   # Docker デーモン固定（バージョンは CI 環境に合わせて更新）[^3]
      - docker/build:
          image: myorg/myapp
          tag: &quot;v&lt;&lt;pipeline.number&gt;&gt;-{{ now 'YYYYMMDD' }}&quot;
          push: true
          registry: docker.io
          username: $DOCKERHUB_USER
          password: $DOCKERHUB_PASS

workflows:
  build_and_deploy:
    jobs:
      - build-and-push

# .circleci/config.yml

version: 2.1

orbs:

docker: circleci/docker@2.4 # 公式 Orbs（バージョンは随時更新要確認）[^2]

jobs:

build-and-push:

docker:

- image: cimg/base:stable

steps:

- checkout

- setup_remote_docker:

version: 20.10.14 # Docker デーモン固定（バージョンは CI 環境に合わせて更新）[^3]

- docker/build:

image: myorg/myapp

tag: "v<<pipeline.number>>-{{ now 'YYYYMMDD' }}"

push: true

registry: docker.io

username: $DOCKERHUB_USER

password: $DOCKERHUB_PASS

workflows:

build_and_deploy:

jobs:

- build-and-push

解説

setup_remote_docker によりビルド環境が分離され、同時に docker_layer_caching が自動有効化（設定フラグは不要）。
タグはパイプライン番号と日付を組み合わせて一意性を担保し、リリース履歴の可視化に寄与する。
公式ブログで紹介されている構成例をベースにしており、実装時は Orbs のバージョンが最新かどうかを必ず確認してください。

3‑2. Jenkins + マルチステージ Dockerfile + docker‑compose

(1) `Jenkinsfile`（Declarative Pipeline）

pipeline {
    agent any
    environment {
        REGISTRY = &quot;docker.io&quot;
        IMAGE   = &quot;myorg/myapp&quot;
        TAG     = &quot;${env.BUILD_NUMBER}-${new Date().format('yyyyMMdd')}&quot;
    }
    stages {
        stage('Checkout') {
            steps { checkout scm }
        }
        stage('Build Image') {
            steps {
                script {
                    dockerImage = docker.build(&quot;${IMAGE}:${TAG}&quot;)
                }
            }
        }
        stage('Security Scan') {
            steps {
                sh '''
                trivy image --exit-code 1 --severity HIGH,CRITICAL ${IMAGE}:${TAG}
                '''
            }
        }
        stage('Push Image') {
            steps {
                withCredentials([usernamePassword(credentialsId: 'dockerhub',
                                                  usernameVariable: 'DOCKER_USER',
                                                  passwordVariable: 'DOCKER_PASS')]) {
                    sh &quot;echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin&quot;
                    sh &quot;docker push ${IMAGE}:${TAG}&quot;
                }
            }
        }
        stage('Integration Test') {
            steps {
                sh '''
                docker compose -f ci/docker-compose.yml up -d
                # テストスクリプト例: ./scripts/integration_test.sh
                ./scripts/integration_test.sh
                docker compose -f ci/docker-compose.yml down
                '''
            }
        }
    }
    post {
        always { cleanWs() }
    }
}

pipeline {

agent any

environment {

REGISTRY = "docker.io"

IMAGE = "myorg/myapp"

TAG = "${env.BUILD_NUMBER}-${new Date().format('yyyyMMdd')}"

}

stages {

stage('Checkout') {

steps { checkout scm }

}

stage('Build Image') {

steps {

script {

dockerImage = docker.build("${IMAGE}:${TAG}")

}

stage('Security Scan') {

steps {

sh '''

trivy image --exit-code 1 --severity HIGH,CRITICAL ${IMAGE}:${TAG}

'''

}

stage('Push Image') {

steps {

withCredentials([usernamePassword(credentialsId: 'dockerhub',

usernameVariable: 'DOCKER_USER',

passwordVariable: 'DOCKER_PASS')]) {

sh "echo $DOCKER_PASS | docker login -u $DOCKER_USER --password-stdin"

sh "docker push ${IMAGE}:${TAG}"

}

stage('Integration Test') {

steps {

sh '''

docker compose -f ci/docker-compose.yml up -d

# テストスクリプト例: ./scripts/integration_test.sh

./scripts/integration_test.sh

docker compose -f ci/docker-compose.yml down

'''

}

post {

always { cleanWs() }

}

(2) マルチステージ Dockerfile

# Stage 0: ビルド環境（Node + npm）
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci               # 再現性の高いインストール
COPY . .
RUN npm run build        # 本番ビルド成果物のみ残す

# Stage 1: 実行環境（最小イメージ）
FROM node:20-alpine AS runtime
WORKDIR /app
COPY --from=builder /app/dist ./dist
CMD [&quot;node&quot;, &quot;dist/index.js&quot;]

# Stage 0: ビルド環境（Node + npm）

FROM node:20-alpine AS builder

WORKDIR /app

COPY package*.json ./

RUN npm ci # 再現性の高いインストール

COPY . .

RUN npm run build # 本番ビルド成果物のみ残す

# Stage 1: 実行環境（最小イメージ）

FROM node:20-alpine AS runtime

WORKDIR /app

COPY --from=builder /app/dist ./dist

CMD ["node", "dist/index.js"]

(3) `docker-compose.yml`（CI 用）

version: &quot;3.9&quot;
services:
  db:
    image: postgres:15-alpine
    environment:
      POSTGRES_USER: test
      POSTGRES_PASSWORD: secret
  app:
    build: .
    depends_on:
      - db
    ports:
      - &quot;8080:8080&quot;

version: "3.9"

services:

db:

image: postgres:15-alpine

environment:

POSTGRES_USER: test

POSTGRES_PASSWORD: secret

app:

build: .

depends_on:

- db

ports:

- "8080:8080"

解説

マルチステージビルドは不要な開発ツールを除外し、イメージサイズを 150 MB → 45 MB 程度に削減できる（Docker 公式ブログ参照）[^4]。
Trivy による脆弱性スキャンは CI の「品質ゲート」として必須。スキャンで高リスクが検出された場合はビルドを失敗させることで、脆弱なイメージの流出を防止する。
docker‑compose による統合テストはローカルと同一構成で実行でき、環境差異による不具合を大幅に低減する。

セキュリティと運用上のベストプラクティス {#セキュリティと運用上のベストプラクティス}

項目	推奨設定	目的
シークレット管理	CircleCI → Contexts、GitHub Actions → Secrets, Jenkins → Credentials Binding Plugin（ID 管理）	ソースコードに平文で埋め込まない。
Docker Content Trust (DCT)	`DOCKER_CONTENT_TRUST=1` を CI 環境変数で有効化し、署名済みイメージのみプッシュ/プル	イメージ改ざん防止。
イメージスキャン	Trivy・Anchore などをビルド直後に実行し、`CRITICAL/HIGH` が出たらジョブ失敗	脆弱性の早期検知。
最小権限のランナー	`docker:20.10` の公式イメージだけでなく、必要な API 権限は限定的に付与（例：ECR への push 権限のみ）	ランナーが侵害された際の被害範囲を縮小。
キャッシュ管理	`docker_layer_caching` と `buildx cache-from / cache-to` を併用し、ビルド時間とネットワーク帯域を削減	再利用可能なレイヤーを明示的に管理。

ポイント：セキュリティは「スキャン」「署名」「最小権限」の 3 本柱で構成され、CI パイプラインの全フェーズに組み込むことが重要。

トラブルシューティング集 {#トラブルシューティング集}

症状	原因例	対策
`client version too old` エラー	CI ランナーの Docker CLI が古い（サーバ側は新しい API バージョン）	Docker CLI を固定バージョン (`docker:20.10.14-cli`) に更新し、`DOCKER_API_VERSION` 環境変数で合わせる[^5]。
ビルドキャッシュが無効化されている	`setup_remote_docker` のオプション指定ミスや Orbs のバージョン不一致	`docker_layer_caching: true` が有効か、Orbs バージョンを最新版に合わせる。
シークレットが取得できない	CI 設定画面でシークレット名のスペルミスまたは権限不足（Contexts 未割り当て）	変数名とアクセス権限を再確認し、ジョブ実行ユーザーに Context を付与。
イメージサイズが想定以上になる	マルチステージビルドの `COPY --from=` が抜けている、不要なファイルが残っている	`.dockerignore` に `node_modules`, `tests`, `*.md` 等を追加し、ステージ間のコピー範囲を最小化。

高度な活用例（マルチアーキテクチャ・キャッシュ戦略） {#高度な活用例}

1. マルチプラットフォームイメージのビルド

# CircleCI の例（buildx を利用）
- run:
    name: Set up Docker Buildx
    command: |
      docker buildx create --use
- docker/build:
    image: myorg/myapp
    tag: &quot;v${CIRCLE_TAG}&quot;
    platforms: linux/amd64,linux/arm64
    push: true

# CircleCI の例（buildx を利用）

- run:

name: Set up Docker Buildx

command: |

docker buildx create --use

- docker/build:

image: myorg/myapp

tag: "v${CIRCLE_TAG}"

platforms: linux/amd64,linux/arm64

push: true

buildx により AMD64 と ARM64 の 2 種類のイメージを同時に生成し、EKS（x86）と Graviton ベースの EC2（ARM）の両方でデプロイ可能。

2. 高度キャッシュ：外部レジストリへのキャッシュ保存

- docker/build:
    image: myorg/myapp
    tag: &quot;latest&quot;
    push: false
    cache-from: type=registry,ref=myorg/cache:buildcache
    cache-to:   type=registry,ref=myorg/cache:buildcache,mode=max

- docker/build:

image: myorg/myapp

tag: "latest"

push: false

cache-from: type=registry,ref=myorg/cache:buildcache

cache-to: type=registry,ref=myorg/cache:buildcache,mode=max

ビルドキャッシュを専用レジストリ myorg/cache に保存し、別ジョブや別ランナーでも再利用できる。特に大型モノリシックアプリのビルド時間が 40 % 程度短縮される実績あり（社内測定）[^6]。

参考文献・出典確認要項 {#参考文献}

No.	内容	出典（URL）	確認事項
^1	Qiita における Docker ビルド時間約30 %短縮事例	https://qiita.com/y-t0910/items/cabb4698c1f0b6f53d3b	数値の最新性・再現性を確認
^2	CircleCI Orbs `circleci/docker@2.4` のリリースノート	https://github.com/CircleCI-Public/docker-orb/releases	バージョンが最新かどうか
^3	`setup_remote_docker` の推奨 Docker デーモンバージョン	https://circleci.com/docs/setup-remote-docker/	バージョン番号の正確性
^4	Docker 公式ブログ（2025/01/16）におけるマルチステージベストプラクティス	https://www.docker.com/ja-jp/blog/docker-and-jenkins-build-robust-ci-cd-pipelines/	日付・内容の正確性
^5	Docker API バージョン不整合に関する Stack Overflow 記事	https://stackoverflow.com/questions/79817033/sudden-docker-error-about-client-api-version	エラーメッセージと対策の有効性
^6	社内ベンチマークレポート（2024 Q4）「Build Cache の効果」	（社内ドキュメント）	公開情報として参照できるか確認

注記：上記出典は執筆時点での情報です。実装前に各リンク先の最新バージョン・数値を必ず再確認してください。

まとめ

Docker は CI/CD の根幹――環境差異を排除し、ビルド時間と障害率を削減できる。
ツール選定は目的に合わせて：高速キャッシュが必要なら CircleCI、GitHub エコシステムとの統合が重要なら GitHub Actions、既存インフラ活用や高度なカスタマイズが求められるなら Jenkins。
実装パターンは「設定ファイル（YAML）＋ Dockerfile + テスト環境（docker‑compose）」の三層構造で整理すると保守性が向上する。
セキュリティは CI の段階から組み込む：シークレット管理、イメージスキャン、Docker Content Trust が基本。
高度な活用としてマルチアーキテクチャビルドや外部キャッシュの活用を検討すれば、さらなるコスト削減と信頼性向上が期待できる。

本ガイドをベースに、自社プロジェクトの要件・リソースに最適な Docker + CI/CD パイプラインを設計・実装してください。

スポンサードリンク

DockerとCI/CDの基本と主要ツール別設定ガイド

Docker が CI/CD にもたらす価値 {#docker-が-cicd-にもたらす価値}

主要 CI ツールの比較と選定ポイント {#主要-ci-ツールの比較と選定ポイント}

2‑1. CircleCI

2‑2. GitHub Actions

2‑3. Jenkins

実装パターン別サンプルコード {#実装パターン別サンプルコード}

3‑1. CircleCI でのイメージビルド & Docker Hub へのプッシュ

3‑2. Jenkins + マルチステージ Dockerfile + docker‑compose

(1) Jenkinsfile（Declarative Pipeline）

(2) マルチステージ Dockerfile

(3) docker-compose.yml（CI 用）

セキュリティと運用上のベストプラクティス {#セキュリティと運用上のベストプラクティス}

トラブルシューティング集 {#トラブルシューティング集}

高度な活用例（マルチアーキテクチャ・キャッシュ戦略） {#高度な活用例}

1. マルチプラットフォームイメージのビルド

2. 高度キャッシュ：外部レジストリへのキャッシュ保存

参考文献・出典確認要項 {#参考文献}

まとめ

(1) `Jenkinsfile`（Declarative Pipeline）

(3) `docker-compose.yml`（CI 用）