Anmelden / Registrieren Konto

Die Einführung von Red Hat Enterprise Linux (RHEL) 8.3 bringt eine Vielzahl neuer Container-Funktionen mit sich. Diese bauen auf RHEL 8.2 (New container capabilities in Red Hat Enterprise Linux 8.2) auf und bieten Nutzern noch mehr Gründe für ein Upgrade von RHEL 7.

Hier ein kurzer Überblick:

  • Neues Training für Container Tools

  • Update auf den schnellen Stream von container-tools:rhel8

  • Podman 2.0 mit neuer REST API und Docker-kompatiblem Endpunkt

  • Skopeo 1.X mit größerer Stabilität und An-/Abmeldefunktionen

  • Buildah und Skopeo Image sind allgemein verfügbar und werden unterstützt

  • Das Podman-Container-Image ist als Technologievorschau verfügbar

  • Neue Anwendungs-Container-Images

  • Unterstützung des Podman-Manifests

Schneller Stream für das Aktualisieren von Container Tools (container-tools:rhel8)

Der container-tools:rhel8-Stream mit RHEL 8.3 für folgende Versionen: Podman 2.0.5, Buildah 1.15.1 und Skopeo 1.1.1.

Hier ist eine Liste einiger interessanter neuer Funktionen ab RHEL 8.2:

  • Rootless Podman fügt jetzt einen Eintrag zu /etc/passwd für Nutzer hinzu, die Podman mit --userns=keep-id ausführen.

  • Der Befehl podman system connection ist wieder verwendbar und wurde überarbeitet, um mehrere Verbindungen zu unterstützen.

  • Podman verfügt jetzt über das neue globale Flag --connection, um eine Verbindung zu einer Remote-Podman-API-Instanz anzugeben.

  • Der Befehl podman search erlaubt jetzt Platzhalter in Suchbegriffen.

  • Der Befehl podman play kube unterstützt jetzt den Pull-Typ „IfNotPresent".

  • Die REST API und der Podman-Systemservice sind nicht mehr experimentell und jetzt einsatzbereit.

  • Der Podman-Befehl unterstützt jetzt Remoteverbindungen über die REST API unter Verwendung des Flags --remote.

  • Der Podman-Remoteclient wurde vollständig neu programmiert, um die neue REST API anstelle von Varlink zu verwenden.

  • Der Befehl podman generate systemd unterstützt jetzt das Flag --new, wenn er mit Pods verwendet wird, sodass portierbare Services für Pods erstellt werden können.

  • Buildah: Zusätzlichen VFS-Image-Speicher zum Container hinzufügen

  • Buildah: Bessere Integration von containers.conf

Podman 2.0

Hierbei handelt es sich um eine neue Hauptversion von Podman. Aber was bedeutet eigentlich eine „neue Hauptversion"? Podman verwendet die sogenannte „semantische Versionierung" (Semantic Versioning), kurz: SemVer. Die Website semver.org enthält eine gute Beschreibung, daher hier nur eine kurze Auffrischung. Unter SemVer hat jedes Programm eine Major-, Minor- und Patch-Nummer im Format MAJOR.MINOR.PATCH. In RHEL 8.3 veröffentlichen wir beispielsweise Podman 2.0.5. So erklärt semver.org die Versionsnummern:

  1. MAJOR-Versionen enthalten inkompatible API-Änderungen.

  2. MINOR-Versionen enthalten zusätzliche, abwärtskompatible Funktionen.

  3. PATCH-Versionen enthalten abwärtskompatible Bug-Fixes.

Die Major-Version von Podman wurde inkrementiert, da die aktuelle auf varlink basierende API durch die neue REST API ersetzt wurde, die Podman 2.0 mit einer auf Version 1.40 gerichteten Docker-Kompatibilitätsschicht referenziert. Die neue REST API ist die bevorzugte Methode zur programmgesteuerten Interaktion mit Podman. Die varlink-basierte Schnittstelle ist mittlerweile veraltet. Sie wird nicht mehr erweitert und soll in Podman 3.0 entfernt werden.

Diese REST-Schnittstelle ist das letzte Puzzleteil, um den Übergang bei einem Upgrade von RHEL 7 für Kunden, die den Docker-Daemon verwenden, auf RHEL 8 mit Podman zu erleichtern. Bereits bei der Einführung von RHEL 8 war Podman in vielen wichtigen Bereichen mit dem Docker-Daemon kompatibel. Podman verwendet dieselben Images, kann mit denselben Registrierungsservern kommunizieren, verwendet dieselbe Runtime (runc) und verfügt sogar über eine Befehlszeile (Command Line Interface, CLI), mit der Nutzer der Docker-CLI sehr vertraut ist. 

  • Image-Format: kompatibel

  • Registry-Format: kompatibel

  • Runtime-Format: kompatibel

  • CLI: kompatibel

  • API: kompatibel ab Version 2.0

Mit der neuen Podman 2.0 REST API sorgen wir für lückenlose Kompatibilität. Dies sollte es Nutzern ermöglichen, Code, der auf der Docker-API basiert, in RHEL 8 zu übernehmen. Dies verdanken wir der hervorragenden Arbeit des Podman-Teams.

Weitere Informationen erhalten Sie in den folgenden Artikeln und Dokumentationen:

Container Images für Buildah und Skopeo

Durch das Verpacken von Software als Container Images können andere Entwickler ihre Arbeit als "Konsumenten" beginnen (Life in The Container – When it comes to code, be a consumer). Dies gilt sowohl für Anwendungsabhängigkeiten als auch für die Tools, mit denen wir unsere Anwendungen erstellen. Um Reibungsverluste zu vermeiden und in jedem möglichen Use Case OCI-konforme Tools (Open Container Initiative) zu ermöglichen, arbeitet Red Hat an containerisierten Versionen von Container Tools wie Buildah, Skopeo und Podman.

Mit dem Release von RHEL 8.3 bieten wir jetzt eine Technologievorschau der Container Images für Podman sowie allgemein verfügbare Images für Buildah und Skopeo. Wir laden Sie ein, diese Images zu verwenden und uns Feedback zu geben. Ziel ist es, eine Reihe von containerisierten Anwendungen bereitzustellen, mit denen Sie überall dort andere Anwendungen erstellen können, wo Sie bereits Container ausführen.

Neue Anwendungs-Container-Images

Mit RHEL 8.3 veröffentlichen wir aktualisierte Versionen vieler Container Images, mit denen Nutzer Anwendungen erstellen können. Weitere Details erfahren Sie in den Versionshinweisen und auf der Produktseite zu RHEL 8 im Red Hat Ecosystem Catalog.

Produktseite zu Red Hat Universal Base Image (UBI) 8

Produktseite zu RHEL 8

  • GCC Toolset/Perftools 10

  • Grafana

  • PCP

Unterstützung des Podman-Manifests

Sie können den Befehl podman run -it ubi8 auf RHEL 8 ausführen, unabhängig davon, ob es auf x86, ARM, POWER oder Z installiert ist. Der Befehl ist sehr einfach, aber die Container Images sind für jede physische Architektur unterschiedlich. Die Binärdateien in den Container Images wurden für die jeweilige Architektur kompiliert. Für x86 kompilierte Binärdateien können nicht auf ARM-Prozessoren ausgeführt werden und umgekehrt. Damit die Befehle auf jeder Architektur funktionieren, muss Red Hat mehrere Container Images in ein Container Repository einbetten. Für RHEL 8-Images bedeutet dies, dass in jedes Repository (z. B. registry.access.redhat.com/ubi8/ubi) vier verschiedene Images eingebettet sind, jeweils eines für jede unterstützte Architektur (z. B. x86, ARM, POWER und Z).

Dieser neue Unterbefehl podman manifest hilft Nutzern bei der Interaktion mit den Metadaten, die für die Arbeit mit diesen Multi-Arch-Repositories erforderlich sind. Diese Metadaten werden im OCI-Sprachgebrauch häufig als Image-Index oder im Docker-Sprachgebrauch als Manifestliste bezeichnet. Sie sind im Wesentlichen Teil der JSON-Metadaten, die Container Engines wie Podman oder Docker wichtige Informationen zu den in einem Repository verfügbaren Architekturen (x86, ARM, POWER, Z) liefern.

Die neueste Version von Podman in RHEL 8.3 bietet die Basis-Tools, die zum Erstellen von Multi-Arch-Images (Images für mehr als eine Architektur) und deren Übertragung auf Remote-Server erforderlich sind. Diese Funktionen sind für Kunden nützlich, die erweiterte Container Image Builds durchführen.

Beispiel zum Erstellen eines lokalen Manifests:

podman manifest create localhost/list

Und zur Überprüfung:

podman manifest inspect localhost/list

Ausgabe:

{  "schemaVersion": 2,  "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",  "manifests": null }

Verbesserung Ihrer Linux-Kenntnisse mit RHEL Container Tools

Aufgrund der zunehmenden Bedeutung von Containern bei der Unternehmenssoftware hat Red Hat zwei unserer Linux-Kernkurse um einen Tag verlängert, um das Thema Container abzudecken. Ab dem 1. Oktober 2020 wurden die Kurse Red Hat System Administration II (RH134) und RHCSA Rapid Track (RH199) von vier auf fünf Tage verlängert, wobei sich der letzte Tag auf das Thema Container konzentriert, zur Vorbereitung der Nutzer auf Kubernetes und Red Hat OpenShift.

Teilnehmer an den Kursen RH134 und RH199 verwenden jetzt RHEL Container Tools, um Services als Container auf einem einzigen RHEL-Server abzurufen, auszuführen und zu verwalten. 

OpenShift basiert auf RHEL als bewährte Basis und bietet die Sicherheitsfunktionen, Stabilität und Infrastrukturen, die Sie kennen und erwarten. Red Hat hat Linux unternehmensfähig gemacht. Jetzt tun wir dasselbe mit Kubernetes. Und da Container im Grunde genommen eine Linux-Technologie sind, kann Red Hat Ihnen einen optimierten Lernpfad bieten, mit dem Sie Ihre Kernkompetenzen um Container und Kubernetes erweitern können.

Durch diese Aktualisierung unserer Linux-Kurse beinhaltet das Red Hat Certified System Administrator Exam (EX200) auch das Thema Container. Dieser neue Prüfungsinhalt bietet Teilnehmern praktische Erfahrungen in echten Container-Anwendungen und verlängert die Prüfungsdauer um 30 Minuten.

Red Hat Enterprise Linux 7 EX200 ist von diesen Änderungen nicht betroffen. Inhaltliche Änderungen betreffen nur Red Hat Enterprise Linux 8.2 RH199, RH134 und EX200. In Red Hat System Administration I (RH124) werden Container nicht behandelt. Der Kurs wurde jedoch auf RHEL 8.2 aktualisiert.

Weitere Informationen zu diesen Trainings- und Zertifizierungsaktualisierungen finden Sie im vollständigen Blog und auf der Landing Page zur Karriereförderung.

Fazit

Ob im Container Image oder auf dem Container Host, RHEL steht bei Red Hat Containern an erster Stelle. RHEL 8.3, die neueste Version, bietet Funktionen, die als Grundlage für OpenShift und darüber hinaus dienen. 

Weitere Informationen zu den neuen Funktionen finden Sie in der Produktdokumentation, in den Versionshinweisen und in den neuen UBI-Images im Ecosystem Catalog.


About the author

Scott McCarty is technical product manager for the container subsystem team, which enables key product capabilities in OpenShift Container Platform and Red Hat Enterprise Linux. Focus areas includes container runtimes, tools, and images. Working closely with engineering teams, at both a product and upstream project level, he combines personal experience with customer and partner feedback to enhance and tailor strategic container features and capabilities.

Highlights

Das könnte für Sie von Interesse sein