Python: GitHub Actions でデプロイする

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

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

Stackhero は、デプロイ作業を効率化するために設計された、すぐに使える Python クラウドソリューションを提供しています：

シンプルな git push だけで、数秒でアプリケーションを本番環境にデプロイできます。

ご自身のドメイン名を利用可能で、HTTPS 証明書の自動設定により安全な接続も自動で管理されます。

自動バックアップ、ワンクリックアップデート、予測可能な料金体系により、インフラ管理ではなくコードに集中できます。

プライベートかつ専用インフラ上で、強力なパフォーマンスとセキュリティを実現。お客様の環境は分離され、保護されています。

時間を節約し、ワークフローをシンプルに：Stackhero の Python クラウドホスティングなら、わずか 5分でコードを稼働させることができます。

GitHub Actions を利用すると、Python コードの本番サーバーへのデプロイを含む様々なタスクを自動化できます。

このガイドでは、GitHub Actions を安全かつ信頼性高く設定し、Python コードをステージング環境と本番環境の両方にデプロイする方法を解説します。

運用を整理するために、staging と production の2つのブランチを使用します。これらのブランチにコードを push するたびに、対応する Stackhero インスタンスへ自動的にデプロイされます。

ステージングインスタンスの用意は必須ではありません。このガイドに従い、本番インスタンスのみで運用することも可能です。ただし、スムーズなデプロイと本番環境への安心したリリースのためには、ステージングと本番の両インスタンスを維持することを強く推奨します。この運用は業界標準であり、多くの問題を未然に防ぐ堅実なアプローチです。

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

Python サービスの作成

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

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

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

SSH キーの設定

SSH キーは、GitHub Actions が安全に Python サービスへ接続し、コードをデプロイするために必要です。このステップは Stackhero サービスの保護において非常に重要です。

ローカル環境で新しい SSH キーを生成するには、以下のコマンドを実行します：

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

公開鍵の登録

まず、生成した公開鍵を表示します：

cat /tmp/ssh_key.pub

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

サービス設定の取得

以下の手順に従ってください：

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

公開鍵の追加

秘密鍵の登録

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 をクリックします。

シークレットの追加

先ほど生成した秘密鍵を表示します：

cat /tmp/ssh_key

シークレットの設定では、Name に STACKHERO_SSH_PRIVATE_KEY、Value に秘密鍵を貼り付けてください。

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

続いて、Environment variables セクションで Add variable をクリックします。

変数の設定

Name に STACKHERO_ENDPOINT を入力し、Value には Stackhero ダッシュボードで確認できる Python サービスのエンドポイントを貼り付けます。

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

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

生成したキーの削除

セキュリティのため、これらの SSH キーはもう必要ありませんので、ローカルから削除しておきましょう：

rm /tmp/ssh_key /tmp/ssh_key.pub

GitHub Actions ワークフローの設定

リポジトリ内に .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:
    # 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

これで、production ブランチが GitHub に push され、GitHub Actions がトリガーされて Stackhero インスタンスへコードがデプロイされます。

デプロイ状況を確認するには、GitHub プロジェクトページで Actions をクリックしてください。

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

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

ステージング環境の作成

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

環境の設定後、以下のようにしてステージングブランチを作成できます：

git checkout -b staging

その後、ステージングブランチを GitHub に push します：

git push --set-upstream origin staging

これで、ステージングブランチが指定した Python インスタンスに自動的にデプロイされます。

さらに進んだ運用

production および staging ブランチへの直接 push を防ぐため、これらのブランチを保護することをおすすめします。この構成では、チームメンバーは staging ブランチへのプルリクエストを作成し、適切な権限を持つユーザーがレビュー・マージする必要があります。ステージング環境で変更が検証された後、認可された担当者が production ブランチへマージできます。

このワークフローにより、承認済みの変更のみが本番環境に反映されるとともに、新機能を本番公開前にステージングでテストできるため、信頼性も向上します。