Wat voor werk hoort bij maatwerk?

Bij zulke wijzigingen komt meer kijken dan alleen het aanpassen van de configuratie op een server. We zorgen ook dat de wijziging gecontroleerd wordt doorgevoerd, vastgelegd blijft, en bij toekomstige werkzaamheden opnieuw kan worden toegepast.

Daarvoor gebruiken we configuratiemanagement, versiebeheer en codereviews. Stuk voor stuk gevestigde werkwijzen binnen professioneel infrastructuurbeheer.

Wat houden die precies in? En welke stappen doorlopen we voordat een wijziging daadwerkelijk op een server terechtkomt?

Van handmatige aanpassingen naar configuratie als code

Een server kun je rechtstreeks configureren. Je logt in via SSH, past een configuratiebestand aan, en herstart een service.

Dat kan, maar na verloop van tijd weet niemand meer wie, wat, wanneer heeft uitgevoerd. Zeker met meerdere beheerders.

Dan wordt het onmogelijk om vragen te beantwoorden als:

• Waarom is deze instelling ooit aangepast?
• Welke wijzigingen zijn er sinds de oorspronkelijke inrichting doorgevoerd?
• Hoe zorgen we ervoor dat een vervangende server exact dezelfde configuratie krijgt?
• Wat gebeurt er als we een bepaalde wijziging moeten terugdraaien?

Om die problemen te voorkomen, gebruiken we Ansible: een veelgebruikt hulpmiddel voor configuratiemanagement.

In plaats van wijzigingen rechtstreeks op servers uit te voeren, leggen we de gewenste configuratie eerst vast in code. Ansible zorgt vervolgens dat die configuratie op de juiste servers wordt toegepast.

Zo beschikken we over een centrale, reproduceerbare beschrijving van hoe een omgeving ingericht hoort te zijn.

Van klantverzoek naar wijziging op de server

Hoe ziet dat er in de praktijk uit? Neem een klant die een eigen CA-certificaat wil toevoegen aan hun omgeving.

1. Het verzoek concretiseren

Het begint met een supportticket. Daarin bespreken we met de klant wat er nodig is, voor welke systemen het certificaat moet gelden, en eventuele bijzonderheden.

Niet alle informatie uit zo'n gesprek is direct relevant voor de engineer die de wijziging gaat uitvoeren. Daarom verwerken we de uitkomst intern tot een concreet 'issue'.

Daarin staat wat er moet gebeuren, waarom de wijziging nodig is, en met welke technische randvoorwaarden rekening moet worden gehouden.

Zo kan de DevOps-engineer gericht aan de slag, zonder eerst de volledige correspondentie - met allerlei irrelevante details - te hoeven doorlopen.

2. De wijziging voorbereiden in Ansible

De engineer onderzoekt hoe het certificaat aan de bestaande configuratie moet worden toegevoegd. Vervolgens wordt de benodigde Ansible-code geschreven of aangepast.

De aanpassing wordt vastgelegd in Git, ons versiebeheersysteem. Vervolgens opent de engineer een pull request (PR).

Een pull request is een voorstel om een wijziging aan de bestaande code toe te voegen. Het laat precies zien welke regels zijn toegevoegd, verwijderd of aangepast. Ook kan de engineer hierin toelichten waarom bepaalde technische keuzes zijn gemaakt. Die informatie blijft permanent beschikbaar.

3. Een collega kijkt mee

Voordat de wijziging wordt doorgevoerd, beoordeelt een andere engineer het pull request: het vierogenprincipe.

De reviewer kijkt onder andere of:

• De wijziging technisch correct is.
• De wijziging functioneel doet wat de klant nodig heeft.
• Er geen onbedoelde gevolgen zijn.
• De beveiliging en betrouwbaarheid van de omgeving gewaarborgd blijven.
• De wijziging ook bij toekomstige uitrol of vervanging van servers correct kan worden toegepast.

Een reviewer kan opmerkingen plaatsen of om aanpassingen vragen. De oorspronkelijke engineer verwerkt die feedback, waarna de code opnieuw wordt beoordeeld.

4. Gecontroleerd uitrollen

Met goedgekeurde code is de wijziging nog niet automatisch op de server doorgevoerd.

Eerst bepalen we hoe en wanneer we de configuratie toepassen. Afhankelijk van de wijziging controleren we vooraf welke aanpassingen Ansible gaat uitvoeren, en of er bijvoorbeeld services herstart moeten worden.

Na afloop controleren we of de wijziging daadwerkelijk is toegepast en het gewenste resultaat heeft. In ons voorbeeld betekent dat onder andere controleren of het CA-certificaat beschikbaar is voor de bedoelde applicaties en of de betreffende verbindingen correct functioneren.

En voilà: de wijziging is afgerond!

Waarom al die stappen?

Dit proces kost meer tijd dan rechtstreeks een instelling op een server aanpassen. Daar staat tegenover dat we veel meer zekerheid en inzicht krijgen, zowel tijdens de wijziging als in de jaren daarna.

Concreet levert deze werkwijze het volgende op:

• Herleidbaarheid

  We kunnen terugvinden wie een wijziging heeft aangebracht, wanneer dat is gebeurd en vooral waarom. Via het oorspronkelijke issue blijft ook de aanleiding vanuit de klant bewaard.

• Controle door meerdere engineers

  Dankzij het vierogenprincipe worden technische keuzes getoetst voordat ze in productie terechtkomen.

• Inzicht in wijzigingen

  Versiebeheer laat exact zien welke configuratieregels zijn veranderd, en hoe de configuratie zich door de tijd heeft ontwikkeld.

• Reproduceerbaarheid

  Wanneer een server vervangen of een nieuwe node toegevoegd wordt, kunnen we dezelfde configuratie opnieuw toepassen.

• Consistentie

  Servers met dezelfde functie krijgen dezelfde configuratie.

• Gecontroleerde uitrol

  We kunnen vooraf beoordelen wat een wijziging gaat doen.

• Eenvoudiger onderzoek

  Wanneer zich later een probleem voordoet, kunnen we nagaan welke wijzigingen zijn doorgevoerd. Dat helpt bij het achterhalen van de oorzaak, en het voorbereiden van een eventuele correctie.

• Overdraagbaarheid

  De kennis over de inrichting van een omgeving zit niet in het hoofd van één engineer. Collega's kunnen de configuratie, de wijzigingsgeschiedenis en bijbehorende afwegingen raadplegen.

Zorgvuldig beheer vraagt om meer dan technische uitvoering

Een eigen CA-certificaat toevoegen - en eigenlijk het meeste maatwerk-werk - is op zichzelf geen uitzonderlijk ingewikkelde opdracht. Maar het werk bestaat uit meer dan de technische aanpassing alleen: het verzoek wordt uitgewerkt, de configuratie voorbereid, de code beoordeeld en de wijziging gecontroleerd uitgerold. Dat is professioneel infrastructuurbeheer.

Een wijziging moet vandaag correct werken, maar ook over een jaar nog te begrijpen, te controleren en opnieuw uit te voeren zijn.