Share via

Azure Container Apps で Python Web アプリの継続的デプロイを構成する

  • [アーティクル]

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

チュートリアルのこの部分では、コンテナー アプリの継続的デプロイまたはデリバリー (CD) を構成する方法について説明します。 CD は、アプリ開発ワークフローの自動化である継続的インテグレーションと継続的デリバリー (CI/CD) の DevOps プラクティスの一部です。 具体的には、継続的デプロイに GitHub Actions を使用します。

このサービス図では、この記事で説明するコンポーネント (CI/CD の構成) が強調表示されています。

A screenshot of the services in the Tutorial - Deploy a Python App on Azure Container Apps. Sections highlighted are parts related to continuous integration - continuous delivery (CI/CD).

前提条件

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

  • このチュートリアル シリーズの前回の記事で作成したリソースとその構成には、Azure Container Registry と Azure Container Apps の コンテナー アプリが含まれています。

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

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

コンテナーの CD を構成する

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

このセクションでは、GitHub Actions ワークフローを使用して継続的デプロイをセットアップします。 継続的デプロイでは、トリガーに基づいて新しい Docker イメージとコンテナーのリビジョンが作成されます。 このチュートリアルでのトリガーは、pull request (PR) など、リポジトリの "メイン" ブランチに対する変更です。 トリガーされると、ワークフローで新しい Docker イメージが作成され、それが Azure Container Registry にプッシュされて、新しいイメージでコンテナー アプリが新しいリビジョンに更新されます。

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>"

ここで:

  • <app-name> は、サービス プリンシパルのオプションの表示名です。 --name オプションを省略すると、表示名として GUID が生成されます。
  • <subscription-ID> は、Azure でサブスクリプションを一意に識別する GUID です。 サブスクリプション ID がわからない場合は、az account show コマンドを実行すると、出力の id プロパティからお使いのサブスクリプション 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

ここで:

  • <resource-group-name> はリソース グループの名前です。 このチュートリアルに沿う場合は、"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; のいずれかになります。ここで、userid は GitHub ユーザー ID です。
  • <registry-name> は、このチュートリアル用に作成した既存のコンテナー レジストリ、または使用できるレジストリです。
  • <client-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 です。
  • <client-secret> は、前の az ad sp create-for-rbac コマンドの password プロパティの値です。

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

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

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

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

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

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

Screenshot showing a fork of the sample repo and starting in the main branch.

ステップ 2. 変更を加えます。

  • /templates/base.html ファイルに移動します。 (Django の場合、パスは restaurant_review/templates/restaurant_review/base.html です)。
  • [編集] を選択し、"Azure Restaurant Review" という語句を "Azure Restaurant Review - Redeployed" に変更します。

Screenshot showing how to make a change in a template file in the fork of the sample repo.

手順 3. 変更を "メイン" ブランチに直接コミットします。

  • 編集するページの下部にある [コミット] ボタンを選択します。
  • コミットによって、GitHub Actions ワークフローが開始されます。

Screenshot showing how to commit a change in a template file in the fork of the sample repo.

Note

"メイン" ブランチに直接変更を加える方法を示しました。 一般的なソフトウェア ワークフローでは、"メイン" 以外のブランチに変更を加えてから pull request (PR) を作成し、その変更を "メイン" にマージします。 PR によって、同様にワークフローが開始されます。

GitHub アクションについて

ワークフロー履歴を表示する

ステップ 1. GitHub で、サンプル リポジトリのフォークに移動し、[アクション] タブを開きます。

Screenshot showing how to view GitHub Actions for a repo and look at workflows.

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

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

Screenshot showing how to see where GitHub Actions secrets are stored in GitHub.

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

OAuth 認証アプリ

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

Screenshot showing how to see the authorized apps for a user in GitHub.

トラブルシューティングのヒント

Azure CLI az ad sp create-for-rba コマンドを使用してサービス プリンシパルを設定中にエラーが発生しました。

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

  • "複数のアプリケーションに同じ表示名があります" というエラーが表示されます。

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

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

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

Web サイトに、"メイン" ブランチでマージした変更が表示されません。

  • GitHub : GitHub Actions ワークフローが実行されていること、およびワークフローがトリガーされるブランチに変更がチェックインされていることを確認します。
  • Azure portal: Azure Container Registry を確認して、ブランチへの変更後のタイムスタンプが付いた新しい Docker イメージが作成されているかどうかを確認します。
  • Azure portal: コンテナー アプリのログを確認します。 プログラミング エラーが発生している場合は、ここに表示されます。
    • コンテナー アプリ | [リビジョン管理] | <アクティブなコンテナー> | リビジョンの詳細 | コンソール ログに移動します
    • 列の順序を選択して、"生成時刻"、"Stream_s"、"Log_s" を表示します。 ログを新しい順に並べ替えて、"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 リポジトリでは次のようになります。

    • .github/workflows/<workflow-name>.yml ファイルがリポジトリから削除されます。
    • 秘密鍵は削除されません。
    • Azure Container Apps は、GitHub アカウントの認証済み OAuth アプリとして残ります。

  • 切断後、Azure では次のようになります。

    • コンテナーは、最後にデプロイされたコンテナーのままとなります。 コンテナー アプリを Azure Container Registry に再接続すると、新しいコンテナー リビジョンで最新のイメージが取得されます。
    • 継続的デプロイ用に作成および使用されたサービス プリンシパルは削除されません。

次のステップ

チュートリアルが終了し、余分なコストをかけたくない場合は、使用したリソースを削除してください。 リソース グループを削除して、グループ内のすべてのリソースを削除することが、リソースを削除する最も簡単な方法です。 リソース グループを削除する方法の例については、コンテナー化のチュートリアルのクリーンアップに関する記事を参照してください。

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