Als ik eerlijk ben heb ik "geen tijd" om met een nieuwe studie bezig te gaan. Na een werkdag van 8 uur zit ik 's avonds nog vaak achter mijn pc. Bijvoorbeeld podcasts van Scott Hanselman uitwerken, zaken die daarin genoemd zijn te testen. Zo wil ik "nog eens" naar Angular kijken, dat betekent het uitzoeken hoe dat framework in elkaar zit. Maar ik heb ook nog een paar domeinnamen waar ik werkende websites op wil plaatsen, ik wil mijn eigen Zabbix monitoring beter uitwerken, een eigen notificatie-hub opzetten. Ik heb een eigen TODO-app gemaakt waarin de lijst zo nu en dan wordt aangevuld, daar staan nu 32 zaken open waar ik nog wat mee moet doen. En dan ga je ook nog bezig met een studie?
Maar goed, toen ik in 2014 bij TRES kwam, was de insteek dat ik dat wel meer zou doen. Je kunt wel veel in eigen tijd doen en met zaken bezig zijn en uitzoeken hoe het werkt, op je CV (en/of LinkedIn) staat het goed als je een certificaat gehaald hebt, zodat je huidige en volgende werkgever(s) kunnen zien dat een onafhankelijke organisatie beoordeeld heeft dat je voldoende kennis had/hebt om het examen af te ronden. Zo heb ik in 2020 met mijn collega Dirk Jan de fundamentals behaald van Microsoft Azure, dit jaar, 2021, wordt het tijd voor AZ-204. Dat is gericht op development van applicaties in de Azure-omgeving, naast onze eigen hosting zijn er enkele projecten die al in Azure draaien. Als je jezelf een "senior developer" noemt hoor je natuurlijk ook kennis van zaken te hebben zodat je zelf je weg kunt vinden en ook dat je collega's bij vragen en problemen kunt helpen.
Een tijd geleden heeft een collega de AZ-203 gevolgd en hier het boek voor gelezen. Hoewel de 204 niet gelijk is aan de 203 zullen er overeenkomsten zijn. In maart 2021 zijn van 204 de specs aangepast, dus hoewel ik dit boek ga lezen, zijn er natuurlijk (meer?) verschillen. De link naar de site van Azure waarin staat wat de specs voor 204 zijn is hier te vinden: link.
Maar goed, eerst het boek en daarna die specs behandelen. We beginnen met hoofdstuk 1, het ontwikkelen van een Azure infrastructuur "as a service compute solution". Hierbij worden 3 onderdelen benoemd, de VM (virtuele machines), Azure Batch Services en containers.
Hoewel deze zaken niet heel ingewikkeld lijken, moet je daarmee oppassen. Vaak krijg je dan vragen waarvan je denkt: "stond dat in het boek?". We lopen het even stuk voor stuk door.
Virtuele Machine
Met een VM heb je nog veel gedoe om het operating system op de VM draaiende te houden. Op een VM kun je Windows, Windows Server en Linux draaien. De lijsten kun je hier en hier bekijken. Deze kun je in de Marketplace vinden, hier kunnen ook andere leveranciers hun VM's aanbieden. Je geeft bij een VM de eigenschappen: naam, locatie (west europa bijvoorbeeld), grootte (geheugen, disk, processors), limieten (een subscription kan per regio 20 VM's hebben), extensies (scripts uitvoeren, deployment en configuratie beheren, diagnostische data verzamelen), gerelateerde resources (resource groep waar de VM in zit, storage account voor opslaan "disk data", virtueel netwerk en netwerk interface).
Je kunt de VM met verschillende methodes benaderen. Azure Portal, PowerShell, Azure CLI of via de REST API of met C#.
Je kunt je VM opbouwen met een ARM template, dit is een stuk JSON-code. Parameters bestaan uit een naam, type en "default value". Via een parameter-file kun je jouw eigen waardes voor de variabelen doorgeven. Anders wordt de default value gekozen. Je kunt hier de handleiding voor de templates bekijken: link en hier de functies die je in templates kunt gebruiken: link. Een item kan een parent zijn voor child-items. Maar een parent-item kan eerder aangemaakt worden dan de child-items. Als een parent afhankelijk is van één of meerdere child-items moet je dat expliciet aangeven met dependsOn.
De virtuele disk van je VM is geëncrypt. Maar de data "op die disk", dus binnen je VM is dat niet. Dat kun je wel regelen, maar er zijn een paar uitzonderingen waarbij dat niet kan. De vraag is, moet je dat allemaal voor het examen weten? In het echt ga je in de specs wel kijken of het voor jouw VM wel of niet kan. Encryptie wordt ondersteund op Windows VM's, Linux VM's (moet minimaal 7GB geheugen hebben). Virtual Machine Scale Set, Windows kan, Linux alleen bij data-disks. Managed Disks, daar kun je het ook op aanzetten. Basic-tier, OS Drives voor Linux en data-drives voor Linux waarbij het OS al geëncrypt is, in deze gevallen kun je geen encryptie gebruiken. Ook niet bij "classic VM's", Azure Files, Network File Systems (NFS), Dynamic Volumes en Windows VM die met RAID draait.
Azure Batch Services
Als je zware processen draait (het renderen van 3D animaties, het verwerken van een hoop grote afbeeldingen), daarvoor is een VM niet geschikt. Voor zulke zaken kun je gebruik maken van de Batch Service API.
Je hebt hier een batch account voor nodig. Binnen een batch account kun je meerdere workloads uitvoeren. Een pool is een verzameling van compute nodes, deze doen het werk. Een job organiseert hoe de taken uitgevoerd worden. En een taak is een script, commando of applicatie die uitgevoerd wordt. Voordat je iets met API calls kunt doen, dan moet je in het bezit zijn van het batch account name, de batch account URL (https://batch_account_name.region.batch.azure.com), batch account key voor authenticatie (als het goed is heb je er 2, daar moet je 1 van gebruiken), storage account name, storage account key (ook hier heb je weer 2 waarvan je er 1 moet gebruiken). Azure Batch Explorer kun je downloaden als cliënt voor Windows, Linux en Mac (link). Azure Batch ondersteunt het gebruik van Docker en Singularity containers.
Als je zelf een pool wilt configureren, dan kun je hier meer informatie vinden: link. Azure Powershell is hier op Github te vinden: link. Je kunt ook met C# werken, naast dat je een batch-account moet hebben kun je een .NET core project opzetten en daar de Microsoft.Azure.Batch en Microsoft.Azure.Storage nuget-packages aan toevoegen.
Containers
Docker is "de" partij die gebruikt wordt. En om die containers aan te sturen kun je gebruik maken van Azure Container Service (ACS) of Azure Managed Kubernetes Service (AKS). Het boek geeft al aan dat je met ACS nog veel zelf moet doen, terwijl de open-source code van Kubernetes en de implementatie die hier gebruikt wordt (AKS) dus je voorkeur zou moeten hebben. Een AKS cluster bestaat uit Cluster Master Nodes (deze nodes beheren het cluster en zorgen voor de aansturing) en de Nodes, deze bevatten de virtuele machines waarop jouw containers uitgevoerd zullen worden.
Een master node bestaat uit: API Server (beheerd via kubectl of Kubernetes Dashboard), scheduler (welke nodes kunnen werk doen), etcd (key-value store voor configuratie en status van het cluster), controller manager: stuurt andere controllers aan via bv. het dashboard, je kunt controllers hebben voor deployments, garbage collection.
Omdat Azure de boel beheert kun je zelf niet veel doen, je kunt de AKS logs bekijken in Azure Monitor logs. Andere admin-acties voer je uit via de Azure Portal of Azure CLI.
Elke node bestaat uit een kubernetes agent (kubelet), die voert de opdrachten van de master node uit. Proxy, beheert het virtuele netwerk op de node. Container runtime, component wat ervoor zorgt dat de container kan "draaien" en toegang heeft tot netwerk en opslag.
Als je een AKS node maakt stel je de grootte in. Een agent heeft 60ms van de CPU en 20% van het geheugen nodig (tot maximaal 4GB).
Tijdens het schrijven van dit boek konden alleen Ubuntu VM's als nodes in een cluster gebruikt worden. Voor meer informatie kun je op de aks-engine github-pagina kijken: link. Ik heb nog even gezocht en volgens mij kan nu ook gewoon Windows gebruikt worden: link.
De volgende termen horen bij het deployen van containers naar een AKS:
Pod, een resource voor 1 of meerdere containers, waarin schedules, limieten e.d. ingesteld kunnen worden.
Deployments, 1 of meerdere gelijksoortige pods kunnen in een deployment samengevoegd worden. Dit zorgt voor het automatisch herstarten als er een probleem optreedt.
YAML manifests, de werking van een deployment wordt in een YAML file uitgewerkt. De sleutelwaarde "kind" geeft het type van de pod weer: deployment, statefulset, daemonset.
Statefulset: hierin hebben de pods een vast IP adres, de opslag blijft bewaard, deployment en schalen wordt netjes afgehandeld.
Daemonset: deze pods worden gegarandeerd gedeployed naar elke node in het manifest. Wordt vaak gebruikt voor het verzamelen van logs.
Met deze tutorial kun je zelf het aanmaken van een AKS doorlopen: link.
Voor je eigen oplossingen kun je jouw eigen docker-files maken. Hoe je dat het beste kunt doen, dat kun je hier nalezen: link.
Het boek geeft nog een afsluitende examen-tip. Voor authenticatie wordt wel gebruik gemaakt van Azure AD (wat voor ontwikkeling en test prima is), een admin account (standaard staat dit uit en wordt ook afgeraden omdat het wachtwoord in code opgeslagen wordt). De aangeraden methode voor productie is dus om een Service Principal te gebruiken voor authenticatie met de ACR (Azure Container Registry). Uitleg daarover staat hier: link.