次の方法で共有

GitHub Actions を使用して Azure App Service にデプロイする

GitHub Actions を使用してワークフローを自動化し、GitHub から Azure App Service にデプロイします。

前提条件

アプリの作成時に GitHub Actions のデプロイを設定する

GitHub Actions デプロイは、既定の[Web アプリ プロセスの作成] に統合されています。 [デプロイ] タブで [継続的デプロイ] を [有効] に設定し、選択した組織、リポジトリ、ブランチを構成します。

App Service の [デプロイ] タブで GitHub Actions のデプロイを有効にする方法を示すスクリーンショット。

継続的デプロイを有効にすると、 Web アプリの作成プロセスでは 、基本認証の選択に基づいて認証方法が自動的に選択され、それに応じてアプリと GitHub リポジトリが構成されます。

基本認証の選択 認証方法
Disable ユーザー割り当て ID (OpenID Connect) (推奨)
有効化 基本認証

Note

アプリを作成すると、Azure アカウントに特定のアクセス許可がないことを示すエラーが表示されることがあります。 お使いのアカウントに、ユーザー割り当て ID の作成と構成に必要なアクセス許可が必要な場合があります。 別の方法については、次のセクションを参照してください。

Deployment Center から GitHub Actions のデプロイを設定する

既存のアプリの場合は、App Service の Deployment Center を使用して GitHub Actions をすぐに使い始めることができます。 このターンキー メソッドは、アプリケーション スタックに基づいて GitHub Actions ワークフロー ファイルを生成し、GitHub リポジトリにコミットします。

Deployment Center を使用すると、ユーザー割り当て ID を使用して、より安全な OpenID Connect 認証を簡単に構成することもできます。 詳細については、ユーザー割り当て ID オプションに関する記事を参照してください。

必要なアクセス許可がお使いの Azure アカウントに与えられている場合、ユーザー割り当て ID を作成できます。 必要なアクセス許可がない場合、[ID] ドロップダウン メニューで既存のユーザー割り当てマネージド ID を選択できます。 Web サイト共同作成者ロールを利用すると、Azure 管理者と共同でユーザー割り当てマネージド ID を作成できます。

詳しくは、「Azure App Service への継続的デプロイ」をご覧ください。

GitHub Actions ワークフローを手動で設定する

展開センターを使用せずにワークフローを展開できます。 次の 3 つの手順を実行します。

  1. デプロイ資格情報を生成します。
  2. GitHub シークレットを構成します。
  3. ワークフロー ファイルを GitHub リポジトリに追加します。

デプロイ資格情報を生成する

OpenID Connect を使用して、Azure App Service for GitHub Actions で認証することをお勧めします。 この認証方法では、有効期間の短いトークンが使用されます。 GitHub Actions を使用して OpenID Connect を設定する場合、より複雑な作業になりますが、セキュリティが強化されます。

ユーザー割り当てマネージド ID、サービス プリンシパル、または発行プロファイルで認証することもできます。

次の手順では、Azure CLI ステートメントを使用して Microsoft Entra アプリケーション、サービス プリンシパル、およびフェデレーション資格情報を作成する手順について説明します。 Azure portal で Microsoft Entra アプリケーション、サービス プリンシパル、フェデレーション資格情報を作成する方法については、 GitHub と Azure の接続に関するページを参照してください。

  1. 既存のアプリケーションがない場合は、リソースにアクセスできる新しい Microsoft Entra アプリケーションとサービス プリンシパルを登録します。 Microsoft Entra アプリケーションを作成します。

    az ad app create --display-name myApp

    このコマンドは、自分の appId である client-id を含む JSON 出力を返します。 後で AZURE_CLIENT_ID の GitHub シークレットとして使用する値を保存します。

    objectId値は、Graph API でフェデレーション資格情報を作成し、APPLICATION-OBJECT-IDとして参照するときに使用します。

  2. サービス プリンシパルを作成する。 $appIDを JSON 出力のappIdに置き換えます。

    このコマンドは、次の手順で使用する別の objectId を含む JSON 出力を生成します。 新しい objectId は assignee-object-id です。

    appOwnerTenantIdをコピーして、後で AZURE_TENANT_ID の GitHub シークレットとして使用します。

    az ad sp create --id $appId

  3. サブスクリプションとオブジェクト別に新しいロールの割り当てを作成します。 既定では、このロールの割り当ては既定のサブスクリプションに紐づけられます。 $subscriptionId をサブスクリプション ID に、$resourceGroupName をリソース グループ名に、$webappName を Web アプリ名に、$assigneeObjectId を生成された id に置き換えます。 Azure CLI を使用して Azure サブスクリプションを管理する方法について説明します。

    az role assignment create --role "Website Contributor" --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/$webappName --assignee-principal-type ServicePrincipal

  4. 次のコマンドを実行して、Microsoft Entra アプリの 新しいフェデレーション ID 資格情報を作成 します。

    • APPLICATION-OBJECT-IDを、Active Directory アプリケーションのアプリの作成時に生成したappIdに置き換えます。

    • 後で参照するには、CREDENTIAL-NAME の値を設定します。

    • subject を設定します。 GitHub では、ワークフローに応じてその値が定義されます。

      • GitHub Actions 環境のジョブの場合は、次を使用します。 repo:< Organization/Repository >:environment:< Name >
      • 環境に関連付けられていないジョブの場合は、ワークフローのトリガーに使用される ref パスに基づいてブランチ/タグの ref パスを含めます: repo:< Organization/Repository >:ref:< ref path>。 たとえば、repo:n-username/ node_express:ref:refs/heads/my-branch または repo:n-username/ node_express:ref:refs/tags/my-tag です。
      • pull request イベントによってトリガーされるワークフローの場合は、 repo:< Organization/Repository >:pull_requestを使用します。
    az ad app federated-credential create --id <APPLICATION-OBJECT-ID> --parameters credential.json
("credential.json" contains the following content)
{
    "name": "<CREDENTIAL-NAME>",
    "issuer": "https://token.actions.githubusercontent.com",
    "subject": "repo:organization/repository:ref:refs/heads/main",
    "description": "Testing",
    "audiences": [
        "api://AzureADTokenExchange"
    ]
}

GitHub シークレットの構成

アプリケーションの クライアント ID、 テナント ID、 サブスクリプション ID を Azure/login アクションに指定する必要があります。 これらの値は、ワークフロー内で直接指定するか、GitHub シークレットに格納してワークフローで参照できます。 GitHub シークレットとして値を保存する方がより安全なオプションです。

  1. GitHub リポジトリを開き、[設定]>[セキュリティ]>[Secrets and variables] (シークレットと変数)>[アクション]>[新しいリポジトリ シークレット] に移動します。

  2. AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_ID のシークレットを作成します。 GitHub シークレットには、Active Directory アプリケーションの次の値を使用します。

    GitHub シークレット Active Directory アプリケーション
    AZURE_CLIENT_ID アプリケーション (クライアント) ID
    AZURE_TENANT_ID ディレクトリ (テナント) ID
    AZURE_SUBSCRIPTION_ID サブスクリプション ID

  3. [ シークレットの追加] を選択して各シークレットを保存します。

GitHub リポジトリにワークフロー ファイルを追加する

お使いの GitHub リポジトリの /.github/workflows/ パスの YAML (.yml) ファイルによってワークフローが定義されます。 この定義には、ワークフローを構成するさまざまな手順とパラメーターが含まれます。

少なくとも、ワークフロー ファイルには次の個別の手順があります。

  1. 作成した GitHub シークレットを使用して App Service で認証します。
  2. Web アプリを作成します。
  3. Web アプリをデプロイします。

App Service アプリにコードをデプロイするには、 azure/webapps-deploy@v3 アクションを使用します。 このアクションには、app-nameの Web アプリの名前と、言語スタックに応じて、*.zipに展開する*.war、*.jar、package、またはフォルダーのパスが必要です。 azure/webapps-deploy@v3 アクションの入力可能値の完全一覧については、action.yml を参照してください。

以下の例は、サポートされているさまざまな言語で Web アプリをビルドするワークフローの一部です。

構成したマネージド ID を使用して OpenID Connect を使用してデプロイするには、azure/login@v2、client-id、およびtenant-id キーでsubscription-id アクションを使用します。 前に作成した GitHub シークレットを参照します。

name: .NET Core

on: [push]

permissions:
      id-token: write
      contents: read

env:
  AZURE_WEBAPP_NAME: my-app    # Set this to your application's name
  AZURE_WEBAPP_PACKAGE_PATH: '.'      # Set this to the path to your web app project, defaults to the repository root
  DOTNET_VERSION: '6.0.x'           # Set this to the dot net version to use

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Check out the repo
      - uses: actions/checkout@main
      - uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

      
      # Setup .NET Core SDK
      - name: Setup .NET Core
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: ${{ env.DOTNET_VERSION }} 
      
      # Run dotnet build and publish
      - name: dotnet build and publish
        run: |
          dotnet restore
          dotnet build --configuration Release
          dotnet publish -c Release --property:PublishDir='${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp' 
          
      # Deploy to Azure Web apps
      - name: 'Run Azure webapp deploy action using publish profile credentials'
        uses: azure/webapps-deploy@v3
        with: 
          app-name: ${{ env.AZURE_WEBAPP_NAME }} # Replace with your app name
          package: '${{ env.AZURE_WEBAPP_PACKAGE_PATH }}/myapp'
      
      - name: logout
        run: |
          az logout

よく寄せられる質問

Maven プラグインを使用して WAR ファイルをデプロイするにはどうすればよいですか?

Maven プラグインを使用して Java Tomcat プロジェクトを構成した場合は、このプラグインを使用して Azure App Service にデプロイすることもできます。 Azure CLI GitHub アクションを使用する場合、Azure 資格情報が使用されます。

    - name: Azure CLI script file
      uses: azure/cli@v2
      with:
        inlineScript: |
          mvn package azure-webapp:deploy

Maven プラグインの使用方法と構成方法の詳細については、 Azure App Service の Maven プラグイン Wiki を参照してください。

Azure CLI を使用して WAR ファイルをデプロイするにはどうすればよいですか?

Azure CLI を使用して App Service にデプロイする場合は、Azure CLI の GitHub アクションを使用できます。

- name: Azure CLI script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path '${{ github.workspace }}/target/yourpackage.war' --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }}  --async true --type war

Azure CLI の GitHub アクションを使用して構成する方法の詳細については、 Azure CLI GitHub アクションを参照してください。

コマンドの使用方法やパラメーターの詳細など、 az webapp deploy コマンドの詳細については、 az webapp deploy ドキュメントを参照してください。

スタートアップ ファイルをデプロイするにはどうすればいいですか?

Azure CLI の GitHub アクションを使用します。 次に例を示します。

- name: Deploy startup script
  uses: azure/cli@v2
  with:
    inlineScript: |
      az webapp deploy --src-path ${{ github.workspace }}/src/main/azure/createPasswordlessDataSource.sh --name ${{ env.AZURE_WEBAPP_NAME }} --resource-group ${{ env.RESOURCE_GROUP }} --type startup --track-status false

コンテナーにデプロイする方法

Azure Web Deploy アクションを使用すると、GitHub Actions を使用してカスタム コンテナーを App Service にデプロイするワークフローを自動化できます。 詳細については、「 コンテナーへのデプロイ」を参照してください。

デプロイメント スロットにデプロイする方法はどのようにすればいいですか？

アクションで slot-name パラメーターを使用して、運用スロットの代わりにデプロイ スロットにazure/webapps-deploy@v3できます。 スロットにデプロイするには、ワークフローのデプロイ ステップに slot-name パラメーターを追加します。

- name: Deploy to Azure Web App
  uses: azure/webapps-deploy@v3
  with:
    app-name: 'my-app-name'
    slot-name: 'staging'  # Deploy to the 'staging' slot instead of production
    package: './output'

Note

OpenID Connect またはサービス プリンシパル認証を使用する場合は、アプリとデプロイ スロットの両方で ID に Web サイト共同作成者 ロールがあることを確認します。 発行プロファイル認証の場合は、Azure portal から特定のスロットの発行プロファイルをダウンロードします (デプロイ>デプロイ スロット> スロット >発行プロファイルをダウンロードします)。

デプロイ後に Tomcat 構成を更新するにはどうすればいいですか?

デプロイ後にいずれかの Web アプリ設定を更新する場合は、 App Service 設定 アクションを使用できます。

    - uses: azure/appservice-settings@v1
      with:
        app-name: 'my-app'
        slot-name: 'staging'  # Optional and needed only if the settings have to be configured on the specific deployment slot
        app-settings-json: '[{ "name": "CATALINA_OPTS", "value": "-Dfoo=bar" }]' 
        connection-strings-json: '${{ secrets.CONNECTION_STRINGS }}'
        general-settings-json: '{"alwaysOn": "false", "webSocketsEnabled": "true"}' #'General configuration settings as Key Value pairs'
      id: settings

このアクションの使用方法と構成方法の詳細については、 App Service 設定 リポジトリを参照してください。

関連コンテンツ

Azure GitHub のアクションとワークフローに関する次のリファレンスを確認してください。

  • Last updated on