Alle posts van Wander

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.

De meeste mensen die met Bash werken zijn wel bekend met het fenomeen “Command Substitiuion”; Je zet in een commandline een commoando tussen $( en ), of tussen backticks `, en dat stuke van je commandline wordt vervangen door de output van dat commando. Nu zijn er helaas situaties waar je die output in een (tijdelijk) bestand nodig hebt voor een ander commando, en je niet moeilijk wilt doen met het herschikken van file-descriptors of het zelf aanmaken van tijdelijke bestanden. In die gevallen kun je gebruik maken van “Process Substitution”, waarbij Bash zelf voor de tijdelijke bestanden zorgt in de vorm van named pipes.

OpenShift Network Observability Operator In recente versies van OpenShift kun je de “Network Observability Operator” installeren om een beter inzicht te krijgen in de netwerk flows tussen de verschillende componenten/pods/services/etc op je cluster, als ook het netwerk verkeer dat je cluster verlaat. Deze inzichten kunnen dan gebruikt worden voor verschillende zaken; Het doorberekenen van netwerk gebruik, optimalisatie van traffic-flow tussen de componenten van een micro service, of zelfs het detecteren van “ongebruikelijk” verkeer in een applicatie.