【入門編】【実務直結】GitHub ActionsでDockerイメージを自動ビルド・公開する効率的なワークフロー – バージョン管理・CI/CD活用バイブル

こんにちは。DevOpsの世界へようこそ。

GitHub ActionsでDockerイメージを扱う際、多くの初心者が陥る罠があります。それは「毎回ゼロからビルドして、貴重なCI時間を浪費する」ことです。大規模なアプリケーションになればなるほど、この非効率さはチームの生産性を奪う癌になります。

今日は、現場で即戦力となる「爆速で、かつ堅牢な」Dockerビルド・ワークフローの極意を伝授します。これをマスターすれば、あなたのGitHub Actionsは単なる自動化ツールから、開発のスピードを加速させる最強の武器に変わります。

—

1. なぜ「キャッシュ戦略」がすべてなのか?

Dockerのビルドには「レイヤー」という概念があります。Dockerfileの各行がキャッシュとして保存され、変更がない限り再利用されます。GitHub Actionsでこれを実現するには、「GitHub Actions Cache」を賢く使うのが定石です。

これを使わないと、毎回数分〜数十分かかるビルドが、最適化すれば数秒で終わります。

2. 目標:実務レベルのワークフローを作成する

今回は、以下の3つを実現するワークフローを構築します。
1. ビルド時間の極小化(GitHub Actions Cache活用)
2. マルチプラットフォーム対応(arm64とamd64両対応)
3. GHCR(GitHub Container Registry)への自動公開

必要なセットアップ

リポジトリの `Settings > Actions > General` で、Workflowの読み書き権限が許可されていることを確認してください。

HelloWorld的なワークフローファイル (`.github/workflows/docker-publish.yml`)

name: Build and Push Docker Image

on:
push:
branches: [ “main” ] # mainへのプッシュで自動実行

jobs:
build:
runs-on: ubuntu-latest
permissions:
contents: read
packages: write # GHCRへの書き込み権限

steps:

  • name: リポジトリのチェックアウト

uses: actions/checkout@v4

# QEMU: マルチプラットフォームビルドの要

  • name: Set up QEMU

uses: docker/setup-qemu-action@v3

# Buildx: キャッシュやマルチプラットフォームを扱うための次世代エンジン

  • name: Set up Docker Buildx

uses: docker/setup-buildx-action@v3

# GHCRへのログイン

  • name: Login to GitHub Container Registry

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:
context: .
push: true
# タグ付け:コミットSHAとlatestを自動付与
tags: |
ghcr.io/${{ github.repository_owner }}/my-app:latest
ghcr.io/${{ github.repository_owner }}/my-app:${{ github.sha }}
# キャッシュの設定(ここが肝)
cache-from: type=gha
cache-to: type=gha,mode=max
# ARM64とAMD64のマルチプラットフォーム対応
platforms: linux/amd64,linux/arm64

—

3. この構成が「伝説的」である理由

① `cache-from: type=gha`

これが魔法の言葉です。GitHub Actions専用のキャッシュストレージに、ビルド結果のレイヤーを保存します。次回の実行時、変更のあったレイヤー以外は即座にロードされるため、ビルド時間は劇的に短縮されます。

② `mode=max`

デフォルトだと「最終段階」のレイヤーしかキャッシュされません。`mode=max` を指定することで、ビルド途中の重いレイヤー(依存関係のインストールなど)も全てキャッシュさせます。これが「現場で震えるほど速い」理由です。

③ `platforms: linux/amd64,linux/arm64`

現代の開発環境は混在しています。Mac (Apple Silicon) の開発者が増えた今、arm64対応のイメージをCIで自動生成しておくことは必須のマナーと言えるでしょう。

—

4. 精度高い動作確認のステップ

1. コミットとプッシュ: このファイルを `.github/workflows/` に置いてプッシュします。
2. Actionsタブを確認: GitHubリポジトリの「Actions」ページを開き、実行状況を確認しましょう。
3. GHCRを確認: 成功したら、リポジトリの右側サイドバーにある「Packages」にイメージが登録されているはずです。
4. 2回目の実行: 再度コミットしてプッシュしてみてください。ビルド時間が1回目より格段に速くなっていることに驚くはずです。

最後に:先輩からのアドバイス

「ツールをただ動かす」のは誰でもできます。しかし、「なぜそのキャッシュ戦略が必要なのか」「なぜレイヤーを意識すべきなのか」という本質を理解しているエンジニアは、障害に強く、チームから圧倒的に信頼されます。

この構成は、どんなプロジェクトでも明日から使える「鉄板」のテンプレートです。ぜひあなたのプロジェクトに組み込んで、浮いた時間をコードの品質向上や、新しい技術の学習に充ててください。

応援しています。何か詰まったら、いつでも聞いてくださいね!

タイトルとURLをコピーしました