Op moderne Fedora systemen (en ook andere distributies) wordt standaard een filesysteem gebruikt dat momenteel niet in RHEL beschikbaar is: Btrfs.

Btrfs heeft een aantal leuke features die anders op een andere manier (bijvoorbeeld via Stratis en/of VDO) opgevangen moeten worden, zoals copy-on-write snapshots, transparante compressie, en sub-volumes.

Er zijn in de Linux wereld veel manieren om applicaties te packagen voor eindgebruikers. Deze methodes zijn grofweg op te delen in twee types; Het eerste type maakt geen onderscheid tussen Operating Systeem onderdelen en applicaties, denk bijvoorbeeld aan RPM of DPKG, en het tweede type houdt applicaties gescheiden van het onderliggende OS, zoals je ook kent van je mobiele telefoon.

In dat tweede type heb je ook weer een aantal smaken, AppImage, Snap, Flatpak, en meer.

Er zijn een hoop gevallen waarbij een OpenShift cluster vanuit technische- of veiligheidsredenen niet aan het internet verbonden mag of kan zijn. Nu geeft dit natuurlijk nogal wat problemen bij het installeren, upgraden, en gebruiken van zo’n cluster.

Nu heeft OpenShift de mogelijkheid om verzoeken voor images vanaf externe container registries om te leiden naar een registry van jouw keuze. Nu moet je alleen die registry nog vullen met de goede images, en dat zijn er nogal wat…

Today’s organizations increasingly depend on digital systems and services. Any disruption or downtime can have a significant impact on revenue, user experience and brand reputation. To mitigate such risks, Site Reliability Engineering (SRE) has emerged as a vital discipline that focuses on building and maintaining highly reliable and scalable systems. Effective monitoring stands as a fundamental pillar of SRE.

Tijdens het ontwikkelen van een applicatie kan het helpen om snel te kunnen itereren op builds en tests, zonder steeds naar een extern systeem te moeten pushen om je builds of images te testen. ook kan het nuttig zijn om lokale versies van externe servies, zoals databases, te draaien met test data.

Maar als je meerdere containers lokaal wilt orkestreren kan het soms uiputtend worden om al die losse containers te moeten blijven stoppen, starten, bijwerken, etc. In die gevallen zou het handig zijn als je al je builds, configs, en meer met een enkel configuratie bestand en een enkel commando kon beheren.

Sinds een aantal jaren kun je naast de regulier Fedora Workstation (en de spins daarvan) ook een radicaal andere versie van een Fedora desktop installeren: Fedora Silverblue.

Op een Silverblue systeem heb je niet één root filesysteem, maar meerdere. Updates werken dan ook niet op je live systeem, maar als overlays op een upstream image. Applicaties installeer je als het even kan via Flatpak, maar je mag ook zelf RPM pakketten laten layeren bovenop het basis image.

Met de release van OpenShift 4.13 is de support voor het gebruik van de nieuwste generatie Control Groups (cgroup v2) van Technology Preview (TP) naar General Availability (GA) gegaan. Wel staat de standaard instelling nog op de eerste generatie.

Met de release van OpenShift 4.13 is de Custom Metrics Autoscaler Operator gepromoveerd naar General Availability (GA). Met deze operator kun je het aantal replica’s van je deployments automatisch laten schalen aan de hand van CPU gebruik, geheugen gebruik, custom Prometheus metrics, of Kafka Queues (die laatste is wel nog Technology Preview).

De beste methode om naar een nieuwe major versie van Red Hat Enterprise Linux (RHEL) te migreren is met een schone installatie of een nieuw image. In een ideale wereld kun je dit zonder problemen met al je systemen doen, je custom software werkt gewoon, en al je machines zijn volledig met behulp van automation uitgerold en geconfigureerd. In de echte wereld heb je helaas echter altijd wel een paar machines die zoveel handwerk hebben gehad, of zo slecht gedocumenteerd zijn, dat dit niet mogelijk is.

Voor die gevallen is er sinds de release van RHEL8 wel een manier om in ieder geval je OS wel te kunnen upgraden naar een nieuwe versie, zonder een nieuwe installatie te moeten doen: Leapp

In een heterogene server omgeving wil je vaak dezelfde (soort) taken uitvoeren op machines die verschillende distributies draaien. Nu kun je hiervoor verschillende playbooks gebruiken, maar je kunt je playbooks ook slim hiermee om laten gaan en voor één doel ook één playbook gebruiken.