Zoals elk jaar heeft HCS Company ook dit jaar weer een leuke puzzel voor jullie met Pasen.

Dit jaar is de Paashaas langs geweest op Wander zijn desktop, en heeft daar wat woorden voor jullie verstopt achtergelaten. De woorden kunnen zich echt overal bevinden, in plaatjes, applicaties, tekstbestanden, etc., maar overal staat duidelijk aangegeven om welk woord het gaat. Aan jullie de taak om alle zes de woorden te vinden, die in de goede volgorde te zetten, en de resulterende zin op te sturen.

Éé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.

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.

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.

De hardcore CLI fanaten onder ons zullen het niet willen geloven, maar er zijn echt mensen die de voorkeur geven aan een grafische omgeving waar ze in mogen klikken met een muis of een touchscreen voor hun beheer-werkzaamheden.

Als jij ook van die mensen kent, of er zelf eentje bent natuurlijk, dan ben je waarschijnlijk blij om te weten dat er meerdere applicaties zijn die je een grafische omgeving willen geven om je Kubernetes en/of OpenShift clusters te beheren.