Share via


Implementeren in App Service met behulp van GitHub Actions

Ga aan de slag met GitHub Actions om uw werkstroom te automatiseren en te implementeren in Azure-app Service vanuit GitHub.

Vereisten

  • Een Azure-account met een actief abonnement. Gratis een account maken
  • Een GitHub-account. Als u geen account hebt, kunt u zich registreren voor een gratis account.

Implementatie van GitHub Actions instellen bij het maken van de app

GitHub Actions-implementatie is geïntegreerd in de standaardwizard voor het maken van apps. U hoeft alleen continue implementatie in te stellen op het tabblad Implementatie en de gewenste organisatie, opslagplaats en vertakking te configureren.

Een schermopname van het inschakelen van gitHub Actions-implementatie in de wizard App Service maken.

Wanneer u continue implementatie inschakelt, kiest de wizard voor het maken van apps automatisch de verificatiemethode op basis van de basisverificatieselectie en configureert u uw app en uw GitHub-opslagplaats dienovereenkomstig:

Basisverificatieselectie Verificatiemethode
Uitschakelen Door de gebruiker toegewezen identiteit (OpenID Connect) (aanbevolen)
Inschakelen Basisverificatie

Notitie

Als u een foutmelding krijgt bij het maken van uw app waarin wordt aangegeven dat uw Azure-account niet over bepaalde machtigingen beschikt, beschikt het mogelijk niet over de vereiste machtigingen om de door de gebruiker toegewezen identiteit te maken en te configureren. Zie GitHub Actions-implementatie instellen vanuit het Implementatiecentrum voor een alternatief.

Implementatie van GitHub Actions instellen vanuit het Implementatiecentrum

Voor een bestaande app kunt u snel aan de slag met GitHub Actions met behulp van het App Service Deployment Center. Met deze turn-key-methode wordt automatisch een Werkstroombestand voor GitHub Actions gegenereerd op basis van uw toepassingsstack en wordt dit doorgevoerd in uw GitHub-opslagplaats.

Met het Implementatiecentrum kunt u ook eenvoudig de veiligere OpenID Connect-verificatie configureren met de door de gebruiker toegewezen identiteitsoptie.

Als uw Azure-account over de benodigde machtigingen beschikt, kunt u ervoor kiezen om een door de gebruiker toegewezen identiteit te maken. Anders kunt u een bestaande door de gebruiker toegewezen beheerde identiteit selecteren in de vervolgkeuzelijst Identiteit . U kunt samenwerken met uw Azure-beheerder om een door de gebruiker toegewezen beheerde identiteit te maken met de rol Inzender voor websites.

Zie Continue implementatie naar Azure-app Service voor meer informatie.

Een GitHub Actions-werkstroom handmatig instellen

U kunt ook een werkstroom implementeren zonder het Implementatiecentrum te gebruiken. In dat geval moet u drie stappen uitvoeren:

  1. Implementatiereferenties genereren
  2. Het GitHub-geheim configureren
  3. Het werkstroombestand toevoegen aan uw GitHub-opslagplaats

1. Implementatiereferenties genereren

De aanbevolen manier om te verifiëren met Azure-app Services voor GitHub Actions is met OpenID Connect. Dit is een verificatiemethode die gebruikmaakt van kortdurende tokens. Het instellen van OpenID Connect met GitHub Actions is complexer, maar biedt beperkte beveiliging.

U kunt ook verifiëren met een door de gebruiker toegewezen beheerde identiteit, een service-principal of een publicatieprofiel.

Hieronder wordt u door de stappen geleid voor het maken van een Active Directory-toepassing, service-principal en federatieve referenties met behulp van Azure CLI-instructies. Zie Connect GitHub en Azure voor meer informatie over het maken van een Active Directory-toepassing, service-principal en federatieve referenties in Azure Portal.

  1. Als u geen bestaande toepassing hebt, registreert u een nieuwe Active Directory-toepassing en service-principal die toegang heeft tot resources. Maak de Active Directory-toepassing.

    az ad app create --display-name myApp
    

    Met deze opdracht wordt een JSON uitgevoerd met een JSON appId die uw client-id. Sla de waarde op die u later wilt gebruiken als het AZURE_CLIENT_ID GitHub-geheim.

    U gebruikt de waarde bij het objectId maken van federatieve referenties met Graph API en verwijst ernaar als de APPLICATION-OBJECT-ID.

  2. Een service-principal maken. Vervang de door de $appID appId uit uw JSON-uitvoer.

    Met deze opdracht wordt JSON-uitvoer gegenereerd met een andere objectId en wordt in de volgende stap gebruikt. Het nieuwe objectId is de assignee-object-id.

    Kopieer het appOwnerTenantId te gebruiken als gitHub-geheim voor AZURE_TENANT_ID later gebruik.

     az ad sp create --id $appId
    
  3. Maak een nieuwe roltoewijzing per abonnement en object. De roltoewijzing is standaard gekoppeld aan uw standaardabonnement. Vervang $subscriptionId door uw abonnements-id, $resourceGroupName door de naam van uw resourcegroep, $webappName door de naam van uw web-app en $assigneeObjectId door de gegenereerde idnaam. Meer informatie over het beheren van Azure-abonnementen met de Azure CLI.

    az role assignment create --role contributor --subscription $subscriptionId --assignee-object-id  $assigneeObjectId --scope /subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/$webappName --assignee-principal-type ServicePrincipal
    
  4. Voer de volgende opdracht uit om een nieuwe federatieve identiteitsreferentie te maken voor uw Active Directory-toepassing.

    • Vervang door APPLICATION-OBJECT-ID de appId (gegenereerd tijdens het maken van de app) voor uw Active Directory-toepassing.
    • Stel een waarde in om CREDENTIAL-NAME later te verwijzen.
    • Stel de subject in. De waarde wordt gedefinieerd door GitHub, afhankelijk van uw werkstroom:
      • Taken in uw GitHub Actions-omgeving: repo:< Organization/Repository >:environment:< Name >
      • Voor taken die niet zijn gekoppeld aan een omgeving, moet u het referentiepad voor vertakkingen/tags opnemen op basis van het referentiepad dat wordt gebruikt voor het activeren van de werkstroom: repo:< Organization/Repository >:ref:< ref path>. Bijvoorbeeld repo:n-username/ node_express:ref:refs/heads/my-branch of repo:n-username/ node_express:ref:refs/tags/my-tag.
      • Voor werkstromen die door een pull-aanvraaggebeurtenis zijn geactiveerd: 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"
        ]
    }     
    

2. Het GitHub-geheim configureren

U moet de client-id, tenant-id en abonnements-id van uw toepassing opgeven voor de azure-/aanmeldingsactie. Deze waarden kunnen rechtstreeks in de werkstroom worden opgegeven of kunnen worden opgeslagen in GitHub-geheimen en waarnaar wordt verwezen in uw werkstroom. Het opslaan van de waarden als GitHub-geheimen is de veiligere optie.

  1. Open uw GitHub-opslagplaats en ga naar Beveiligingsgeheimen > > > en variabelen Acties > nieuwe opslagplaats.

  2. Geheimen maken voor AZURE_CLIENT_ID, AZURE_TENANT_IDen AZURE_SUBSCRIPTION_ID. Gebruik deze waarden uit uw Active Directory-toepassing voor uw GitHub-geheimen:

    GitHub Secret Active Directory-toepassing
    AZURE_CLIENT_ID Client-id van toepassing
    AZURE_TENANT_ID Id van directory (tenant)
    AZURE_SUBSCRIPTION_ID Abonnements-id
  3. Sla elk geheim op door Geheim toevoegen te selecteren.

3. Voeg het werkstroombestand toe aan uw GitHub-opslagplaats

Een werkstroom wordt gedefinieerd door een YAML-bestand (.yml) in het /.github/workflows/ pad in uw GitHub-opslagplaats. Deze definitie bevat de verschillende stappen en parameters die deel uitmaken van de werkstroom.

Het werkstroombestand zou minimaal de volgende afzonderlijke stappen hebben:

  1. Verifieer met App Service met behulp van het GitHub-geheim dat u hebt gemaakt.
  2. Bouw de web-app.
  3. Implementeer de web-app.

Als u uw code wilt implementeren in een App Service-app, gebruikt u de actie azure/webapps-deploy@v3 . De actie vereist de naam van uw web-app en app-name , afhankelijk van uw taalstack, het pad van een *.zip, *.war, *.jar of map om in packagete implementeren. Zie de definitie action.yml voor een volledige lijst met mogelijke invoer voor de azure/webapps-deploy@v3 actie.

In de volgende voorbeelden ziet u het deel van de werkstroom waarmee de web-app wordt gebouwd, in verschillende ondersteunde talen.

Als u wilt implementeren met OpenID Connect met behulp van de beheerde identiteit die u hebt geconfigureerd, gebruikt u de azure/login@v1 actie met de client-id, tenant-iden sleutels en subscription-id verwijst u naar de GitHub-geheimen die u eerder hebt gemaakt.

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:
      # Checkout the repo
      - uses: actions/checkout@main
      - uses: azure/login@v1
        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

Veelgestelde vragen

Hoe kan ik een WAR-bestand implementeren via de Maven-invoegtoepassing?

Als u uw Java Tomcat-project hebt geconfigureerd met de Maven-invoegtoepassing, kunt u ook implementeren naar Azure-app Service via deze invoegtoepassing. Als u de Azure CLI GitHub-actie gebruikt, worden uw Azure-aanmeldingsreferenties gebruikt.

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

Meer informatie over de Maven-invoegtoepassing en hoe u deze kunt gebruiken en configureren, vindt u in de Maven-invoegtoepassingswiki voor Azure-app Service.

Hoe kan ik een WAR-bestand implementeren via Az CLI?

Als u liever de Azure CLI gebruikt om te implementeren in App Service, kunt u de GitHub Action voor Azure CLI gebruiken.

- 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

Meer informatie over de GitHub Action voor CLI en hoe u deze kunt gebruiken en configureren, vindt u in de Azure CLI GitHub-actie. Meer informatie over de opdracht az webapp deploy, how to use and the parameter details is te vinden in de az webapp deploy documentation.

Hoe kan ik een opstartbestand implementeren?

Gebruik de GitHub Action voor CLI. Voorbeeld:

- 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

Hoe kan ik implementeren in een container?

Met de actie Azure Web Deploy kunt u uw werkstroom automatiseren om aangepaste containers te implementeren in App Service met behulp van GitHub Actions. Gedetailleerde informatie over de stappen voor implementatie met behulp van GitHub Actions vindt u in de implementatie in een container.

Hoe kan ik de Tomcat-configuratie bijwerken na de implementatie?

Als u de instellingen van uw web-apps na de implementatie wilt bijwerken, kunt u de actie App Service-instellingen gebruiken.

    - 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

Meer informatie over deze actie en hoe u deze kunt gebruiken en configureren, vindt u in de opslagplaats App Service-instellingen .

Volgende stappen

Bekijk verwijzingen in Azure GitHub Actions en werkstromen: