End-to-end-implementaties begrijpen

  • 5 minuten

GitHub Actions-werkstromen zijn flexibele hulpprogramma's die u op veel verschillende manieren kunt configureren om aan uw behoeften te voldoen. In deze les leert u hoe u werkstromen gebruikt om een volledige oplossing te implementeren, waaronder het configureren van de Azure-infrastructuur en het uitvoeren van andere implementatiebewerkingen.

Hoeveel werkstromen?

In sommige organisaties verschilt het team dat de Azure-omgeving beheert, van het team dat de code ontwikkelt die in de omgeving wordt uitgevoerd. In deze situaties is het vaak verleidelijk om meerdere werkstromen te maken, die elk eigendom zijn van het team dat verantwoordelijk is voor het specifieke gebied. U kunt bijvoorbeeld één werkstroom maken om de Bicep-code te implementeren waarmee de Azure-resources van uw website worden geïmplementeerd en een andere werkstroom waarmee de websitetoepassing wordt geïmplementeerd.

Hoewel deze benadering u enige flexibiliteit kan bieden bij het beheren van de werkstromen, kan het lastig zijn om alles gesynchroniseerd te houden. Stel dat uw websiteteam een nieuwe instelling nodig heeft voor de Azure-app Service-app om een functie in te schakelen die door het team wordt gebouwd. De werkstroom voor toepassingsimplementatie kan pas worden uitgevoerd als de werkstroom voor de implementatie van de infrastructuur is voltooid. Het kan ook ingewikkeld worden om gegevens te verzenden, zoals de namen van Azure-resources die zijn gemaakt door uw infrastructuurwerkstroom, tussen de werkstromen.

In plaats daarvan is het vaak beter om één werkstroom te maken waarmee alles wordt geïmplementeerd dat nodig is voor uw oplossing, zelfs als verschillende teams of verschillende personen de onderdelen beheren. U kunt hulpprogramma's zoals Git en GitHub gebruiken om uw werk te coördineren. Wanneer een nieuwe functie wordt toegevoegd, kunt u een vertakking gebruiken om de benodigde wijzigingen aan te brengen in uw Bicep-bestand. Wanneer de wijziging gereed is om te worden geïntegreerd en vrijgegeven, voert één werkstroom alle stappen uit die nodig zijn om de oplossing te bouwen en te implementeren, waardoor de kans op synchronisatie wordt verminderd.

Tip

Wanneer u code voor uw oplossing bouwt, moet u deze waarschijnlijk regelmatig implementeren, zodat u kunt testen hoe deze werkt. Het kan zijn dat het implementeren van uw infrastructuur samen met uw toepassingscode ervoor zorgt dat uw werkstroom langzaam wordt uitgevoerd en uw voortgang remt.

Als u op deze positie bent, kunt u overwegen om de infrastructuurimplementatie voor uw ontwikkelomgeving uit te schakelen. U kunt padfilters, herbruikbare werkstromen en voorwaarden gebruiken om dit te bereiken. U moet echter de volledige implementatievolgorde intact laten voor uw andere omgevingen.

Het besturingsvlak en het gegevensvlak

Veel Azure-resources bieden twee verschillende lagen voor toegang. Het besturingsvlak implementeert en configureert de resource. Met het gegevensvlak kunt u toegang krijgen tot de functionaliteit van de resource.

Wanneer u Bicep-bestanden maakt en implementeert, communiceert u met het besturingsvlak. In Azure is het besturingsvlak Azure Resource Manager. U gebruikt Resource Manager om de configuratie van elk van uw resources te definiëren.

Uw werkstroom moet echter vaak meer doen dan alleen met het besturingsvlak werken. U moet bijvoorbeeld het volgende doen:

  • Upload een blob naar een opslagaccount.
  • Een databaseschema wijzigen.
  • Maak een API-aanroep naar een service van derden.
  • Een machine learning-modelupdate activeren.
  • Een website implementeren in een Azure-app Service-app.
  • Software implementeren op een virtuele machine.
  • Registreer een DNS-vermelding bij een externe provider.

Wanneer u een end-to-end-werkstroom beschouwt, moet u normaal gesproken uw Azure-resources implementeren en vervolgens een reeks bewerkingen uitvoeren op de gegevensvlakken van deze resources. Soms worden deze bewerkingen de laatste mijl van de implementatie genoemd, omdat u het grootste deel van de implementatie uitvoert met behulp van het besturingsvlak en slechts een kleine hoeveelheid configuratie blijft bestaan.

Notitie

Sommige resources hebben geen duidelijke verdeling tussen het besturingsvlak en het gegevensvlak. Deze omvatten Azure Data Factory en Azure API Management. Beide services ondersteunen volledig geautomatiseerde implementaties met bicep, maar hiervoor zijn speciale overwegingen vereist. Aan het einde van de module vindt u koppelingen naar meer informatie op de overzichtspagina.

Gegevensvlakbewerkingen uitvoeren

Wanneer u een implementatiewerkstroom maakt die communiceert met het gegevensvlak van uw resources, kunt u een van de volgende drie algemene benaderingen gebruiken:

  • Resource Manager-implementatiescripts
  • Werkstroomscripts
  • Workflowacties

Resource Manager-implementatiescripts worden gedefinieerd in uw Bicep-bestand. Ze voeren Bash- of PowerShell-scripts uit en ze kunnen communiceren met Azure CLI-opdrachten en Azure PowerShell-cmdlets. U maakt een beheerde identiteit voor het implementatiescript dat moet worden gebruikt voor verificatie bij Azure, en Azure richt automatisch de andere resources in die nodig zijn om het implementatiescript uit te voeren.

Implementatiescripts zijn handig wanneer u een basisscript in uw implementatieproces moet uitvoeren, maar ze bieden u niet eenvoudig toegang tot andere elementen vanuit uw werkstroom.

U kunt ook uw eigen logica uitvoeren vanuit een implementatiewerkstroom. GitHub Actions biedt een uitgebreid ecosysteem van acties voor veelvoorkomende dingen die u moet doen. Als u geen actie kunt vinden die aan uw behoeften voldoet, kunt u een script gebruiken om uw eigen Bash- of PowerShell-code uit te voeren. Werkstroomacties en scripts worden uitgevoerd vanuit de runner van uw werkstroom. U moet de actie of het script vaak verifiëren bij het gegevensvlak van de service die u gebruikt en hoe u dit doet, is afhankelijk van de service.

Werkstroomacties en -scripts bieden u flexibiliteit en controle. Ze bieden u ook toegang tot werkstroomartefacten, waarover u binnenkort meer informatie krijgt. In deze module richten we ons op werkstroomacties. Aan het einde van de module vindt u een koppeling naar meer informatie over Resource Manager-implementatiescripts op de overzichtspagina.

Uitvoerwaarden

Normaal gesproken maakt en configureert een werkstroom uw Azure-resources door een Bicep-bestand te implementeren. De volgende onderdelen van de werkstroom communiceren vervolgens met het gegevensvlak van die resources. Voor interactie met de resources hebben de werkstroomacties en stappen informatie nodig over de Azure-resource die is gemaakt.

Stel dat u een Bicep-bestand hebt waarmee een opslagaccount wordt geïmplementeerd. U wilt dat uw werkstroom het opslagaccount implementeert en vervolgens enkele blobs uploadt naar een blobcontainer in het opslagaccount. De werkstroomstap waarmee de blobs worden geüpload, moet de naam van het opslagaccount kennen waarmee verbinding moet worden gemaakt en de naam van de blobcontainer waarnaar het bestand moet worden geüpload.

Het is raadzaam om het Bicep-bestand te laten beslissen over de namen van uw Azure-resources. Het kan parameters, variabelen of expressies gebruiken om de namen voor het opslagaccount en de blobcontainer te maken. Het Bicep-bestand kan vervolgens een uitvoer weergeven die de naam van elke resource levert. Latere stappen in de werkstroom kunnen de uitvoerwaarde lezen. Op die manier hoeft uw werkstroomdefinitie geen namen of andere gegevens vast te stellen die kunnen veranderen tussen omgevingen of op basis van regels die zijn gedefinieerd in uw Bicep-bestand.

Met GitHub Actions kunt u de waarden van uitvoer doorgeven met behulp van werkstroomvariabelen. Met de azure/arm-deploy actie worden automatisch variabelen gemaakt voor elk van uw Bicep-implementatie-uitvoer. U kunt ook handmatig werkstroomvariabelen maken in scripts. Aan het einde van deze module vindt u koppelingen naar meer informatie op de pagina Samenvatting.

Wanneer u variabelen opent die in een andere taak zijn gemaakt, moet u de variabele publiceren om deze toegankelijk te maken voor de taak die deze leest. Stel dat u een taak maakt waarmee een Bicep-bestand wordt geïmplementeerd en dat u de appServiceAppName uitvoer moet doorgeven aan uw werkstroom. U gebruikt het outputs trefwoord om op te geven dat de appServiceAppName werkstroomvariabele moet worden ingesteld op de waarde van de appServiceAppName uitvoervariabele die door de deploy stap is gemaakt:

job1:
  runs-on: ubuntu-latest
  outputs:
    appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy Bicep file
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: Playground1
      template: ./deploy/main.bicep

Vervolgens maakt u in een latere taak een expliciete afhankelijkheid van de taak die de variabele heeft gemaakt door het needs trefwoord op te geven en verwijst u naar de variabele met behulp van de naam van de gepubliceerde variabele:

job2:
  needs: job1
  runs-on: ubuntu-latest
  steps:
  - run: |
      echo "${{needs.job1.outputs.appServiceAppName}}"

Door Bicep-uitvoer en werkstroomvariabelen te gebruiken, kunt u een werkstroom maken waarmee uw Bicep-code wordt geïmplementeerd en vervolgens verschillende acties op de resources worden uitgevoerd als onderdeel van uw implementatie.