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 werkstroom ontwerpt voor het bouwen en implementeren van een app naast de infrastructuur.
Apps bouwen
Veel soorten apps moeten worden gecompileerd of gebouwd voordat u ze kunt gebruiken. 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. Een buildproces omvat gewoonlijk andere activiteiten, waaronder het comprimeren van de afbeeldingsbestanden die worden geleverd aan de gebruikers van uw website, het linten van uw code om te controleren of deze goede codeprocedures volgt en eenheidstests uitvoert die het gedrag van afzonderlijke onderdelen van uw app verifiëren. U kunt 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 werkstroomloper. Latere onderdelen van uw werkstroom moeten samenwerken met het artefact om het te implementeren via uw omgevingen en deze testen naarmate deze vordert door de kwaliteitspoorten die u in uw werkstroomdefinitie definieert.
Notitie
Mogelijk hebt u gehoord van de termen continue integratie en continue implementatie, of CI/CD. Een buildproces bevindt zich binnen het onderdeel continue integratie van uw werkstroom.
Werkstroomartefacten
De artefacten die in uw werkstroom worden gegenereerd, worden niet opgeslagen in uw Git-opslagplaats. Ze worden afgeleid van de broncode, maar zijn geen code zelf, dus ze horen niet bij een opslagplaats voor broncodebeheer. Ze worden gemaakt in het bestandssysteem van de werkstroomloper. Er wordt een nieuwe runner gemaakt voor elke werkstroomtaak, dus u hebt een manier nodig om de bestanden tussen taken en hardlopers te delen.
Werkstroomartefacten bieden een manier om bestanden op te slaan in GitHub Actions en ze zijn gekoppeld aan de specifieke uitvoering van uw werkstroom. U gebruikt de actions/upload-artifact werkstroomactie om GitHub Actions te instrueren een bestand of map te uploaden vanuit het bestandssysteem van de runner als een werkstroomartefact:
- name: Upload folder as a workflow artifact
uses: actions/upload-artifact@v3
with:
name: my-artifact-name
path: ./my-folder
De path eigenschap is de locatie die uw gecompileerde code of uitvoerbestanden op het bestandssysteem van de jobrunner bevat. De inhoud op deze locatie wordt geüpload naar het artefact. U kunt één bestand, meerdere bestanden of een map opgeven.
Elk artefact heeft een naam, die u opgeeft met behulp van de name eigenschap. U gebruikt de naam van het artefact om hiernaar te verwijzen verderop in de werkstroom. Volgende werkstroomtaken kunnen het artefact downloaden, zodat ze ermee kunnen werken, bijvoorbeeld om de website te implementeren op de server waarop het wordt gehost:
Gebruik de actions/download-artifact actie om alle werkstroomartefacten te downloaden:
- uses: actions/download-artifact@v3
U kunt ook een artefactnaam opgeven om alleen een specifiek artefact te downloaden:
- uses: actions/download-artifact@v3
with:
name: my-artifact-name
Apps implementeren
Het buildproces voor een app genereert en uploadt een implementeerbaar artefact. Latere taken in de werkstroom 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 azure/webapps-deploy actie:
- uses: azure/webapps-deploy@v2
with:
app-name: my-app-service
package: my-artifact-name/website.zip
U moet verschillende stukjes informatie opgeven om uw app te implementeren in App Service. Deze informatie bevat de resourcenaam van de App Service-app, die u opgeeft met behulp van de app-name eigenschap. Zoals u in de vorige les hebt geleerd, moet u een uitvoer toevoegen aan uw Bicep-bestand en een werkstroomvariabele gebruiken om de naam van de app door te geven via uw werkstroom. U moet ook een .zip-bestand opgeven met de app die moet worden geïmplementeerd met behulp van de package eigenschap. Dit is meestal het pad naar een werkstroomartefact.
App Service heeft een eigen verificatiesysteem voor gegevensvlakken dat wordt gebruikt voor implementaties. De azure/webapps-deploy actie verwerkt het verificatieproces automatisch voor u:
De azure/webapps-deploy actie maakt gebruik van de identiteit die is gekoppeld aan de actieve Azure-sessie van uw taak, die u hebt aangemeld met behulp van een workloadidentiteit
. Met de actie worden de benodigde referenties voor implementatie
gemaakt en gedownload. 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 overzichtspagina 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 we eerder hebben 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 naar virtuele machines te organiseren.
Als u Kubernetes of Azure Kubernetes Service (AKS) gebruikt, gebruikt u gewoonlijk een iets andere benadering om uw oplossing te bouwen en te implementeren. Nadat uw app is gemaakt, maakt uw werkstroom 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 werkstroomartefact.
In deze module richten we ons op Azure-app Service om de betrokken werkstroomconcepten 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 werkstroom
In een vorige module hebt u geleerd over de waarde en het belang van het uitvoeren van geautomatiseerde tests vanuit uw werkstroom. Wanneer u een app implementeert, is het een goede gewoonte voor de werkstroom 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 te controleren vanuit uw werkstroom nadat de implementatietaak is voltooid.
Uw implementatiewerkstroom
In de volgende oefening werkt u uw implementatiewerkstroom bij om nieuwe taken toe te voegen om de toepassing van uw website te bouwen en deze in elke omgeving te implementeren:
