1.1 Deploy Web Apps
Define deployment slots; roll back deployments; implement pre- and post- deployment actions; create, configure, and deploy packages; create App Service plans; migrate Web Apps between App Service plans; create a Web App within an App Service plan
Den største fordelen ved å bruke en Paas (Platform as a Service) som Azure App Services for å bygge applikasjoner, er produktivitetsnivået du kan oppnå. Gjennom en PaaS trenger du ikke forvalte OS eller den underliggende hardware siden dette er ivaretatt av selve tjenesten. Istedenfor har du mulighet til å kunne fokusere på å bygge og tilpasse selve applikasjonen. Sammenlignet med tradisjonell deployment av en applikasjon i et on-premise-miljø, så er deployment av en web app rimelig rett fram, og kan gjøres med få klikk i Azure-portalen.
Azure sin plattform er utviklet fra et DevOps-perspektiv, hvor du kan integrere med f.eks. GitHub for å forvalte kildekoden med en "continueous delivery"-tilnærming. I denne sammenheng kan også BitBucket, Local Git og Visual Studio Online nevnes.
I tillegg finnes det også helt enkle metoder å forvalte kildekoden på, som f.eks. FTP, OneDrive eller Dropbox.
Azure App Service består i hovedsak av fem hovedkomponenter:
- Web apps: Web-baserte applikasjoner som kan skaleres basert på kravene og behovene til bedriften
- Mobile apps: Applikasjoner som kan kjøre på alle enheter
- Logiske apps: For automatisering av prosesser og integrasjon av systemer og data på tvers av skyen uten å måtte skrive kode
- API apps: For å forvalte REST API-er som tjenester kan benytte seg av, slik som f.eks. i et IoT-scenario
- Funksjoner: Hendelsesbaserte applikasjoner som f.eks. kan brukes for å spinne opp en applikasjon automatisk ved behov.
1.1.1 Define deployment slots
Når du arbeider med utvikling og test av en webapplikasjon som skal produksjonssettes, så kan det komme med som et veldig nyttig verktøy å opprette såkalte deployment slots. En deployment slot lar deg deploye ulike instanser av ditt prosjekt til forskjellige liknende URL-er, noe som gjør det enkelt å sammenligne ulike versjoner av din web app i parallell.
Fordelen med deployment slots er at du får muligheten til å validere endringene du gjør til din web app gjennom å deploye endringene til en test-utgave, for så å "swappe" denne inn som produksjonsutgaven dersom den fungerer tilfredsstillende. Swapping er i realiteten bare et re-routing av endepunktene til de involverte deployment slotsene. Dette skjer helt sømløst, og vil gi deg null nedetid i forbindelse med oppdatering.
Hvor mange forskjellige slots som støttes avhenger av hvilken app service plan applikasjonen din er knyttet til, som beskrevet i Kapittel 1.1.5 nedenfor. App service plan må være enten i kategorien Standard som støtter inntil 5 slots, eller Premium, som støtter inntil 20 slots.
Når du legger til en deployment slot, vil denne kunne nås med en URL på formatet:
[navn på web app]-[navn på deployment slot].[domene], som i mitt tilfelle da blir: dagsle-staging.azurewebsites.com
NB! For å kunne benytte seg av Deployment Slots krever man en Service Plan som er Standard eller Premium.
Set up staging environments in Azure App Service: https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing
Why Azure Deployment Slots are Awesome and How to Use Them: https://stackify.com/azure-deployment-slots/
1.1.2 Roll back deployments
Dersom en stor bug blir funnet i en ny utgave av web appen, har du til enhver tid mulighet til også å swappe tilbake igjen til forrige utgave av applikasjonen som fungerte fint. På nøyaktig samme måte som du swappet mellom staging og production slot da du byttet til siste utgave, så kan du utføre byttet én gang til for å komme tilbake igjen til utgangspunktet. Inne på web appen, velg Deployment slots og deretter velg "Swap".
Deretter, velg hvilken slot som du ønsker å rulle tilbake som "source", og så hvilken slot du ønsker å rulle tilbake til som "destination". Klikk deretter OK, så skjer roll back innen kort tid.
1.1.3 Implement pre- and post-deployment actions
https://github.com/projectkudu/kudu/wiki/Post-Deployment-Action-Hooks
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-deploy
Har ikke funnet noe god informasjon på nettet om dette.
1.1.4 Create, configure, and deploy packages
- Mange ulike metoder man kan publisere kode til WebApp
- Kudu.NET som er motor som synkroniserer innhold fra Git (lokalt/remote)/OneDrive/Dropbox
- Default er det FTP/SFTP, og kan kopiere f.eks med FileZilla.
- Egendefinerte script kan legges under tools-mappe site\deployments\tools som kjøres under publisering av filene.
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-deploy
1.1.5 Create App Services plans
Alle apper som opprettes må ha en app service plan, som kan sies å være en kontainer for din applikasjon. Denne kontaineren definerer grensene og mulighetene som finnes innenfor miljøet hvor applikasjonen skal kjøre.
Oppsett av en app service plan består av to valg:
- hvilken lokasjon appen skal kjøres fra.
- hva slags prisnivå (pricing tier) du ønsker. Jo høyere pris per måned, jo bedre ytelse og funksjonalitet vil du få med.
Det finnes fem ulike kategorier, sortert fra lav til høy funksjonalitet og pris:
- Free
- Shared
- Basic
- Standard
- Premium
Som standard benyttes pricing tier S1 standard, som vil gi kostnader på web appen til rundt 600kr per måned. Heldigvis finnes det også rimeligere varianter slik som F1 (free) eller D1 (shared*) som kun gir deg det nødvendige for å hoste en applikasjon. Dette er fine alternativer under labbing og testing. I forbindelse med produksjonsetting av en web app så vil man typisk velge en pricing tier med mer ytelse og funksjonalitet.
Hvilken pricing tier du velger for din app service plan beror på hvilke behov du har for applikasjonen, både når det gjelder ytelse og lagringskapasitet på den virtuelle maskinen som hoster applikasjonen, samt ekstra funksjonalitet som skalering til flere instanser, backup og trafikk-routing.
Selv om én applikasjon kun kan være medlem av én app service plan, så kan én app service plan ha flere applikasjoner assosiert med seg.
1.1.6 Migrate Web Apps between App Service plans
You can not currently migrate App Service plans for Web Apps between different resource groups.
The select App Service plan UI is filtered by the following criteria:
- Exists within the same Resource Group
- Exists in the same Geographical Region
- Exists within the same Webspace
Azure App Service plans in-depth overview: https://docs.microsoft.com/en-us/azure/app-service/azure-web-sites-web-hosting-plans-in-depth-overview
1.1.7 Create a Web App within an App Service plan
Når en web app skal opprettes så trenger du i første omgang kun å angi fire ulike valg, som er navn, abonnement, ressursgruppe og app service plan. Dersom man ikke selv velger app service plan aktivt, vil man automatisk få tildelt en app service plan plassert i sør-sentrale USA med prisnivå S1.
