Één van de meest onmisbare tools bij het debuggen van problemen ope een Kubernetes/OpenShift cluster zijn de “Events”. Kleine stukjes informatie/logging die door de verschillende controllers gegeneerd worden (als Kubernetes objecten) met informatie over wat er allemaal gebeurt en misgaat. Zo zul je in deze events berichten tegenkomen over het al dn niet succesvol ophalen van container images, het starten van pods en containers, het aanmaken van Jobs vanuit een CronJob, het falen van de verschillende probes die op een pod kunnen staan, en meer.

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.

Door het automatisch bijwerken van je base images op je containerplatform is het mogelijk om de nieuwste versies op je OpenShift platform te hebben. Het kan natuurlijk ook voorkomen dat per direct een nieuwe base image gebouwd moet worden. Dit moet je dan met de hand kunnen doen. Wat nu?

Soms kan het gebeuren dat er in een instantie van AWX (of Ansible Tower, of Red Hat Ansible Automation Platform) credentials staan opgeslagen die belangrijk zijn, maar die nergens anders terug te vinden zijn. Ga je in zo een geval naar de web interface van AWX, die krijg je overal bij de belangrijke velden $encrypted$ te zien, maar niet de waardes die je zo hard nodig hebt.

Gelukkig is er een manier om via het awx-manage commando deze waardes niet alleen op te vragen, maar ook te laten ontsleutelen.

In een vorige aflevering van Sudo Friday hebben we gekeken naar een aantal grafische applicaties om je Kubernetes clusters mee te managen. Een applicatie die daarvoor op Wander zijn lijst stond om te onderzoeken, maar die helaas (nog) niet met alle authenticatie methodes werkte, en dus helaas ook niet met OpenShift, was “Seabird”.

Één van de belangrijkste features van elke pakketmanager is het kunnen terug rollen naar vorige versies. Dit kan bijvoorbeeld nuttig zijn wanneer een nieuwere versie een bug heeft geïntroduceerd in een applicatie waar je op vertrouwd.

Met yum/dnf heb je hiet het downgrade commando voor, die naar de vorige versie gaat, of de versie die je opgegeven hebt.

Met flatpak kun je exact hetzelfde doen, alleen gebruiken we daar geen Epoch-Version-Release nummering zoals bij RPM pakketten, maar werken we met Git commit hashes voor de versie van het manifest.

Chatbots everywhere, handy assistants in applications, AI is booming and particularly generative models. More than a year after the disruptive release of ChatGPT lots has happened. Language models are everywhere and tooling to run these are becoming easier as well. Let’s take one of these local serving models, Ollama and create a Visual Studio Code extension that will use this model server for answering questions about our code base using one of the community AI models.

Praktisch elk Open Source project heeft wel een logo of een mascotte, maar sommige zijn bekender dan anderen, terwijl hun project of applicatie misschien wel heer erg bekend is.

In deze video laat Wander veertien verschillende logos zien, en jullie mogen raden van welk project ze zijn.

Niet iedereen is gelukkig genoeg om het budget te hebben voor Ansible Automation Platform (AAP), en sommige mensen gebruiken liever een upstream open-source versie van een product dan de betaalde, ondersteunde, versie. Voor Ansible orkestratie kom je dan al snel uit op Ansible AWX.

Recente versies van AWX zijn alleen geschreven om op een Kubernetes platform te draaien, en uitgerold te worden via een operator. Nu kun je wel een dev versie met podman draaien, maar dat levert ook weer problemen op.

Hoe doe je dat dan als je geen (toegang tot) een Kubernetes cluster hebt? De minikube variant zoals beschreven in de AWX documentatie is alleen bedoelt voor test omgevingen, niet productie… Het antwoord kan zijn: “K3S”. Deze lichtgewicht Kubernetes implementatie is wel geschikt voor productie, en kan ook redelijk eenvoudig geïnstalleerd worden.

Via het upstream “kubevirt” project is het mogelijk om virtuele machines te draaien als pods op een Kubernetes cluster. Op OpenShift is hier een door Red Hat ondersteunde versie van genaamd “OpenShift Virtualization”. Op deze manier kun je je VMs makkelijk (bijna) hetzelfde beheren als je containers, bijvoorbeeld met een tool als ArgoCD, of met Tekton Pipelines.