この記事では、GitHub Actions の継続的インテグレーションおよび継続的デリバリー (CI/CD) プラットフォームを使用して、Python Web アプリを Azure App Service on Linux にデプロイする方法について説明します。 GitHub Actions ワークフローでは、リポジトリへのコミットが発生するたびに、コードが自動的にビルドされ、App Service インスタンスにデプロイされます。 テスト スクリプト、セキュリティ チェック、マルチステージのデプロイなど、GitHub Actions ワークフローに他の自動化を追加できます。
アプリ コードのリポジトリを作成する
この記事の手順を完了するには、GitHub リポジトリにコミットされた Python Web アプリが必要です。
既存のアプリ: 既存の Python Web アプリを使用するには、アプリが GitHub リポジトリにコミットされていることを確認します。
新しいアプリ: 新しい Python Web アプリが必要な場合は、 https://github.com/Microsoft/python-sample-vscode-flask-tutorial GitHub リポジトリをフォークして複製できます。 このサンプル コードでは、 Visual Studio Code の Flask チュートリアルをサポートし、機能する Python アプリケーションを提供します。
注
アプリで Django と SQLite データベースを使用している場合、これらの手順では機能しません。 SQLite は、ローカルファイルベースのストレージ制限のため、ほとんどのクラウドホスト環境ではサポートされていません。 PostgreSQL や Azure Cosmos DB などのクラウドと互換性のあるデータベースに切り替えることを検討してください。 詳細については、この記事で後述する Django の考慮事項を確認 するを参照してください。
ターゲット App Service インスタンスを作成する
App Service インスタンスを作成する最も簡単な方法は、対話型の Azure Cloud Shell を介して Azure コマンド ライン インターフェイス (CLI) を使用することです。 Cloud Shell には、 Git と Azure CLI が含まれています。 次の手順では、 az webapp up コマンドを使用して、App Service インスタンスを作成し、アプリの初期デプロイを行います。
Azure Portal ( https://portal.azure.com ) にサインインします。
ポータルのツール バーで Cloud Shell オプションを選択して、Azure CLI を開きます。
Cloud Shell で、ドロップダウン メニューから Bash オプションを選択します。
Cloud Shell で、git clone コマンドを使用してリポジトリを 複製 します。
ヒント
コマンドまたはテキストを Cloud Shell に貼り付けるには、 Ctrl+Shift+V キーボード ショートカットを使用するか、右クリックしてコンテキスト メニューから [貼り付け ] を選択します。
Flask サンプル アプリの場合は、次のコマンドを使用できます。
<github-user>部分を、リポジトリをフォークした GitHub アカウントの名前に置き換えます。git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.gitアプリが別のリポジトリにある場合は、特定のリポジトリの GitHub Actions を設定します。
<github-user>部分を、リポジトリをフォークした GitHub アカウントの名前に置き換え、実際のリポジトリ名を<repo-name>プレースホルダーに指定します。git clone https://github.com/<github-user>/<repo-name>.git
注
Cloud Shell は、cloud-shell-storage-<your-region> という名前のリソース グループ内の Azure Storage アカウントによってサポートされます。 そのストレージ アカウントには、複製されたリポジトリを格納する Cloud Shell ファイル システムのイメージが含まれています。 このストレージには少額のコストがかかります。 この記事を完了した後、作成した他のリソースと共にストレージ アカウントを削除できます。
Cloud Shell で、Python アプリのリポジトリ フォルダーにディレクトリを変更し、 az webapp up コマンドでアプリが Python として認識されるようにします。 Flask サンプル アプリの場合は、次のコマンドを使用します。
cd python-sample-vscode-flask-tutorialCloud Shell で、 az webapp up コマンドを使用して App Service インスタンスを作成し、アプリの初期デプロイを行います。
az webapp up --name <app-service-name> --runtime "PYTHON:3.9"<app-service-name>プレースホルダーには、Azure で一意の App Service 名を指定します。 名前の長さは 3 ~ 60 文字にする必要があり、文字、数字、ハイフンのみを使用できます。 名前の先頭は文字、末尾は文字または数字にする必要があります。システムで使用可能なランタイムの一覧については、
az webapp list-runtimesコマンドを使用します。コマンドにランタイム値を入力するときは、
PYTHON:X.Y形式を使用します。ここで、X.Yは Python のメジャー バージョンとマイナー バージョンです。--locationパラメーターを使用して、App Service インスタンスのリージョンの場所を指定することもできます。 使用可能な場所の一覧については、az account list-locations --output tableコマンドを使用します。
アプリにカスタム スタートアップ スクリプトがある場合は、 az webapp config コマンドを使用してスクリプトを開始します。
アプリにカスタム スタートアップ スクリプトがない場合は、次の手順に進みます。
Flask サンプル アプリの場合は、次のコマンドを実行して 、startup.txt ファイル内のスタートアップ スクリプトにアクセスする必要があります。
az webapp config set \ --resource-group <resource-group-name> \ --name <app-service-name> \ --startup-file startup.txtリソース グループ名と App Service インスタンス名を
<resource-group-name>と<app-service-name>プレースホルダーに指定します。 リソース グループ名を見つけるには、前のaz webapp upコマンドからの出力を確認します。 リソース グループ名には、azure アカウント名の後に _rg サフィックス <azure-account-name>_rg_ が含まれます。
実行中のアプリを表示するには、ブラウザーを開き、App Service インスタンスのデプロイ エンドポイントに移動します。 次の URL で、
<app-service-name>プレースホルダーを App Service インスタンス名に置き換えます。http://<app-service-name>.azurewebsites.net汎用ページが表示される場合は、App Service インスタンスが起動するまで数秒待ってから、ページを更新します。
- 汎用ページが引き続き表示される場合は、正しいフォルダーから展開したことを確認します。
- Flask サンプル アプリの場合は、 python-sample-vscode-flask-tutorial フォルダーからデプロイしたことを確認します。 また、スタートアップ コマンドが正しく設定されていることを確認します。
App Service で継続的デプロイを設定する
次の手順では、継続的デリバリー (CD) を設定します。これは、ワークフローがトリガーされるたびに新しいコード展開が行われることを意味します。 この記事の例のトリガーは、プル要求 (PR) など、リポジトリの メイン ブランチに対する変更です。
Cloud Shell で、システム (
~) のルート ディレクトリにいることを確認し、python-sample-vscode-flask-tutorial などのアプリ サブフォルダーにいないことを確かめてください。az webapp deployment github-actions add コマンドを使用して GitHub Actions を追加します。 プレースホルダーを特定の値に置き換えます。
az webapp deployment github-actions add \ --repo "<github-user>/<github-repo>" \ --resource-group <resource-group-name> \ --branch <branch-name> \ --name <app-service-name> \ --login-with-github--login-with-githubパラメーターは、対話型メソッドを使用して個人用アクセス トークンを取得します。 プロンプトに従って認証を完了します。同じ App Service インスタンス名を持つ既存のワークフロー ファイルがシステムで検出された場合は、プロンプトに従ってワークフローを上書きするかどうかを選択します。 コマンドで
--forceパラメーターを使用すると、競合するワークフローを自動的に上書きできます。
addコマンドは、次のタスクを完了します。- リポジトリの .github/workflows/<workflow-name>.yml パスに新しいワークフロー ファイルを作成します。 ファイル名には、App Service インスタンスの名前が含まれています。
- App Service インスタンスのシークレットを含む発行プロファイルを取得し、それを GitHub アクションシークレットとして追加します。 シークレットの名前は 、AZUREAPPSERVICE_PUBLISHPROFILE_で始まります。 このシークレットはワークフロー ファイルで参照されます。
az webapp deployment source show コマンドを使用して、ソース管理デプロイ構成の詳細を取得します。 プレースホルダー パラメーターを特定の値に置き換えます。
az webapp deployment source show \ --name <app-service-name> \ --resource-group <resource-group-name>コマンド出力で、
repoUrlプロパティとbranchプロパティの値を確認します。 これらの値は、addコマンドで指定した値と一致する必要があります。
GitHub のワークフローとアクションを調べる
ワークフロー定義は、リポジトリの /.github/workflows/ パスの YAML (.yml) ファイルで指定されます。 この YAML ファイルには、GitHub リポジトリに関連付けられている自動化されたプロセスであるワークフローを構成するさまざまな手順とパラメーターが含まれています。 ワークフローを使用して、GitHub 上の任意のプロジェクトをビルド、テスト、パッケージ化、リリース、デプロイできます。
各ワークフローは 1 つ以上のジョブで構成され、各ジョブは一連のステップです。 各ステップは、シェル スクリプトまたはアクションです。 各ジョブには、ワークフロー ファイルに Action セクションがあります。
Azure App Service へのデプロイ用に Python コードを使用して設定されたワークフローに関しては、ワークフローには次のアクションがあります。
| アクション | 説明 |
|---|---|
| チェックアウト | GitHub Actions エージェントであるランナーのリポジトリを確認します。 |
| setup-python | ランナーに Python をインストールします。 |
| アプリサービスビルド | Web アプリを作成します。 |
| webapps-deploy | 発行プロファイル資格情報を使用して Web アプリをデプロイし、Azure で認証します。 資格情報は GitHub シークレットに格納されます。 |
ワークフローの作成に使用されるワークフロー テンプレートは 、Azure/actions-workflow-samples です。
ワークフローは、指定されたブランチへのプッシュ イベントでトリガーされます。 イベントと分岐は、ワークフロー ファイルの先頭で定義されます。 たとえば、次のコード スニペットは、 メイン ブランチへのプッシュ イベントでワークフローがトリガーされていることを示しています。
on:
push:
branches:
- main
OAuth によって承認されたアプリ
継続的デプロイを設定するときは、GitHub アカウントの承認された OAuth アプリとして Azure App Service を承認します。 App Service では、承認されたアクセスを使用して、リポジトリの .github/workflows/<workflow-name>.yml パスに GitHub アクション YAML ファイルを作成します。
GitHub アカウントで承認されたアプリを表示し、アクセス許可を取り消すには、[設定>Integrations/Applications] に移動します。
ワークフロー発行プロファイルのシークレット
リポジトリに追加された .github/workflows/<workflow-name>.yml ワークフロー ファイルには、ワークフローのデプロイ ジョブに必要な発行プロファイル資格情報のプレースホルダーがあります。 発行プロファイル情報は、リポジトリに暗号化されて格納されます。
シークレットを表示するには、 設定>Security>Secret と変数>Actions に移動します。
この記事では、GitHub アクションが発行プロファイル資格情報を使用して認証されます。 サービス プリンシパルや OpenID Connect など、認証には他にも方法があります。 詳細については、「 GitHub Actions を使用して App Service にデプロイする」を参照してください。
ワークフローの実行とテスト
最後の手順では、リポジトリに変更を行ってワークフローをテストします。
ブラウザーで、サンプル リポジトリ (または使用したリポジトリ) のフォークに移動し、トリガーの一部として設定したブランチを選択します。
Python Web アプリを少し変更します。
Flask チュートリアルでは、簡単な変更を次に示します。
- トリガー ブランチの /hello-app/templates/home.html ファイルに移動します。
- [ 編集] (鉛筆) を選択します。
- エディターで、print
<p>ステートメントを見つけて、"Redeployed!" というテキストを追加します。
作業中のブランチに変更を直接コミットします。
- エディターで、右上にある [ 変更のコミット ] を選択します。 [ 変更のコミット] ウィンドウが開きます。
- [ 変更のコミット ] ウィンドウで、必要に応じてコミット メッセージを変更し、[ 変更のコミット] を選択します。
コミット プロセスによって GitHub Actions ワークフローがトリガーされます。
ワークフローを手動でトリガーすることもできます。
継続的デプロイ用に設定されたリポジトリの [アクション] タブに移動します。
ワークフローの一覧でワークフローを選択し、[ワークフローの 実行] を選択します。
失敗したワークフローのトラブルシューティング
ワークフローの状態は、アプリ リポジトリの [アクション] タブで確認できます。 この記事で作成したワークフロー ファイルを調べると、 ビルド とデプロイという 2 つのジョブが表示 されます。 このワークフローは、 Azure/actions-workflow-samples テンプレートに基づいています。
失敗したジョブの場合は、ジョブタスクの出力を確認して、失敗の兆候を探してください。
調査する一般的な問題を次に示します。
依存関係がないためにアプリが失敗した場合、 requirements.txt ファイルはデプロイ中に処理されませんでした。 この動作は、この記事に示すように、
az webapp upコマンドを使用するのではなく、ポータルで直接 Web アプリを作成した場合に発生します。ポータルを使用してアプリ サービスをプロビジョニングした場合、ビルド アクションの
SCM_DO_BUILD_DURING_DEPLOYMENT設定が設定されていない可能性があります。 この設定はtrueに設定する必要があります。az webapp upコマンドは、ビルド アクションを自動的に設定します。"TLS ハンドシェイク タイムアウト" に関するエラー メッセージが表示された場合は、アプリ リポジトリの [アクション] タブで [自動デプロイのトリガー] を選択して、ワークフローを手動で実行します。 タイムアウトが一時的な問題であるかどうかを判断できます。
この記事に示すようにコンテナー アプリの継続的デプロイを設定すると、初期ワークフロー ファイル .github/workflows/<workflow-name>.yml が自動的に作成されます。 ファイルを変更した場合は、変更を削除して、エラーの原因かどうかを確認します。
配置後スクリプトを実行する
デプロイ後スクリプトでは、アプリ コードで想定される環境変数の定義など、いくつかのタスクを実行できます。 アプリ コードの一部としてスクリプトを追加し、スタートアップ コマンドを使用してスクリプトを実行します。
ワークフロー YAML ファイルで変数値をハードコーディングしないようにするには、GitHub で変数を構成し、スクリプト内の変数名を参照することを検討してください。 暗号化されたシークレットは、リポジトリまたは環境 (アカウント リポジトリ) 用に作成できます。 詳細については、「 GitHub Actions でのシークレットの使用」を参照してください。
Django に関する考慮事項を確認する
この記事で前述したように、別のデータベースを使用する場合は、GitHub Actions を使用して Django アプリを Azure App Service on Linux にデプロイできます。 App Service は db.sqlite3 ファイルをロックするため、SQLite データベースを使用できません。これにより、読み取りと書き込みの両方が禁止されます。 この動作は、外部データベースには影響しません。
App Service での Python アプリの構成 - コンテナーのスタートアップ プロセスに関する記事では、App Service がアプリ コード内の wsgi.py ファイル (通常はアプリ オブジェクトを含む) を自動的に検索する方法について説明します。 webapp config set コマンドを使用してスタートアップ コマンドを設定した場合は、--startup-file パラメーターを使用して、アプリ オブジェクトを含むファイルを指定しました。 webapp config set コマンドは、webapps-deploy アクションでは使用できません。 代わりに、 startup-command パラメーターを使用してスタートアップ コマンドを指定できます。 たとえば、次のコードは、ワークフロー ファイルでスタートアップ コマンドを指定する方法を示しています。
startup-command: startup.txt
Django を使用する場合は、通常、アプリ コードのデプロイ後に python manage.py migrate コマンドを使用してデータ モデルを移行します。 デプロイ後スクリプトで migrate コマンドを実行できます。
GitHub Actions の切断
App Service インスタンスから GitHub Actions を切断すると、アプリのデプロイを再構成できます。 切断後のワークフロー ファイルの動作と、ファイルを保存または削除するかどうかを選択できます。
次の Azure CLI az webapp deployment github-actions remove コマンドを使用して、GitHub Actions を切断 します。 プレースホルダーを特定の値に置き換えます。
az webapp deployment github-actions remove \
--repo "<github-username>/<github-repo>" \
--resource-group <resource-group-name> \
--branch <branch-name> \
--name <app-service-name> \
--login-with-github
リソースをクリーンアップする
この記事で作成した Azure リソースに料金が発生しないようにするには、App Service インスタンスと App Service プランを含むリソース グループを削除します。
Azure Cloud Shell を含め、Azure CLI がインストールされている任意の場所で、 az group delete コマンドを使用してリソース グループを削除できます。
az group delete --name <resource-group-name>
ストレージ アカウントの削除
少額の月額料金が発生する Cloud Shell のファイル システムを維持するストレージ アカウントを削除するには、 cloud-shell-storage で始まるリソース グループを削除します。 グループの唯一のユーザーである場合は、リソース グループを削除しても安全です。 他のユーザーがいる場合は、リソース グループ内のストレージ アカウントを削除できます。
GitHub アカウントとリポジトリを更新する
Azure リソース グループを削除する場合は、継続的デプロイ用に接続された GitHub アカウントとリポジトリに次の変更を行うことを検討してください。
- アプリ リポジトリで、 .github/workflows/<workflow-name>.yml ファイルを削除します。
- アプリ リポジトリの設定で、ワークフロー用に作成された AZUREAPPSERVICE_PUBLISHPROFILE_ 秘密鍵を削除します。
- GitHub アカウントの設定で、GitHub アカウントの承認された Oauth アプリとして Azure App Service を削除します。