GitHub ActionsとDockerで作るCI/CDパイプラインの設計パターン

CI/CD（継続的インテグレーション・継続的デリバリー）パイプラインを最初から設計するとき、何をどの順番で組み立てるかで後の保守コストが大きく変わる。シード記事が公開したリポジトリは、GitHub ActionsとDockerを組み合わせた実践的な構成例として参照しやすい。今回はその設計を技術的に読み解きながら、背景知識や代替手段も含めて整理する。

Nginxコンテナを使う静的サイト構成の意味

シード記事のDockerfileは次のように書かれている。

FROM nginx:alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

nginx:alpine は、Alpine Linux（軽量Linuxディストリビューション）をベースにしたNginxの公式イメージで、サイズが数十MB程度に抑えられる。フルサイズのDebian系イメージと比べると数倍小さく、コンテナレジストリへのプッシュ時間やプル時間が短縮される。

静的ファイルをNginxで配信する構成は、ReactやViteでビルドした成果物を配信する際にも広く使われるパターンだ。ビルドと配信を分離する「マルチステージビルド」と組み合わせると、ビルドツールをコンテナイメージに含めずに済む。たとえば第1ステージでNode.jsを使ってビルドし、第2ステージでその成果物だけをNginxにコピーする構成がその代表例だ。

GitHub ActionsのワークフローとGHCRの役割

シード記事のパイプラインは、プッシュやプルリクエストを契機にGitHub Actionsを起動し、Dockerイメージのビルド・プッシュまでを自動化している。プッシュ先はGHCR（GitHub Container Registry）で、GitHub PackagesのDockerイメージ向けサービスだ。Docker Hubと異なり、リポジトリと同じ認証基盤（GitHubトークン）で操作できるため、シークレット管理がシンプルになる。

GitHub Actionsのワークフローファイルは .github/workflows/ 以下にYAML形式で置く。代表的なステップは以下の構造になる。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:latest

GITHUB_TOKEN はActionsが自動で発行する一時トークンで、外部シークレットを別途登録する必要がない。この仕組みが、CIセットアップのハードルを下げる要因のひとつになっている。

パイプラインが壊れたときの読み方

シード記事で特に注目したいのは、デバッグの記録だ。PythonからNginxへ移行した際、CIが以前の検証ステップ（削除済みのPythonファイルを参照するもの）を実行しようとして失敗した。この状況は実務でも起きやすい。

GitHub Actionsのログは、ステップ単位で折り畳まれている。失敗したステップを展開すると、どのコマンドが何というエラーを返したかが確認できる。「ファイルが見つからない」系のエラーであれば、ワークフローYAMLが古い前提（パスや言語ランタイム）を参照していることが多い。

対処の基本は3ステップだ。

ログの最後のエラー行を読んで原因コマンドを特定する
ワークフローYAMLで該当ステップを探し、不要なら削除・更新する
変更をコミットしてActionsを再トリガーし、パスするか確認する

パイプラインを「一度作れば終わり」ではなく、アプリケーションの変化に合わせて更新し続けるものとして扱う発想が、長期運用の安定につながる。

他のCIサービスとの比較と選択基準

GitHub Actions以外の主要なCIサービスとしては、GitLab CI/CD、CircleCI、Jenkins、そしてクラウドネイティブなAWS CodeBuildなどがある。GitLab CI/CDはリポジトリとCIが同一プラットフォームに統合されており、セルフホスト型のRunnerも柔軟に構成できる。CircleCIはキャッシュ戦略やParallelismが細かく設定でき、大規模なテストスイートの高速化に強みがある。

GitHub Actionsの優位点は、GitHubリポジトリとの親和性と、Marketplaceで公開されているActionの豊富さだ。docker/build-push-action や actions/cache のように、よく使うステップをそのまま呼び出せる。一方、プライベートリポジトリでの無料実行時間には上限があるため、大量のCIジョブを回す場合はコスト試算が必要になる。

今回のシード記事のように「まず一本通したパイプラインを作る」アプローチは、ツール選定や最適化を後回しにして構造を理解するうえで合理的だ。DockerとGitHub ActionsはドキュメントやOSSの事例が豊富で、日本のエンジニアコミュニティでも多く使われているため、調査コストが低い。

設計の選択肢が増えた今、「なぜこの構成か」を説明できるかどうかが、パイプラインの品質を左右する。