Best Practices zum Erstellen bootfähiger Container

• Der Image-Modus von Red Hat Enterprise Linux (RHEL) vereinfacht den Aufbau, die Bereitstellung und die Verwaltung von RHEL als bootfähige Container
• Entwickler, Betriebsteams und Lösungsanbieter können dieselben containernativen Tools und Technologien verwenden, um Anwendungen und das zugrunde liegende Betriebssystem zu verwalten

Aufbau bootfähiger Container vs. Anwendungscontainer

• Wie gewöhnliche Anwendungscontainer können auch bootfähige Container mit bestehenden Container-Technologien wie Podman, Docker oder buildkit erstellt werden
• Images können in Container-Registries wie Quay.io, Docker Hub, GitHub Container Registry oder einer internen Container-Registry gespeichert werden
• Bootfähige Container sind eine natürliche Weiterentwicklung der Container-Technologie und bieten einen umfassenden containernativen Workflow sowie eine entsprechende User Experience, einschließlich des vollständigen Betriebssystems und des Linux-Kernels

Verwendung von Containerfile

• Ein Containerfile (auch Dockerfile genannt) enthält alle Informationen, die zum Erstellen eines Container-Images erforderlich sind, darunter das Basis-Image, Anweisungen zur Installation von Softwarepaketen sowie das Kopieren von Dateien aus einem Git-Repository
• Der Workflow und die Tools zum Erstellen bootfähiger Container sind im Wesentlichen dieselben wie bei Anwendungscontainern
• Beim Erstellen bootfähiger Container gelten jedoch einige Best Practices

Best Practices für Linting

• Es wird empfohlen, als letzten Schritt im Containerfile den Befehl bootc container lint auszuführen
• Dieser Befehl führt innerhalb des Container-Images mehrere Prüfungen durch und gibt bei Problemen einen Fehler aus
• Er prüft zum Beispiel, ob sich mehrere Kernel unter /usr/lib/modules befinden, kontrolliert die Dateisyntax in /usr/lib/bootc/kargs.d und überprüft den Zustand von /etc und /usr/etc in Bezug auf Sauberkeit und Konsistenz

GitHub Actions und Speicherplatz auf dem Datenträger

• Beim Erstellen von Containern mit GitHub Actions kann es aufgrund der Größe bootfähiger Container-Images zu Problemen mit dem verfügbaren Speicherplatz kommen
• Um dieses Problem zu lösen, kann dem Workflow eine Stufe hinzugefügt werden, die das Verzeichnis /opt/hostedtoolcache löscht, um Speicherplatz freizugeben

/var verstehen

• /var ist ein Verzeichnis für persistente, veränderliche, maschinenlokale Daten und Zustände; auch während eines Updates bleibt der Inhalt von /var im Container-Image unverändert
• Wenn eine Anwendung daher Daten nach /var schreibt, sollten diese in ein anderes Verzeichnis wie /usr/share verschoben werden, um Probleme mit schreibgeschützten Mounts zu vermeiden

Verwendung des Befehls useradd

• Wenn in Packaging-Skripten useradd aufgerufen wird, kann es zu State Drift kommen, wenn /etc/passwd lokal verändert wird
• Um solche Probleme zu vermeiden, kann die Verwendung der systemd-Option DynamicUser=yes zur dynamischen Benutzererstellung erwogen werden
• In komplexeren Fällen kann die Umstellung auf DynamicUser=yes jedoch schwierig sein; dann empfiehlt sich die Benutzererstellung mit systemd-sysusers

Einbetten von Containern mit Quadlet

• Das Ausführen containerisierter Workloads in systemd ist eine einfache und zugleich leistungsfähige Methode für zuverlässige Deployments
• Podman bietet mit Quadlet ein Tool zur Integration in systemd, mit dem sich containerisierte Workloads deklarativ verwalten lassen
• Quadlet ist vollständig in den Image-Modus integriert, und logisch gebundene Images können genutzt werden, um Anwendungscontainer-Images beim Booten vorab zu laden

Zusammenfassung

• Mit dem Image-Modus vollzieht sich ein Paradigmenwechsel bei der Arbeitsweise mit RHEL-Hosts
• Das Betriebssystem lässt sich mit cloudnativen Tools erstellen, bereitstellen und verwalten; dabei arbeitet man mit einem unveränderlichen OS, bei dem der Großteil des Systems schreibgeschützt eingehängt ist