Wijziging, versies en draaiboeken

Het cluster, de basisdiensten en de virtuele machines komen uit code. Een afwijking wordt binnen 5 minuten gemeld en teruggezet; een noodwijziging staat binnen 1 werkdag in code.

Wijzigen kan alleen via een wijzigingsvoorstel met ondertekende vastleggingen en twee beoordelaars naast de auteur. De vlootbrede rollen werken daarbij met een hardwaresleutel.

Het versiebeheer weigert langs iedere route, rechtstreeks naar de hoofdtak, via een wijzigingsvoorstel, via de API en met een beheerdersaccount, een niet-ondertekende vastlegging, een wijziging zonder twee beoordelaars en zelfgoedkeuring. De beschermingsregels staan als code vast en worden dagelijks vergeleken met hun vastlegging onder versiebeheer/.

Een draaiboek draait in productie alleen na goedkeuring door een ander dan de aanvrager, gebonden aan de vastgelegde versie van draaiboek en invoer. Bij een levering is die goedkeuring het samenvoegen van de dienstbeschrijving. Alleen het uitsluitingsdraaiboek voor een uitgevallen knooppunt is vooraf goedgekeurd.

Versies blijven binnen de ondersteuning, door de leverancier bevestigd of in eigen beheer. Een overgang naar een volgende versie start ten minste 3 maanden vóór het einde van de ondersteuning. Bij de acceptatie bevestigen de leveranciers iedere productcombinatie, ook de tussenliggende upgradecombinaties; anders geldt de terugvaloptie.

OpenBao, Forgejo en NetBox vallen onder eigen beheer van platformbeheer, net als de koppelingen die de leverancier alleen met HashiCorp Vault test (External Secrets Operator, cert-manager en de credential-plug-in van de automatisering) en de collectie netbox.netbox. Dat betekent: versies binnen het versiebeleid van het project, beveiligingsupdates binnen de termijnen van het SAK Patch Management, een onderhoudsplan per product met contactroute en een beproeving van iedere versie in de leeromgeving.

Iedere productcombinatie wordt gekwalificeerd, met de voorgeschreven terugvaloptie als de kwalificatie mislukt. Een product krijgt pas productiestatus na een geslaagde kwalificatie of na de overstap naar de terugvaloptie.

Een nieuwe versie van het cluster of van een basisdienst gaat na de leeromgeving eerst naar het vlootcluster en daarna per cel naar het basisdienstencluster, vóór het clusterbeheer, de werkervirtualisatie en de gehoste clusters, met eerst de proefgroep en dan de uitrolgolven. Een nieuwe versie van een basisdienst gaat eerst naar het basisdienstencluster van cel 1; beleid en inrichting komen met de eerste uitrolgolf, en cel 2 volgt na cel 1. Per venster gaat één basisdienst over, nooit het geheimenbeheer en de toegangsvoorziening samen. Een afgedwongen regel gaat alleen tijdelijk terug naar ‘melden’.

Het cluster wordt knooppunt voor knooppunt bijgewerkt, en een volgend knooppunt pas bij gezond quorum en gezonde partnerleden. Per knooppunt gaat eerst het lid van de externe verkeersverdeling naar secundair, stoppen de virtuele machines op lokale schijven, verhuist het firmwarebeheer en schakelt de database over.

Een basisdienst wordt bijgewerkt in een eigen venster, met een back-up vooraf. De overstappen naar CloudNativePG 1.31, Forgejo 19.0 LTS, de opvolger van midPoint 4.10 en iedere nieuwe minorversie van OpenBao krijgen elk een eigen draaiboek, beproefd in de leeromgeving.

Voor het basisdienstencluster zijn deze draaiboeken vereist, elk met een eigenaar en een vaste beproeving. Ze staan in de opslagplaats Draaiboeken en draaien waar mogelijk op de automatisering.

De vereiste draaiboeken zijn beproefd vóór productie en daarna volgens de beproevingskalender. Iedere beloofde eigenschap heeft een proef met slaagcriterium, eigenaar en bewaard resultaat.

De acceptatie van het basisdienstencluster toont aan: uitval van ieder knooppunt onder referentiebelasting, met de gemeten onderbreking per dienst; een werkende startketen na een herstart van alle knooppunten zonder opslagcluster; automatische ontgrendeling na een rollende herstart, ook vanuit de herstelzone, en geen ontgrendeling zonder bereikbare module; een nieuw roottoken met drie en niet met twee houders; herstel van iedere dienst met al haar gegevens en herbouw van het cluster in de leeromgeving; en de voorwaarden bij de acceptatie of hun terugvaloptie.

Negatieve proeven tonen aan dat worden geweigerd en gemeld: een opvraging van een geheim uit een andere naamruimte, aanvragen boven de grens van een mount, een niet-ondertekende vastlegging langs iedere route, een lokale aanmelding, schrijven met een leesrobot, verkeer van de runner naar een andere bestemming, een opvraging uit de herstelzone buiten herstel-<cel> en een certificaat uit de tussen-CA ‘vloot’ voor een celnaam.