Ruby: GitHub Actions でデプロイする

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

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

Stackheroは、数多くの利点を提供する、すぐに使えるRubyクラウドソリューションを提供しています。

シンプルなgit pushでアプリケーションを数秒でデプロイ。

独自のドメイン名を使用し、HTTPS証明書の自動設定による強化されたセキュリティを享受。

自動バックアップ、ワンクリック更新、そしてシンプルで透明性があり、予測可能な価格設定で安心を提供。

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

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

GitHub Actions を利用すると、Ruby コードを本番サーバーへデプロイするなどのタスクを自動化できます。手動での作業は一切不要です。

このガイドでは、GitHub Actions を安全かつ信頼性高く設定し、Ruby コードをステージング環境と本番環境の両方へ自動デプロイする方法をご紹介します。この方法により、デプロイの一貫性が保たれ、エラーのリスクも低減できます。

まず、GitHub リポジトリで staging と production の2つのブランチを用意します。これらのブランチにコードを push するたびに、対応する Stackhero インスタンスへ自動的にデプロイされます。

ステージングインスタンスの用意は必須ではありません。このガイドは本番インスタンスのみでも進められますが、ステージングと本番の両方の環境を構築することを強く推奨します。これは業界のベストプラクティスであり、本番ユーザーに影響が及ぶ前に問題を検出できます。

始める前に、GitHub アカウントと Ruby コードが格納されたリポジトリを用意してください。

Ruby サービスの作成

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

まだ Stackhero アカウントをお持ちでない場合数分で無料登録でき、その後すぐに Ruby クラウドサービスを数クリックで作成できます。

本番・ステージングサービスの例

SSH キーの設定

GitHub Actions からコードをデプロイできるようにするには、SSH キーを設定する必要があります。これにより、認可されたアクションのみが Stackhero サービスへ接続でき、デプロイのセキュリティが確保されます。

以下のコマンドで新しい SSH キーペアをローカルで生成します：

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

公開鍵の登録

次に、作成した公開鍵を取得します：

cat /tmp/ssh_key.pub

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

その後、

SSH public keys の下で Add a public key をクリックします。
Description には GitHub Action と入力します。
Key には、先ほど取得した公開鍵の内容を貼り付けます。

サービス設定の取得

秘密鍵の登録

次に、GitHub のウェブサイトでプロジェクトを開きます。

Settings > Environments へ進み、New environment をクリックします。 GitHub 環境の設定

環境名を「production」として保存します。環境の設定

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

Add deployment branch or tag rule をクリックし、パターンに「production」と入力してルールを追加します。環境ブランチの設定環境ブランチの設定

SSH 秘密鍵を安全に保存するため、Environment secrets で Add secret をクリックします。シークレットの追加

ローカルで秘密鍵を取得します：

cat /tmp/ssh_key

Name には STACKHERO_SSH_PRIVATE_KEY、Value には秘密鍵の内容を貼り付けます。 SSH 秘密鍵シークレットの設定

続いて、Ruby サービスのエンドポイントを環境変数として追加します。Environment variables で Add variable をクリックします。変数の設定

Name には STACKHERO_ENDPOINT、Value には Stackhero ダッシュボードで確認できる Ruby サービスのエンドポイントを入力します。エンドポイント変数の設定

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

生成したキーの削除

Stackhero および GitHub へのキー登録が完了したら、セキュリティのためローカルのキーを削除してください。

rm /tmp/ssh_key /tmp/ssh_key.pub

GitHub Actions ワークフローの設定

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

# ファイル: .github/workflows/deploy-to-stackhero.yml

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

on:
  push:
    # git 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 の「Settings」/「Environments」で該当ブランチの環境に設定してください。
        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 へ push します。

git push --set-upstream origin production

この最後の git push で、コードが GitHub の production ブランチにアップロードされます。GitHub Actions が自動的に起動し、Stackhero インスタンスへコードがデプロイされます。

ワークフローの実行状況は、プロジェクトの GitHub ページで Actions をクリックして確認できます。本番環境へデプロイされた GitHub Actions

これで、GitHub Actions を使った本番環境への継続的デプロイが構築できました。

ステージング環境の作成

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

ステージング環境の設定が完了したら、ステージングブランチを作成します。

git checkout -b staging

ステージングブランチを GitHub へ push します。

git push --set-upstream origin staging

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

さらに進んだ運用

デプロイの安全性を高めるために、production および staging ブランチの保護をおすすめします。これにより、直接 push できなくなり、変更は必ずプルリクエスト経由となります。適切な権限を持つチームメンバーが staging へのプルリクエストをレビュー・承認し、問題なければ同様に production へマージできます。

このワークフローを採用することで、セキュリティ（認可されたユーザーのみが staging や production へデプロイ可能）と信頼性（新機能は必ずステージングで検証されてから本番へ反映）が向上します。これにより、スムーズなデプロイと安定した本番環境を維持できます。