Distribuera ditt program till Azure med hjälp av GitHub Actions-arbetsflöden som skapats av Visual Studio

Artikel
01/26/2025

Från och med Visual Studio 2019 version 16.11 kan du skapa nya GitHub Actions-arbetsflöden för .NET-projekt som finns på GitHub.com.

Förutsättningar

Du måste vara inloggad på ditt GitHub-konto i Visual Studio.
Ett Azure-konto. Om du inte har något Azure-konto aktiverar du dina Azure-förmåner för Visual Studio-prenumeranter eller registrera dig för en kostnadsfri utvärderingsversion.

Distribuera ett enskilt projekt till Azure med GitHub Actions

Högerklicka på ditt GitHub.com värdbaserade projekt i Solution Explorer och välj Publicera.

högerklicka på > Publicera

På nästa skärm väljer du Azure och sedan Nästa.

välja Azure

Beroende på din projekttypfår du en annan lista över Azure-tjänster att välja mellan. Välj en av de Azure-tjänster som stöds som passar dina behov.

välja lämplig Azure-tjänst för ditt projekt

I det sista steget i guiden väljer du CI/CD med hjälp av GitHub Actions-arbetsflöden (genererar yml-fil) och väljer sedan Slutför.

CI/CD med GitHub Actions-arbetsflöden (genererar yml-fil)

Visual Studio genererar ett nytt GitHub Actions-arbetsflöde och ber dig att checka in det och skicka det till GitHub.com.

committa och pusha

Om du slutför det här steget med hjälp av inbyggda Git-verktygidentifierar Visual Studio körningen av arbetsflödet.

arbetsflödet körs

Ange GitHub-hemligheter

För att det genererade arbetsflödet ska kunna distribueras till Azure kan det kräva åtkomst till en publiceringsprofil.

en GitHub-hemlighet

En lyckad distribution kan också kräva åtkomst till ett tjänstens huvudnamn.

två GitHub-hemligheter

I samtliga fall försöker Visual Studio ange GitHub-hemligheten åt dig med rätt värde. Om det misslyckas meddelar det dig och ger dig möjlighet att försöka igen.

GitHub-hemlighet saknas

Om det inte går att ange hemligheten igen ger Visual Studio dig möjlighet att få åtkomst till hemligheten manuellt, så att du kan slutföra processen via lagringsplatsens sida på GitHub.com.

ställ in saknande GitHub secret

Distribuera flera projekt till Azure Container Apps med GitHub Actions

De här stegen är lämpliga om du har fler än ett projekt som använder Docker-containrar och du vill distribuera dem som en app för flera projekt. Du kan implementera flera projekt-appar, till exempel de som implementerar mikrotjänster, till Azure Container Apps eller Azure Kubernetes Service (AKS). Den här artikeln beskriver Azure Container Apps.

Högerklicka på noden GitHub Actions i Solution Explorer och välj Nytt arbetsflöde. Arbetsflödesguiden för GitHub Actions visas.
På målskärmen för GitHub Actions-arbetsflöde väljer du Azure.
För det specifika målet väljer du Azure Container Apps. Guiden går vidare till skärmen Container App.
Välj en befintlig Azure Container App eller välj Skapa ny.

När du skapar en ny visas den här skärmen. När du testar eller lär dig är det vanligtvis bäst att skapa en ny resursgrupp för att göra det enklare att ta bort allt senare. En Container Apps-miljö är en säker gräns för grupper av containerappar som delar samma virtuella nätverk och skriver loggar till samma loggningsmål. Se även Azure Container Apps-miljöer. Om du inte vet vad det är eller inte har skapat något tidigare skapar du en ny för den här instansen.

När den nya Azure Container Apps-instansen har skapats visas den.
Välj Nästa för att gå vidare till skärmen Registry. Välj ett befintligt Azure Container Registry eller skapa ett nytt.

Om du väljer att skapa en ny visas den här skärmen. Ange resursgruppen, SKU:n och välj samma region, om möjligt, som tidigare. Information om SKU:er för Azure Container Registry finns i Azure Container Registry-tjänstnivåer.

När det nya registret har skapats visas det på skärmen.
De distributionsbara projekten i din lösning visas. välj de projekt som du vill distribuera tillsammans i samma Azure Container Apps-instans.
Välj Slutför. Du kan se de kommandon som utfärdas för att skapa tillgångarna i Azure och konfigurera autentiseringen. Om något misslyckas bör du notera den kommandorad som används, eftersom du kan försöka igen från CLI. Oroa dig inte för mycket om du får ett auktoriseringsfel i det här skedet. Du kan också konfigurera autentiseringen senare i Visual Studio.
När den är klar visas sammanfattningsskärmen. Sammanfattningsskärmen visar autentiseringsuppgifterna som matchar de poster som Visual Studio skapar i din GitHub-lagringsplats under GitHub Actions-hemligheterna. Kontrollera om det finns gula varningstecken. Om något av autentiseringsstegen misslyckades under skapandeprocessen har du möjlighet att korrigera det här genom att klicka på länken med varningstecknet och följa några steg.
Öppna arbetsflödesfilen för att kontrollera vad Visual Studio genererade. Visual Studio gör sitt bästa för att generera ett arbetsflöde för din situation, men varje app och lagringsplats är unik, så du måste ofta redigera arbetsflödets YML-fil manuellt som genereras av Visual Studio innan den körs korrekt. Öppna den genom att expandera GitHub Actions-noden i Solution Explorer, högerklicka på arbetsflödet som nyss skapades och välja Redigera.

Följande visar ett exempel på en arbetsflödesfil som skapats av Visual Studio för en lösning med två distributionsbara projekt, WebAPI och WebFrontEnd.

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

Huvudfunktionen i arbetsflödet är att logga in på Azure-tjänsterna med rätt autentisering och köra kommandona för att skapa och distribuera appen.

Redigera och testa arbetsflödet

Proceduren ovan genererar en YML-arbetsflödesfil, men du behöver normalt granska och anpassa den innan den kan användas för en distribution. Du kan behöva läsa GitHubs vägledning om hur du skriver arbetsflödesåtgärder. se Om anpassade åtgärder. Arbetsflödesfilen innehåller många konfigurerbara element, till exempel inställningarna för miljövariablerna och namnen på hemligheterna. Du kan se referenser till platserna för dina Dockerfiles, namnet på din Azure-containerapp, grenen på lagringsplatsen som du ska använda för att utlösa arbetsflödeskörningar och referenser till hemligheterna i GitHub. Hemligheter refereras med hjälp av syntaxen ${{ secrets.SECRET_NAME }}. Se GitHub Actions-hemligheter.

Om dina projekt inte finns i roten på förvaret måste du ändra arbetsflödet till att ange sökvägen för att hitta Dockerfilerna. Lägg till miljövariabler för de relativa sökvägarna till Dockerfile i båda projekten.

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

Använd värdena för dessa miljövariabler för parametern file enligt följande:

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

Om du behöver göra ändringar i Dockerfile kan du göra och spara ändringarna, checka in och skicka till fjärrlagringsplatsen. Arbetsflödet som Visual Studio genererar innehåller en utlösare som gör att det körs om det uppdateras på en angiven gren. Om du pushar på working-grenen borde den se ut som följande kod:

on:
  push:
  branches:
  - working

Om du vill testa ändringarna checkar du in dem och push-överför dem till den gren av lagringsplatsen som anges i utlösarkoden. Du behöver inte skapa en pull request (PR). Arbetsflödet körs så länge push-utlösaren är inställd på rätt gren.

På fliken Åtgärder på lagringsplatsen på GitHub.com letar du efter arbetsflödeskörningen. Du kan komma dit direkt med hjälp av en länk på fliken GitHub Actions-sammanfattning i Visual Studio. I GitHub kan du öppna arbetsflödeskörningen för att visa loggarna.

Felsökning

Följande felsökningstips kan vara användbara om arbetsflödet inte körs korrekt.

Problem: Byggfasen lyckas inte byggas

Ett problem som kan uppstå i Dockerfile är att byggfasen inte fungerar som den gör i Visual Studio. Standard dockerfile som Visual Studio genererar för ett projekt visar det här problemet. Överväg följande ändringar i byggfasen om du har en sådan Dockerfile. Här är ett exempel där ett projekt fanns på docker/ComposeSample/WebApi i en lagringsplats. Den fullständiga sökvägen anges eftersom Dockerfile-kontexten i arbetsflödets byggcontainer är inställd på lagringsplatsens rot, men i Visual Studio är den inställd på mappen ovanför projektmappen. Suffixet _build läggs till här för att skapa byggmappen, och i stället för att bara kopiera projektfilen kopieras hela mappen. Jämfört med det standard Dockerfile som genereras av Visual Studio togs fildelen av sökvägen i det första argumentet i COPY-kommandot bort så att vi kopierar hela mappen istället för bara projektfilen. Utan dessa ändringar genererar det här steget ett MSBuild-fel.

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

Problem: Autentiseringsuppgifter

Arbetsflödet kräver att rätt användarnamn och lösenordshemligheter konfigureras för Azure-åtkomst. Visual Studio försöker göra detta automatiskt när du skapar Azure-tillgångarna eller från GitHub Actions-skärmen i Microsoft Visual Studio IDE. Du kan kontrollera hemligheterna i GitHub och se till att de finns där, eller återskapa dem och lägga till dem igen i GitHub om det behövs med hjälp av avsnittet Inställningar på lagringsplatsen. Kontrollera hemlighets-ID:t mot det som refereras i varje avsnitt i arbetsflödet. Om det behövs kan du gå till containerregistret i Azure-portalen och hämta användarnamnet och lösenordet för containerregistret och använda dessa värden för att uppdatera hemligheterna i GitHub.

Om du körde kommandot az ad sp create-for-rbac för att konfigurera tjänstens huvudnamn och hämta ett klient-ID, klienthemlighet och klient-ID lägger du till klient-ID:t och klienthemligheten som hemligheter i avsnittet GitHub Actions Secrets för din GitHub-lagringsplats. Du kan ange autentiseringsuppgifter för Azure-inloggning i form av ett användarnamn (klient-ID för appen) och lösenord (klienthemlighet) för Azure Container App-autentisering. Det gör du genom att ersätta steget Azure login med följande kod. Använd dina egna GitHub-hemligheter som du skapade för klient-ID och klienthemlighet, och använd tenant-ID:t från utdata från samma kommando.

- 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

Om Dockerfile fungerar korrekt och autentiseringen är korrekt och du fortfarande ser problem med arbetsflödet bör du överväga följande resurser:

Vilka projekttyper stöds?

ASP.NET Core
ASP.NET 5 och senare
Azure Functions

Vilka Azure-tjänster stöds?

Azure Web Apps
Azure Functions
Azure API Management

Dela via