Één van de “hippe” design-patronen voor applicaties van de afgelopen paar jaar is de Microservice. Het uit elkaar trekken van je applicatie in meerdere, kleine, services, die via het netwerk en een afgesproken (simpele) API met elkaar praten. Hier horen dan ook principes bij als “loosely-coupled” die zeggen dat het falen van component A niet tot het falen van component B mag leiden (maar component B mag best zeggen dat iets nu niet kan).

De meeste Kubernetes gebruikers weten wel hoe ze Environment Variabelen op een container moeten definiëren. Wat niet iedereen weet is dat je naast het hardcoden van deze variabelen ze ook op meerdere manieren uit ConfigMaps en Secrets kunt alten komen, of zelfs uit specifieke velden van je Pod zelf.

Wanneer je een container start met podman zal de tijzone binnen de container standaard op UTC gezet worden, standaard universele tijd. Wanneer je hosts in meerdere tijdzones hebt draaien is dit erg fijn, want de logtijden etc. van de verschillende containers zullen allemaal met elkaar gelijk lopen.

Sommige mensen vinden dit daarentegen minder fijn, omdat ze dan in hun hoof moeten gaan omrekenen naar de lokale tijd wanneer ze de logs aan het interpreteren zijn.

Tegenwoordig is “Kubernetes” het standaard antwoord op de vraag “Hoe moeten we dit draaien?”.

Wander is het hier niet mee eens. Hoe leuk hij Kubernetes ook vind, het zou niet per definitie het goede antwoord moeten zijn. Kubernetes voegt een laag aan beheer en complexiteit toe die in veel gevallen vermeden kan worden, of in ieder geval zwaar gereduceerd tot een meer Linux-native oplossing.

Als consultant kijkt Wander graag mee over de schouder (of via screenshare) naar de terminals van andere mensen. Soms leert hij een nieuw trucje, soms ziet hij iets moois, maar soms ziet hij ook dingen waar de haren op zijn rug van overeind gaan staan.

Sinds de eerste (beta) release van Red Hat Linux in 1994 heeft de familieboom van Red Hat (afgeleide) distributies wat flinke kronkels en vertakkingen gemaakt. Zoveel zelfs dat sommige mensen door de takken de boom niet meer zien.

Bijna elk Linux systeem heeft een vorm van “swap”, maar wat is dat nou precies? En wat doet dat voor me? Heb ik het echt nodig? Kan ik het eten?

Op dit kanaal hebben we in het verleden al eens gekeken naar Kyverno, een handige manier om beleid af te dwingen op Kubernetes objecten, en externe certificaten voor OpenShift Routes.

Met de release van Kyverno 1.15 een aantal maanden geleden is er een aantal nieuwe policy types beschikbaar gekomen voor Kyverno die gebruiken maken van Common Expression Lanaguage (CEL), dezelfde taal die ook door Kubernetes zelf gebruikt wordt op objecten als validatingadmissionpolicies, maar ook door dingen als Tekton Webhook Triggers.

CEL regels evalueren meestal sneller, en met minder resource gebruik dan traditionele Kyverno regels.

Op het gemiddelde Linux werkstation heb je een ruime keuze aan terminal emulators. Sommige, zoals XTerm, gaan al langer mee dan veel van onze kijkers, andere, zoals ptyxis, bieden speciale integraties met je desktop omgeving of containers.

Een andere categorie is degene waar de emulators puur voor de snelheid gaan. Zo snel mogelijk renderen, zoveel mogelijk tekst per seconde over het scherm heen pompen.

Één van de emulators uit de laatste categorie is kitty. Maar snelheid alleen is niet genoeg, kitty biedt ook een grote hoeveelheid aan configureerbaarheid en extensies. Zo kun je graphics rechtstreeks in je terminal bekijken, zijn er remote-control mogelijkheden, en zit er een tab/window/pane systeem in dat doet denken aan tmux.

Tegenwoordig kun je je “AI” Large Language Models met spcifiekere kennis enn vaardigheden verrijken door ze te koppelen aan Model COntext Protocol (MCP) servers. Dit zijn programma’s die via een JSON API je LLMs met extra informatie of vaardigheden kunnen uitbreiden. Uit het Red Hat Lightspeed project is nu de linux-mcp-server voortgekomen, een MCP die (basis) informatie kan geven over je lokale systeem, en systemen waar je met SSH toegang tot hebt.