Node.js: GitHub Actions でデプロイする

GitHub Actions を使って Node.js コードをデプロイする方法

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

Stackheroは、数多くの利点を提供するNode.jsクラウドソリューションを提供しています。主な利点は以下の通りです:

  • シンプルなgit push数秒でアプリケーションをデプロイ
  • 独自のドメイン名を使用し、HTTPS証明書の自動設定による強化されたセキュリティを享受。
  • 自動バックアップワンクリックアップデート、そしてシンプルで透明性があり、予測可能な価格設定で安心を提供。
  • プライベートで専用のVMによる最適なパフォーマンスと強固なセキュリティを実現。

時間を節約し、生活を簡素化:StackheroのNode.jsクラウドホスティングソリューションを試すのに5分しかかかりません

GitHub Actions を利用すると、Node.js コードを本番サーバーへデプロイするなどのタスクを簡単に自動化できます。このガイドでは、GitHub Actions を使って Node.js アプリケーションをステージング環境と本番環境の両方に安全かつ確実にデプロイする手順を解説します。

stagingproduction の2つのブランチを運用することを推奨します。これらのブランチのいずれかにコードをプッシュすると、対応する Stackhero サービスへ自動的にデプロイされます。

ステージング環境の用意は必須ではありません。 本ガイドは本番環境のみでもご利用いただけますが、デプロイを円滑にし、本番公開前に十分な検証を行うためにも、ステージングと本番の両環境を運用することを強く推奨します。 この運用方法は業界でも広く採用されており、よくあるデプロイの問題を防ぐのに役立ちます。

始める前に、GitHub アカウントと Node.js コードをホストしているリポジトリがあることをご確認ください。

まず、Stackhero ダッシュボードにサインインし、ステージング用と本番用の2つの Stackhero サービスを作成します。分かりやすくするために、サービス名を「Staging」と「Production」としておくと良いでしょう。

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

Node.js サービスの例Node.js サービスの例

SSH キーは、GitHub Actions がデプロイ時に Node.js サービスへ安全に接続するために必要です。このステップは Stackhero サービスのセキュリティ確保に不可欠です。

お使いのコンピュータで、以下のコマンドで新しい SSH キーを生成できます:

ssh-keygen -C "" -f /tmp/ssh_key -N ""

作成した公開鍵を確認するには、次のコマンドを実行します:

cat /tmp/ssh_key.pub

次に、Stackhero ダッシュボードで本番用 Node.js サービスを選択し、Configure ボタンをクリックします。

サービス設定の取得サービス設定の取得

以下の手順を続けてください:

  1. SSH public keysAdd a public key をクリックします。
  2. Description には GitHub Action と入力します。
  3. Key には先ほどコピーした公開鍵を貼り付けます。

サービス設定の取得サービス設定の取得

次に GitHub に移動し、プロジェクトリポジトリを開きます。Settings をクリックし、Environments を選択します。New environment を作成してください。

GitHub 環境の設定GitHub 環境の設定

Name に「production」と入力し、確定します。

環境の設定環境の設定

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

環境制限の設定環境制限の設定

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

環境ブランチの設定環境ブランチの設定

環境ブランチの設定環境ブランチの設定

Environment secretsAdd secret をクリックします。

シークレットの追加シークレットの追加

生成した秘密鍵を取得するには、次のコマンドを実行します:

cat /tmp/ssh_key

GitHub では NameSTACKHERO_SSH_PRIVATE_KEY を指定し、Value フィールドに秘密鍵を貼り付けてください。

SSH 秘密鍵シークレットの設定SSH 秘密鍵シークレットの設定

続いて Environment variablesAdd variable をクリックします。

変数の設定変数の設定

NameSTACKHERO_ENDPOINT を入力し、Value フィールドに Node.js サービスのエンドポイントを貼り付けます。エンドポイントは Stackhero ダッシュボードで確認できます。

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

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

セキュリティのため、Stackhero と GitHub への登録が完了したら、コンピュータ上の SSH キーを削除しておくことを推奨します:

rm /tmp/ssh_key /tmp/ssh_key.pub

Git リポジトリ内に .github/workflows ディレクトリがなければ作成し、deploy-to-stackhero.yml というファイルを追加します:

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

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

on:
  push:
    # デプロイをトリガーするブランチをリストします。各ブランチに対応する GitHub 環境("Settings" > "Environments")を作成してください。
    # その環境に STACKHERO_SSH_PRIVATE_KEY シークレットと STACKHERO_ENDPOINT 変数を追加します。
    branches: [ "production", "staging" ]

jobs:
  Deploy:
    environment: ${{ github.ref_name }}
    runs-on: ubuntu-latest
    steps:
    - uses: stackhero-io/github-actions-deploy-to-stackhero@v1
      with:
        # STACKHERO_SSH_PRIVATE_KEY と STACKHERO_ENDPOINT は各 GitHub 環境で設定してください。
        ssh_private_key: ${{ secrets.STACKHERO_SSH_PRIVATE_KEY }}
        endpoint: ${{ vars.STACKHERO_ENDPOINT }}

ワークフローファイルを作成したら、次のようにコミットします:

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

本番ブランチを作成するには:

git checkout -b production

その後、変更を GitHub にプッシュします:

git push --set-upstream origin production

このプッシュにより、コードが production ブランチに送信され、GitHub Actions が Stackhero サービスへのデプロイを自動的に実行します。デプロイ状況を確認するには、GitHub プロジェクトで Actions をクリックしてください。

本番環境へデプロイした GitHub Actions本番環境へデプロイした GitHub Actions

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

ステージング環境のセットアップも本番環境とほぼ同じです。必要に応じて productionstaging に置き換えて、上記の手順を繰り返してください。

まず、ステージングブランチを作成します:

git checkout -b staging

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

git push --set-upstream origin staging

GitHub Actions により、staging ブランチが指定した Node.js サービスへ自動的にデプロイされます。

production および staging ブランチへの直接プッシュを防ぐため、これらのブランチを保護することを推奨します。開発ブランチからステージングブランチへのプルリクエストを作成し、ステージング環境で変更を検証した後、本番ブランチへマージする運用が理想的です。

このワークフローにより、認可されたコントリビューターのみがステージングや本番ブランチへプッシュできるようになり、新機能の本番公開前に追加のテスト工程を設けることができます。