GitHub ActionsでDocker Stackを自動デプロイ

前回までの連載で、Docker Swarmによるオーケストレーションの基本と、Docker Stackを用いた宣言的なデプロイ手法を学びました。しかし、開発の現場では「コードをGitHubにプッシュしたら自動で本番環境に反映される」仕組み、いわゆるCI/CD（継続的インテグレーション／継続的デリバリー）が不可欠です。

今回は、GitHub Actionsを使用して、Docker StackをSwarmクラスタへ自動デプロイするCDパイプラインの構築方法を徹底解説します。

---

なぜ「GitHub Actions × Docker Stack」なのか？

手動デプロイには「オペレーションミスのリスク」や「作業の属人化」といった課題があります。GitHub ActionsでCDを自動化することで、以下のメリットを享受できます。

• 迅速なリリース: プッシュから数分で本番環境が更新される。
• 信頼性の向上: 定義された手順が常に正確に実行される。
• 履歴の可視化: 誰がいつデプロイしたかがGitHub上で一目瞭然。

アーキテクチャ図

GitHub (Code/Workflow) -> SSH Connection -> Swarm Manager -> Docker Stack Deploy

---

ハンズオン：自動デプロイパイプラインを構築する

このハンズオンでは、GitHubへのプッシュを検知し、リモートのSwarm ManagerへSSH経由でデプロイ命令を送るWorkflowを作成します。

前提条件

• Docker Stack入門を完了し、Swarmクラスタが構築済みであること。
• GitHubのリポジトリにソースコードと docker-compose.yml がプッシュされていること。
• デプロイ先サーバーのIPアドレスと、SSH接続用の秘密鍵があること。

ステップ1：GitHub Secretsの設定

セキュリティのため、サーバーの接続情報はコードに直接書かず、GitHubの「Secrets」に保存します。

1. GitHubリポジトリの Settings > Secrets and variables > Actions を開きます。
2. New repository secret をクリックし、以下の3つを登録します。
   • SSH_HOST: サーバーのIPアドレス
   • SSH_USERNAME: SSHユーザー名（例: root）
   • SSH_PRIVATE_KEY: サーバーにログインするための秘密鍵の内容

ステップ2：Workflowファイル（deploy.yml）の作成

リポジトリ直下に .github/workflows/deploy.yml を作成し、以下の内容を記述します。

YAML

name: Deploy to Docker Swarm

on:
  push:
    branches:
      - main  # mainブランチにプッシュされた時に発火

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1.0.3
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USERNAME }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            # 1. プロジェクトディレクトリへ移動（なければ作成）
            mkdir -p ~/my-app
            cd ~/my-app
            
            # 2. 最新のdocker-compose.ymlをGitHubから取得（簡易的な例）
            # ※本来はDocker RegistryからイメージをPullするのが理想的です
            echo "${{ github.sha }}" > version.txt
            
            # 3. Stackのデプロイ実行
            docker stack deploy -c docker-compose.yml my-web-app --with-registry-auth

ステップ3：自動デプロイの実行と確認

1. ローカルで適当な変更（例：docker-compose.yml のレプリカ数を変更）を行い、GitHubへプッシュします。
2. GitHubの Actions タブを開き、Workflowが走り始めたことを確認します。
3. すべてのステップが緑色（Success）になれば完了です。

ステップ4：サーバー側での確認

Swarm Managerにログインし、実際にスタックが更新されているか確認します。

Bash

docker stack services my-web-app

---

本格的な運用に向けたTips

今回のハンズオンは「最小構成」です。実運用では以下の要素も検討してください。

• Docker Registryの利用: GitHub Actions側でイメージをビルドし、Docker HubやGitHub Packagesへプッシュ。その後、サーバー側でそのイメージをPullしてデプロイするのが標準的な流れです。
• Docker Contextの利用: ssh-action を使う代わりに、GitHub Actions Runner内に docker context を作成し、リモートのDockerデーモンを直接操作する方法もあります。
• Slack通知: デプロイが完了または失敗した際に、Slackへ通知を送るステップを追加すると便利です。

---

まとめ

GitHub Actionsを活用すれば、Docker Swarm環境へのデプロイは驚くほどスムーズになります。

1. Secrets で認証情報を安全に管理。
2. Workflow でデプロイ手順をコード化（Pipeline as Code）。
3. Push するだけで本番環境が最新の状態に。

これで、Dockerオーケストレーションの「構築」「管理」そして「自動化」までのサイクルが完成しました。