Managed VM-module (platformzijde)¶
De Managed VM-module deployt virtuele machines met een vaste baseline: beveiligingsinstellingen, eigenaargroepen, monitoring, back-up en patching. Workload teams gebruiken de module via standaardaanvragen, zie Managed virtuele machines. Deze pagina is voor het platformteam: hoe een aanvraag een wijziging wordt, wat je regelmatig moet controleren en hoe je de release notes van de module bijhoudt.
Optionele module
De module maakt geen deel uit van de kerncode van hub en spoke. De configuratie staat naast de spoke-configuratie en de module heeft eigen releases en release notes. Controleer welke versie en welke opties je platform draait, en welke pipeline de module deployt.
Hoe een aanvraag een wijziging wordt¶
| Stap | Wie | Wat |
|---|---|---|
| 1 | Aanvrager | Vult de aanvraag in (Aanvragen en wijzigen), of opent een pull request op het VM-configuratiebestand als diegene toegang heeft |
| 2 | Platformteam | Controleert de aanvraag, bewerkt het VM-configuratiebestand voor de spoke en omgeving, opent of reviewt de pull request |
| 3 | Reviewer | Designreview (bijvoorbeeld het architectuurteam van de klant, als het contract dat zegt) |
| 4 | Operator | Reviewt, merget en deployt met de modulepipeline. Werkt het ticket bij. |
| 5 | Operator | Informeert de aanvrager |
Er is één configuratiebestand per spoke en omgeving, in een map per spoke. Een nieuwe spoke-map moet ook worden toegevoegd aan de lijst met spokes in de deploymentpipeline van de module. Anders wordt er niets gedeployd en blijft de pipeline groen. Neem dit op in je checklist voor een nieuwe spoke (Nieuwe spoke).
Laat aanvragers hun eigen pull request niet afronden. De aanvrager opent hem, het platformteam merget hem. Zie Veilig een wijziging doorvoeren.
De checklist van de reviewer en de deploymentstappen staan in Review van een Managed VM pull request. De scope van de service en de grenzen ervan staan in de servicebeschrijving.
Wijzigingstypes die passen bij een standaardwijziging¶
Deze wijzigingen worden verwacht en gelden als standaardwijziging, zolang ze via een pull request lopen:
- een nieuwe VM-configuratie;
- van grootte veranderen (de SKU wijzigen);
- tagupdates;
- wijzigingen in retentie of back-up;
- wijzigingen van eigenaar;
- een wijziging van het aantal instances;
- access packages aan- of uitzetten.
Al het andere (een nieuwe module-optie, een nieuwe image, een wijziging in de baseline) is een wijziging van de module en geen standaardwijziging.
Aanvraagvelden¶
De velden staan op Aanvragen en wijzigen. Houd deze tabel bij voor de minder voor de hand liggende velden:
| Veld | Mapping en valkuilen |
|---|---|
| Korte naam van de workload + korte naam van de configuratie | Samen hebben ze een maximale lengte (8 tekens non-productie, 11 productie in de bronmodule). Langere namen breken afgeleide resourcenamen. De variabele key_vault_name overschrijft de gegenereerde Key Vault-naam als die niet klopt, bijvoorbeeld bij een bestaande Key Vault of zeer lange namen. |
| OS-SKU | Een interne SKU-naam die naar een Azure-image is gemapt. Ontbreekt die, dan geldt de nieuwste. Ondersteunde namen groeien mee met de moduleversies. |
| Te verwijderen datadisk | De 0-gebaseerde index in de data_disks-array. Een disk midden in de lijst verwijderen verschuift de indexen van de rest: lees het bestand eerst opnieuw. |
| Back-up RPO en retentie | Aparte waarden voor elke back-upoplossing. De RPO van de Backup Vault kan achteraf niet worden gewijzigd. |
| Eigenaren | E-mailadressen die in Entra ID bestaan. owners_members bepaalt de leden van de eigenaargroep. |
| Encryption at host | Vereist een feature-registratie op de subscription voordat het kan worden ingeschakeld. |
Module-opties die je moet kennen¶
Deze namen komen uit de release notes van de module. Jouw versie kan afwijken.
| Optie | Doel |
|---|---|
backup_solutions |
Lijst van BackupVault en RecoveryServicesVault |
rsv_alerts_for_all_job_failures_enabled, rsv_alerts_for_critical_operation_failures_enabled |
Alert bij fouten in de Recovery Services vault |
disable_default_maintenance_configuration |
Schakel de eigen maintenance configuration van de module uit, zodat de door policy toegewezen configuratie geldt |
deploy_defender_plans |
Welke Defender-plannen (standaard CloudPosture en VirtualMachines) |
deploy_change_tracking |
Change Tracking en Inventory |
custom_alert_rules |
Extra alertregels op Log Analytics-data |
encryption_at_host_enabled, disk_encryption_enabled |
Encryption at host en Azure Disk Encryption |
deploy_guest_configuration |
Guest Configuration-extensie. Standaard uit. Laat uit staan als een Azure Policy de extensie deployt. |
license_type |
Hybrid Benefit voor Windows- en Linux-VM's |
key_vault_name |
Expliciete Key Vault-naam |
instances |
Aantal identieke VM's van één configuratie. Bij een waarde boven 1 krijgen de VM's dezelfde configuratie en de standaardnamen met een oplopend achtervoegsel. |
useAccessPackages |
Access packages in Entra ID, zodat eigenaren gebruikers toewijzen in het My Access-portaal. Sommige platformen gebruiken ze niet meer. Als je platform false verkiest, vraag de aanvrager dan te bevestigen als de pull request true zet. |
Patchtoewijzing via policy¶
VM's worden aan maintenance configurations toegewezen via dynamic scopes op de maintenance configurations. De scopes selecteren
VM's op de tag PatchPriority:
- Een Azure Policy-initiative wordt toegewezen op een management group. Het zorgt dat elke subscription daaronder in de dynamic scope van beide maintenance configurations valt (niet-businesskritiek en businesskritiek), zodat nieuwe subscriptions geen wijziging nodig hebben.
- Subscriptions buiten die management group (bijvoorbeeld direct onder de tenant root group) hebben dezelfde policy nodig, toegewezen op dat niveau, met de hand of in code.
- De managed identity van elke policytoewijzing heeft rechten nodig op de scope van de toewijzing: Contributor (om remediation tasks aan te maken wanneer dat nodig is) en Scheduled Patching Contributor.
- De configuratiebestanden in de coderepository bepalen de schema's. Documentatie die het schema herhaalt, is een gemak en kan verouderd zijn.
De namen van de policies en toewijzingen zijn van jezelf. Gebruik de policyconventies van Policytoewijzingen.
Niemand patcht een VM zonder de tag
Een VM zonder PatchPriority (of met een andere schrijfwijze) valt in geen enkele dynamic scope. Controleer als onderdeel van de
reguliere controle op VM's zonder de tag, bijvoorbeeld met een Azure Policy-audit of een resource graph-query.
Reguliere controle¶
Na elk patchvenster (bijvoorbeeld de volgende werkdag in de ochtend):
- Open Update Manager → Manage → History, filter Update operation op Install updates en Resource type op Azure Virtual Machine.
- Zoek naar Failed en Completed with warnings. Vergelijk installed met total updates: "8 of 10" is een gemiste update.
- Kijk bij Machines naar No updates data (haal eerst filters weg). Die machines stonden uit of hebben geen assessment.
- Maak bij elke fout een taak aan, neem contact op met de workload-eigenaar en los de oorzaak op.
Een maandrapport heeft dezelfde vorm: de lijst met managed VM's per omgeving, patchstatus (pending, failed, installed, excluded, datum), back-upstatus en openstaande vervolgacties. Kopieer geen klantdata naar gedeelde documentatie.
Houd ook een lijst bij van VM's met een speciale behandeling: VM's die door hun eigenaren worden gepatcht, VM's die niet automatisch mogen herstarten en VM's die het grootste deel van de tijd uit staan. De contactpersonen van de eigenaren horen in die lijst.
Reguliere controle: back-ups¶
- Bekijk de mislukte back-upjobs en alertregels van de Recovery Services vaults.
- Test minstens één keer per type workload een herstel, volgens Back-up en herstel.
Release notes¶
Houd release notes per moduleversie bij en zet ze waar de workload teams ze kunnen lezen. Een patroon dat werkt:
- Eén kop per versie met de releasemaand:
## Version 1.4.11 (June 2025). - Opsommingstekens per wijziging, beginnend met Add, Change, Fix of Ignore.
- De namen van nieuwe opties in codeopmaak, met een link naar de Microsoft-documentatie als een feature een vereiste op subscriptionniveau heeft.
- Een regel voor elke gedragswijziging die bestaande VM's raakt (defaults, retentie, rollen), want dat zijn de wijzigingen die afnemers merken.
Uittreksel van opvallende wijzigingen, om het detailniveau te laten zien:
| Versie | Wijziging |
|---|---|
| 1.1.0 | Change Tracking en Inventory, custom alert rules. VM-eigenaren krijgen de rol Virtual Machine Administrator |
| 1.2.0 | Keuze van Defender-plannen |
| 1.3.0 | Recovery Services vault als back-upoplossing (de Backup Vault was de default vanwege compatibiliteit), retentieopties |
| 1.3.1 | Boot diagnostics; beheerders krijgen Virtual Machine Contributor zodat ze de Serial Console kunnen gebruiken |
| 1.3.7 | license_type voor Hybrid Benefit |
| 1.3.9 | Het staging storage account van de Recovery Services vault weigert publieke toegang |
| 1.4.0 | Tags op VM's; disable_default_maintenance_configuration |
| 1.4.4 | Encryption at host, Azure Disk Encryption, Guest Configuration, eigenaarleden; storage account zonder publieke toegang of shared keys |
| 1.4.5 | Alerts voor jobfouten in de Recovery Services vault |
| 1.4.9 | Standaard back-upoplossing gewijzigd naar Recovery Services vault |
| 1.4.11 | Windows Server 2025, Ubuntu 24.04, meer RHEL-versies |
Zie ook Wat te doen als een nieuwe versie wordt gereleased voor hoe nieuwe platformversies worden uitgerold, en Achterwaartse compatibiliteit voor hoe wijzigingen van defaults worden aangekondigd.