Wanneer je kustomize gebruikt om met Overlays de lifecycle-fases van je applicatie te beheren dan ga je vroeger dan later een keer de vragen stellen hoe je promoties van images (en Bases) tussen deze fases kunt automatiseren. Met de hand references en image transformers doorzetten is meestal geen optie vanwege de kans op fouten, en het willen automatiseren van de promotie pipelines.

Nu zijn er bestaande oplossingen met tools als Renovate die dit (gedeeltelijk) voor je kunnen oplossen, maar die hebben vaak wat meer infrastructuur nodig. Als je deze tools nog niet gebruikt dan zou je zelf wat scriptjes kunnen schrijven, maar nu heb je nog iets extras om te beheren en bij te houden.

In a typical containerized application we have a lifecycle that goes a little like this:

1. Developers push code to an application repository.
2. A pipeline builds the latest code and pushes the resulting image to a registry
3. The pipeline updates the images: transformer in a Kustomization Overlay for the dev environment with the new image by using a command like kustomize edit set image foobar=registry.example.com/foobar@sha256:deadbeef
4. A tool like ArgoCD picks up the new image and starts a new deployment.

This works well for the dev environment, but when that image needs to be promoted to a new environment like tst we either need to copy the updated image transformer manually, or try to read the updated version from the dev Kustomization.

And images are not the only thing. A typical Kustomize Overlay will include a versioned Base with something like this:

1apiVersion: kustomize.config.k8s.io/v1beta1
2kind: Kustomization
3resources:
4- git.example.com/foobar.git/deploy/base?ref=v0.2.1

In this example we see that the Base that is being used comes from the Git tag or branch called v0.2.1. If a newer version of the application needs a newer Base a developer can update that reference in the dev Overlay, but promotions will need to be handled as well.

Simply copying the kustomization.yaml file between Overlays will most likely not work, since different Overlays typically use different Replica transformers, different ConfigMap en Secret Generators etc.

Read on to learn how you can automate this.

In de Kubernetes wereld is “Kustomize” één van de handigste manieren om met je manifesten om te gaan als je naar meerdere omgevingen of life cycle fases wilt uitrollen. Het is niet voor niks dat de basis-functionalieit van Kustomize ook in het kubectl en oc commando zit ingebakken.

Naast alle ingebouwde transformatie die Kustomize kan uitvoeren op zaken als replicas, images, labels, etc. is er ook een ingebouwde transformer die patches kan uitvoeren, zowel Strategic Merge patches die misschien kent van kubectl apply als JSON6902 patches zoals bekend van kubectl patch.

In a previous post we looked at how to add extensions to the new Keycloak operator. In that article we used a ConfigMap to store those extensions. In the real world a PersistentVolumeClaim (PVC) would be a more realistic choice, especially for larger or more extensions.

In this post we will look at how to change out the ConfigMap for a PVC, and how to set up a Job that can fill that PVC with the content we want.

Als je een applicatie die via Hem charts wordt gedistribueerd in je OpenShift GitOps (ArgoCD) wilt opnemen heb je twee opties:

1. Een ArgoCD applicatie van het type “Helm” maken
2. De Helm chart via kustomize laten renderen, en de kustomization.yaml in je ArgoCD opnemen.

De eerste oplossing is het makkelijkst, en heeft weinig extra configuratie nodig. Het nadeel is wel dat je wat betreft aanpassingen gelimiteerd bent op wat de schrijver van de chart via de values.yaml heeft aangeboden.

Wanneer je extra aanpassingen nodig hebt kom je dus al snel uit op de tweede methode: De helm chart via kustomize laten renderen (inclusief aanpassingen via values.yaml), en daar extra aanpassingen op doen via de bekende kustomize transformers zoals images:, patches:, replicas:, etc.

In een vorige video hebben we gekeken hoe je namespaces kunt beheren met behulp van GitOps methodologieën. Deze week gaan we hierop verder bouwen en gaan we ook (Cluster)ResourceQuotas introduceren.

In het verleden hebben we op dit kanaal al vaker gekeken naar het managen van namespaces voor applicatie-teams op Kubernetes en OpenShift clusters. Deze keer kijken we naar hetzelfde probleem, maar pakken we het op een GitOps methode aan.