GitHub ActionsによるDockerベースCI/CDパイプライン構築

2026年6月12日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 GitHub ActionsによるCI/CDワークフローの概要
2 GitHub Actionsのワークフロー構築手順
- 2.1 YAMLファイルの基本構造
- 2.2 ステップごとの処理フロー
3 Dockerイメージのビルドとホスティング
- 3.1 Dockerfileの最適化手法
  - 3.1.1 具体例: 多段階ビルドのDockerfile
- 3.2 イメージのビルド・プッシュ自動化
4 Kubernetes/AWS ECSとのデプロイ連携
5 セキュリティ設定と環境管理
6 実践例と今後の展望
- 6.1 ワークフローYAMLファイルの具体例
- 6.2 継続的改善のためのメトリクス設計

スポンサードリンク

GitHub ActionsによるCI/CDワークフローの概要

GitHub Actionsは、現代のDevOpsエンジニアにとってなくてはならないツールです。特にDockerコンテナを利用したアプリケーション開発においては、コードの変更からテスト、ビルド、デプロイの一連の流れを自動化する「CI/CDパイプライン」が求められています。この記事では、2025年時点の最新技術スタック（GitHub Actions v5、Docker Buildx v0.11、Kubernetes v1.30）を基盤に、GitHub ActionsによるDockerコンテナベースのCI/CDパイプライン構築手順と、AWSやKubernetesとの連携方法を具体的に解説します。実務で導入する際の参考になるよう、具体的なワークフロー設計例も紹介します。

GitHub Actionsのワークフロー構築手順

GitHub Actionsを使用してCI/CDワークフローを構築するには、以下の3つのステップが基本になります。この流れは、Dockerコンテナを用いた自動化に特化した設計方法です。

YAMLファイルの基本構造

GitHub Actionsのワークフローは.github/workflows/ci-cd.ymlなどのファイルで記述されます。このファイルの基本的な構造を以下に示します：

name: CI/CD Pipeline for Docker App

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

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: my-docker-repo/my-app:${{ github.sha }}

name: CI/CD Pipeline for Docker App

on:

push:

branches: [main]

pull_request:

branches: [main]

jobs:

build-and-deploy:

runs-on: ubuntu-latest

steps:

- name: Checkout code

uses: actions/checkout@v3

- name: Set up Docker Buildx

uses: docker/setup-buildx-action@v2

- name: Build and push Docker image

uses: docker/build-push-action@v5

with:

context: .

file: ./Dockerfile

push: true

tags: my-docker-repo/my-app:${{ github.sha }}

このYAMLファイルでは、コードプッシュ時に自動でビルドとイメージのプッシュが実行される仕組みとなっています。

ステップごとの処理フロー

ワークフローは通常、以下のステップで構成されます：

リポジトリからコードを取得（actions/checkout@v3を使用）
Docker Buildxのセットアップ（Dockerイメージビルダーの初期化）
Dockerイメージのビルドとプッシュ（docker/build-push-action@v5で実行）

上記の手順により、GitHub Actionsが自動的にコード変更を検出し、Dockerコンテナを構築・ホスティングする仕組みを作成できます。

Dockerイメージのビルドとホスティング

Dockerコンテナを利用したCI/CDパイプラインでは、Dockerfileの最適化とイメージの自動ビルド・プッシュが重要なステップです。以下にその詳細を説明します。

Dockerfileの最適化手法

Dockerfileはアプリケーションの構築に必要な手順を記述したファイルです。効率的なDockerコンテナを作成するには、多段階ビルド（multi-stage build）やベースイメージの選定が重要です。

最適化項目	内容
多段階ビルド	一時的な構築環境を別コンテナで分離し、最終的なイメージサイズを小さくする
ベースイメージの選定	`alpine`や`scratch`などの軽量なベースイメージを利用することでリソース効率が向上
キャッシュの有効化	よく変更されないレイヤー（例：パッケージインストール）を先に記述し、リビルド時のキャッシュ利用を促進

具体例: 多段階ビルドのDockerfile

# 第1ステージ: ビルド環境
FROM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN go build -o my-app

# 第2ステージ: 最終イメージ
FROM alpine:3.18
WORKDIR /root/
COPY --from=builder /app/my-app .
CMD [&quot;./my-app&quot;]

# 第1ステージ: ビルド環境

FROM golang:1.21 AS builder

WORKDIR /app

COPY . .

RUN go build -o my-app

# 第2ステージ: 最終イメージ

FROM alpine:3.18

WORKDIR /root/

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

CMD ["./my-app"]

イメージのビルド・プッシュ自動化

GitHub Actionsでは、docker/build-push-action@v5アクションを使用してDockerイメージを構築・ホスティングできます。このアクションは、build contextやタグ設定を柔軟に指定可能で、複数のリポジトリとの連携も可能です。

Kubernetes/AWS ECSとのデプロイ連携

CI/CDパイプラインを完成させるには、最終的にアプリケーションをクラウド環境へデプロイする必要があります。以下では、KubernetesとAWS ECSそれぞれでのベストプラクティスとGitHub Actionsとの連携方法を紹介します。

クラウドネイティブなワークフロー設計

現代のDevOpsでは、「クラウドネイティブ」なアーキテクチャが主流です。このスタイルでは、コンテナイメージの自動ビルドとデプロイが基本的なワークフローとなります。

HelmチャートによるK8sデプロイ

Kubernetesにおいては、Helmチャートが非常に効率的な管理ツールです。GitHub ActionsからHelmを使用してデプロイするには、以下の手順を実施します：

Helmリポジトリの設定（helm repo add）
Chartファイルの作成・配置
GitHub Actionsでhelm installコマンドを実行

この方法であれば、CI/CDパイプライン内でKubernetesへのデプロイも自動化されます。

AWS ECSタスク定義の自動生成

AWS ECSでも、GitHub Actionsとの連携が可能です。ここでは、AWS CLIとECSのAPIを使用してタスク定義を動的に作成・更新します。

AWS Secrets Managerから認証情報を取得
ECSタスク定義のJSONファイルを作成
aws ecs register-task-definitionコマンドでリジスター

この手順により、アプリケーションがAWS ECSに自動デプロイされる仕組みを構築できます。

セキュリティ設定と環境管理

CI/CDパイプラインにおいては、セキュリティの確保が不可欠です。以下では、暗号化されたシークレット管理やネットワークアクセス制御など、実務で重要なポイントを解説します。

暗号化されたシークレットの管理

GitHub Actionsには「Secrets」という機能があり、Docker HubやAWS認証情報などの機密情報を暗号化して保存できます。これにより、リポジトリに直接シークレットを記述するリスクが回避されます。

注意事項: GitHub SecretsはプロジェクトのSettings > Secrets and variables > Actionsから管理し、定期的なローテーションが必要です。

ネットワークポリシーベースのアクセス制御

アプリケーションがクラウド環境へ接続する際は、ネットワークポリシーによるアクセス制御が重要です。例えば、AWS VPC内で特定IPからのみ通信を許可する設定などを加えることで、不正なアクセスを防ぎます。

IAMロールによる最小権限設計

クラウドサービスとの連携では、IAMロールを使用して最小限の権限でリソースにアクセスする仕組みを構築します。これにより、過剰な権限を持たせることでのリスクが抑えられ、セキュリティ体制が強化されます。

実践例と今後の展望

具体的なワークフローYAMLファイルの例や、継続的な改善に向けたメトリクス設計について解説します。実際には、以下のようなYAMLファイルでCI/CDパイプラインを構築できます：

ワークフローYAMLファイルの具体例

name: Deploy to Kubernetes

on:
  push:
    branches: [main]

jobs:
  deploy-k8s:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Helm
        uses: azure/setup-helm@v1

      - name: Deploy to Kubernetes
        run: |
          helm upgrade --install my-app ./charts/my-app \
            --namespace dev \
            --set image.tag=${{ github.sha }}

name: Deploy to Kubernetes

on:

push:

branches: [main]

jobs:

deploy-k8s:

runs-on: ubuntu-latest

steps:

- name: Checkout code

uses: actions/checkout@v3

- name: Set up Helm

uses: azure/setup-helm@v1

- name: Deploy to Kubernetes

run: |

helm upgrade --install my-app ./charts/my-app \

--namespace dev \

--set image.tag=${{ github.sha }}

この例では、GitHub ActionsがHelmチャートを使用してKubernetesにアプリケーションをデプロイするフローが記述されています。

継続的改善のためのメトリクス設計

CI/CDパイプラインにおいては、継続的な改善を目指すため、ビルド成功率やデプロイ時間などのメトリクスを収集・可視化することが重要です。これにより、問題の早期発見やチーム間での共有が可能となります。

メトリクス	評価基準	例
ビルド成功率	90%以上を目標とする	GitHub Actionsの`status`ステータスから取得
デプロイ時間	3分以内に収める	`start_time`と`end_time`から計算
リロード回数	月1回以下を維持	環境変更頻度の指標

GitHub ActionsによるCI/CDワークフロー構築
Dockerイメージの自動ビルドとホスティング
Kubernetes/AWS ECSとのデプロイ連携
セキュリティ設定と環境管理
実践的なワークフローYAMLファイルの例

記事を参考にGitHub Actionsによる自動化フローの導入を試してみましょう。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-Docker

comment コメントをキャンセル

: Docker

Docker Compose 基本と最新仕様 – V2への移行とベストプラクティス

Docker Compose のファイル構造と最新 V2 CLI の活用方法を実務向けにわかりやすくまとめました。

: Docker

Docker と Kubernetes 比較 2026：最新機能と実務ベストプラクティス

本記事は「Docker と Kubernetes 比較 2026」をキーワードに、イメージ最適化・BuildKit 改善から HPA の予測型スケーリング、Pod Security Admission まで、最新機能とユースケース別の導入判断基準を実務視点でまとめています。

: Docker

DockerマルチステージビルドとKubernetesデプロイの完全ガイド

Dockerのマルチステージビルドによる軽量化と、Kubernetesへのデプロイ手順・ベストプラクティスを解説します。

: Docker

Docker Compose V2 GAリリースと2026年の新機能まとめ

Docker Compose V2が一般提供され、プラグイン化とCompose Specificationへの完全対応により、導入・運用が大幅に簡素化されました。

: Docker

Docker Compose V2 完全ガイド：GA情報・インストールから移行手順まで

Docker Compose V2 が 2026 年 4 月に GA し、Docker CLI に統合されたプラグインとして提供されます。本稿ではインストール手順から V1 との違い、実践的な移行フローまでを詳しく解説します。

OPPO Watch Freeで睡眠モニタリング設定方法【初心者ガイド】

OPPO 2026年最新5G機種ラインアップと実測速度徹底比較