Docker: GitHub Actions でデプロイする

GitHub Actions を使って Docker コンテナをデプロイする方法

👋 Stackheroのドキュメントへようこそ！

Stackheroは、DockerクラウドCaaS (Containers as a Service) の即時利用可能なソリューションを提供し、多くの利点があります。例えば：

docker-compose up だけでコンテナを簡単に本番環境にデプロイ。

HTTPSで保護されたカスタマイズ可能なドメイン名（例: https://api.your-company.com, https://www.your-company.com, https://backoffice.your-company.com）。

プライベートで専用のVMによる最適なパフォーマンスと強力なセキュリティ。

ワンクリックでの簡単なアップデート。

時間を節約し、生活を簡素化：StackheroのDocker CaaSクラウドホスティングソリューションを試して、コンテナを本番環境にデプロイするのに5分しかかかりません！

GitHub Actions を利用すると、Docker コンテナを本番サーバーへデプロイするなどのタスクを簡単に自動化できます。このガイドでは、GitHub Actions を安全かつ信頼性高く設定し、Docker コンテナをステージング環境および本番環境へデプロイする方法をご紹介します。

このセットアップでは、staging と production の2つのブランチを管理します。どちらかのブランチにコードをプッシュすると、自動的に対応する Stackhero インスタンスへデプロイされます。

ステージングインスタンスの用意は必須ではありません。このガイドは本番インスタンスのみでもご利用いただけます。ただし、本番環境へのデプロイ時のリスクを減らし、安心して運用するためには、ステージングと本番の両方のインスタンスを持つことを強く推奨します。これは業界標準のベストプラクティスであり、多くの潜在的な問題を回避するのに役立ちます。

始める前に、GitHub アカウントとコードをホストするリポジトリをご用意ください。

Docker サービスの作成

まず Stackhero ダッシュボードにログインし、ステージング用と本番用の2つの Stackhero サービスを作成します。管理しやすくミスを減らすために、サービス名を「Staging」と「Production」に変更しておくと便利です。

まだ Stackhero アカウントをお持ちでない場合無料で2分ほどで作成でき、その後 Docker クラウドサービスを数クリックでセットアップできます。

Docker サービスの例

環境変数とシークレットの設定

ドメイン名と証明書パスワードの取得

GitHub Actions から Stackhero の Docker サービスへ接続するには、サービスのドメイン名と証明書パスワードの2つの情報が必要です。

Stackhero ダッシュボードで「production」Docker サービスを選択し、「Configure」ボタンをクリックします。

サービス設定の取得
「Domain name」と「Docker certificates password」の両方をコピーし、次の手順で使用します。

サービス設定の取得

GitHub でドメイン名と証明書パスワードを設定する

GitHub でプロジェクトを開きます。
Settings > Environments に進み、New environment をクリックします。

GitHub 環境の設定
Name フィールドに「production」と入力し、確定します。

環境の設定
No restriction ボタンをクリックし、Selected branches and tags を選択します。

環境制限の設定
Add deployment branch or tag rule をクリックし、Name pattern フィールドに「production」と入力して Add rule をクリックします。

環境ブランチの設定環境ブランチの設定
Environment secrets の下で Add secret をクリックします。

シークレットの追加
シークレット名に STACKHERO_CERTIFICATES_PASSWORD を指定し、証明書パスワードを Value フィールドに貼り付けます。

証明書パスワードシークレットの設定
Environment variables の下で Add variable をクリックします。

変数の設定
名前に STACKHERO_ENDPOINT を指定し、Stackhero ダッシュボードで確認できる Docker サービスのエンドポイントを Value フィールドに貼り付けます。

エンドポイント変数の設定

サービスのドメイン名をカスタマイズしている場合は、<XXXXXX>.stackhero-network.com の代わりにカスタムドメインを使用してください。

Docker Compose 設定ファイルのカスタマイズ

すでに docker-compose.yml ファイルがプロジェクトのルートにあり、カスタマイズが不要な場合はこのセクションをスキップできます。

デフォルトでは、GitHub Actions はプロジェクトのルートディレクトリにある docker-compose.yml ファイルを参照します。別のファイルや構成を使いたい場合は、デプロイコマンドを調整できます。たとえば、Node.js と Docker のスターターボイラープレートを利用している場合は、新しい環境変数 STACKHERO_DEPLOY_COMMAND を作成し、以下のように設定します：

docker compose --env-file env.list --file docker/docker-compose.yml --file docker/docker-compose.production.yml up --build --remove-orphans -d

GitHub Actions ワークフローの設定

ローカルマシンで Git リポジトリに移動し、.github/workflows ディレクトリを作成します。その中に deploy-to-stackhero.yml というファイルを作成し、以下の内容を記述します：

# File: .github/workflows/deploy-to-stackhero.yml

name: Deploy to Stackhero
description: Deploy branch "${{ github.ref_name }}" to Stackhero

on:
  push:
    # These branches trigger the deploy action on push.
    # Be sure to create an environment matching the branch name in GitHub (under Settings > Environments).
    # Then add the secret STACKHERO_CERTIFICATES_PASSWORD and variable STACKHERO_ENDPOINT in that environment.
    branches: [ "production", "staging" ]

jobs:
  Deploy:
    environment: ${{ github.ref_name }}
    runs-on: ubuntu-latest
    steps:
    - uses: stackhero-io/github-actions-deploy-docker-containers-to-stackhero@v1
      with:
        # The secret STACKHERO_CERTIFICATES_PASSWORD and the variable STACKHERO_ENDPOINT should be defined in the corresponding branch environment on GitHub.
        certificates_password: ${{ secrets.STACKHERO_CERTIFICATES_PASSWORD }}
        endpoint: ${{ vars.STACKHERO_ENDPOINT }}
        # deployment_command is optional. You can use it if you need to customize the Docker Compose command.
        deployment_command: ${{ vars.STACKHERO_DEPLOY_COMMAND }}

変更をコミットするには、以下のコマンドを実行します：

git add -A .
git commit -m "Add GitHub Actions to deploy to Stackhero"

本番ブランチを作成するには、次のコマンドを実行します：

git checkout -b production

そして、本番ブランチを GitHub にプッシュします：

git push --set-upstream origin production

コードをプッシュすると、GitHub Actions が自動的に本番 Stackhero インスタンスへデプロイします。デプロイの進捗は GitHub プロジェクトの Actions タブで確認できます。

本番環境にデプロイされた GitHub Actions

これで、GitHub Actions を使った本番環境への自動デプロイが完了です。

ステージング環境の作成

ステージング環境のセットアップも本番環境と同じ手順です。production の代わりに staging を使って同様に進めてください。

次に、ステージングブランチを作成します：

git checkout -b staging

そして、ステージングブランチを GitHub にプッシュします：

git push --set-upstream origin staging

これで、GitHub Actions が自動的にステージング用 Docker インスタンスへステージングブランチをデプロイします。

docker-compose.yml で環境変数を利用する

GitHub プロジェクトで定義した環境変数は、docker-compose.yml ファイル内でも利用できます。たとえば、ステージング用（staging.my-company.com）と本番用（my-company.com）で異なるドメインにデプロイしたい場合に便利です。

GitHub の Settings > Environments で、WEBSITE_DOMAIN という環境変数を作成します。
ステージング環境には WEBSITE_DOMAIN を「staging.my-company.com」に設定します。
本番環境には WEBSITE_DOMAIN を「my-company.com」に設定します。

次に、.github/workflows/deploy-to-stackhero.yml ファイルを更新し、WEBSITE_DOMAIN 変数を Stackhero GitHub Action に渡します：

name: Deploy to Stackhero
description: Deploy branch "${{ github.ref_name }}" to Stackhero

on:
  push:
    branches: [ "production", "staging" ]

jobs:
  Deploy:
    environment: ${{ github.ref_name }}
    runs-on: ubuntu-latest
    steps:
    - uses: stackhero-io/github-actions-deploy-docker-containers-to-stackhero@v1
      with:
        certificates_password: ${{ secrets.STACKHERO_CERTIFICATES_PASSWORD }}
        endpoint: ${{ vars.STACKHERO_ENDPOINT }}
        deployment_command: ${{ vars.STACKHERO_DEPLOY_COMMAND }}
      env:
        WEBSITE_DOMAIN: ${{ vars.WEBSITE_DOMAIN }}

さらに、docker-compose.yml ファイルを修正し、ハードコーディングされたドメイン名の代わりに WEBSITE_DOMAIN 変数を使用します：

services:
  test:
    image: nginx
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.test.rule=Host(`${WEBSITE_DOMAIN}`)" # WEBSITE_DOMAIN 環境変数をドメイン名として利用します。
      - "traefik.http.routers.test.tls.certresolver=letsencrypt"

さらに進んだ運用のために

production および staging ブランチへの直接プッシュを防ぐため、ブランチ保護を有効にすることを推奨します。ブランチ保護を設定すると、変更はプルリクエスト経由でのみ反映され、適切な権限を持つメンバーによるレビューとマージが必要になります。これにより、まずステージング環境で機能を検証し、承認後に本番環境へ反映する運用が可能です。

このワークフローを採用することで、（ステージング・本番環境へのデプロイ権限を持つ）認可されたチームメンバーのみがデプロイできるというセキュリティと、新機能を本番投入前にステージングで十分にテストできるという信頼性の両方を確保できます。