Uw toepassing implementeren in Azure met behulp van GitHub Actions-werkstromen die zijn gemaakt door Visual Studio

Artikel
01/26/2025

Vanaf Visual Studio 2019 versie 16.11 kunt u nieuwe GitHub Actions-werkstromen maken voor .NET-projecten die worden gehost op GitHub.com.

Voorwaarden

U moet zijn aangemeld bij uw GitHub-account in Visual Studio.
Een Azure-account. Als u geen Azure-account hebt, activeert u uw Azure-voordelen voor Visual Studio-abonnees of meldt u zich aan voor een gratis proefversie.

Eén project implementeren in Azure met behulp van GitHub Actions

Klik in Solution Explorer met de rechtermuisknop op uw GitHub.com gehoste project en kies Publiceren.

met de rechtermuisknop > Publiceer

Selecteer in het volgende scherm Azure en kies vervolgens Volgende.

Azure selecteren

Afhankelijk van uw projecttypekrijgt u een andere lijst met Azure-services waaruit u kunt kiezen. Kies een van de ondersteunde Azure-services die aan uw behoeften voldoen.

de juiste Azure-service voor uw project selecteren

Selecteer in de laatste stap van de wizard CI/CD met behulp van GitHub Actions-werkstromen (genereert yml-bestand) en kies vervolgens Voltooien.

CI/CD met behulp van GitHub Actions-werkstromen (genereert yml-bestand)

Visual Studio genereert een nieuwe GitHub Actions-werkstroom en vraagt u deze door te voeren en naar GitHub.com te pushen.

doorvoeren en pushen

Als u deze stap voltooit met behulp van de ingebouwde Git-hulpprogramma's, detecteert Visual Studio de uitvoering van de werkstroom.

werkstroom wordt uitgevoerd

De GitHub-geheimen instellen

Voordat de gegenereerde werkstroom naar Azure kan worden geïmplementeerd, is mogelijk toegang vereist tot een publicatieprofiel.

één GitHub-geheim

Een succesvolle implementatie kan ook de toegang tot een service principalvereisen.

twee GitHub-geheimen

In alle gevallen probeert Visual Studio het GitHub-geheim voor u in te stellen met de juiste waarde. Als dit mislukt, wordt u hiervan op de hoogte gesteld en krijgt u de mogelijkheid om het opnieuw te proberen.

GitHub-geheim ontbreekt

Als het geheim niet opnieuw kan worden ingesteld, krijgt u in Visual Studio handmatig toegang tot het geheim, zodat u het proces kunt voltooien via de pagina van uw opslagplaats op GitHub.com.

ontbrekende GitHub-geheime instellen

Meerdere projecten implementeren in Azure Container Apps met behulp van GitHub Actions

Deze stappen zijn geschikt als u meer dan één project hebt dat gebruikmaakt van Docker-containers en u deze wilt implementeren als een app voor meerdere projecten. U kunt multiproject-apps implementeren, zoals apps die microservices implementeren in Azure Container Apps of AKS-(Azure Kubernetes Service). Dit artikel heeft betrekking op Azure Container Apps.

Klik met de rechtermuisknop op het knooppunt GitHub Actions in Solution Explorer en kies Nieuwe werkstroom. De werkstroomwizard van GitHub Actions wordt weergegeven.
Kies Azureop het doelscherm van de GitHub Actions-werkstroom.
Kies voor het specifieke doel Azure Container Apps. De wizard gaat verder naar het scherm Container App.
Kies een bestaande Azure Container App of kies Nieuwemaken.

Wanneer u een nieuw scherm maakt, ziet u dit scherm. Bij het testen of leren is het meestal raadzaam om een nieuwe resourcegroep te maken, zodat u alles later gemakkelijker kunt verwijderen. Een Container Apps-omgeving is een veilige grens rond groepen container-apps die hetzelfde virtuele netwerk delen en logboeken naar hetzelfde doel voor logboekregistratie schrijven. Zie Azure Container Apps-omgevingen. Als u niet weet wat dat is of er nog nooit een eerder hebt gemaakt, maak dan een nieuwe voor dit exemplaar.

Zodra het is gemaakt, wordt het nieuwe Azure Container Apps-exemplaar weergegeven.
Kies Volgende om naar het Registerscherm te gaan. Kies een bestaand Azure Container Registry of maak een nieuwe.

Als u ervoor kiest om een nieuw scherm te maken, ziet u dit scherm. Geef de resourcegroep, SKU en kies indien mogelijk dezelfde regio, zoals eerder. Zie Azure Container Registry-servicelagenvoor meer informatie over de SKU's voor Azure Container Registry.

Nadat het nieuwe register is gemaakt, wordt dit weergegeven op het scherm.
De implementeerbare projecten in uw oplossing worden weergegeven; kies de projecten die u samen wilt implementeren in hetzelfde Azure Container Apps-exemplaar.
Kies voltooien. U kunt zien welke opdrachten worden uitgegeven om de assets in Azure te maken en de verificatie in te stellen. Als er iets mislukt, noteert u de gebruikte opdrachtregel, omdat u het opnieuw kunt proberen vanuit de CLI. Maak u geen zorgen als u in deze fase een autorisatiefout krijgt. U kunt de verificatie ook later instellen in Visual Studio.
Zodra de bewerking is voltooid, wordt het overzichtsscherm weergegeven. In het overzichtsscherm worden de referenties weergegeven, die overeenkomen met de vermeldingen die Visual Studio maakt in uw GitHub-opslagplaats onder de GitHub Actions-geheimen. Controleer op gele waarschuwingssignalen. Als een van de verificatiestappen is mislukt tijdens het aanmaakproces, kunt u dit hier corrigeren door te klikken op de koppeling door op het waarschuwingsteken te klikken en een paar stappen uit te voeren.
Open het werkstroombestand om te controleren wat Visual Studio heeft gegenereerd. Hoewel Visual Studio het beste een werkstroom voor uw situatie kan genereren, is elke app en opslagplaats uniek, dus u moet vaak het YML-werkstroombestand dat door Visual Studio wordt gegenereerd handmatig bewerken voordat het wordt uitgevoerd. Als u het wilt openen, vouwt u het knooppunt GitHub Actions in Solution Explorer uit, klikt u met de rechtermuisknop op de werkstroom die zojuist is gemaakt en kiest u Bewerken.

Hieronder ziet u een voorbeeld van een werkstroombestand dat door Visual Studio is gemaakt voor een oplossing met twee implementeerbare projecten, WebAPI en 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

De belangrijkste functie van de werkstroom is om u aan te melden bij de Azure-services met de juiste verificatie en de opdrachten uit te voeren om de app te bouwen en te implementeren.

De werkstroom bewerken en testen

Met de bovenstaande procedure wordt een YML-werkstroombestand gegenereerd, maar normaal gesproken moet u dit controleren en aanpassen voordat het kan worden gebruikt voor een implementatie. Mogelijk moet u verwijzen naar de richtlijnen van GitHub voor het schrijven van werkstroomacties; zie Over aangepaste acties. Het werkstroombestand bevat veel configureerbare elementen, zoals de instellingen voor de omgevingsvariabelen en de namen van de geheimen. U kunt verwijzingen zien naar de locaties van uw Docker-bestanden, de naam van uw Azure Container-app, de tak in de opslagplaats die u gebruikt om de workflowuitvoeringen te activeren, en verwijzingen naar de secrets in GitHub. Er wordt naar geheimen verwezen met behulp van de syntaxis ${{ secrets.SECRET_NAME }}. Zie GitHub Actions-geheimen.

Als uw projecten zich niet in de hoofddirectory van de opslagplaats bevinden, moet u de workflow wijzigen om het pad op te geven om de Dockerfiles te vinden. Voeg omgevingsvariabelen toe voor de relatieve paden naar het Dockerfile in beide projecten.

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

Gebruik de waarden van deze omgevingsvariabelen voor de parameter file als volgt:

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

Als u wijzigingen wilt aanbrengen in het Dockerfile, moet u de wijzigingen aanbrengen en opslaan, doorvoeren en pushen naar de externe opslagplaats. De werkstroom die Visual Studio genereert, bevat een trigger die ervoor zorgt dat deze wordt uitgevoerd als deze wordt bijgewerkt op een opgegeven vertakking. Als u naar de working vertakking pusht, moet deze eruitzien als de volgende code:

on:
  push:
  branches:
  - working

Als u de wijzigingen wilt testen, voert u deze door en pusht u deze naar de vertakking van de opslagplaats die is opgegeven in de triggercode. U hoeft geen pull request (PR) te maken. De werkstroom draait zolang de push trigger is ingesteld op de juiste tak.

Zoek op het tabblad Acties op uw opslagplaats op GitHub.com naar de werkstroomuitvoering. U kunt er rechtstreeks naartoe gaan met behulp van een koppeling op het tabblad Overzicht van GitHub Actions in Visual Studio. In GitHub kunt u de werkstroomuitvoering openen om de logboeken weer te geven.

Probleemoplossing

De volgende tips voor probleemoplossing zijn mogelijk handig als uw werkstroom niet goed wordt uitgevoerd.

Probleem: bouwfase levert geen build op

Een probleem dat u in het Dockerfile kunt tegenkomen, is dat de buildfase niet werkt zoals in Visual Studio. In het standaard Dockerfile dat Visual Studio voor een project genereert, ziet u dit probleem. Houd rekening met de volgende wijzigingen in de buildfase als u een dergelijke Dockerfile hebt. Hier volgt een voorbeeld waarin een project zich in docker/ComposeSample/WebApi in een opslagplaats bevindt. Het volledige pad wordt opgegeven omdat de Dockerfile-context in de buildcontainer van de workflow is ingesteld op de hoofdmap van de repository, terwijl deze in Visual Studio is ingesteld op de map boven de projectmap. Het achtervoegsel _build wordt hier toegevoegd om de buildmap te maken en in plaats van alleen het projectbestand te kopiëren, wordt de hele map gekopieerd. Vergeleken met de standaard Dockerfile die door Visual Studio is gegenereerd, is het bestandsonderdeel van het pad in het eerste argument van de opdracht COPY verwijderd, zodat we de hele map kopiëren in plaats van alleen het projectbestand. Zonder deze wijzigingen produceert deze fase een MSBuild-fout.

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

Probleem: inloggegevens

Voor de werkstroom moeten de juiste gebruikersnaam- en wachtwoordgeheimen worden ingesteld voor Azure-toegang. Visual Studio probeert dit automatisch te doen wanneer u de Azure assets maakt of vanuit het GitHub Actions-scherm in de Microsoft Visual Studio IDE. U kunt de geheimen in GitHub controleren en zien of ze er zijn, of ze opnieuw genereren en indien nodig opnieuw toevoegen aan GitHub via de sectie Instellingen in de repository. Controleer de geheime ID vergeleken met hetgeen in elke sectie van de werkstroom wordt genoemd. Indien nodig kunt u naar het containerregister in Azure Portal gaan en de gebruikersnaam en het wachtwoord voor het containerregister ophalen en deze waarden gebruiken om de geheimen in GitHub bij te werken.

Als u de opdracht az ad sp create-for-rbac hebt uitgevoerd om een service-principal in te stellen en een client-id, clientgeheim en tenant-id op te halen, voegt u de client-id en het clientgeheim toe als geheimen in de sectie GitHub Actions Secrets voor uw GitHub-opslagplaats. U kunt azure-aanmeldingsreferenties opgeven in de vorm van een gebruikersnaam (client-id voor de app) en het wachtwoord (clientgeheim) voor de verificatie van de Azure Container App. Vervang hiervoor de stap Azure login door de volgende code. Gebruik uw eigen GitHub-geheime namen die u hebt gemaakt voor de client-id en het clientgeheim en gebruik de tenant-id uit de uitvoer van dezelfde opdracht.

- 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

Als het Dockerfile correct werkt en de verificatie juist is en u nog steeds problemen ondervindt met uw werkstroom, kunt u de volgende resources overwegen:

Welke projecttypen worden ondersteund?

ASP.NET Core
ASP.NET 5 en hoger
Azure Functions

Welke Azure-services worden ondersteund?

Azure Web Apps
Azure Functions
Azure API Management

Delen via