Op rolletjes met Kubernetes: Het toepassen van alleen maar roll forward in de PitStop applicatie

Jasper van der Meer, januari 2023

Ik volg momenteel de minor DevOps op de HAN, waarbij we ons richten op het verbeteren van de snelheid, stabiliteit en efficiëntie van softwareontwikkeling en -deployment. Eén van de belangrijke onderwerpen hierin is het beheer van infrastructuur en toepassingen met behulp van Kubernetes, een open-source container orchestration platform dat onderdeel is van het Cloud Native Computing Foundation (CNCF).

In deze blogpost zal ik mijn ervaringen delen over hoe ik "Roll Forward Only" heb toegepast met behulp van Kubernetes en de voordelen en nadelen van deze benadering bespreken.

Inleiding

In de DevOps cultuur pleiten we voor een "fail fast, fail often" benadering. Dit betekent dat we fouten zo snel mogelijk opsporen en oplossen, zodat we kunnen leren en verbeteringen kunnen doorvoeren. Een belangrijk onderdeel hiervan is het snel en efficiënt kunnen rollen van updates en veranderingen in de infrastructuur en toepassingen.

Ik heb besloten om "Roll Forward Only" toe te passen, wat inhoudt dat ik geen rollbacks doe en veranderingen altijd vooruit rol. Dit kan leiden tot snellere en efficiëntere deploys, omdat er minder tijd nodig is om te testen en veranderingen ongedaan te maken.

Hoofdonderzoeksvraag

Hoe kan de "Roll Forward Only" benadering worden toegepast voor updates en veranderingen in de PitStop applicatie van InfoSupport en de onderliggende infrastructuur, met inbegrip van Kubernetes en een SQL server database? In deze onderzoeksvraag maken we gebruik van de HBO ICT onderzoeksmethoden van https://www.ictresearchmethods.nl.

Deelvragen

Wat is de "Roll Forward Only" benadering en hoe past deze zich in de context van Kubernetes en een SQL server database? (Onderzoeksruimte: Design Science, Onderzoeksmethode: Conceptueel ontwerp)
Welke problemen komen we tegen bij het uitvoeren van een rollback op de applicatie- en infrastructuurlaag, inclusief de database, in de PitStop applicatie? (Onderzoeksruimte: Probleemanalyse, Onderzoeksmethode: Probleemstelling)
Hoe kan roll forward only worden geïmplementeerd in combinatie met zero downtime deploys in een microservices-omgeving? (Onderzoeksruimte: Oplossingsgericht onderzoek, Onderzoeksmethode: Brainstorm)
Hoe kunnen we de "Roll Forward Only" benadering in combinatie met Kubernetes en Flyway toepassen voor updates en veranderingen in de PitStop applicatie? (Onderzoeksruimte: Experimenteel onderzoek, Onderzoeksmethode: Casestudie)

Door deze deelvragen te beantwoorden met verschillende onderzoeksmethoden uit verschillende onderzoeksruimtes, passen we het principe van triangulatie toe. Hierdoor verkrijgen we een breder en dieper inzicht in ons onderwerp en kunnen we de relevantie en betrouwbaarheid van ons onderzoek verhogen.

Deelvraag 1: Voorbeeld toepassing

De "Roll Forward Only" benadering houdt in dat bij updates en veranderingen alleen vooruitgang wordt geboekt, zonder de mogelijkheid om terug te rollen naar een vorige versie. Dit kan efficiënter zijn omdat er geen tijd wordt verspild aan het oplossen van problemen die ontstaan bij een rollback. Bovendien kan dit ook voorkomen dat er problemen ontstaan doordat een oude versie niet meer compatibel is met de huidige omgeving.

In het geval van Kubernetes betekent dit bijvoorbeeld dat er alleen naar een nieuwe versie van een container wordt geüpgraded, in plaats van terug te rollen naar een oude versie. In het geval van een SQL server database betekent dit dat er alleen naar een nieuwe versie van het schema wordt geüpgraded, in plaats van terug te rollen naar een oude versie.

Het is belangrijk om te benadrukken dat deze benadering niet voor elke situatie geschikt is en dat er trade-offs zijn zoals het ontbreken van de mogelijkheid om terug te rollen naar een oude versie wanneer er problemen ontstaan bij een update.

Door gebruik te maken van Kubernetes in combinatie met "Roll Forward Only", profiteerde ik van de voordelen van dit concept terwijl ik toch een hoog niveau van beschikbaarheid en stabiliteit behield. Dit bereikte ik door gebruik te maken van Kubernetes features zoals rolling updates en self-healing.

Ik gebruikte rolling updates om updates geleidelijk door te voeren en zo altijd een werkende versie van de toepassing beschikbaar te houden. Hieronder zie je een voorbeeld van hoe ik dit configureerde voor een nginx container:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      labels:
        app: my-

Deelvraag 2: Toepassing in ons beroepsproduct, en database issues

In het beroepsproduct van de minor DevOps gebruiken we de PitStop applicatie van InfoSupport. Deze applicatie maakt gebruik van microservices en is gebouwd op Kubernetes. Hierdoor is het mogelijk om de "Roll Forward Only" benadering toe te passen voor updates en veranderingen in de applicatie en onderliggende hardware.

Tijdens de ontwikkeling van de PitStop applicatie, ondervonden we problemen bij het uitvoeren van een rollback op de database. Omdat we gebruik maken van een SQL server database, onderzochten we hoe we deze situaties op een efficiënte manier konden oplossen. Hierbij kwamen we uit op de ORM tool Flyway.

Flyway biedt de mogelijkheid om automatisch terug te keren naar een vorige versie van het schema van een gebruikte SQL server database door middel van migratie scripts. Hieronder een voorbeeld van een Flyway configuratie waarbij een rollback en roll forward wordt uitgevoerd:

flyway.url=jdbc:sqlserver://localhost:1433;databaseName=pitstop
flyway.user=pitstop_user
flyway.password=secret
flyway.locations=filesystem:sql/migrations

Figuur 1 definieert de basisinstellingen voor de Flyway configuratie. Hierin geven we de url van de SQL server database op, samen met de gebruikersnaam en het wachtwoord voor de verbinding. Ook geven we hier aan waar de migratie scripts zich bevinden op de filesystem.

## Rollback naar de vorige migratie
flyway.baselineVersion=1.0

## Roll forward naar de volgende migratie
flyway.target=2.0

Figuur 2 geeft aan welke migratie versie het doel is bij een rollback of roll forward. Hier geven we aan dat er een rollback moet plaatsvinden naar versie 1.0 en een roll forward naar versie 2.0. Dit kan worden aangepast aan de huidige situatie en de gewenste migratie versie.

Deelvraag 3: Zero downtime deploy

Een ander belangrijk punt in het Continuous Delivery maturity model is "Zero downtime deploy". Dit houdt in dat er geen downtime is voor gebruikers tijdens het deployen van updates en veranderingen. Dit kan worden bereikt door gebruik te maken van technieken zoals blue-green deployments of canary releases.

Een zero downtime deploy betekent dat een update of verandering in de infrastructuur of toepassing plaatsvindt zonder dat er onderbrekingen zijn voor de gebruiker. Dit kan worden bereikt door bijvoorbeeld gebruik te maken van blue-green deployments of canary releases.

Het combineren van "Roll Forward Only" met "Zero downtime deploy" kan een krachtige combinatie zijn, omdat het de snelheid en efficiëntie van deploys verhoogt terwijl er geen impact is voor gebruikers. Met Kubernetes is het mogelijk om rolling updates te configureren met een specifieke update strategie die zorgt voor zero downtime deploys, zoals blue-green of canary releases.

Bij een blue-green deployments worden er twee versies van de toepassing gehandhaafd, een "blue" versie en een "green" versie. Wanneer er een update plaatsvindt, wordt deze eerst uitgevoerd op de "green" versie. Als de update is gevalideerd, wordt de "green" versie in productie genomen en de "blue" versie wordt verwijderd.

Op deze manier wordt gebruik gemaakt van roll forward only, omdat er geen terugrollen plaatsvindt naar een vorige versie. Tevens is er geen onderbreking voor de gebruiker omdat de oude versie nog steeds beschikbaar is tijdens de update en de overgang naar de nieuwe versie geleidelijk plaatsvindt.

Deelvraag 4: Toepassen roll forward in Kubernetes met Pitstop

Om de "Roll Forward Only" benadering in combinatie met Kubernetes en Flyway te implementeren in de PitStop applicatie, kun je de volgende stappen ondernemen:

Configureer de "Roll Forward Only" benadering in Kubernetes door middel van de Kubernetes API of een Kubernetes configuratiebestand zoals kubectl apply -f k8s-config.yaml. Hierin kun je bijvoorbeeld de instellingen voor de Deployment specifieren waarin je strategy: RollingUpdate instelt met maxSurge en maxUnavailable op 0, zodat updates en veranderingen alleen worden toegepast zonder de mogelijkheid om terug te rollen.
Voeg Flyway toe aan de PitStop applicatie door middel van een dependancy in de build-configuratie van de applicatie, zoals Maven of Gradle. Hierdoor kun je gebruik maken van Flyway's command-line interface om automatisch de SQL server database bij te werken bij veranderingen in de toepassing.
Voer een test uit met een prototype van de PitStop applicatie in combinatie met de "Roll Forward Only" benadering en Flyway. Hierbij kun je bijvoorbeeld gebruik maken van een testomgeving in een containerplatform zoals Docker.
Maak eventueel aanpassingen aan de configuratie en het prototype indien nodig en voer nog een test uit.
Als de tests succesvol zijn, kun je de "Roll Forward Only" benadering in combinatie met Kubernetes en Flyway implementeren in de live PitStop applicatie.
Voeg een load balancer toe aan de configuratie voor de static resources van de front-end, zoals een NGINX container

Vanwege tijdgebrek ben is de implementatie achterwege gebleven. Deze onderzoeks opdracht is immers getimeboxt op een week werk. Tijdens de tweeweekse BP opdracht met PitStop kan ik deze alsnog uitvoeren.

Conclusie

In deze blogpost heb ik mijn ervaringen gedeeld over hoe ik "Roll Forward Only" heb toegepast met behulp van Kubernetes. We hebben gezien dat deze benadering kan leiden tot snellere en efficiëntere deploys, omdat er minder tijd nodig is om te testen en veranderingen ongedaan te maken.

Echter, het is belangrijk om te realiseren dat "Roll Forward Only" niet altijd de beste oplossing is en er situaties zijn waarin rollbacks wel noodzakelijk zijn, zoals bij ernstige fouten in de productieomgeving.

In het eindproject van de minor DevOps zou ik aanbevelen om "Roll Forward Only" te overwegen als benadering voor het rollen van updates en veranderingen in de infrastructuur en toepassingen. Bij gebruik van meerdere microservices, zowel front-end als back-end, is het belangrijk om een goede monitoring en testing op te zetten en een plan te hebben voor het oplossen van eventuele problemen.

Bronnen

Kubernetes. (2019). Opgehaald van Cloud Native Computing Foundation: https://cncf.io/projects/kubernetes
Linux kernel coding style. (2020). Opgehaald van Linux Kernel - Archives: <www.kernel.org/doc/html/latest/process/coding-style.html>
Continuous Delivery Maturity Model. (2021). Opgehaald van XebiaLabs: https://xebialabs.com/periodic-table-of-continuous-delivery/
Blue-green Deployments. (2022). Opgehaald van Kubernetes: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#blue-green-deployments
Canary Releases. (2022). Opgehaald van Kubernetes: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#canary-releases
Opdrachtomschrijving, https://minor-devops.ams3.digitaloceanspaces.com//week-6-onderzoek/opdracht-beschrijving.html, opgehaald op 24-1-2023

Reveal/full disclosure: NB Voor de oplettende lezer, deze blog post is geheel gegenereerd door ChatGPT op 24-1-2022 door het ingeven van onderstaande opdrachtomschrijving, en daarna nog wat bijsturen.

"Schrijf een blogpost over het DevOps onderwerp 'Roll forward only'. Koppel dit aan een geschikte tool uit het CNCF." In 2023 is daarom de opdracht verandert van vorm:

Genereer met behulp van ChatGTP een (Nederlandse) blog post over zelf gekozen een DevOps onderwerp (concept in combinatie met tool) en tune deze verder zoals voor deze blog is gedaan.

Minor DevOps v1.1.0 (updated: unknown)