Werner

Uitdaging: De klant creëerde aparte 'klant' omgevingen, maar door het proces duurde het meer dan een week om er één te maken. Er was een documentatie pagina waarin vermeld stond welke stappen (ansible-playbooks) er allemaal uitgevoerd moesten worden.

Oplossing: Processen geautomatiseerd met Terraform voor IaC en Ansible voor configuratie, geïntegreerd in een Jenkins-pipeline. Via een Jenkins-job kon de klant een basisconfiguratie genereren en een omgeving creëren op bases van deze net gegenereerde data. Via Terraform werd de infrastructuurd gemaakt op AWS (of Azure), en met Ansible werden alle applicaties geïmplementeerd met een basis opzet. Na deployment was deze omgeving klaar om verder gefinetuned te worden voor de wensen van de klant.

Resultaten: Implementatietijd verminderd van meer dan een week tot uren, verbeterde betrouwbaarheid en kosten significant verlaagd. De engineer kon de job op de achtergrond uitvoeren en zich richten op andere taken.

Lessen geleerd: Het integreren van IaC-tools zoals Terraform vereist initiële investering in training, maar betaalt zich uit in reproduceerbare omgevingen. Daarnaast heeft dit ook geholpen in de business case om vanuit een disaster recovery snel een omgeving neer te kunnen zetten en backups te kunnen restoren.

Technologieën: Terraform, Ansible, AWS, Azure, GIT, Jenkins.

Uitdaging: De klant had meerdere klantomgevingen en wilde "dingen eenvoudiger" maken.

Oplossing: Een ontwerp gemaakt en getest met een proof of concept. Het doel was om een EKS-service te provisioneren in 3 verschillende AWS-regio's. In elke EKS zou Argo CD worden geïmplementeerd. Argo CD zou een ApplicationSet gebruiken die informatie leest uit een GIT-repository. Deze GIT-repository had een directory structuur met regio/klant, en elke directory bevatte een JSON bestand met de applicaties en hun versies. Wanneer een nieuwe klant wordt toegevoegd aan deze GIT-repository, zou Argo CD dit direct opmerken en een nieuwe vCluster creëren. Argo CD zou dan de juiste applicaties en hun versies implementeren in deze nieuwe vCluster, waardoor de omgeving direct beschikbaar wordt voor gebruik.

Resultaten: Dit zou een klant in staat stellen om binnen 10 minuten onboard te zijn en te draaien nadat de wijziging was gemerged in GIT.

Technologieën: Kubernetes, AWS, Argo CD, GIT.

Uitdaging: De klant had een Kubernetes draaiend in AWS, maar het was niet up-to-date. Kubernetes was meerdere versies oud, net als de componenten zoals de Ingress controller.

Oplossing: Versie voor versie heb ik de EKS-service bijgewerkt door eerst de ontwikkelomgeving te upgraden, gevolgd door de productieomgeving. Ondertussen heb ik een overzicht gemaakt van alle componenten, zoals de Ingress Controller, Argo CD en diverse andere operators, en een plan gemaakt om elk van de componenten bij te werken. Eerst naar de laatste versie in dezelfde major versie die al draaide, dan de noodzakelijke wijzigingen toepassen als onderdeel van de upgrade, en dan doorgaan naar ofwel de volgende major update of de laatste beschikbare versie. Daarnaast, omdat Kubernetes op EKS draaide, gebruikte het nog de Amazon Linux 2 nodes. Ik heb een plan gemaakt om over te stappen naar Amazon Linux 2023 en dus ook ervoor gezorgd dat het succesvol werkte op de ontwikkelomgeving, voordat het naar productie ging.

Resultaten: Kubernetes en de bijbehorende tools waren up-to-date. Een zeer kritiek Nginx Ingress controller CVE-probleem werd gevonden en een patch werd beschikbaar gesteld, gelukkig een paar weken nadat ik de Nginx Ingress Controller had bijgewerkt. Omdat ik ervoor had gezorgd dat Kubernetes weer up-to-date was, konden we de wijziging binnen minuten toepassen.

Lessen geleerd: Het up-to-date houden van omgevingen is cruciaal, zeker wanneer er security incidenten/patches nodig zijn.

Technologieën: Kubernetes, AWS (CloudFormation).

Uitdaging: Er was een logging-setup, waarbij logevents die gegenereerd werden vanuit de applicatie soms niet eens aankwamen in de cloudoplossing van Elasticsearch.

Oplossing: Filebeat draaide als DaemonSet in Kubernetes en stuurde alles door naar een enkele Logstash-pod. Vanuit daar ging dit naar Elasticsearch. Naar aanleiding van een korte analyse heb ik voorgesteld om Fluent-bit te gebruiken en deze events in Kafka te plaatsen. Vervolgens heb ik meerdere Logstash-instanties gedeployeerd die de data uit Kafka haalden en deze doorstuurden naar Elasticsearch. Daarnaast heb ik diverse fine-tuning toegepast, zodat – mocht Kafka of Elasticsearch zelf even niet beschikbaar zijn – er geen data verloren ging en alle logging snel weer in Elasticsearch te vinden was.

Resultaten: Sinds de wijziging is geactiveerd, is er geen enkele constatering meer geweest dat er ook maar één event was verdwenen. Het werd echter wel duidelijk dat in de vorige setup meer logs niet aankwamen in Elasticsearch dan aanvankelijk werd gedacht.

Lessen geleerd: De integratie van Kafka voegde buffering toe, wat cruciaal bleek voor schaalbaarheid, maar vereiste zorgvuldige configuratie om zowel network latency te minimaliseren als het hebben van voldoende storage.

Technologieën: Kubernetes, Filebeat, Logstash, Fluent-bit, Kafka, Elasticsearch, AWS (CloudFormation).