Toepassingen en virtuele machines configureren
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 van uw code om te controleren of deze goede coderingsprocedures volgt.
- Eenheidstests uitvoeren om het gedrag van afzonderlijke onderdelen van uw app te 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 samenwerken met het artefact om het te implementeren via uw omgevingen en deze testen naarmate de kwaliteitspoorten worden doorlopen die u in uw pijplijndefinitie definieert.
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 uw pijplijn. U gebruikt de PublishBuildArtifacts ingebouwde pijplijntaak om Azure Pipelines opdracht te geven om 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 pathToPublish eigenschap is de locatie die uw gecompileerde code of uitvoerbestanden bevat in het bestandssysteem van de pijplijnagent. De inhoud op deze locatie wordt gepubliceerd naar het artefact. U kunt één bestand of een map opgeven.
Elk artefact heeft een naam, die u opgeeft met behulp van de artifactName taakeigenschap. U gebruikt de naam van het artefact om dit later in de pijplijn te raadplegen. 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 naar 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 de App Service-app die u opgeeft met behulp van de ResourceGroupName en WebAppName invoer. 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 benodigde referenties voor implementatie
te maken en te downloaden. Vervolgens worden de implementatiereferenties gebruikt wanneer deze communiceert met de App Service-gegevensvlak-API
.
App Service biedt ook enkele andere implementatiefuncties, waaronder implementatiesites. Sites helpen u veilig nieuwe versies van uw apps te implementeren zonder uitvaltijd. 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 sites in deze module, maar we bieden een koppeling naar meer informatie over deze sites op de pagina Samenvatting 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 gemaakt, maakt uw pijplijn een containerinstallatiekopie en publiceert deze naar een containerregister, waar uw Kubernetes-cluster vervolgens van 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 statuscontrole-eindpunten. 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 statuscontroles 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:
