メモ
2024 年 6 月 1 日以降に新しく作成される App Service アプリでは、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用する一意の既定のホスト名を生成できます。 たとえば、 myapp-ds27dh7271aah175.westus-01.azurewebsites.netと指定します。 既存のアプリ名は変更されません。
詳細については、一意の既定のホスト名 を持つ Web アプリの作成に関するブログ記事を参照してください。
最新の更新プログラムを取り込む Azure App Service を使用して、GitHub、Bitbucket、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 | 継続的 WebJobs の場合は App_Data/jobs/continuous の下、トリガーされた WebJobs の場合は App_Data/jobs/triggered の下にある <job_name>/run.<extension>。 詳細については、Kudu WebJobs のドキュメントをご覧ください。 |
| 関数 | Azure Functions の継続的なデプロイに関するページをご覧ください。 |
デプロイをカスタマイズするには、リポジトリ ルートに .deployment ファイルを含めます。 詳細については、デプロイのカスタマイズに関するページおよび「Custom deployment script (カスタム デプロイ スクリプト)」を参照してください。
ヒント
Visual Studio では、リポジトリを作成できます。 この方法を使用すると、プロジェクトは Git を使用してすぐにデプロイする準備が整います。
デプロイ ソースを構成する
Azure portal で、App Service アプリの管理ウィンドウに移動します。
左側のメニューで、 展開センターを選択します。 次に、 [設定] を選択します。
[ ソース ] ボックスで、 継続的配置 (CI/CD) オプションのいずれかを選択します。
続行するには、ビルド プロバイダーに対応するタブを選択します。
GitHub Actions は、既定のビルド プロバイダーです。 プロバイダーを変更するには、[プロバイダーの変更]>[App Service のビルド サービス]>[OK] の順に選択します。
初めて GitHub からデプロイする場合は、 [承認] を選択し、承認のプロンプトに従います。 別のユーザーのリポジトリからデプロイするには、[アカウントの 変更] を選択します。
GitHub で Azure アカウントを承認したら、適切な 組織、 リポジトリ、ブランチを選択 します。
組織またはリポジトリが見つからない場合は、GitHub でさらにアクセス許可を有効にする必要がある場合があります。 詳細については、「Organization のリポジトリに対するアクセスを管理する」を参照してください。
セキュリティを強化するために、[認証の種類] で [ユーザー割り当て ID] を選択します。 詳細については、よく寄せられる質問 を参照してください。
注記
[ユーザー割り当て ID] オプションに 必要なアクセス許可 が Azure アカウントにある場合、Azure によってユーザー割り当てマネージド ID が自動的に作成されます。 必要なアクセス許可がない場合は、Azure 管理者と協力して 、アプリで必要なロールを持つ ID を作成し、ドロップダウンで選択します。
(省略可能) 変更を保存する前にこのファイルを確認するには、[ファイルのプレビュー] を選択します。 App Service は、アプリの 言語スタック設定 に基づいてワークフロー テンプレートを選択し、選択した GitHub リポジトリにコミットします。
[保存] を選択します。
選択したリポジトリおよびブランチでの新しいコミットが App Service アプリに継続的にデプロイされるようになりました。 コミットとデプロイは、 [ログ] タブで追跡できます。
継続的なデプロイの無効化
Azure portal で、App Service アプリの管理ページに移動します。
左側のメニューで、 展開センターを選択します。 次に、[設定>Disconnect] を選択します。
GitHub Actions ワークフロー ファイルは既定でリポジトリに保持されますが、アプリへのデプロイは引き続きトリガーされます。 ファイルをリポジトリから削除するには、 [ワークフロー ファイルの削除] を選択します。
[OK] を選択します。
ビルド プロバイダーとは
Deployment Center のデプロイ ソースによっては、いくつかのビルド プロバイダー オプションが表示される場合があります。 ビルド プロバイダーは、ビルド、テスト、デプロイを自動化することで、Azure App Service を使用して継続的インテグレーションと継続的デリバリー (CI/CD) ソリューションを構築するのに役立ちます。
Deployment Center のビルド プロバイダー オプションに限定されるわけではありませんが、App Service を使用すると、それらを迅速に設定し、統合されたデプロイ ログエクスペリエンスを得ることができます。
GitHub Actions ビルド プロバイダーは、GitHub デプロイでのみ使用できます。 アプリのデプロイ センターから構成すると、ビルド プロバイダーは、GitHub Actions ワークフロー ファイルを GitHub リポジトリに入れ、App Service へのビルドタスクとデプロイ タスクを処理することで CI/CD を設定します。
基本認証では、アプリの発行プロファイルが 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 フォルダー内のファイルが変更されます。 アプリの実行には、それらのファイルが使用されます。 ファイルがロックされているため、デプロイが失敗する可能性があります。 すべてのファイルが同時に更新されるわけではないため、アプリはデプロイ中に予期しない動作をすることもあります。 この動作は、顧客向けのアプリでは好ましくありません。
これらの問題を回避するには、いくつかの方法があります。
- 展開せずに ZIP パッケージから直接アプリを実行します。
- デプロイ中に、アプリを停止するか、オフライン モードを有効にします。 詳細については、「Dealing with locked files during deployment」 (デプロイ中にロックされているファイルに対処する) を参照してください。
- 自動スワップを有効にした状態で、ステージング スロットにデプロイします。
よく寄せられる質問
- 基本認証が無効になっている場合、GitHub Actions ビルド プロバイダーは基本認証で動作しますか?
- GitHub Actions でユーザー割り当て ID オプションを使うとどうなりますか?
- "この ID には、このアプリに対する書き込みアクセス許可がありません。というエラーが表示される理由。 別の ID を選択するか、管理者と一緒に、このアプリであなたの ID に Web サイト共同作成者ロールを付与してください。
- なぜ「この ID には、このアプリに対する書き込みアクセス許可がありません」というエラーが表示されるのですか？ 別の ID を選択するか、管理者に依頼して、このアプリであなたの ID にウェブサイト貢献者ロールを付与してもらってください。
基本認証が無効になっている場合、GitHub Actions ビルド プロバイダーは基本認証で機能しますか?
いいえ。 [ユーザー割り当て ID] オプションを指定して GitHub Actions を使用してみてください。
詳細については、「 基本認証なしでデプロイする」を参照してください。
GitHub Actions でユーザー割り当て ID オプションを使うとどうなりますか?
GitHub Actions ソースでユーザー割り当て ID を選択すると、App Service によって Azure と GitHub で必要なすべてのリソースが構成されます。 App Service では、GitHub Actions を使用して推奨される Microsoft OpenID Connect 認証を有効にします。
具体的には、App Service によって次の操作が行われます。
- Azure のユーザー割り当てマネージド ID と、GitHub で選択したリポジトリおよびブランチの間に、フェデレーション資格情報を作成します。
- 選択した GitHub リポジトリのフェデレーション資格情報からシークレット
AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_IDを作成します。 - ID をアプリに割り当てます。
GitHub リポジトリの GitHub Actions ワークフローでは、 Azure/login アクションを使用して、OpenID Connect を使用してアプリで認証できます。 例については、「GitHub リポジトリにワークフロー ファイルを追加する」を参照してください。
App Service によって、必要なアクセス許可 が Azure アカウントにある場合、ユーザー割り当てのマネージド アイデンティティが作成され、設定されます。 この ID は、アプリの [ID] ページには表示されません。 必要なアクセス許可が Azure アカウントにない場合、必要なロールを持つ既存の ID を選択する必要があります。
"マネージド ID にロールベースのアクセスを割り当て、フェデレーション資格情報を構成するための十分なアクセス許可がありません" というエラーが表示されるのはなぜですか?
このメッセージは、GitHub Actions のユーザー割り当てマネージド ID を作成するために必要なアクセス許可が Azure アカウントにないことを示しています。 アプリに関連する必要なアクセス許可は次のとおりです。
Microsoft.Authorization/roleAssignments/writeMicrosoft.ManagedIdentity/userAssignedIdentities/write
既定では、 ユーザー アクセス管理者 ロールと 所有者 ロールには既にこれらのアクセス許可がありますが、 共同作成者 ロールにはアクセスできません。 必要なアクセス許可がない場合は、Azure 管理者と協力して、 Websites 共同作成者ロールを持つユーザー割り当てマネージド ID を作成してください。 その後、 Deployment Center で、 GitHub>Identity ドロップダウンで ID を選択できます。
別の手順の使用の詳細については、「 GitHub Actions を使用して App Service にデプロイする」を参照してください。
なぜ、"この ID には、このアプリに対する書き込みアクセス許可がありません。" というエラーが表示されるのでしょうか。 別の ID を選択するか、管理者と共にこのアプリの ID に Web サイト共同作成者ロールを付与してください。
このメッセージは、選択したユーザー割り当てマネージド ID に、GitHub リポジトリと App Service アプリの間で OpenID Connect を有効にするために必要なロールがないことを示しています。 ID には、アプリの所有者、共同作成者、または Websites 共同作成者のいずれかのロールが必要です。 ID に最小限必要な特権ロールは、Web サイト共同作成者です。