Toepassingen en virtuele machines configureren

Voltooid

Het is gebruikelijk om apps en andere aangepaste code te bouwen voor uw Azure-oplossing. Aangepaste apps kunnen websites, API's en achtergrond-apps bevatten die zonder menselijke interactie worden uitgevoerd. In deze les leert u hoe u een pijplijn ontwerpt voor het bouwen en implementeren van een app naast de infrastructuur.

Apps bouwen

Veel soorten apps moeten worden gecompileerd of gebouwd voordat ze kunnen worden gebruikt. Het buildproces neemt de broncode voor de app, voert een reeks activiteiten erop uit en maakt vervolgens een set implementeerbare bestanden.

Het buildproces compileert de broncode in binaire bestanden of uitvoerbare bestanden, maar bevat gewoonlijk ook andere activiteiten:

• Comprimeer de afbeeldingsbestanden die worden geleverd aan de gebruikers van uw website.
• Linting uw code om te controleren of deze goede coderingsprocedures volgt.
• Het uitvoeren van eenheidstests die het gedrag van afzonderlijke onderdelen van uw app controleren.

Naast deze stappen kunt u ook stappen uitvoeren, zoals het digitaal ondertekenen van de bestanden om ervoor te zorgen dat ze niet kunnen worden gewijzigd.

Wat de reeks stappen ook kan zijn, de uitvoer van het buildproces is een implementeerbaar artefact. Het artefact wordt gewoonlijk opgeslagen in het bestandssysteem van de pijplijnagent. Latere fasen van uw pijplijn moeten omgaan met het artefact om het uit te rollen via uw omgevingen en het te testen naarmate het door de kwaliteitspoorten gaat die u definieert in uw pijplijndefinitie.

Notitie

Mogelijk hebt u gehoord van de termen continue integratie en continue implementatie, of CI- en CD-. Een buildproces bevindt zich binnen het onderdeel continue integratie van uw pijplijn.

Pijplijnartefacten

De artefacten die in uw pijplijn worden gegenereerd, worden niet opgeslagen in uw Git-opslagplaats. Ze worden afgeleid van de broncode, maar zijn geen code zelf en dus horen ze niet bij een opslagplaats voor broncodebeheer. Ze worden gemaakt in het bestandssysteem van de pijplijnagent. Er wordt een nieuwe agent gemaakt voor elke pijplijntaak, dus u hebt een manier nodig om de bestanden tussen taken en agents te delen.

Pijplijnartefacten bieden een manier om bestanden op te slaan in Azure Pipelines, en ze zijn gekoppeld aan de specifieke uitvoering van je pijplijn. U gebruikt de PublishBuildArtifacts ingebouwde pijplijntaak om Azure Pipelines te instrueren een bestand of map te publiceren vanuit het bestandssysteem van de agent als een pijplijnartefact:

- task: PublishBuildArtifacts@1
  displayName: Publish folder as a pipeline artifact
  inputs:
    artifactName: my-artifact-name
    pathToPublish: '$(Build.ArtifactStagingDirectory)/my-folder'

De eigenschap pathToPublish is de locatie die de gecompileerde code of uitvoerbestanden in het bestandssysteem van de pijplijnagent bevat. De inhoud op deze locatie wordt gepubliceerd op het artefact. U kunt één bestand of een map opgeven.

Elk artefact heeft een naam, die u opgeeft met behulp van de artifactName taakeigenschap. Je gebruikt de naam van het artefact om er later in de pijplijn naar te verwijzen. Volgende pijplijntaken en -fasen kunnen het artefact downloaden, zodat ze ermee kunnen werken, bijvoorbeeld om de website te implementeren op de server waarop het wordt gehost:

Wanneer u implementatietaken gebruikt, worden pijplijnartefacten standaard automatisch gedownload. Als u reguliere taken gebruikt, gebruikt u de DownloadBuildArtifacts taak om een pijplijnartefact te downloaden:

- task: DownloadBuildArtifacts@0
  inputs:
    buildType: current
    downloadType: single
    artifactName: my-artifact-name
    downloadPath: '$(System.ArtifactsDirectory)'

Apps implementeren

Het buildproces voor een app genereert en publiceert een implementeerbaar artefact. Latere fasen van de pijplijn implementeren het artefact. De manier waarop u een app implementeert, is afhankelijk van de service die u gebruikt om deze te hosten.

Implementeren in Azure App Service

Uw speelgoedbedrijf gebruikt Azure App Service om de website te hosten. U kunt een App Service-app maken en configureren met bicep. Maar wanneer het tijd is om de app te implementeren, hebt u verschillende opties om de gecompileerde app op de hostinginfrastructuur te krijgen. Deze opties worden beheerd als onderdeel van het App Service-gegevensvlak.

De meest voorkomende benadering is het gebruik van de AzureRmWebAppDeployment Azure Pipelines-taak:

- task: AzureRmWebAppDeployment@4
  inputs:
    azureSubscription: MyServiceConnection
    ResourceGroupName: MyResourceGroup
    WebAppName: my-app-service
    Package: '$(Pipeline.Workspace)/my-artifact-name/website.zip'

U moet verschillende stukjes informatie opgeven om uw app te implementeren in App Service. Deze informatie omvat de resourcegroep en resourcenaam van uw App Service-app die u opgeeft met behulp van de invoer ResourceGroupName en WebAppName. Zoals u in de vorige les hebt geleerd, moet u een uitvoer toevoegen aan uw Bicep-bestand en een pijplijnvariabele gebruiken om de naam van de app door te geven via uw pijplijn. U moet ook een .zip-bestand opgeven met de app die moet worden geïmplementeerd met behulp van de Package invoer. Dit is meestal het pad naar een pijplijnartefact.

App Service heeft een eigen verificatiesysteem voor gegevensvlakken dat wordt gebruikt voor implementaties. De AzureRmWebAppDeployment taak verwerkt het verificatieproces automatisch voor u:

De AzureRmWebAppDeployment-taak maakt gebruik van de service-principal die is gekoppeld aan uw serviceverbinding om automatisch de vereiste referenties voor implementatie te maken en te downloaden. Vervolgens worden de implementatiereferenties gebruikt wanneer deze communiceert met de Api voor het App Service-gegevensvlak.

App Service biedt ook enkele andere implementatiefuncties, waaronder implementatieslots. Slots helpen u nieuwe versies van uw apps veilig uit te rollen zonder onderbrekingen. Ze helpen u ook bij het voorbereiden en opwarmen van de nieuwe versie van uw toepassing voordat u productieverkeer naar de toepassing verzendt. We gebruiken geen slots in deze module, maar we bieden een koppeling naar meer informatie over deze slots op de samenvattingspagina aan het einde van de module.

Apps implementeren in andere Azure-services

Azure biedt veel andere opties voor het hosten van uw apps, die elk een eigen implementatiebenadering hebben.

Azure Functions is gebaseerd op App Service en maakt gebruik van een implementatieproces dat vergelijkbaar is met het implementatieproces dat eerder is beschreven.

Als u implementeert op een virtuele machine, moet u normaal gesproken verbinding maken met het exemplaar van de virtuele machine om uw app te installeren. U moet vaak speciale hulpprogramma's gebruiken, zoals Chef, Puppet of Ansible, om een implementatie te organiseren op virtuele machines.

Als u Kubernetes of Azure Kubernetes Service (AKS) gebruikt, gebruikt u een iets andere benadering om uw oplossing te bouwen en te implementeren. Nadat uw app is gebouwd, maakt uw pijplijn een container-image en publiceert deze naar een containerregister, waarvan uw Kubernetes-cluster vervolgens leest. Omdat uw containerregister de gecompileerde toepassing bewaart, gebruikt u doorgaans geen pijplijnartefact.

In deze module richten we ons op Azure App Service om de betrokken pijplijnconcepten te illustreren. Op de pagina Samenvatting aan het einde van de module vindt u koppelingen naar meer informatie over het implementeren naar andere hostingservices.

Apps testen in uw pijplijn

In een vorige module hebt u geleerd over de waarde en het belang van het uitvoeren van geautomatiseerde tests vanuit uw pijplijn. Wanneer u een app implementeert, is het een goede gewoonte voor de pijplijn om enkele tests uit te voeren die de code van de app aanroepen. Dergelijke tests verminderen het risico dat een app- of implementatiefout downtime kan veroorzaken. In geavanceerdere scenario's kunt u zelfs een set testcases uitvoeren op uw app, zoals het aanroepen van API's of het verzenden en bewaken van een synthetische transactie.

Veel apps implementeren eindpunten voor gezondheidscontrole. Wanneer een statuscontrole-eindpunt een aanvraag ontvangt, voert het een reeks controles uit op de website, zoals ervoor zorgen dat databases en netwerkservices bereikbaar zijn vanuit de app-omgeving. Het antwoord dat door de site wordt geretourneerd, geeft aan of de app in orde is. Ontwikkelaars kunnen hun eigen gezondheidscontroles schrijven en aanpassen aan de vereisten van de app. Als uw app een statuscontrole-eindpunt heeft, is het vaak zinvol om deze vanuit uw pijplijn te bewaken nadat de implementatiefase is voltooid.

Uw implementatiepijplijn

In de volgende oefening werkt u uw implementatiepijplijn bij om nieuwe taken toe te voegen om de toepassing van uw website te bouwen en deze in elke omgeving te implementeren: