Visual Studio によって作成された GitHub Actions ワークフローを使用してアプリケーションを Azure にデプロイする

[アーティクル]
01/31/2025

Visual Studio 2019 バージョン 16.11 以降では、GitHub.com でホストされている .NET プロジェクト用の新しい GitHub Actions ワークフローを作成できます。

前提条件

Visual Studio で GitHub アカウントにサインインしている必要があります。
Azure アカウント。 Azure アカウントをお持ちでない場合は、Visual Studio サブスクライバーの Azure 特典をアクティブ化するか、または無料試用版にサインアップしてください。

GitHub Actions を使用して 1 つのプロジェクトを Azure にデプロイする

ソリューションエクスプローラーで、GitHub.com ホストされているプロジェクトを右クリックし、[ 発行] を選択します。

右クリック > [発行] 発行

次の画面で Azure を選択し、次に、[次へ] を選択します。

[Azure] を選択します ] を選択

プロジェクトの種類に応じて、選択する Azure サービスの別の一覧が表示されます。サポートされている Azure サービスのうち、ニーズに合ったもののいずれかを選択します。

プロジェクト

ウィザードの最後の手順で、[GitHub Actions ワークフローを使用した CI/CD (yml ファイルの生成)] を選択し、[完了] を選択します。

GitHub Actions ワークフローで CI/CD を実行し、yml ファイルを生成する

Visual Studio によって新しい GitHub Actions ワークフローが生成され、コミットして GitHub.com にプッシュするように求められます。

コミットしてプッシュ

組み込みの Git ツールを使用してこの手順を完了すると、Visual Studio によってワークフローの実行が検出されます。

ワークフローが実行されている

GitHub シークレットの設定

生成されたワークフローを Azure に正常にデプロイするには、発行プロファイルへのアクセスが必要になる場合があります。

1つのGitHubシークレット

デプロイが成功すると、サービスプリンシパルへのアクセスが必要になる場合もあります。

2 つの GitHub シークレット

いずれの場合も、Visual Studio は GitHub シークレットを正しい値で設定しようとします。失敗した場合は、通知を受け取り、もう一度試す機会が与えられます。

GitHub シークレットが見つからない

シークレットを再び設定できない場合、Visual Studio ではシークレットに手動でアクセスできるため、GitHub.com のリポジトリのページを通じてプロセスを完了できます。

見つからない GitHub シークレットを設定

GitHub Actions を使用して複数のプロジェクトを Azure Container Apps にデプロイする

これらの手順は、Docker コンテナーを使用する複数のプロジェクトがあり、それらをマルチプロジェクトアプリとしてデプロイする場合に適しています。マイクロサービスを実装するアプリなどのマルチプロジェクトアプリを Azure Container Apps にデプロイしたり、Azure Kubernetes Service (AKS) をしたりできます。この記事では、Azure Container Apps について説明します。

ソリューションエクスプローラーで GitHub Actions ノードを右クリックし、[新しいワークフロー選択します。 GitHub Actions ワークフローウィザードが表示されます。
GitHub Actions Workflow のターゲット画面で、Azure 選択します。
特定のターゲットについては、Azure Container Apps 選択します。ウィザードが コンテナーアプリの 画面に進みます。
既存の Azure Container App を選択するか、[新しい作成] を選択します。

新しい画面を作成すると、この画面が表示されます。テストまたは学習するときは、通常、後ですべてを簡単に削除できるように、新しいリソースグループを作成することをお勧めします。 Container Apps 環境は、同じ仮想ネットワークを共有し、ログを同じログ出力先に書き込むコンテナーアプリのグループに関するセキュリティで保護された境界です。 Azure Container Apps 環境を参照してください。その内容がわからない場合、または以前に作成していない場合は、このインスタンス用の新しいインスタンスを作成します。

作成されると、新しい Azure Container Apps インスタンスが表示されます。
次に進むには「次」を選択して「レジストリ画面」に進みます。既存の Azure Container Registry を選択するか、新しく作成します。

新しい作成を選択した場合は、この画面が表示されます。リソースグループ、SKU を指定し、可能であれば、前と同じリージョンを選択します。 Azure Container Registry の SKU については、「Azure Container Registry サービスレベル」を参照してください。

作成されると、新しいレジストリが画面に表示されます。
ソリューション内の配置可能なプロジェクトが表示されます。同じ Azure Container Apps インスタンスにまとめてデプロイするプロジェクトを選択します。
を選択し、を完了します。 Azure で資産を作成し、認証を設定するために発行されているコマンドを確認できます。何か障害が発生した場合は、CLI からもう一度試すことができるので、使用されているコマンドラインに注意してください。この段階で承認エラーが発生しても、あまり心配しないでください。後で Visual Studio で認証を設定することもできます。
完了すると、概要画面が表示されます。概要画面には、Visual Studio が GitHub リポジトリの GitHub Actions シークレットの下に作成したエントリと一致する資格情報が表示されます。黄色の警告記号を確認します。作成プロセス中に認証手順のいずれかが失敗した場合は、警告記号でリンクをクリックし、いくつかの手順に従って、ここでこれを修正できます。
ワークフローファイルを開いて、Visual Studio で生成された内容を確認します。 Visual Studio は状況に合わせてワークフローを生成するのに最適ですが、すべてのアプリとリポジトリは一意であるため、多くの場合、Visual Studio によって生成されたワークフロー YML ファイルを手動で編集してから正常に実行する必要があります。これを開くには、ソリューションエクスプローラーで [GitHub Actions] ノードを展開し、先ほど作成したワークフローを右クリックして、[の編集]選択します。

次に、WebAPI と WebFrontEnd という 2 つの配置可能なプロジェクトを含むソリューション用に Visual Studio によって作成されたワークフローファイルの例を示します。

on:
push:
  branches:
  - main
env:
CONTAINER_REGISTRY_LOGIN_SERVER: registry20230810121555.azurecr.io
CONTAINER_APP_NAME: containerapp20230810121017
CONTAINER_APP_RESOURCE_GROUP_NAME: webfrontend-container-app-1234
CONTAINER_APP_CONTAINER_NAME: containerapp
jobs:
WebApi_buildImageAndDeploy:
  runs-on: ubuntu-latest
  steps:
  - name: Checkout source code
    uses: actions/checkout@v3
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Login to Docker registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
      username: ${{ secrets.registry20230810121555_USERNAME_6891 }}
      password: ${{ secrets.registry20230810121555_PASSWORD_6891 }}
  - name: Build and push Docker image to Azure container registry
    uses: docker/build-push-action@v4
    with:
      push: true
      tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
      file: WebApi\Dockerfile
  - name: Azure login
    uses: azure/login@v1
    with:
      creds: ${{ secrets.containerapp20230810121017_SPN }}
  - name: Deploy to Azure container app
    uses: azure/CLI@v1
    with:
      inlineScript: >-
        az config set extension.use_dynamic_install=yes_without_prompt
        az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
        az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webapi:${{ github.sha }}
  - name: Azure logout
    run: az logout
WebFrontEnd_buildImageAndDeploy:
  runs-on: ubuntu-latest
  needs: WebApi_buildImageAndDeploy
  steps:
  - name: Checkout source code
    uses: actions/checkout@v3
  - name: Set up Docker Buildx
    uses: docker/setup-buildx-action@v2
  - name: Login to Docker registry
    uses: docker/login-action@v2
    with:
      registry: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}
      username: ${{ secrets.registry20230810121555_USERNAME_2047 }}
      password: ${{ secrets.registry20230810121555_PASSWORD_2047 }}
  - name: Build and push Docker image to Azure container registry
    uses: docker/build-push-action@v4
    with:
      push: true
      tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
      file: WebFrontEnd\Dockerfile
  - name: Azure login
    uses: azure/login@v1
    with:
      creds: ${{ secrets.containerapp20230810121017_SPN }}
  - name: Deploy to Azure container app
    uses: azure/CLI@v1
    with:
      inlineScript: >-
        az config set extension.use_dynamic_install=yes_without_prompt
        az containerapp registry set --name ${{ env.CONTAINER_APP_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --server ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }} --username ${{ secrets.registry20230810121555_USERNAME_2047 }} --password ${{ secrets.registry20230810121555_PASSWORD_2047 }}
        az containerapp update --name ${{ env.CONTAINER_APP_NAME }} --container-name ${{ env.CONTAINER_APP_CONTAINER_NAME }} --resource-group ${{ env.CONTAINER_APP_RESOURCE_GROUP_NAME }} --image ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
  - name: Azure logout
    run: az logout

ワークフローの主な機能は、適切な認証を使用して Azure サービスにサインインし、コマンドを実行してアプリをビルドしてデプロイすることです。

ワークフローの編集とテスト

上記の手順ではワークフロー YML ファイルが生成されますが、通常は、展開に使用する前に確認してカスタマイズする必要があります。ワークフローアクションの記述に関する GitHub のガイダンスを参照する必要がある場合があります。「カスタムアクションについて」を参照してください。ワークフローファイルには、環境変数の設定やシークレットの名前など、構成可能な要素が多数含まれています。 Dockerfile の場所、Azure コンテナーアプリの名前、ワークフロー実行のトリガーに使用するリポジトリ内のブランチ、GitHub のシークレットへの参照を確認できます。シークレットは、構文 ${{ secrets.SECRET_NAME }}を使用して参照されます。 GitHub Actions シークレットを参照してください。

プロジェクトがリポジトリのルートにない場合は、Dockerfile を検索するパスを指定するようにワークフローを変更する必要があります。両方のプロジェクトの Dockerfile に相対パスの環境変数を追加します。

DOCKER_FILEPATH_WEBAPI: docker/ComposeSample/WebApi/Dockerfile
DOCKER_FILEPATH_WEBFRONTEND: docker/ComposeSample/WebFrontend/Dockerfile

file パラメーターには、次の環境変数の値を使用します。

- name: Build and push Docker image to Azure container registry
  uses: docker/build-push-action@v4
  with:
    push: true
    tags: ${{ env.CONTAINER_REGISTRY_LOGIN_SERVER }}/webfrontend:${{ github.sha }}
    file: ${{ env.DOCKER_FILEPATH_WEBFRONTEND }}

Dockerfile に変更を加える必要がある場合は、変更を行って保存し、コミットし、リモートリポジトリにプッシュします。 Visual Studio によって生成されるワークフローには、指定したブランチで更新された場合に実行されるトリガーが含まれています。 working ブランチにプッシュする場合は、次のコードのようになります。

on:
  push:
  branches:
  - working

変更をテストするには、変更をコミットし、トリガーコードで指定されたリポジトリのブランチにプッシュします。プル要求 (PR) を作成する必要はありません。ワークフローは、push トリガーが右分岐に設定されている限り実行されます。

GitHub.com のリポジトリの [アクション] タブで、ワークフローの実行を探します。 Visual Studio の GitHub Actions の [概要] タブのリンクを使用して、直接アクセスできます。 GitHub では、ワークフロー実行を開いてログを表示できます。

トラブルシューティング

ワークフローが正常に実行されない場合は、次のトラブルシューティングのヒントが役立つ場合があります。

問題: ビルドステージでビルドされない

Dockerfile で発生する可能性がある問題の 1 つは、ビルドステージが Visual Studio の場合と同じように動作しないことです。 Visual Studio でプロジェクト用に生成される既定の Dockerfile では、この問題が示されます。このような Dockerfile がある場合は、ビルドステージに対して次の変更を検討してください。プロジェクトがリポジトリ内の docker/ComposeSample/WebApi に配置された例を次に示します。ワークフロービルドコンテナー内の Dockerfile コンテキストがリポジトリのルートに設定されているため、完全なパスが指定されますが、Visual Studio ではプロジェクトフォルダーの上のフォルダーに設定されます。ここに _build サフィックスが追加され、ビルドフォルダーが作成され、プロジェクトファイルをコピーするだけではなく、フォルダー全体がコピーされます。 Visual Studio によって生成された既定の Dockerfile と比較すると、COPY コマンドの最初の引数のパスのファイル部分が削除され、プロジェクトファイルだけでなくフォルダー全体がコピーされます。これらの変更がない場合、このステージでは MSBuild エラーが発生します。

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["docker/ComposeSample/WebApi/", "WebApi_build/"]
RUN dotnet restore "WebApi_build/WebApi.csproj"
COPY . .
WORKDIR "/src/WebApi_build"
RUN dotnet build "WebApi.csproj" -c Release -o /app/build

問題: 認証資格情報

このワークフローでは、Azure アクセス用に適切なユーザー名とパスワードのシークレットを設定する必要があります。 Visual Studio は、Azure アセットを作成するとき、または Microsoft Visual Studio IDE の GitHub Actions 画面からこれを自動的に実行しようとします。 GitHub でシークレットを確認し、シークレットが存在することを確認するか、リポジトリの [設定] セクションを使用して、必要に応じてそれらを再生成して GitHub に再度追加することができます。ワークフローの各セクションで参照されているものに対してシークレット ID を確認します。必要に応じて、Azure portal でコンテナーレジストリに移動し、コンテナーレジストリのユーザー名とパスワードを取得し、これらの値を使用して GitHub のシークレットを更新できます。

az ad sp create-for-rbac コマンドを実行してサービスプリンシパルを設定し、クライアント ID、クライアントシークレット、テナント ID を取得した場合は、GitHub リポジトリの GitHub Actions Secrets セクションにクライアント ID とクライアントシークレットをシークレットとして追加します。 Azure ログイン資格情報は、Azure Container App 認証のユーザー名 (アプリのクライアント ID) とパスワード (クライアントシークレット) の形式で指定できます。これを行うには、手順 Azure login を次のコードに置き換えます。クライアント ID とクライアントシークレットに対して作成した独自の GitHub シークレット名を使用し、同じコマンドの出力からテナント ID を使用します。

- name: Azure login
  uses: azure/CLI@v1
  with:
    inlineScript: |
      az login --service-principal -u ${{ secrets.GITHUB_SECRETID_FOR_USERNAME }} -p ${{ secrets.GITHUB_SECRETID_FOR_PASSWORD }} --tenant {your tenant ID}
      az account list

Dockerfile が正しく機能し、認証が正しく、ワークフローに問題が引き続き発生する場合は、次のリソースを検討してください。

サポートされているプロジェクトの種類はどれですか?

ASP.NET Core
ASP.NET 5 以上
Azure Functions（アズールファンクションズ）

どの Azure サービスがサポートされていますか?

Azure Web Apps
Azure Functions
Azure API Management

次の方法で共有

Visual Studio によって作成された GitHub Actions ワークフローを使用してアプリケーションを Azure にデプロイする

前提条件

GitHub Actions を使用して 1 つのプロジェクトを Azure にデプロイする

GitHub シークレットの設定

GitHub Actions を使用して複数のプロジェクトを Azure Container Apps にデプロイする

ワークフローの編集とテスト

トラブルシューティング

問題: ビルドステージでビルドされない

問題: 認証資格情報

サポートされているプロジェクトの種類はどれですか?

どの Azure サービスがサポートされていますか?

フィードバック

その他のリソース

次の方法で共有

Visual Studio によって作成された GitHub Actions ワークフローを使用してアプリケーションを Azure にデプロイする

前提 条件

GitHub Actions を使用して 1 つのプロジェクトを Azure にデプロイする

GitHub シークレットの設定

GitHub Actions を使用して複数のプロジェクトを Azure Container Apps にデプロイする

ワークフローの編集とテスト

トラブルシューティング

問題: ビルド ステージでビルドされない

問題: 認証資格情報

サポートされているプロジェクトの種類はどれですか?

どの Azure サービスがサポートされていますか?

フィードバック

その他のリソース

前提条件

問題: ビルドステージでビルドされない