Vanaf 4 augustus (link) tot ongeveer 4 december (link) ben ik bezig geweest met de voorbereidingen voor de Azure AZ-204 certificering. Een (verouderd) boek lezen, de pluralsight-courses volgen en de blokken die je zelfstandig via de site van Azure kunt volgen, met een Sandbox-account in Azure zodat je echte zaken kunt uitvoeren.
Werd ik de vorige keer al negatief verrast omdat ik dacht alle blokken afgerond te hebben (en toen bleken er nog 2 blokken bij gekomen te zijn), op 15 december ontplofte ik helemaal. Want toen ik naar de pagina voor Azure 204 ging (link) en naar beneden scrolde waren alle blokken die ik afgerond had weg: er staan nu 12 nieuwe blokken.
Niet al mijn werk/inspanningen zijn nu weggegooide moeite, maar wat ik van 10 november tot 4 december gedaan heb, op vrije dagen door de blokken heen gaan, de uitleg doorlezen, de oefeningen uitvoeren, de samenvattingen maken, uiteindelijk doe je dat om jezelf voor te bereiden voor het examen. En die voorbereiding mag ik nu dus nog een keer doen. Dat ik hier een beetje droevig van wordt is wel het understatement van het jaar.
Ik ga natuurlijk nu niet nog een maand bezig met deze blokken, ik gooi even de turbo op het doorlopen van de oefeningen. Want er zullen vast nog wel zaken in terugkomen die ik in die "oude blokken" al behandeld heb.
We starten met blok 1: Create Azure App Service web apps, link.
Module 1: Explore Azure App Service, link.
De App Service kun je gebruiken om websites, REST API's en mobiele back-ends online te krijgen. Dat kan met .NET, .NET Core, Python, Ruby, Java, PHP, Node.js. Opschalen en terug schalen wordt standaard ondersteund (verhogen van bijvoorbeeld beschikbare RAM) en ook het uitschalen en terugschalen (je app op meerdere machines draaien om de load te verdelen) wordt ondersteund. Met Azure DevOps, GitHub, BitBucket, FTP of lokale GIT-repo kun je zorgen voor een CI/CD traject. En met deployment-slots kun je zorgen dat een nieuwe deploy meteen een "warme start" krijgt en heb je bijna geen downtime. Deployment slots zijn alleen in Standard en Premium abonnementen beschikbaar.
Ook kunnen native zaken op Linux gehost worden, Node.js, Java (JRE 8 en JRE 11), PHP, Python, .NET Core en Ruby. Omdat de lijst uitgebreid kan worden, kun je met onderstaand statement raadplegen welke momenteel ondersteund worden:
az webapp list-runtimes --linux
App Service voor Linux heeft wel een aantal beperkingen/voorwaarden:
- bij een Shared abonnementen kun je geen Linux App Service aanmaken.
- je kunt geen Windows en Linux apps in hetzelfde App Service plan mixen.
- in oude resource-groups kon je dit ook niet mixen, rg's die na 1 januari 2021 aangemaakt zijn wel. Oude rg's worden binnenkort bijgewerkt zodat dit ook ondersteund wordt.
- de Azure portal toont alleen features die nu bij Linux apps werken. Als er nieuwe features zijn, zul je die in de portal zien.
In een App Service plan geef je de instellingen aan.
- regio (west Europa, noord Europa)
- aantal virtuele machines
- grootte van de virtuele machines (small, medium, large)
- prijscategorie (free, shared, basic, standard, premium, premiumv2, premiumv3, isolated)
De prijscategorie heeft invloed op wat wel en niet kan:
- gedeelde bronnen, free en shared draaien op shared resources. dus elke app krijgt een CPU quota en kan niet uitschalen.
- toegewezen bronnen, basic, standard, premium, premiumv2 en premiumv3 draait op "dedicated VMs". Alleen jouw apps in hetzelfde App Service plan delen deze bronnen. Hoe hoger het type, hoe meer VM's je beschikbaar hebt om uit te schalen.
- geïsoleerd: hier draai je op toegewezen Azure Virtuel Networks. Zorgt voor netwerk isolatie naast de isolatie van de bronnen van je apps. Biedt de maximale uitschaal-mogelijkheden.
- consumptie: alleen beschikbaar voor function apps. Schaalt de functies dynamisch op basis van de workload.
Bij Free en Shared krijg je een aantal minuten toegewezen dat de applicaties kunnen draaien.
Om geld te besparen kun je al je apps in een app service plan plaatsen. Maar de resources worden dan wel verdeeld over al deze apps. Het kan dus de moeite waard zijn om een app in een eigen service plan te plaatsen. Kijk daarvoor of:
- de app flink wat resources nodig heeft.
- de app onafhankelijk van de rest geschaald moet worden.
- de app bronnen in een ander geografisch gebied nodig heeft.
Automatisch deployment, ondersteund bij Azure DevOps, GitHub en Bitbucket.
Handmatig deployen: Git, CLI, Zip deploy en FTP/S.
In App Service heb je de mogelijkheid om gebruik te maken van de authenticatie die Azure biedt.
- Het scheelt je werk, je hoeft het zelf niet te implementeren.
- Het is ingebouwd in het platform, heeft geen SDK of code nodig.
- Je kunt met meerdere providers integreren, Azure AD, Facebook, Google, Twitter.
| Provider | Sign-in endpoint | How-To guidance |
|---|---|---|
| Microsoft Identity Platform | /.auth/login/aad | App Service Microsoft Identity Platform login |
| /.auth/login/facebook | App Service Facebook login | |
| /.auth/login/google | App Service Google login | |
| /.auth/login/twitter | App Service Twitter login |
De authenticatie en autorisatie-module draait in dezelfde sandbox als jouw applicatie. Als het geactiveerd is, gaat elk request door deze module en wordt onder andere het volgende gedaan: authenticatie met de provider, validatie, opslaan en verversen van tokens, beheert de geauthenticeerde sessie en injecteert identity-informatie in de headers.
De module draait los van je code en is geconfigureerd via de app settings. Geen SDK, geen specifieke programmeertalen en ook geen aanpassingen in jouw code. In Linux en containers draait dit in een losse container, geïsoleerd van jouw code. Omdat het (dus) niet in-process draait is geen directe integratie met frameworks mogelijk.
De flow voor authenticatie is voor alle providers gelijk, maar is anders afhankelijk of je met de SDK van de provider in wilt loggen. Zonder de SDK van bijvoorbeeld Twitter of Facebook, hierbij delegeert de applicatie "federated" sign-in naar de App Service. Dit zijn vaak browser apps, die de login pagina van de provider kunnen tonen. De server code beheert het inlogproces, zodat het ook wel server-directed flow of server flow genoemd wordt.
Als je wel de SDK gebruikt, daarbij logt een gebruiker handmatig in en stuurt het authenticatie-token naar de App Service voor validatie. Dit zijn vaak apps zonder browser, deze kunnen dus niet de inlogpagina tonen. De code van de applicatie voert het inloggen uit, dit wordt vaak client-directed flow of client flow genoemd. REST API's, Azure Functions, JavaScript browser clients en native mobiele apps gebruiken dit vaak.
We krijgen nog even de (OAuth) flow te zien:
| Step | Without provider SDK | With provider SDK |
|---|---|---|
| Sign user in | Redirects client to /.auth/login/<provider>. | Client code signs user in directly with provider's SDK and receives an authentication token. For information, see the provider's documentation. |
| Post-authentication | Provider redirects client to /.auth/login/<provider>/callback. | Client code posts token from provider to /.auth/login/<provider> for validation. |
| Establish authenticated session | App Service adds authenticated cookie to response. | App Service returns its own authentication token to client code. |
| Serve authenticated content | Client includes authentication cookie in subsequent requests (automatically handled by browser). | Client code presents authentication token in X-ZUMO-AUTH header (automatically handled by Mobile Apps client SDKs). |
App Service kan zorgen dat een niet geauthenticeerde gebruiker automatisch naar /.auth/login/<provider> gestuurd wordt. Of een link tonen naar /.auth/login/<provider> zodat ingelogd kan worden met de provider naar keuze.
In de portal kun je instellen dat iemand die niet geauthenticeerd is het volgende krijgt:
- het kan toegestaan worden, er wordt dan op vertrouwd dat jouw app dit afhandelt. Een request die wel geauthenticeerd is, je krijgt dan ook de authenticatie informatie mee in de HTTP header. Hierdoor kun je zelf flexibel met de flow omgaan.
- of het wordt niet toegestaan. Je wordt of geredirect naar /.auth/login/<provider> of als het request van een native mobiele app komt kan een HTTP 401 Unauthorized teruggegeven worden. Je kunt die ook voor alle aanvragen instellen of een HTTP 403 Forbidden.
Standaard zijn apps in App Service via het internet bereikbaar en kunnen zelf alleen internet-hosted endpoints bereiken. Maar voor veel applicaties moet je zelf het inbound en outbound verkeer beheren.
De rollen die inkomend HTTP en HTTPS verkeer verwerken zijn front ends. De "workload", dus het echte werk wordt uitgevoerd door de workers. Als je wisselt tussen de verschillende prijscategorieën krijg je ook een ander outbound-adres. Met het onderstaande statement kun je zien welke adressen jouw app kan gebruiken:
az webapp show \
--resource-group <group_name> \
--name <app_name> \
--query outboundIpAddresses \
--output tsv
Als je alle mogelijke adressen, onafhankelijk van de prijscategorie, wilt zien kun je dit statement gebruiken:
az webapp show \
--resource-group <group_name> \
--name <app_name> \
--query possibleOutboundIpAddresses \
--output tsv
De opdracht is om een web-app te maken. Maar geen sandbox-account, dit moet met een eigen Free account (trial eigenlijk). Als je die al gehad hebt, kun je deze oefening dus niet doen.
In de cloud-shell maak je een map aan. Daar doe je:
git clone https://github.com/Azure-Samples/html-docs-hello-world.git
Je gaat vervolgens naar deze map. Dan voer je dit uit:
az webapp up --location <myLocation> --name <myAppName> --html
Je krijgt in de gegevens de naam van de resource-groep terug. Die heb je straks nodig bij het opruimen.
Pas wat aan en doe nogmaals de az webapp up, zodat je de aanpassing/upload kunt controleren.
Hierna de boel weer opschonen:
az group delete --name <resource_group> --no-wait
Module 2: Configure web app settings, link.
Omgevings-variabelen-configuratie
In app service worden app settings als variabelen doorgegeven en dan als "environment variabelen".
In je app kun je onder Settings - Configuration - Application Settings deze bekijken.
Het klinkt een beetje als een soort machine.config waarin je zaken kunt zetten die je niet in een eigen web.config/appsettings.json wilt zetten omdat de gegevens gevoelig zijn en je die niet in bezit van iemand anders wilt hebben. Deze App settings zijn "in rust" altijd geëncrypt.
Opmerking, een "geneste" structuur in JSON zoals ApplicationInsights:InstrumentationKey moet je hier opslaan als een ApplicationInsights__InstrumentationKey (2x underscore).
En je kunt ook instellen of ze in een swap-slot in beide opgenomen worden (of niet).
Algemene configuratie
Settings - Configuration - General settings kun je de volgende zaken aanpassen/beheren:
- Stack settings: welke software (Python, Ruby, etc.) en welke versie. Voor Linux en container apps kun je ook de opstart-commando's instellen.
- Platform settings: 32 of 64 bit, websocket protocol: ASP.NET SignalR of socket.io, always on: altijd aan, ook bij geen requests. standaard na 20 minuten "unloaded". Maar bij continue WebJobs of WebJobs die door CRON getriggerd worden moet always on aangevinkt zijn. managed pipeline mode: IIS mode, classic voor legacy apps die een oudere IIS versie nodig hebben. HTTP version: zet op 2.0 om HTTPS/2 te ondersteunen. ARR affinity: bij meerdere instanties de client tijdens de sessie op dezelfde instantie routeren. als een app stateless is deze dus op Off zetten.
- Debugging: remote debugging voor ASP.NET, ASP.NET Core, Node.js aan zetten. Gaat 48 uur later automatisch weer op "off".
- Incoming client certificates: bij wederzijdse authenticatie afdwingen dat de client een certificaat aanlevert.
Path mapping
Hier kun je handler mappings, virtuele applicaties en directory mapping instellen. Weergave is afhankelijk van het OS.
Windows (niet in een container)
IIS handler mappings, virtuele applicaties en directories (mappen).
Met handler mappings kun je aangeven dat een bepaalde extensie (bestand.dirk) afgehandeld moet worden door een bepaalde applicatie. Bij het aanmaken geef je dus de extensie aan, pad naar de script processor en je kunt nog optionele command-line argumenten mee geven.
Linux en containers
Je kunt hier nieuwe opslaglocatie(s) toevoegen. Als je New Azure Storage Mount uitvoert dan geef je daar aan wat de Name (te tonen naam), Configuration Options (Basic of Advanced), Storage Accounts (waar moet het opgeslagen worden), Storage Type (Azure Blobs of Azure Files --> Windows ondersteunt alleen Azure Files), Storage container (basic config, de container die toegevoegd wordt), Share name (advanced config, file share name), Access key (advanced config, access key), Mount path: absolute pad in je container om de nieuwe storage te "mounten".
Diagnostische logging aanzetten
Soms gaat er wat fout en wil je logs checken.
Windows
Bij je app kun je onder App Service logs zaken configureren. "On" voor hetzij Application Logging (Filesystem of Blob of beide).
Via Filesystem is een tijdelijke zaak, na 12 uur wordt dit weer inactief.
Blob is voor langere duur en heeft een blob storage container nodig voor opslag. Je kunt daar ook de mate van detail instellen.
| Level | Categorieën |
|---|---|
| Disabled | None |
| Error | Error, Critical |
| Warning | Warning, Error, Critical |
| Information | Info, Warning, Error, Critical |
| Verbose | Trace, Debug, Info, Warning, Error, Critical (alle categorieën) |
Linux / containers
In Application Logging, ga naar File System. Hier kun je de hoeveelheid MB instellen voor de limieten van de logs. Bij Retention Days kun je instellen hoeveel dagen de logs bewaard moeten blijven.
Web Server Logging
Op het niveau van de webserver stel je dit in bij Web server logging, Storage voor blob en File system voor logs op disk op te slaan. Ook hier kun je Retention Days instellen.
Logging in code
Dat doe je met
System.Diagnostics.Trace.TraceError("If you're seeing this, something bad happened");
ASP.NET Core gebruikt hiervoor de Microsoft.Extensions.Logging.AzureAppServices
Stream Logs
Je wilt de logs bekijken.
Ga in de Portal naar je app en dan naar Log Stream.
Azure CLI (of lokale console): in de Cloud Shell kun je dit commando gebruiken:
az webapp log tail --name appname --resource-group myResourceGroup
Toegang tot de bestanden op het bestandssysteem doe je op de volgende manier:
Linux/container apps: https://
Windows apps: https://
Hier nog even een overzicht van de verschillende types logging:
| Type | Platform | Location | Description |
|---|---|---|---|
| Application logging | Windows, Linux | App Service file system and/or Azure Storage blobs | Logs messages generated by your application code. The messages can be generated by the web framework you choose, or from your application code directly using the standard logging pattern of your language. Each message is assigned one of the following categories: Critical, Error, Warning, Info, Debug, and Trace. |
| Web server logging | Windows | App Service file system or Azure Storage blobs | Raw HTTP request data in the W3C extended log file format. Each log message includes data like the HTTP method, resource URI, client IP, client port, user agent, response code, and so on. |
| Detailed error logging | Windows | App Service file system | Copies of the .htm error pages that would have been sent to the client browser. For security reasons, detailed error pages shouldn't be sent to clients in production, but App Service can save the error page each time an application error occurs that has HTTP code 400 or greater. |
| Failed request tracing | Windows | App Service file system | Detailed tracing information on failed requests, including a trace of the IIS components used to process the request and the time taken in each component. One folder is generated for each failed request, which contains the XML log file, and the XSL stylesheet to view the log file with. |
| Deployment logging | Windows, Linux | App Service file system | Helps determine why a deployment failed. Deployment logging happens automatically and there are no configurable settings for deployment logging. |
Met certificaten kun je extra controles uitvoeren. Je kunt een certificaat toevoegen, dat kan dan door meerdere apps in dezelfde resourcegroep in dezelfde regio gebruikt worden.
Dit zijn de opties:
| Option | Description |
|---|---|
| Create a free App Service managed certificate | A private certificate that's free of charge and easy to use if you just need to secure your custom domain in App Service. |
| Purchase an App Service certificate | A private certificate that's managed by Azure. It combines the simplicity of automated certificate management and the flexibility of renewal and export options. |
| Import a certificate from Key Vault | Useful if you use Azure Key Vault to manage your certificates. |
| Upload a private certificate | If you already have a private certificate from a third-party provider, you can upload it. |
| Upload a public certificate | Public certificates are not used to secure custom domains, but you can load them into your code if you need them to access remote resources. |
Het App Service managed certificate en het App Service certificate voldoen al aan deze eisen, maar als je zelf een private certificate toevoegt, moet die aan deze eisen voldoen:
- geëxporteerd als PFX (met wachtwoord beveiligd), encrypted met triple DES
- bevat private key van minimaal 2048 bits
- bevat alle "intermediate" certificaten in de certificate chain
Als je een "custom domein" in een TLS binding wilt beveiligen, moet het certificaat ook nog voldoen aan:
- bevat een Extended Key Usage voor server authenticatie (OID = 1.3.6.1.5.5.7.3.1)
- is getekend door een trusted certificate authority
Als je een free managed certificate wilt gebruiken, moet je minimaal een Basic abonnement hebben.
Dit certificaat zorgt voor de beveiliging van jouw DNS naam in App Service. TLS/SSL certificaat wat volledig door App Service beheerd wordt en elke keer met een half jaar verlengd wordt (en 45 dagen voor verlopen wordt verlengd).
De volgende beperkingen gelden:
- wildcard wordt niet ondersteund
- ondersteunt niet het gebruik van een client certificaat met thumbprint
- je kunt het certificaat niet exporteren
- geen ondersteuning bij App Service Environment (ASE)
- geen ondersteuning bij root domeinen met Traffic Manager integratie
- als het certificaat voor een CNAME domein is, dan moet deze gemapt worden naar <app-name>.azurewebsites.net
Als je een App Service Certificaat van Azure koopt dan zorgt Azure:
- dat het certificaat gekocht wordt bij GoDaddy
- voert domein verificatie uit voor het domein
- beheert het domein in Azure Key Vault
- zorgt voor het vernieuwen
- synchroniseert het certificaat automatisch met de geimporteerde kopiën in App Service apps
Als je al een werkend App Service certificaat hebt kun je:
- deze importere in de App Service
- het certificaat beheren (vernieuwen, exporteren, etc.)
Als je meerdere certificaten van je certificate leverancier krijgt, moet je deze "mergen" in de juiste volgorde. Hierna kun je deze exporteren met de private key waarmee je request gegenereerd is.
Als deze via OpenSSL gegenereerd is, dan is dit het commando:
openssl pkcs12 -export -out myserver.pfx -inkey <private-key-file> -in <merged-certificate-file>
Het beheren van features
Het doorvoeren van features in code is niet meer afhankelijk van releases.
Feature flag: een variabele met een binaire staat van "aan" of "uit". Deze zorgt ervoor of code wel of niet uitgevoerd wordt.
Feature manager: hiermee beheer je alle feature flags in een applicatie.
Filter: een regel voor het evalueren van de status van een feature flag. Een gebruikersgroep, een device of browser-type, geografische locatie, tijdsblok, allemaal voorbeelden van mogelijke filters.
De weergave van code is duidelijk: if (featureFlagOne)...
De declaratie lichten we wel toe. Deze bestaat uit een naam gevolgd door één of meer filters waarmee bepaald wordt of deze feature "aan" staat. Zodra er maar 1 match is, hoeft niet meer verder gecontroleerd te worden en is de feature "aan".
Module 3: Scale apps in Azure App Service, link.
Autoscaling kan geactiveerd worden op basis van een tijdsschema (met kerst wordt het druk, dus maar automatisch opschalen dan) of op basis van resources die beginnen te knellen (teveel HTTP calls).
Om te voorkomen dat autoscaling uit de hand loopt zijn er limieten. Bij duurdere abonnementen heb je hogere limieten.
Op basis van resources, daarbij kun je deze instellen op:
CPU percentage, geheugen percentage, disk queue lengte, HTTP queue lengte, data in (binnenkomende bytes), data out (verzonden bytes).
Een autoscale regel verzamelt data gedurende een bepaalde periode, de time grain. Elke metriek heeft zijn eigen time grain, maar meestal is dit 1 minuut. De waarde is de time aggregation. Opties zijn Average, Minimum, Maximum, Total, Last en Count.
1 minuut is te kort, dus de volgende stap zorgt voor meer aggregatie tijdens de Duration (welke minimaal 5 minuten is). Je zou die zelf op 10 minuten kunnen zetten. Als de time grain statistics ingesteld is op Maximum, dan wordt de hoogste waarde van deze Duration gepakt.
Een autoscale actie is een scale-out of scale-in. Scale-out maakt meer instanties aan, scale-in ruimt ze op. Een autoscale actie heeft een "cool down" periode: in minuten. Tijdens deze interval zal de regel niet getriggerd worden. Hierdoor kan het systeem stabiliseren tussen autoscale acties. Onthou dat het even duurt voordat zaken opstarten of afsluiten en de metrieken daardoor geen verandering zien. Minimum cool down is 5 minuten.
Je moet autoscale regels "pairen", 1 voor het opschalen van de resources en 1 voor het afschalen van de resources.
Scale out werkt altijd met een "of" op meerdere regels, een scale in werkt altijd met een "en" op meerdere regels.
We zien daarna hoe je dit inregelt in het Azure Portal.
Autoscaling is horizontaal, je schaalt uit en in. Autoscale heeft een maximum, minimum en standaard waarde voor het aantal instanties.
De autoscale job controleert altijd de metriek waarbij het schaalt om te zien of en treshold geraakt is.
Thresholds worden op "instance level" berekend. Dus "uitschalen met 1 instantie als gemiddelde CPU > 80% is wanneer er 2 instanties zijn" betekent dat er uitgeschaald wordt wanneer de gemiddelde CPU op al deze instanties groter dan 80% is. Heeft 1 van de 2 het zwaar: jammer dan.
Alle autoscale successen en mislukkingen worden gelogd in het Activity Log. Hier kun je een alert instellen, zodat je een mail, SMS of webhook activeert als er activiteit is.
We krijgen een overzicht van de best practices.
Zorg dat maximum en minimum verschillende waardes zijn en zorg dat er een redelijke marge tussen zit.
Gebruik voor je metrieken de correcte waarde. In de meeste gevallen is Average de juiste (alternatieven zijn Minimum, Maximum en Total).
Kies je thresholds voor alle metrieken met zorg. Gebruik verschillende metrieken voor de scale in en de scale out.
Als de ene groter of gelijk aan 600 is en de andere kleiner of gelijk aan 600 is, dan krijg je een ping-pong effect (flapping).
We krijgen het voorbeeld, waarbij er afgeschaald zou kunnen worden. Maar de metriek gaat rekenen wat met deze waardes de verwachte load is en komt tot de conclusie dat er dan weer bijgeschaald moet worden. Resultaat: er wordt niet afgeschaald. Zorg dus dat je limieten afwijken.
En wat is het nut van de default? Als er op 1 of andere manier geen metrieken beschikbaar zijn is dit de waarde die gebruikt wordt. Dus heb je bijna altijd wel 3 instanties nodig, zet deze waarde dan niet op 1, want dan krijg je waarschijnlijk problemen.
In het Activity Log kun je terug zien (en hier kun je mailtjes e.d. aan koppelen):
- er wordt een autoscale actie gestart
- er is succesvol een autoscale actie afgerond
- er is iets fout gegaan bij een autoscale actie
- er zijn geen metrieken beschikbaar om een autoscale actie te bepalen
- de metrieken zijn weer beschikbaar (recovery) om beslissingen te nemen
Module 4: Explore Azure App Service deployment slots, link.
Als je een Standard, Premium of Isolated abonnement hebt kun je gebruik maken van deployment slots.
- je kunt hierdoor eerst controleren of je nieuwe deploy productiewaardig is
- het systeem is "opgewarmd", dus er hoeven geen connecties verbroken te worden en de "eerste bezoeker" hoeft de app niet op te starten
- door te swappen kun je ook meteen "terug swappen" als blijkt dat er "toch iets niet goed gaat"
Dit zijn de stappen die gevolgd worden om te zorgen dat er geen downtime is:
als alles opgewarmd is, swap de 2 slots door de routing rules aan te passen.
- voer alle settings van het target slot door naar het swap slot:
- slot specifieke app settings en connectiestrings
- continuous deployment settings, indien aangezet
- app service authenticatie settings, indien aangezet
Elk van deze voorbeelden triggeren alle instanties in het swap slot om te herstarten. Tijdens "swap with preview", dit was dan ook meteen delaatste stap. Swap wordt nu gepauzeerd en je kunt controleren of de boel naar behoren werkt.
- wacht op elke instantie in het swap slot om de herstart af te ronden. Als er ook maar 1 instantie niet wil opstarten wordt de swap operatie ongedaan gemaakt, instellingen worden terug gezet en actie wordt afgebroken.
- als locale cache aan staat, trigger de cache door een HTTP request naar de root (/) te doen. op elke instantie in het swap slot. Wacht tot elke instantie een HTTP response geeft. Dit zorgt namelijk ook weer voor een herstart.
- als auto swap aan staat met "custom warm-up" trigger dan de Application Initiation door een HTTP request op de root (/) van elke instantie te doen.
- als applicationInitialization niet gespecificeerd is, trigger weer een HTTP request
- als er een HTTP response is, nemen we aan dat de boel opgewarmd is
- Om te zorgen dat instellingen "swappable" zijn, plaats de app setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS in elk slot en zet de waarde op 0 of FALSE.
Instellingen zijn of allemaal swappable of allemaal niet. Je kunt niet een deel swappable maken. Managed Identities worden nooit geswapped en worden dus ook niet beïnvloed door deze instelling.
Nog even een overzicht van wat wel en wat niet geswapped wordt:
| Settings that are swapped | Settings that aren't swapped |
|---|---|
| General settings, such as framework version, 32/64-bit, web sockets | Publishing endpoints |
| App settings (can be configured to stick to a slot) | Custom domain names |
| Connection strings (can be configured to stick to a slot) | Non-public certificates and TLS/SSL settings |
| Handler mappings | Scale settings |
| Public certificates | WebJobs schedulers |
| WebJobs content | IP restrictions |
| Hybrid connections * | Always On |
| Virtual network integration * | Diagnostic log settings |
| Service endpoints * | Cross-origin resource sharing (CORS) |
| Azure Content Delivery Network * |
Features marked with an asterisk (*) are planned to be unswapped.
Je kunt dus ook een preview doen. In dat geval kun je op de URL https://<app_name>-<source-slot-name>.azurewebsites.net bekijken hoe de app gaat werken.
In de algemene instellingen kun je ook aangeven dat je wilt Auto swappen, vinkje zetten bij Configuration, General Settings. Linux apps ondersteunen dit (nog) niet.
Je kunt ook een eigen warm-up instellen. Dus dat niet (alleen) de root aangeroepen wordt, maar ook andere pagina's. Voorbeeld:
<system.webServer>
<applicationInitialization>
<add initializationPage="/" hostName="[app hostname]" />
<add initializationPage="/Home/About" hostName="[app hostname]" />
</applicationInitialization>
</system.webServer>
Hoe je die tag in kunt stellen, Microsoft Azure verwijst hiervoor naar een externe site (goh, die zag ik niet aankomen): link, schijnbaar iemand die een goed verhaal hierover opgezet heeft, ik had verwacht dat Azure hier zelf documentatie over had.
En je kunt nog een paar andere zaken instellen:
- WEBSITE_SWAP_WARMUP_PING_PATH: als je niet wil dat / aangeroepen wordt, maar bijvoorbeeld /swagger
- WEBSITE_SWAP_WARMUP_PING_STATUSES: standaard zijn alle statussen geldig. je kunt hier zelf een komma-gescheiden lijst invullen, bijvoorbeeld 200,202. Ik kan me voorstellen dat je bij een 500 status de swap wilt afbreken
Standaard wordt je verkeer gestuurd naar http://<app_name>.azurewebsites.net maar je kunt ook instellen dat een deel van je verkeer naar een andere URL gaat, bijvoorbeeld om nieuwe features te testen.
Bij je app, tabblad Deployment slots, hier kun je in het Traffic veld een percentage plaatsen en zo een deel naar dit slot laten gaan. Bij een nieuw slot staat dit standaard op 0%. In de browser kun je in de headers zien waar je heen gaat, via de header x-ms-routing-name, dus x-ms-routing-name=staging bij een staging-slot en x-ms-routing-name=self bij een productie-slot.
Als iemand via een bepaalde route binnen gekomen is kun je deze terug sturen naar de andere route via een link die er zo uit ziet: https://<webappname>.azurewebsites.net/?x-ms-routing-name=self of https://<webappname>.azurewebsites.net/?x-ms-routing-name=staging