次の方法で共有

Azure App Service への継続的デプロイ

  • [アーティクル]

Note

2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用して一意の既定のホスト名を生成するオプションが備わります。 既存のアプリ名は変更されません。

例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

詳細については、App Service リソースの一意の既定のホスト名に関するページを参照してください。

Azure App Service により、最新の更新プログラムをプルすることで、GitHub、Bitbucket、Azure Repos のリポジトリからの継続的配置が可能になります。

リポジトリを準備する

Azure App Service ビルド サーバーから自動ビルドを取得するには、リポジトリのルートに、プロジェクトの適切なファイルがあることを確認してください。

ランタイム ルート ディレクトリのファイル
ASP.NET (Windows のみ) *.sln、 *.csproj、または default.aspx
ASP.NET Core *.sln または *.csproj
PHP index.php
Ruby (Linux のみ) Gemfile
Node.js スタート スクリプトで server.js、app.js、または package.json
Python *.py、 requirements.txt、または runtime.txt
HTML default.htm、default.html、default.asp、index.htm、index.html、または iisstart.htm
WebJobs 継続的 Web ジョブの場合は App_Data/jobs/continuous の下で、トリガーされた Web ジョブの場合は App_Data/jobs/triggered の下で <job_name>/run.<extension>。 詳細については、Kudu WebJobs のドキュメントをご覧ください。
関数 Azure Functions の継続的なデプロイに関するページをご覧ください。

デプロイをカスタマイズするには、 .deployment ファイルをリポジトリのルートに含めます。 詳細については、デプロイのカスタマイズに関するページおよび「Custom deployment script (カスタム デプロイ スクリプト)」を参照してください。

Note

Visual Studio を使用する場合は、Visual Studio にリポジトリを自動作成させてください。 すぐに、Git を使用してプロジェクトをデプロイできるようになります。

デプロイ ソースを構成する

  1. Azure portal で、App Service アプリの管理ページに移動します。

  2. 左側のウィンドウで、 [デプロイ センター] を選択します。 次に、 [設定] を選択します。

  3. [ソース] ボックスで、いずれかの CI/CD オプションを選択します。

    デプロイ ソースの選択方法を示すスクリーンショット。

続行するには、ビルド プロバイダーに対応するタブを選択します。

  1. GitHub Actions は、既定のビルド プロバイダーです。 プロバイダーを変更するには、[プロバイダーの変更]>[App Service のビルド サービス]>[OK] の順に選択します。

  2. 初めて GitHub からデプロイする場合は、 [承認] を選択し、承認のプロンプトに従います。 別のユーザーのリポジトリからデプロイする場合は、 [アカウントの変更] を選択します。

  3. GitHub で Azure アカウントを承認したら、[組織]、[リポジトリ] の順に選択し、必要な [ブランチ] を選択します。

    組織またはリポジトリが見つからない場合は、GitHub でさらにアクセス許可を有効にしなければならないことがあります。 詳細については、「Organization のリポジトリに対するアクセスを管理する」を参照してください。

  4. セキュリティを強化するために、[認証の種類] で [ユーザー割り当て ID] を選択します。 詳細については、よく寄せられる質問のページを参照してください。

    Note

    [ユーザー割り当て ID] オプションに 必要なアクセス許可 が Azure アカウントにある場合、Azure によってユーザー割り当てマネージド ID が自動的に作成されます。 必要なアクセス許可がない場合は、Azure 管理者と共同で、アプリに対して必要なロールを持つ ID を作成し、ここで、ドロップダウンでそれを選択します。

  5. (省略可能) 変更を保存する前にこのファイルを確認するには、[ファイルのプレビュー] を選択します。 App Service は、アプリの言語スタック設定に基づいてワークフロー テンプレートを選択し、それを、選択された GitHub リポジトリにコミットします。

  6. [保存] を選択します。

    選択したリポジトリおよびブランチでの新しいコミットが App Service アプリに継続的にデプロイされるようになりました。 コミットとデプロイは、 [ログ] タブで追跡できます。

継続的なデプロイの無効化

  1. Azure portal で、App Service アプリの管理ページに移動します。

  2. 左側のウィンドウで、 [デプロイ センター] を選択します。 次に、 [設定]>[接続解除] の順に選択します。

    Azure portal の App Service アプリでクラウド フォルダーの同期を接続解除する方法を示すスクリーンショット。

  3. 既定では、GitHub Actions ワークフロー ファイルはリポジトリに保持されますが、引き続きアプリへのデプロイをトリガーします。 ファイルをリポジトリから削除するには、 [ワークフロー ファイルの削除] を選択します。

  4. [OK] を選択します。

ビルド プロバイダーとは

デプロイ センターのデプロイ ソースによっては、ビルド プロバイダーに対して選択できるいくつかのオプションが表示される場合があります。 ビルド プロバイダーを使用すると、ビルド、テスト、デプロイが自動化されるため、Azure App Service で CI/CD ソリューションを構築するのに役立ちます。

デプロイ センターにあるビルド プロバイダー オプションに制限されませんが、App Service を使用すると、ビルド プロバイダー オプションを迅速に設定でき、統合されたデプロイ ログ エクスペリエンスが提供されます。

GitHub Actions ビルド プロバイダーは、GitHub デプロイでのみ使用できます。 アプリのデプロイ センターから構成する場合、CI/CD を設定するために、次のアクションが実行されます。

  • GitHub Actions ワークフロー ファイルを GitHub リポジトリに保管して、App Service のビルドとデプロイのタスクを処理します。
  • 基本認証の場合、アプリの発行プロファイルを GitHub シークレットとして追加します。 ワークフロー ファイルは、このシークレットを使用して App Service に対する認証を行います。
  • ユーザー割り当て ID については、「GitHub Actions でユーザー割り当て ID オプションを使うとどうなりますか?」を参照してください。
  • ワークフロー実行ログから情報をキャプチャし、それをデプロイ センターの [ログ] タブに表示します。

GitHub Actions ビルド プロバイダーは、次の方法でカスタマイズできます。

  • GitHub リポジトリでワークフロー ファイルが生成された後に、そのファイルをカスタマイズします。 詳しくは、「GitHub Actions のワークフロー構文」を参照してください。 ワークフローが azure/webapps-deploy アクションを使用して App Service にデプロイされていることを確認してください。
  • 選択したブランチが保護されている場合でも、構成を保存せずに引き続きワークフロー ファイルのプレビューを表示してから、手動でリポジトリに追加することができます。 この方法では、Azure portal とのログ統合は行われません。
  • 基本認証またはユーザー割り当てマネージド ID を使用する代わりに、Microsoft Entra ID のサービス プリンシパルを使用してデプロイすることもできます。 これをポータルで構成することはできません。

使用しているアプリのデプロイ中の動作

正式にサポートされているすべてのデプロイ メソッドは、アプリの /home/site/wwwroot フォルダー内のファイルに変更を加えます。 アプリの実行には、それらのファイルが使用されます。 したがって、ファイルがロックされていることにより、デプロイに失敗する可能性があります。 すべてのファイルが同時に更新されるわけではないため、アプリはデプロイ中に予期しない動作をすることもあります。 この動作は、顧客向けのアプリでは好ましくありません。 これらの問題を回避するにはいくつかの方法があります。

よく寄せられる質問

基本認証が無効になっている場合、GitHub Actions ビルド プロバイダーは基本認証で機能しますか?

いいえ。 [ユーザー割り当て ID] オプションを指定して GitHub Actions を使用してみてください。

詳細については、「基本認証を使用しないデプロイ」を参照してください。

GitHub Actions でユーザー割り当て ID オプションを使うとどうなりますか?

[GitHub Actions] ソースで[ユーザー割り当て ID] を選択すると、App Service によって、Azure と GitHub で、GitHub Actions で推奨される OpenID Connect 認証を有効にするために必要なすべてのリソースが構成されます。

具体的には、App Service によって次の操作が行われます。

  • Azure のユーザー割り当てマネージド ID と、GitHub で選択したリポジトリおよびブランチの間に、フェデレーション資格情報を作成します。
  • 選択した GitHub リポジトリのフェデレーション資格情報からシークレット AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_ID を作成します。
  • ID をアプリに割り当てます。

この後、GitHub リポジトリ内の GitHub Actions ワークフローで、OpenID Connect を使用してアプリでの認証を行う Azure/ログインアクションを使用できます。 例については、「GitHub リポジトリにワークフロー ファイルを追加する」を参照してください。

必要なアクセス許可 が Azure アカウントにある場合、Azure によって、ユーザー割り当てマネージド ID が自動的に作成されて構成されます。 この ID は、アプリの [ID] ページには表示されません。 必要なアクセス許可が Azure アカウントにない場合、必要なロールを持つ既存の ID を選択する必要があります。

"このアプリに対して、マネージド ID にロールベースのアクセスを割り当て、フェデレーション資格情報を構成できる十分なアクセス許可がありません" というエラーが表示されるのはなぜですか?

このメッセージは、Azure アカウントに、GitHub Actions のユーザー割り当てマネージド ID を作成するために必要なアクセス許可がないことを示しています。 (アプリのスコープで) 必要なアクセス許可は次のとおりです。

  • Microsoft.Authorization/roleAssignments/write
  • Microsoft.ManagedIdentity/userAssignedIdentities/write

既定では、ユーザー アクセス管理者ロールと所有者ロールにはこれらのアクセス許可が既にありますが、共同作成者ロールにはありません。 必要なアクセス許可がない場合は、Azure 管理者と共同で、Web サイト共同作成者ロールを持つユーザー割り当てマネージド ID を作成します。 その後、デプロイ センターの [GitHub]>[ID] ドロップダウンで ID を選択できます。

代替手順の詳細については、「GitHub Actions を使用した App Service へのデプロイ」を参照してください。

"この ID には、このアプリに対する書き込みアクセス許可がありません。 別の ID を選択するか、管理者と共同で、このアプリの ID に Web サイト共同作成者ロールを付与してください。" というエラーが表示されるのはなぜですか?

このメッセージは、選択したユーザー割り当てマネージド ID に、GitHub リポジトリと App Service アプリの間で OpenID Connect を有効にするために必要なロールがないことを示しています。 ID には、アプリに対して、所有者、共同作成者、Web サイト共同作成者のうちいずれかのロールが必要です。 ID に最小限必要な特権ロールは、Web サイト共同作成者です。

その他のリソース