Der Image-Modus für Red Hat Enterprise Linux (RHEL) verwendet dieselben Tools, Kompetenzen und Muster wie containerisierte Anwendungen, um ein Betriebssystem bereitzustellen, das einfacher zu entwickeln, bereitzustellen und auszuführen ist. Dieser Beitrag behandelt die Konzepte hinter dem Image-Modus und hilft, Nutzende in grundlegende Konzepte einzuführen, die für das Paketieren von Betriebssystemen in OCI-Container Images (Open Container Initiative) erforderlich sind.
Mit den folgenden Schritten und Prozessen können Sie die Konzepte hinter dem Image-Modus für RHEL aus einer praktischen Perspektive besser verstehen, indem Sie ein benutzerdefiniertes Image erstellen und bereitstellen.
Anforderungen:
- Sämtliche Befehle werden auf einem abonnierten RHEL 9.x-System (Laptop, VM (virtuelle Maschine) usw.) mit mindestens 10 GB verfügbarem Festplattenspeicher ausgeführt. Beachten Sie, dass je nach Größe und Menge der zu erstellenden Images möglicherweise mehr Festplattenspeicher erforderlich ist.
- Ein Red Hat Account mit Produktions- oder Entwicklungssubskriptionen (kostenlose Entwicklungssubskriptionen sind hier erhältlich).
Eine Container Registry – in diesem Beispiel wird quay.io als Registry zur Veröffentlichung der Inhalte verwendet. Sie können jedoch auch einen anderen gehosteten Registry-Service nutzen oder eine Registry lokal ausführen. Ein quay.io-Account kann schnell und einfach hier erstellt werden.
Einstieg
Vergewissern Sie sich zuerst, dass für Ihr System eine Subskription für den Erhalt von RHEL-Inhalten besteht.
$ sudo subscription-manager register
Als Nächstes installieren wir Podman. Wir empfehlen, die aktuell verfügbare Version zu verwenden, aber alle Versionen ab v4.* funktionieren. Beachten Sie, dass andere Container-Tools, wie Docker oder Container Pipeline-Tools, in einer Produktivumgebung funktionieren können. In diesem Beispiel werden die Konzepte zur Verwendung von Podman vermittelt. Denken Sie jedoch daran, dass andere Tools für Ihre Umgebung möglicherweise relevanter sind.
$ sudo dnf -y install podman
Authentifizieren Sie sich jetzt über registry.redhat.io. Rufen Sie zunächst https://access.redhat.com/terms-based-registry auf, und klicken Sie auf „New service account“. Klicken Sie hier auf den Namen des neuen Eintrags, kopieren Sie die Anweisungen für „docker login“, und fügen Sie sie in das Terminal ein, indem Sie den „docker“-Befehl durch „podman“ ersetzen. Die vollständigen Anweisungen finden Sie hier, falls Sie weitere Informationen benötigen. Zur Konvertierung des Container Images in ein Disk Image mit Image Builder sind erweiterte Berechtigungen für Podman erforderlich. Authentifizieren Sie sich mit und ohne sudo bei der Registry.
$ podman login registry.redhat.io
#repeat with sudo
$ sudo podman login registry.redhat.io
Bootc-Container Images unterscheiden sich technisch in 2 wichtigen Punkten von Anwendungs-Containern:
- Bootc-Images verwenden OSTree im Container.
- Ein bootc-Image enthält einen Kernel und genügend andere Pakete zum Starten einer physischen oder virtuellen Maschine.
Basis-Images von Anwendungs-Containern enthalten in der Regel einen minimalen Satz an Paketen, die sich nicht auf das Hardwaremanagement beziehen. Und im Gegensatz zum Red Hat Universal Base Image (UBI) werden bootc-Images in RHEL unter denselben Lizenzbedingungen wie RHEL verteilt.
Jetzt rufen wir das Basis-Image rhel-bootc
ab.
$ podman pull registry.redhat.io/rhel9/rhel-bootc:9.4
Erstellen eines Containerfiles
Sehen wir uns nun ein Beispiel für ein Containerfile an. Sie kennen diese vielleicht als „Dockerfiles“. Wir fangen einfach an und installieren einen LAMP-Stack. Speichern Sie den folgenden Text in einer neuen Datei namens Containerfile
:
FROM registry.redhat.io/rhel9/rhel-bootc:9.4
#install the lamp components
RUN dnf module enable -y php:8.2 nginx:1.22 && dnf install -y httpd mariadb mariadb-server php-fpm php-mysqlnd && dnf clean all
#start the services automatically on boot
RUN systemctl enable httpd mariadb php-fpm
#create an awe inspiring home page!
RUN echo '<h1 style="text-align:center;">Welcome to image mode for RHEL</h1> <?php phpinfo(); ?>' >> /var/www/html/index.php
Nun haben wir ein einfaches Betriebssystem beschrieben, das einen Webserver auf Port 80 ausführt und dazu eine Datenbank und PHP zur Verfügung stellt. Jetzt erstellen wir das Container Image:
Erstellen eines Images
$ podman build -f Containerfile -t quay.io/[my_account]/lamp-bootc:latest
Hinweis:
Mit -t
wird das Image mit einem Tag versehen. In diesem Beispiel wird davon ausgegangen, dass quay.io die verwendete Registry ist. Nehmen Sie Anpassungen für die von Ihnen verwendete Registry vor.
-f
weist Podman an, unser Containerfile zu verwenden.
Testen des Images
Nachdem wir nun unser Image erstellt haben, müssen wir es testen. Da es sich bei unserem Image um einen Container handelt, ist er schnell ausgeführt, und wir können auf Tippfehler achten, da eine Fehlermeldung ausgegeben wird. Wir vergeben der Einfachheit halber den Kurznamen („lamp“):
$ podman run -d --rm --name lamp -p 8080:80 quay.io/[my_account]/lamp-bootc:latest /sbin/init
Der Container wird gestartet, und Sie müssen sich jetzt nicht anmelden. Öffnen Sie einen Browser und überprüfen Sie, ob Sie die unter http://[your_ip_address]:8080 bereitgestellte Webseite anzeigen können. Wenn die Seite nicht geladen wird, überprüfen Sie Ihre Firewall-Regeln. Wenn Sie ein lokales System verwenden, sollte die Loopback-Adresse ordnungsgemäß funktionieren. In diesem Beispiel starten wir systemd. In vielen Testszenarien ist es jedoch effizienter, einfach eine Anwendung zu starten. Schnelle Tests und Validierungen zählen zu den tiefgreifendsten Aspekten bei der Verwendung von Containern zur Definition von Betriebssystem-Images.
Sie können über podman exec
unter Verwendung des oben festgelegten Namens in Shell für die ausgeführte Container-Instanz ausführen.
$ podman exec -it lamp /bin/bash
Stoppen Sie die Instanz unter Verwendung desselben Namens:
$ podman stop lamp
Übertragung in eine Registry
Authentifizieren Sie sich anschließend, indem Sie sich bei quay.io anmelden, das Image in die Registry übertragen und das Repository so konfigurieren, dass es öffentlich zugänglich ist.
$ podman login quay.io
$ podman push quay.io/[my_account]/lamp-bootc:latest
Zu diesem Zeitpunkt haben wir ein mehrschichtiges Image erstellt, das wir bereitstellen können. Für die Installation auf einem Host gibt es verschiedene Möglichkeiten: Wir können das Installationsprogramm von RHEL verwenden und ein Bare Metal-System (Deployment über USB, PXE usw.) starten, oder wir können Image Builder verwenden, um das Container Image in ein startfähiges Image zu konvertieren. Beachten Sie, dass zukünftige Updates direkt nach ihrer Veröffentlichung in der Container Registry angewendet werden, sobald der Container „installiert“ ist. Der Installationsprozess findet also nur einmal statt.
Deployment über KVM/QEMU mit einem Qcow2-Disk Image
In diesem Beispiel wird Image Builder verwendet, um das Container Image in eine mit qcow2 formatierte Disk zu konvertieren. In unserem Beispiel wird davon ausgegangen, dass sich das Image in einem öffentlich zugänglichen Repository befindet. Weitere Informationen zur Verwendung eines Images aus einem privaten Repository finden Sie in der Image Builder-Dokumentation. Neben qcow2 sind auch andere Image-Formate verfügbar.
Erstellen Sie zunächst eine config.json
-Datei, die die Konfiguration der resultierenden Disk ermöglicht. In diesem Beispiel enthält config.json
die Nutzenden, die Sie erstellen möchten. Fügen Sie in diesem Beispiel Ihren eigenen SSH-Schlüssel und Ihr eigenes Passwort ein.
{
"blueprint": {
"customizations": {
"user": [
{
"name": "cloud-user",
"password": "changeme",
"key": "ssh-rsa AAAAB3Nz..........",
"groups": [
"wheel"
]
}
]
}
}
}
Übertragen Sie als Nächstes die Datei config.json
zusammen mit dem lamp-Container an Image Builder:
$ sudo podman run --rm -it --privileged \
-v .:/output \
-v $(pwd)/config.json:/config.json \
--pull newer \
registry.redhat.io/rhel9/bootc-image-builder:9.4 \
--type qcow2 \
--config /config.json \
quay.io/[my_account]/lamp-bootc:latest
Sobald das Image bereit ist, können wir es mit libvirt (oder direkt mit qemu) ausführen.
virt-install \
--name lamp-bootc \
--memory 4096 \
--vcpus 2 \
--disk qcow2/disk.qcow2 \
--import \
--os-variant rhel9.4
Wenn die VM ausgeführt wird, sollten Sie überprüfen können, ob die Site ausgeführt wird, indem Sie http://[your_instance_ip_address] in einem Browser anzeigen.
Deployment in AWS mit einem AMI-Disk Image
Für dieses Beispiel müssen wir bestätigen, dass cloud-init in unserem zuvor erstellten lamp-Containerfile verfügbar ist. Hier hilft uns der Container Workflow. Wir können ganz einfach ein mehrschichtiges Image für unseren Use Case erstellen. Wir demonstrieren einen Build mit mehreren Schichten, aber Sie können das ursprüngliche Containerfile auch bearbeiten, um cloud-init hinzuzufügen, falls dies einfacher ist.
FROM quay.io/[my_account]/lamp-bootc:latest
#install cloud-init for AWS
RUN dnf install -y cloud-init && dnf clean all
Erstellen und übertragen Sie das Image:
$ podman build -f Containerfile -t quay.io/[my_account]/lamp-bootc-aws:latest
$ podman push quay.io/[my_account]/lamp-bootc-aws:latest
Zum Injizieren von Nutzenden und SSH-Schlüsseln nutzen wir cloud-init, sodass wir den config.json
-Schritt aus dem obigen KVM-Beispiel überspringen können. (Das Erstellen einer cloud-init-Konfiguration wird in diesem Dokument nicht behandelt.) Durch die Verwendung von cloud-init erhöhen wir die Sicherheit, da wir vermeiden, dass hartcodierte Zugangsdaten in unserem Image enthalten sind. Führen Sie als Nächstes Image Builder aus, um unser AMI zu erstellen:
$ sudo podman run --rm -it --privileged \
--pull=newer \
--security-opt label=type:unconfined_t \
-v $XDG_RUNTIME_DIR/containers/auth.json:/run/containers/0/auth.json \
-v $HOME/.aws:/root/.aws:ro \
--env AWS_PROFILE=default \
registry.redhat.io/rhel9/bootc-image-builder:9.4:latest \
--type ami \
--aws-ami-name lamp-bootc-aws \
--aws-bucket bootc-bucket \
--aws-region us-east-1 \
quay.io/[my_account]/lamp-cloud-init-bootc:latest
Zum Konfigurieren der Eigenschaften für AWS stehen zusätzliche Optionen zur Verfügung. Weitere Informationen finden Sie über diesen Link.
Nachdem der Veröffentlichungsprozess erfolgreich abgeschlossen wurde, können Sie Ihr Image starten und http://[your_instance_ip_address] in einem Browser anzeigen.
Bare Metal-Installation über Kickstart
Wie Sie gesehen haben, gibt es verschiedene Möglichkeiten, unseren Container zu installieren. In diesem Abschnitt wird die Verwendung von Kickstart beschrieben, das für Bare Metal-Bereitstellungen mit ISO-, PXE- oder USB-Laufwerken sehr beliebt ist. Es wird davon ausgegangen, dass Sie mit Kickstart-Konzepten vertraut sind, da dieser Guide hierzu nicht ins Detail geht. Fügen Sie im folgenden Beispiel Details zu Nutzenden, Passwörtern und SSH-Schlüsseln ein. Das Hinzufügen zusätzlicher Optionen wird unterstützt. Beachten Sie jedoch, dass der Abschnitt „%packages“ mit diesem Workflow nicht funktioniert, da die Instanz durch das Container Image ersetzt wird. Laden Sie die 9.4-Boot-ISO für Ihre Architektur von dieser Website herunter.
text
network --bootproto=dhcp --device=link --activate
# Basic partitioning
clearpart --all --initlabel --disklabel=gpt
reqpart --add-boot
part / --grow --fstype xfs
# Here's where we reference the container image to install - notice the kickstart
# has no `%packages` section! What's being installed here is a container image.
ostreecontainer --url quay.io/[my_account]/lamp-bootc:latest
firewall --disabled
services --enabled=sshd
# optionally add a user
user --name=cloud-user --groups=wheel --plaintext --password=changemme
sshkey --username cloud-user "ssh-ed25519 AAAAC3Nza....."
# if desired, inject a SSH key for root
rootpw --iscrypted locked
sshkey --username root "ssh-ed25519 AAAAC3Nza....." #paste your ssh key here
reboot
Kopieren Sie diese Konfigurationsdatei auf einen Webserver, aktualisieren Sie Passwort und SSH-Schlüssel, starten Sie physische oder virtuelle Systeme mit den Installationsmedien, und hängen Sie Folgendes an die Kernel-Argumente an:
inst.ks=http://path_to_my_kickstart
Drücken Sie Strg-x, um mit dieser Option zu starten.
Wenn kein HTTP-Server verfügbar ist, können Sie das HTTP-Servermodul verwenden, das in den meisten Python-Installationen verfügbar ist. Führen Sie im Verzeichnis, das die Kickstart-Datei enthält, folgenden Befehl aus:
$ python -m http.server
Ein anderer Ansatz, bei dem kein HTTP-Server zum Hosten der Kickstart-Datei verwendet wird, fügt den Kickstart in die ISO des Installationsprogramms ein. Das lorax-Paket enthält ein Dienstprogramm namens „mkksiso“, mit dem diese Datei in eine ISO eingebettet werden kann. Dies ist nützlich, um direkt von einem USB-Speicher zu starten, und vermeidet die Bearbeitung des Startmenüs. Run: mkksiso --ks /PATH/TO/KICKSTART /PATH/TO/ISO /PATH/TO/NEW-ISO
Übertragen eines Updates
Ein wichtiger Aspekt hierbei ist, dass die Installation oder Bereitstellung eine einmalige Aufgabe ist. Ein Großteil der Vorteile dieses Modells stellt sich an „Tag 2“ ein, wenn Änderungen durch das Übertragen von Images an die Registry vorgenommen werden. Automatische Updates sind standardmäßig aktiviert! Dies ist für Wartungsfenster einfach zu konfigurieren oder kann komplett deaktiviert werden. Um es auszuprobieren, nehmen Sie eine Änderung an Ihrem Containerfile vor, und wiederholen Sie die Erstellungs-& und Übertragungsschritte, um das neue Image in Ihrer Registry verfügbar zu machen. Der Standard-Timer für die systemd-Einheit beginnt nach einer Stunde Betriebszeit, aber Sie können das Upgrade auch früher mit dem Befehl „bootc upgrade“ ausführen.
Nächste Schritte
Nachdem Sie nun ein einfaches Beispiel mit dem Image-Modus für RHEL durchgearbeitet haben, empfehlen wir, einige Ihrer eigenen Use Cases zu untersuchen und die Möglichkeiten und operative Effizienz zu berücksichtigen, die sich durch die Verwendung von Container-Tools zur Versionierung und Verwaltung von Betriebssystem-Deployments ergeben. Schauen Sie sich unbedingt unser bootc-Beispiel-Repository an, das eine Reihe von Plattformen und nützliche Szenarien ermöglicht. Lesen Sie außerdem die vollständige Dokumentation.
Über den Autor
Ben Breard is a Senior Principal Product Manager at Red Hat, focusing on Red Hat Enterprise Linux and Edge Offerings.
Nach Thema durchsuchen
Automatisierung
Das Neueste zum Thema IT-Automatisierung für Technologien, Teams und Umgebungen
Künstliche Intelligenz
Erfahren Sie das Neueste von den Plattformen, die es Kunden ermöglichen, KI-Workloads beliebig auszuführen
Open Hybrid Cloud
Erfahren Sie, wie wir eine flexiblere Zukunft mit Hybrid Clouds schaffen.
Sicherheit
Erfahren Sie, wie wir Risiken in verschiedenen Umgebungen und Technologien reduzieren
Edge Computing
Erfahren Sie das Neueste von den Plattformen, die die Operations am Edge vereinfachen
Infrastruktur
Erfahren Sie das Neueste von der weltweit führenden Linux-Plattform für Unternehmen
Anwendungen
Entdecken Sie unsere Lösungen für komplexe Herausforderungen bei Anwendungen
Original Shows
Interessantes von den Experten, die die Technologien in Unternehmen mitgestalten
Produkte
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud-Services
- Alle Produkte anzeigen
Tools
- Training & Zertifizierung
- Eigenes Konto
- Kundensupport
- Für Entwickler
- Partner finden
- Red Hat Ecosystem Catalog
- Mehrwert von Red Hat berechnen
- Dokumentation
Testen, kaufen und verkaufen
Kommunizieren
Über Red Hat
Als weltweit größter Anbieter von Open-Source-Software-Lösungen für Unternehmen stellen wir Linux-, Cloud-, Container- und Kubernetes-Technologien bereit. Wir bieten robuste Lösungen, die es Unternehmen erleichtern, plattform- und umgebungsübergreifend zu arbeiten – vom Rechenzentrum bis zum Netzwerkrand.
Wählen Sie eine Sprache
Red Hat legal and privacy links
- Über Red Hat
- Jobs bei Red Hat
- Veranstaltungen
- Standorte
- Red Hat kontaktieren
- Red Hat Blog
- Diversität, Gleichberechtigung und Inklusion
- Cool Stuff Store
- Red Hat Summit