Hoe maakt de tool Cookiecutter het werkleven van Public Cloud Engineers leuker? 💡

“Voor klanten rollen we hun omgevingen in Azure uit met Infrastructure as Code. In ons geval op dit moment met Terraform. Het gaat daarbij om bijvoorbeeld Virtual Machines, databases, storage, etcetera. De omgevingen zijn per klant weliswaar uniek, alleen kun je voor losse onderdelen bestaande code voor de infrastructuur gebruiken. Een database-server bijvoorbeeld, die je dan met dezelfde code die je eerder hebt ontwikkeld, weer opnieuw opzet. Om die code nu uit je hoofd te leren, is ook weer zo wat,” grapt Adriaan Sterkenburg, Public Cloud engineer bij True.

Bij het werk voor klanten hebben Public Cloud engineers voor elke klant een eigen repository in GitLab aangemaakt, met daarin de Infrastructure as Code voor die klant. Adriaan: “De opbouw van die repo is bij elke klant nagenoeg hetzelfde. Denk aan mappenstructuur en benodigde bestanden om daarmee een CI/CD-pipeline te configureren.” Die repo’s werden eerder handmatig, stuk voor stuk, opnieuw opgebouwd. Wel elke keer volgens een uitgekiende standaard met alle ervaring en best practices van True engineers erin. Maar toch: handmatig opzetten. Van nature zijn mensen bij True snel op zoek naar hoe iets slimmer of makkelijker kan. Hoe kan dit slimmer?

💡 Lees over een van onze andere best practices: Infrastructure drift check

Om het opzetten van een standaard repo makkelijker te maken, heeft Team Public Cloud de tool Cookiecutter ingezet. “Cookiecutter maakt geautomatiseerd een kopie van het projecttemplate waar je project-variabelen meegeeft. Om te beginnen, hebben we een projecttemplate voor een klantrepository in Cookiecutter aangemaakt. Dat is een lege repo met de mappen en bestanden die we elke keer nodig hebben. Een variabele die we invoegen, is bijvoorbeeld het klant ID-nummer. De template is gebaseerd op onze standaard, bewezen werkwijzes en leunt op andere middelen die we inzetten, zoals GitLab, pipeline configuraties en Terraform modules”, zegt Adriaan.

Door Cookiecutter te gebruiken, staat een nieuwe repo nu binnen een paar klikken klaar voor een nieuw project. Alleen voor een nieuw project: Cookiecutter checkt de aanwezigheid van branches in een repo. Zijn die er, dan breekt Cookiecutter de deployment van de template naar de repo af.

Adriaan: “Ook zorgt een projecttemplate met Cookiecutter ervoor dat alles is ingevuld bij de start van een project. Denk bijvoorbeeld aan monitoring op resources instellen. Een tool en template generiek houden, voorkomt dat elementen bij de start of oplevering ongemerkt over het hoofd worden gezien.”

Een ander voordeel, geeft Adriaan mee: “In de praktijk komen er bij elke omgeving soms nieuwe foutmeldingen kijken of configuraties die net niet lekker gaan. Die ben je dan bij elk project opnieuw aan het oplossen. Met Cookiecutter is het idee om zo’n melding maar één keer te hoeven oplossen voor alle toekomstige omgevingen.

💡 De veiligheid van Infrastructure as Code verbeteren?

De basis van Cookiecutter staat nu klaar om gebruik verder te ontwikkelen. Naast ‘hoe kan het slimmer’ zit ook schaalbaarheid in de natuur van Trueligans. De vervolgstap: verdere automatisering van het opzetten van een Azure project. “Veel automatisering hangt af van een goede basis. Als het fundament niet generiek is voor een project, kun je daar voor verdere automatisering niet tegenop scripten. De basis moet dus goed staan,” geeft Adriaan mee.

“Het generieke template moet volledig met variabelen te vullen zijn, inclusief verwijzigingen naar andere modules. Vervolgens moet het verder leiden tot automatisch opzetten van de juiste Terraform bestanden, of zelf een complete Azure of Azure Kubernetes Service omgeving”, zegt Adriaan. “Theoretisch zou het dan een kwestie zijn van je variabelen invoeren, waarna het aangemaakte project van Cookiecutter in bijvoorbeeld GitLab, Terraform en Azure automatisch een vervolg in gang zet. Dat betekent wel dat álle automatisering er omheen tiptop in orde moet zijn. Uiteindelijk willen we alle combinaties in Cookiecutter kunnen maken. Dat vergt minder handmatig werk om nieuwe omgevingen compleet uit te rollen.”

Hoe mooi het idee van copy-paste van infrastructuur code ook is, Adriaan noemt bewust het woord ’theoretisch’. “In theorie is zoiets waterdicht. De praktijk is – zoals bij veel engineeringwerk – een stuk weerbarstiger. Als Cookiecutter het niet doet, kan dat bij configuraties van Cookiecutter liggen, maar ook bij die in GitLab, Kubernetes of Azure. Een foutmelding kan een domino-effect veroorzaken, waardoor je er minder snel achterkomt waar het niet lekker loopt. En dan is er nog het principe van fault tolerance. Het idee dat als één service uitvalt, Cookiecutter alsnog op goede wijze het project kan aanmaken en niet faalt door deze uitval”, zegt Adriaan. “Om alles in Cookiecutter te kunnen zetten, moeten we ook alle afhankelijkheden in kaart hebben. Dat zijn er vaak meer dan je van te voren denkt. We hebben nog leuke breinbrekers voor de boeg!”

Maar, zegt Adriaan, de eerste winst is geboekt. De basis staat, waardoor het goed verder werken is met ideeën voor verdere inzetbaarheid en automatisering van het proces. Dat maakt het werk tof!