チュートリアル:Azure Container Apps で Python Web アプリの継続的デプロイを構成する

この記事は、Azure Container Appsを に Python Web アプリをコンテナー化してデプロイする方法に関するチュートリアル シリーズの一部です。 Container Apps を使用すると、複雑なインフラストラクチャを管理することなく、コンテナー化されたアプリをデプロイできます。

このチュートリアルでは、次の操作を行います。

• GitHub Actions ワークフローを使用して、コンテナー アプリの継続的デプロイを構成します。
• サンプル リポジトリのコピーに変更を加えて、GitHub Actions ワークフローをトリガーします。
• 継続的デプロイの構成で発生する可能性がある問題のトラブルシューティングを行います。
• チュートリアル シリーズの終了時に不要なリソースを削除します。

継続的デプロイは、アプリ開発ワークフローの自動化である継続的インテグレーションと継続的デリバリー (CI/CD) の DevOps プラクティスに関連しています。

次の図は、このチュートリアルのタスクを示しています。

前提 条件

継続的デプロイを設定するには、次のものが必要です。

• 前のチュートリアルで作成したリソース (およびその構成) には、Azure Container Registry のインスタンスと、Azure Container Apps内のコンテナー アプリが含まれます。

• サンプル コード (Django または Flask) をフォークし、Azure Container Apps から接続できる GitHub アカウント。 (フォークではなくサンプル コードをダウンロードした場合は、ローカル リポジトリを GitHub アカウントにプッシュしてください)。

• 必要に応じて、開発環境に Git インストール してコードを変更し、GitHub のリポジトリにプッシュします。 または、GitHub で直接変更を行うことができます。

コンテナーの継続的デプロイを構成する

前のチュートリアルでは、Azure Container Apps でコンテナー アプリを作成して構成しました。 構成の一部は、Azure Container Registry インスタンスから Docker イメージをプルすることでした。 コンテナー イメージは、コンテナー リビジョンの作成時 (コンテナー アプリを初めて設定したときなど) にレジストリからプルされます。

このセクションでは、GitHub Actions ワークフローを使用して継続的デプロイを設定します。 継続的デプロイでは、トリガーに基づいて新しい Docker イメージとコンテナー リビジョンが作成されます。 このチュートリアルで説明しているトリガーは、リポジトリの メイン ブランチでの変更、例えばプル要求による変更です。 ワークフローがトリガーされると、新しい Docker イメージが作成され、Azure Container Registry インスタンスにプッシュされ、新しいイメージを使用してコンテナー アプリが新しいリビジョンに更新されます。

Azure CLI

Azure CLI コマンドは、Azure Cloud Shell 、または Azure CLI がインストール ワークステーションで実行できます。

Windows コンピューター上の Git Bash シェルでコマンドを実行している場合は、続行する前に次のコマンドを入力します。

export MSYS_NO_PATHCONV=1

1. az ad sp create-for-rbac コマンドを使用して、サービス プリンシパルを作成します。

   az ad sp create-for-rbac \
   --name <app-name> \
   --role Contributor \
   --scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"
   

   コマンド内で:

   • <アプリ名> は、サービス プリンシパルのオプションの表示名です。 --name オプションをオフにすると、表示名として GUID が生成されます。
   • <subscription-ID> は、Azure のサブスクリプションを一意に識別する GUID です。 サブスクリプション ID がわからない場合は、az account show コマンドを実行し、出力の id プロパティからコピーできます。
   • <resource-group-name> は、Azure Container Apps コンテナーを含むリソース グループの名前です。 ロールベースのアクセス制御 (RBAC) は、リソース グループ レベルにあります。 前のチュートリアルの手順に従った場合、リソース グループの名前は pythoncontainer-rg。

   次の手順のために、このコマンドの出力を保存します。 特に、クライアント ID (appId プロパティ)、クライアント シークレット (password プロパティ)、テナント ID (tenant プロパティ) を保存します。

2. az containerapp github-action add コマンドを使用して GitHub Actions を構成します。

   az containerapp github-action add \
   --resource-group <resource-group-name> \
   --name python-container-app \
   --repo-url <https://github.com/userid/repo> \
   --branch main \
   --registry-url <registry-name>.azurecr.io \
   --service-principal-client-id <client-id> \
   --service-principal-tenant-id <tenant-id> \
   --service-principal-client-secret <client-secret> \
   --login-with-github
   

   コマンド内で:

   • <リソース グループ名> は、リソース グループの名前です。 このチュートリアルでは、pythoncontainer-rgです。
   • <https://github.com/userid/repo> は、GitHub リポジトリの URL です。 このチュートリアルでは、https://github.com/userid/msdocs-python-django-azure-container-apps または https://github.com/userid/msdocs-python-flask-azure-container-appsです。 これらの URL では、userid は GitHub ユーザー ID です。
   • レジストリ名 は、前のチュートリアルで作成した既存の Azure Container Registry インスタンス、または使用できるインスタンスです。
   • <クライアント ID> は、前の az ad sp create-for-rbac コマンドの appId プロパティの値です。 ID は、00000000-0000-0000-0000-00000000フォームの GUID です。
   • <tenant-id> は、前の az ad sp create-for-rbac コマンドの tenant プロパティの値です。 ID は、クライアント ID に似た GUID でもあります。
   • <クライアント シークレット> は、前の az ad sp create-for-rbac コマンドの password プロパティの値です。

Azure portal

1. Azure portalで、継続的デプロイを構成するコンテナー アプリに移動します。 サービス メニューで、継続的デプロイを選択します。

   

2. Azure Container Apps が GitHub アカウントにアクセスすることを承認する:

   1. [Sign in with GitHub](GitHub アカウントでサインイン) を選択します。
   2. 承認ダイアログで、Authorize AzureAppService を選択します。

   

   ヒント

   アカウントのセキュリティ セクションから、GitHub アカウントへの Container Apps アクセスを取り消すことができます。

3. 継続的デプロイの詳細を構成します。

   • 組織の: GitHub ユーザー名を使用します。
   • リポジトリ: サンプル アプリのフォークを選択します。 (最初にサンプル コードを開発者環境にダウンロードした場合は、リポジトリを GitHub にプッシュします)。
   • [ブランチ]: main を選択します。
   • リポジトリ のソース: Azure Container Registry を選択します。
   • レジストリ: 前のチュートリアルで作成した Azure Container Registry インスタンスを選択します。
   • イメージ: Docker イメージ名を選択します。 このチュートリアルでは、python-container-app。
   • [サービス プリンシパル]: [新規作成] のままにし、作成プロセスで新しいサービス プリンシパルを作成できるようにします。

   [Start continuous deployment] (継続的デプロイの開始) を選択して構成を完了します。

   

4. 継続的デプロイに関する情報を確認します。

   この情報には、作成された GitHub Actions ワークフロー ファイルへのリンクが含まれています。 Azure Container Apps がファイルをあなたのリポジトリにチェックインしました。

   

継続的デプロイの構成では、サービス プリンシパル によって、GitHub Actions が Azure リソースにアクセスして変更できるようになります。 サービス プリンシパルに割り当てられたロールは、リソースへのアクセスを制限します。 サービス プリンシパルには、コンテナー アプリを含むリソース グループに対する組み込みの 共同作成者 ロールが割り当てられました。

ポータルの手順に従うと、サービス プリンシパルが自動的に作成されます。 Azure CLI の手順に従った場合は、継続的デプロイを構成する前にサービス プリンシパルを明示的に作成しました。

GitHub Actions を使用して Web アプリを再デプロイする

このセクションでは、サンプル リポジトリのフォークされたコピーを変更します。 その後、変更が Web サイトに自動的にデプロイされることを確認できます。

まだ作成していない場合は、サンプル リポジトリの フォーク を作成します (Django または Flask)。 GitHub または開発環境で直接、Git を使用してコマンド ラインからコードを変更できます。

GitHub

1. サンプル リポジトリのフォークに移動し、"メイン" ブランチから開始します。

   

2. 変更を加えます。

   1. /templates/base.html ファイルに移動します。 (Django の場合、パスは restaurant_review/templates/restaurant_review/base.html です)。
   2. [編集] を選択し、フレーズ Azure Restaurant Review を Azure Restaurant Review - Redeployed に変更します。

   

3. 編集中のページの下部で、[メイン ブランチに直接コミットする] が選択されていることを確認します。 次に、[変更のコミット]ボタンを選択します。

   

コミットによって GitHub Actions ワークフローが開始されます。

コマンド ライン

まだ行っていない場合は、git clone を使用してフォークされたリポジトリを開発環境にプルし、ディレクトリをリポジトリに変更します。 次に、次の手順を実行します。

1. main で開始します。

   git checkout main
   git pull
   

2. 変更を加えます。

   ./templates/base.html ファイル (Django の./restaurant_review/templates/restaurant_review/base.html) に移動し、フレーズ Azure Restaurant Review を Azure Restaurant Review - Redeployedに変更します。

3. 変更をコミットして GitHub にプッシュします。

   git commit -a -m "Redeploy with title change."
   git push
   

Git を初めて使用するときは、グローバル変数の user.name と user.emailの設定が必要になる場合があります。 詳細については、git-configの ヘルプを参照してください。

メイン ブランチへの変更のプッシュにより、GitHub Actions ワークフローが開始されます。

手記

このチュートリアルでは、メイン ブランチを直接変更する方法を示しています。 一般的なソフトウェアワークフローでは、 メイン以外のブランチ で変更を行い、その変更をメインにマージするためのプルリクエスト を作成します。 プル要求もワークフローを開始します。

GitHub Actions について

ワークフロー履歴の表示

ワークフロー履歴を表示する必要がある場合は、次のいずれかの手順を使用します。

GitHub

GitHubで、サンプル リポジトリのフォークに移動し、Actions タブを開きます。

コマンド ライン

これらの手順では、GitHub CLIを使用します。

1. ワークフローの概要を取得します。 複製を含むフォルダーで次のコマンドを実行します。

   gh workflow view
   

   このコマンドを実行すると、ワークフローを選択するように求められた後、そのワークフローの最近の実行の概要が表示されます。

   手記

   ghを初めて使用する場合は、認証を求められる場合があります。 GitHub CLI プロンプトに従って認証します。

   複数のリモートを構成している場合は、gh repo set-default を実行して既定のリモート リポジトリを選択するように求められる場合があります。 表示されたオプションからフォークを選択します。

   --repo [HOST/]OWNER/REPO パラメーターを追加することで、既定のリポジトリを設定しなくても、任意のフォルダーから gh workflow view コマンドを実行できます。

2. ワークフロー実行の詳細については、GitHub を参照してください。

   gh workflow view --web
   

ワークフロー シークレット

リポジトリに追加された .github/workflows/<ワークフロー名>.yml ワークフロー ファイルには、ワークフローのビルドおよびコンテナー アプリの更新ジョブに必要な資格情報のプレースホルダーが含まれています。 資格情報情報は、リポジトリの [設定] 領域の [セキュリティシークレットと変数 ][アクション]の下に暗号化されて格納されます。

資格情報情報が変更された場合は、ここで更新できます。 たとえば、Azure Container Registry パスワードを再生成する場合は、REGISTRY_PASSWORD 値を更新する必要があります。 詳細については、GitHub ドキュメントの 暗号化されたシークレット を参照してください。

OAuth によって承認されたアプリ

継続的デプロイを設定するときは、GitHub アカウントの承認された OAuth アプリとして Azure Container Apps を指定します。 Container Apps では、承認されたアクセスを使用して、.github/workflows/<workflow-name>.ymlで GitHub Actions YAML ファイルを作成します。 [統合]>[アプリケーション]で、承認されたアプリを表示し、アカウントのアクセス許可を取り消すことができます。

トラブルシューティング

Azure CLI を使用してサービス プリンシパルを設定しているときにエラーが発生する

このセクションは、Azure CLI az ad sp create-for-rba コマンドを使用して、サービス プリンシパルの設定中に発生するエラーのトラブルシューティングに役立ちます。

"InvalidSchema: 接続アダプターが見つかりませんでした" というエラーが表示された場合:

• 実行しているシェルを確認します。 Bash シェルを使用している場合は、MSYS_NO_PATHCONV 変数を export MSYS_NO_PATHCONV=1として設定します。

  詳細については、Git Bash シェルから Azure CLI でサービス プリンシパルを作成できない GitHub の問題を参照してください。

"複数のアプリケーションが同じ表示名を持つ" というエラーが表示される場合:

• サービス プリンシパルの名前は既に取得されています。 別の名前を選択するか、--name 引数を省略します。 GUID は表示名として自動的に生成されます。

GitHub Actions ワークフローに失敗しました

ワークフローの状態を確認するには、リポジトリの [アクション] タブに移動します。

• 失敗したワークフローがある場合は、ワークフロー ファイルの詳細を確認します。 ビルドとデプロイという 2 つのジョブが必要です。 失敗したジョブの場合は、ジョブのタスクの出力を調べて問題を探します。
• "TLS ハンドシェイク タイムアウト" を含むエラー メッセージがある場合は、ワークフローを手動で実行します。 リポジトリの [アクション] タブで、[自動デプロイのトリガー] を選択して、タイムアウトが一時的な問題であるかどうかを確認します。
• このチュートリアルに示すようにコンテナー アプリの継続的デプロイを設定すると、ワークフロー ファイル (.github/workflows/<workflow-name>.yml) が自動的に作成されます。 このチュートリアルでは、このファイルを変更する必要はありません。 変更した場合は、変更を元に戻し、ワークフローを試してください。

メイン ブランチでマージした変更が Web サイトに表示されない

GitHub で次の手順を実行します。

• GitHub Actions ワークフローが実行されていること、およびワークフローをトリガーするブランチに変更をチェックインしたことを確認します。

Azure portal で次の手順を実行します。

• Azure Container Registry インスタンスを調べて、ブランチに変更した後にタイムスタンプを使用して新しい Docker イメージが作成されたかどうかを確認します。

• コンテナー アプリのログを調べて、プログラミング エラーがあるかどうかを確認します。

  1. コンテナー アプリに移動し、リビジョン管理><アクティブなコンテナー>>リビジョンの詳細>コンソール ログに移動します。
  2. 列の表示順序を選択して、生成時刻、Stream_s、および Log_sを設定します。
  3. 最新のログを並べ替え、Stream_s 列で Python stderr と stdout メッセージを探します。 Python の print 出力は stdout メッセージです。

Azure CLI で次の手順を実行します。

• az containerapp logs show コマンドを使用します。

継続的デプロイを停止したい

継続的デプロイを停止するということは、コンテナー アプリをリポジトリから切断することを意味します。

Azure portal で次の手順を実行します。

• コンテナー アプリに移動します。 サービスメニューで、[継続的デプロイ] を選択し、[切断] を選択します。

Azure CLI で次の手順を実行します。

• az container app github-action remove コマンドを使用します。

切断した後:

• .github/workflows/<workflow-name>.yml ファイルがリポジトリから削除されます。
• シークレット キーはリポジトリから削除されません。
• Azure Container Apps は、GitHub アカウントの承認された OAuth アプリとして残ります。
• Azure では、コンテナーは最後にデプロイされたコンテナーのままにされます。 新しいコンテナー リビジョンが最新のイメージを取得できるように、コンテナー アプリを Azure Container Registry インスタンスに再接続できます。
• Azure では、継続的デプロイに作成して使用したサービス プリンシパルは削除されません。

リソースの削除

チュートリアル シリーズを使い終えて、追加のコストを発生させたくない場合は、使用したリソースを削除します。

リソース グループを削除すると、グループ内のすべてのリソースが削除され、リソースを最も簡単に削除できます。 リソース グループを削除する方法の例については、「Containerize tutorial cleanup」を参照してください。

関連コンテンツ

このチュートリアルを基に構築する場合は、次の手順を実行できます。

• Azure Container Apps でスケーリング 規則を設定する
• Azure Container Apps でカスタム ドメイン名と証明書をバインドする
• Azure Container Apps でアプリを監視する