Mit Distrobox lassen sich komplette Distributionen bequem in Container sperren und so unter anderem gefahrlos testen.

Dieser Artikel gibt meine Motivation für den Bau von Container-Images und die Vorgehensweise wieder und zeigt, wie ich mit Buildah meine OCI-kompatiblen Container-Images erstelle.

Es handelt sich dabei mehr um einen Erfahrungsbericht als ein Tutorial und ich erhebe keinen Anspruch auf Vollständigkeit. Das behandelte Beispiel ist jedoch zum Einstieg und zur Nachahmung für all jene geeignet, die Container ausführen können und diese gerne ohne Verwendung von Containerfiles bauen möchten.

Motivation

Ich möchte die Ansible-Rollen aus meiner Collection tronde.nextcloud mit Molecule und Podman-Containern testen. Als Zielplattform für das Deployment der Nextcloud unterstütze ich zunächst Debian und RHEL.

Die Tests sollen verifizieren, dass Nextcloud im Container in einer rootless-Podman-Umgebung bereitgestellt werden kann. Da der Test unter Verwendung von Podman-Containern durchgeführt werden soll, müssen diese Container eine solche rootless-Podman-Umgebung bereitstellen.

Für RHEL 8 und RHEL 9 habe ich entsprechende Container-Images gefunden. Für Debian bin ich nicht fündig geworden und habe daher beschlossen, diese Container-Images selbst zu erstellen.

Buildah ist das Werkzeug meiner Wahl, da:

• Container-Images damit interaktiv erstellt werden können,
• die verwendeten Befehle am Ende in einem Bash-Skript gesammelt werden können,
• sich damit sogar interaktive Abfragen mit Heredocs beantworten lassen,
• man kein containerfile(5) benötigt und
• ich das Werkzeug noch nicht kenne und es gerne kennenlernen möchte.

Für mich sind dies ausreichend Gründe, um mich kopfüber in ein neues Container-Projekt zu stürzen. Wer mehr über die Beziehung von Buildah zu Podman erfahren möchte, dem empfehle ich den englischsprachigen Artikel: Buildah and Podman Relationship von Tom Sweeney.

Mein Weg zum Image

Um rootless Podman in einem Container zum Laufen zu bekommen, habe ich mich an dem englischsprachigen Artikel How to use Podman inside of a container von Dan Walsh orientiert. Das Ergebnis findet ihr in meinem GitHub-Repo tronde/container-image-forge.

Die folgenden Code-Blöcke zeigen Auszüge aus dem Skript buildah_create_debian_bookworm_with_rootless_podman.sh (Commit 7634ed8). Die enthaltenen Befehle werden unter dem jeweiligen Code-Block erläutert. Alle Befehle werden als normaler Benutzer ohne Root-Rechte ausgeführt.

# Name of target container image
tctri=debian_rootless_podman

# Get a base image
ctr=$(buildah from --pull=newer docker://docker.io/library/debian:bookworm)

• Die Variable tctri nimmt den Namen des Container-Images auf, welches ich erzeugen werde
• Die Variable ctr nimmt den Namen des Containers auf, welcher durch den buildah-from(1)-Befehl erzeugt wird; mit diesem Container wird im Folgenden gearbeitet
• Die Option --pull=newer sorgt dafür, dass das Image nur dann aus der angegebenen Registry heruntergeladen wird, wenn es aktueller als das evtl. lokal gespeicherte Image ist

buildah run -- $ctr apt -y update
buildah run -- $ctr apt -y upgrade
buildah run -- $ctr apt -y install podman fuse-overlayfs libvshadow-utils libcap2-bin ca-certificates

• Mit buildah-run(1) werden Befehle innerhalb des Arbeits-Containers ausgeführt
• Ich aktualisiere die im Basis-Image enthaltenen Pakte und
• installiere die für rootless Podman benötigten Pakete
• Das Paket ca-certificates wird benötigt, um später Container-Images aus einer Registry herunterladen zu können

buildah run -- $ctr useradd podman
buildah run -- $ctr sh -c "echo podman:1:999 > /etc/subuid"
buildah run -- $ctr sh -c "echo podman:1001:64535 >> /etc/subuid"
buildah run -- $ctr sh -c "echo podman:1:999 > /etc/subgid"
buildah run -- $ctr sh -c "echo podman:1001:64535 >> /etc/subgid"
buildah run -- $ctr setcap cap_setuid+epi /usr/bin/newuidmap
buildah run -- $ctr setcap cap_setgid+epi /usr/bin/newgidmap

• Mit den hier dargestellten Befehlen wird der nicht-privilegierte Benutzer podman erstellt
• Die IDs für /etc/sub[g,u]id habe ich mir aus dem ubi9/podman-Image abgeschaut
• Die setcap-Befehle sind notwendig, um rootless Podman ausführen zu können; ich habe sie durch Internetrecherche und Trial-and-Error zusammengestellt

buildah config -v /var/lib/containers $ctr
buildah config -v /home/podman/.local/share/containers $ctr

• Das Image wird in der Lage sein, rootful und rootless Podman auszuführen
• Mit den beiden Befehlen werden die Volumes hinzugefügt, die Podman als Container Storage nutzt
  • Rootful Podman verwendet /var/lib/containers
  • Rootless Podman verwendet /home/podman/.local/share/containers

buildah run -- $ctr chown -R podman:podman /home/podman
buildah run -- $ctr sh -c "mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers /var/lib/shared/vfs-images /var/lib/shared/vfs-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock; touch /var/lib/shared/vfs-images/images.lock; touch /var/lib/shared/vfs-layers/layers.lock"
buildah config --env _CONTAINERS_USERNS_CONFIGURED="" $ctr

• Der Benutzer podman bekommt ein HOME-Verzeichnis
• Ich erstelle die Verzeichnisse, die ich im Artikel [7] gefunden habe
• Ich erstelle die Environment-Variable, die ich ebenfalls in genanntem Artikel [7] gefunden habe

buildah run -- $ctr apt -y reinstall uidmap
buildah run -- $ctr apt -y clean
buildah run -- $ctr rm -rf /var/lib/apt/lists/*

• Aus mir nicht bekannter Ursache muss das Paket uidmap neu installiert werden, um ein UID/GID-Mapping sicherzustellen; dies scheint analog zur Neuinstallation der shadow-utils in Artikel [7] notwendig zu sein
• Die beiden folgenden Befehle sollen den Paket-Cache aufräumen, um die Größe des resultierenden Images zu verkleinern, zeigen jedoch keinen sichtbaren Effekt

# Commit to an image
buildah commit --rm $ctr $tctri
# Alternative: Use this and add GPG fingerprint for image signing
# buildah commit --sign-by <fingerprint> --rm $ctr $tctri

# Tag the image just created
buildah tag $tctri $tctri:bookworm-$(date --iso)

• Mit buildah-commit(1) wird der Inhalt des Arbeits-Containers $ctr in ein Container-Image namens $tctri geschrieben
• Durch Angabe der Option --rm wird der Arbeits-Container entfernt
• Die Kommentarzeile lässt erkennen, dass ich zukünftig beabsichtige, meine Images digital zu signieren
• buildah-tag(1) fügt dem Image einen Tag mit Datumsstempel hinzu; siehe auch: Recommendations for tagging and versioning container images

Der Befehl buildah-commit(1) fügt dem neuen Image übrigens nur einen weiteren Layer hinzu, egal wie viele Befehle zuvor im Arbeits-Container ausgeführt wurden. Das erzeugte Image umfasst also die Layer des Basis-Image plus einen weiteren.

Zwischenfazit

An diesem Punkt habe ich ein Basis-Image ausgewählt, mithilfe von buildah zusätzliche Software installiert, einen Benutzer hinzugefügt und ein neues Image erzeugt.

Um den Build-Prozess zu automatisieren, habe ich die notwendigen Befehle in Bash-Skripte geschrieben und unter https://github.com/Tronde/container-image-forge abgelegt.

Die fertigen Images halte ich in der Registry https://quay.io/repository/rhn-support-jkastnin/debian_rootless_podman vor. Fühlt euch frei, diese für eigene Experimente zu benutzen, doch verwendet sie nur mit Vorsicht in Produktion. Ich erzeuge diese Images nur nach Bedarf neu, so dass die veröffentlichen Versionen veraltet und voller Sicherheitslücken sein können.

Validierung

Jetzt, wo die Images fertig sind, kann ich prüfen, ob sich rootless Podman darin auch wie gewünscht ausführen lässt.

Die Prozesse innerhalb des von meinem Container-Image instanziierten Containers laufen als Benutzer root. Um die Prozesse als Benutzer podman auszuführen, ist dies beim Aufruf von podman run explizit mit anzugeben. Der folgende Code-Block verdeutlicht dies und zeigt zugleich den ersten Fehler beim Versuch rootless Podman auszuführen.

]$ podman run --rm localhost/debian_rootless_podman:bookworm-2024-09-21 id
uid=0(root) gid=0(root) groups=0(root)
]$ podman run --rm --user podman localhost/debian_rootless_podman:bookworm-2024-09-21 id
uid=1000(podman) gid=1000(podman) groups=1000(podman)
]$ podman run --rm --security-opt label=disable --user podman --device /dev/fuse localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
time="2024-09-21T18:43:35Z" level=error msg="running `/usr/bin/newuidmap 15 0 1000 1 1 1 999 1000 1001 64535`: newuidmap: write to uid_map failed: Operation not permitted\n"
Error: cannot set up namespace using "/usr/bin/newuidmap": exit status 1

Der Fehler deutet auf fehlende capabilities(7) hin. Um diese Hypothese zu testen, wiederhole ich den letzten Befehl mit der Option --privileged (siehe dazu podman-run(1)):

]$ podman run --rm --security-opt label=disable --user podman --device /dev/fuse --privileged localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
host:
…

Damit funktioniert es. Leider geben sich viele Menschen an dieser Stelle mit dem Ergebnis zufrieden. Doch ich möchte diese Container nicht einfach mit --privileged ausführen. Also studiere ich die Manpage capabilities(7) und teste mich Stück für Stück heran, bis ich mit dem folgenden Kommando ebenfalls erfolgreich bin:

]$ podman run  --rm --user podman --security-opt label=disable --device /dev/fuse --cap-add=setuid,setgid,sys_admin,chown localhost/debian_rootless_podman:bookworm-2024-09-21 podman info
host:
…

Dies ist schon deutlich besser, da dem Container hiermit deutlich weniger Privilegien eingeräumt werden müssen. Das Thema Container-Privilegien und capabilities(7) werde ich noch genauer untersuchen. Eventuell folgt dazu dann auch ein weiterer Artikel. Für den Moment ist das Ergebnis gut genug.

Quellen und weiterführende Links

1. Buildah.io
2. Ansible Collection tronde.nextcloud
3. Mein Wochenendprojekt Nextcloud im Container
4. Podman Images im Red Hat Catalog
5. Buildah and Podman Relationship von Tom Sweeney
6. About Ansible Molecule
7. How to use Podman inside of a container by Dan Walsh
8. Using podman containers
9. Having trouble getting started with rootless podman running rootless podman inside a Debian 12 image #23838
10. Recommendations for tagging and versioning container images

Incus jongliert Container und virtuelle Maschinen. Die neue Version kann einen Sub-Pfad eines Volumes als Disk verwenden und isolierte OVN-Netzwerke erzeugen.

Das Solus-Projekt hat die Entfernung des AppArmor-Patchsets aus der Linux-Kernel-Version 6.9 in ihrem aktuellen Branch angekündigt. Diese Änderung markiert den Beginn des Endes der Unterstützung von Snap-Paketen in der Distribution und signalisiert eine Umstellung auf Flatpak als bevorzugtes Framework für die Softwareinstallation. Solus hat seit 2017 sowohl Snap- als auch Flatpak-Unterstützung angeboten und den Nutzern […]

Der Beitrag Solus wechselt von Snap zu Flatpak erschien zuerst auf fosstopia.

Canonicals Container-Dienst LXD schiebt jetzt virtuelle Maschinen automatisch auf passende CPU-Kerne.

Als Fork des Container-Managers LXD entstanden, entfernt sich die Version 6.2 von Incus weiter von seinem Vorbild.

Mit Version 6.2 des Container- und Virtual-Machine-Manager Incus kommt unter anderem das neue Kommando “incus top” , das Systeminformationen ausgibt.

Das bei Red Hat entwickelte Podman ist eine Alternative zu Docker. Es benötigt keinen Daemon und läuft ohne Root-Rechte. Gerade ist Podman 5.0 erschienen.

Quelle

Flox ist nach Angaben der Entwickler eine virtuelle Umgebung und ein Paketmanager in einem.

Canonical treibt die Umstellung der Softwarepakete vom traditionellen Debian Paketformat ins hauseigene Snap Containerformat voran. In Ubuntu 24.04 LTS wird der E-Mail Client Thunderbird exklusiv als Snap-Paket angeboten. Dies deutete sich bereits in den Vorversionen an. Ubuntu 22.04 LTS kam noch mit einem Debian Paket. Ubuntu 23.10 bot bereits ein Snap Paket an, welches aus...

Der Beitrag Ubuntu 24.04 treibt die Debian Paket zu Snap Transformation voran erschien zuerst auf MichlFranken.

Canonical treibt die Umstellung der Softwarepakete vom traditionellen Debian Paketformat ins hauseigene Snap Containerformat voran. In Ubuntu 24.04 LTS wird der E-Mail Client Thunderbird exklusiv als Snap-Paket angeboten. Dies deutete sich bereits in den Vorversionen an. Ubuntu 22.04 LTS kam noch mit einem Debian Paket. Ubuntu 23.10 bot bereits ein Snap Paket an, welches aus...

Der Beitrag Ubuntu 24.04 treibt die Debian Paket zu Snap Transformation voran erschien zuerst auf MichlFranken.

Die als Grundlage für Container beliebte schlanke Distribution Alpine Linux aktualisiert in ihrer neuen Version 3.19 vor allem die enthaltene Software.

Die Software Distrobox startet Distributionen innerh

Die Software Distrobox startet Distributionen innerhalb eines Containers. Diese kann die neue Version 1.6 auch mit dem Containerdienst Lilipod hochfahren.

Suse hat Rancher Prime 2.0 vorgestellt. Die Kubernetes-Management-Plattform bringt unter anderem eine tiefere Integration von NeuVector, der Containersicherheitsplattform von Suse.

Als Tech Preview führt Suse die Rancher Prime Application Collection ein, eine kuratierte Bibliothek von Entwickler- und Infrastrukturanwendungen. Diese Anwendungen seien mit Suse Linux Enterprise (SLE) Base Container Images erstellt und verpackt worden und Kunden könnten sie schnell und einfach starten und bei der Erstellung von Workloads und Anwendungen auf die Zero-Trust-Prinzipien von Suse und die Sicherheitsgarantien der Software-Lieferkette bauen.

Der durch generative AI unterstützte Rancher Prime-Kundenassistent sei nun im Rancher Prime-Kunden-Slack-Kanal verfügbar und biete Anleitungen zu vielen Themen wie Installation und Konfiguration, Leistung und Fehlerbehebung, teilt Suse weiter mit.

Neben Rancher Prime 2.0, der kommerziellen Enterprise-Plattform habe auch die Rancher-Community-Edition Updates bekommen, heißt es.

Der Beitrag Suse bringt Rancher Prime 2.0 erschien zuerst auf Linux-Magazin.

In diesem Tutorial zeige ich euch, wie ihr eine automatische Aktualisierung für Container in rootless-Podman-Umgebungen konfigurieren und diese Container als systemd-Services verwalten könnt.

Das Tutorial gliedert sich in folgende Abschnitte:

1. Anwendungsfälle
2. Voraussetzungen
3. Umgebung und verwendetes Container-Image
4. Konfiguration des systemd-Service mit Auto-Update-Funktion
5. Container (automatisch) aktualisieren

Wer sich nicht für die möglichen Anwendungsfälle interessiert und lieber gleich starten möchte, kann den ersten Abschnitt überspringen. Die übrigen Abschnitte sollten in der angegebenen Reihenfolge gelesen werden.

Anwendungsfälle

• Container werden auf einem Single-Container-Host ausgeführt und nicht in K8s-Umgebungen
• Man vertraut dem Anbieter, dass dieser stabile und nutzbare Container-Images bereitstellt
• Es soll regelmäßig geprüft werden, ob aktualisierte Container-Images vorhanden sind
• Sind aktuellere Images vorhanden, sollen laufende Container entfernt und unter Verwendung der aktuellen Images neu erstellt werden

Voraussetzungen

Um diesem Tutorial folgen zu können, benötigt ihr einen Host mit einer rootless-Podman-Umgebung. Podman muss dabei in der Version >= 3.3 verfügbar sein. In der folgenden Liste findet ihr einige Links, die euch helfen, eine solche Umgebung aufzusetzen.

• Podman Installation Instructions
• Basic Setup and Use of Podman in a Rootless environment
• Rootless-Podman mit Debian Bullseye
• Kurztipp: Rootless Podman + docker-compose unter Fedora
• RHEL 9: Setting up rootless containers
• RHEL 8: Setting up rootless containers

Darüber hinaus solltet ihr Manpages lesen können.

Umgebung und verwendetes Container-Image

• RHEL 9
• Podman 4.4.1
• Container-Image von louislam/uptime-kuma

Das Betriebssystem spielt eine untergeordnete Rolle, da wir durch die Verwendung von Containern die Anwendung vom Betriebssystem entkoppeln. Alle zur Ausführung der Anwendung notwendigen Abhängigkeiten sind im Container-Image enthalten.

Uptime Kuma ist eine schlanke und schnelle Monitoring-Anwendung, welche unter anderem als Container-Image bereitgestellt wird. Ich habe die Anwendung als Beispiel für dieses Tutorial ausgewählt, da ich die Anwendung selbst nutzen möchte und so Synergieeffekte nutzen kann.

Wer ein anderes Container-Image nutzen möchte, muss in den folgenden Beispielen louislam/uptime-kuma:latest durch den fully qualified container name des zu nutzenden Images ersetzen.

Für die Konfiguration werden die auf dem System verfügbaren Podman-Manpages benutzt.

Konfiguration des Systemd-Service mit Auto-Update-Funktion

Bei den folgenden Schritten habe ich mich am Beispiel aus podman-auto-update(1) orientiert. Ich zeige zuerst den jeweils auszuführenden Befehl in einem Code-Block, gefolgt von einer Erläuterung der genutzten Optionen.

Podman-Volume erzeugen

$ podman volume create uptime-kuma
uptime-kuma

Um Daten persistent speichern zu können, müssen diese außerhalb des Containers abgelegt werden. Der dargestellte Befehl erzeugt ein Podman-Volume mit dem Namen „uptime-kuma“.

Mit dem folgenden Befehl lassen sich detaillierte Informationen zum gerade erstellten Volume anzeigen:

$ podman volume inspect uptime-kuma
[
     {
          "Name": "uptime-kuma",
          "Driver": "local",
          "Mountpoint": "/home/tronde/.local/share/containers/storage/volumes/uptime-kuma/_data",
          "CreatedAt": "2023-08-22T20:52:06.477341481+02:00",
          "Labels": {},
          "Scope": "local",
          "Options": {},
          "MountCount": 0,
          "NeedsCopyUp": true,
          "NeedsChown": true
     }
]

Der Schlüssel Mountpoint enthält den Pfad im lokalen Dateisystem, in dem das Volume erstellt wurde.

Manpages zum Nachschlagen:

• podman-volume(1)
• podman-volume-create(1)
• podman-volume-inspect(1)

Container starten

$ podman run --label "io.containers.autoupdate=registry" -d -p 3001:3001 -v uptime-kuma:/app/data:Z --name=uptime-kuma docker.io/louislam/uptime-kuma:latest
Trying to pull docker.io/louislam/uptime-kuma:latest...
Getting image source signatures
Copying blob d7ca72974892 done  
Copying blob 475646a04a73 done  
Copying blob 1d496c24aec8 done  
Copying blob 6a3727d8681d done  
Copying blob b00c91ba9805 done  
Copying blob ddade83992f9 done  
Copying blob b8454ed537a7 done  
Copying blob 849e609eff67 done  
Copying blob f861188db6a1 done  
Copying blob 5f3c3e6d7f1c done  
Copying blob 4f4fb700ef54 skipped: already exists  
Copying blob 68b7bcf7c878 done  
Copying config fb3a3565b2 done  
Writing manifest to image destination
Storing signatures
ad7b049d9b84962311f5bafb5329f59961d8a031e54a571f079b8243ea8059ee

• podman run ist das Kommando, mit dem ein neuer Container gestartet wird
• Die Option --label "io.containers.autoupdate=registry" gibt an, dass Podman die Remote-Registry prüft, ob dort ein aktualisiertes Image vorhanden ist; dieses Label ist Voraussetzung, um die Auto-Update-Funktion nutzen zu können
• Mit der Option -d wird der Container im Hintergrund gestartet und die Container-ID auf STDOUT ausgegeben
• Durch -p 3001:3001 wird der Host-Port 3001 mit dem Port der Anwendung (ebenfalls 3001) im Container verbunden
• Die Option -v uptime-kuma:/app/data:Z hängt das im vorhergehenden Schritt erstellte Podman-Volume in das Verzeichnis /app/data innerhalb des Containers ein; :Z sorgt dafür, dass der SELinux-Kontext korrekt gesetzt wird
• --name=uptime-kuma spezifiziert den Namen des Containers; dieser ist etwas leichter zu merken als die Container-ID
• Der Befehl endet mit dem fully qualified container name docker.io/louslam/uptime-kuma:latest
• Die letzte Zeile des Code-Blocks enthält die Container-ID

Manpages zum Nachschlagen:

• podman-run(1)
• podman-auto-update(1)

Systemd-Service-Unit mit podman-generate-systemd erstellen

$ podman generate systemd --name --new uptime-kuma
# container-uptime-kuma.service
# autogenerated by Podman 4.4.1
# Tue Aug 22 21:29:46 CEST 2023

[Unit]
Description=Podman container-uptime-kuma.service
Documentation=man:podman-generate-systemd(1)
Wants=network-online.target
After=network-online.target
RequiresMountsFor=%t/containers

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
Restart=on-failure
TimeoutStopSec=70
ExecStart=/usr/bin/podman run \
	--cidfile=%t/%n.ctr-id \
	--cgroups=no-conmon \
	--rm \
	--sdnotify=conmon \
	--replace \
	--label io.containers.autoupdate=registry \
	-d \
	-p 3001:3001 \
	-v uptime-kuma:/app/data:Z \
	--name=uptime-kuma docker.io/louislam/uptime-kuma:latest
ExecStop=/usr/bin/podman stop \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
ExecStopPost=/usr/bin/podman rm \
	-f \
	--ignore -t 10 \
	--cidfile=%t/%n.ctr-id
Type=notify
NotifyAccess=all

[Install]
WantedBy=default.target

• Der Befehl gibt den Inhalt der generierten Service-Unit auf STDOUT aus
• Die Option --name verwendet den Namen des Containers anstelle der Container-ID im Dateinamen der Service-Unit (hier: container-uptime-kuma.service)
• Wichtig ist die Option --new, um Container von aktualisierten Images erstellen zu können; ohne diese Option können Systemd-Units Container nur unter Verwendung des ursprünglichen Images starten und stoppen und ein Auto-Update ist nicht möglich
• Der folgende Code-Block fügt dem Befehl die Option --files hinzu, um eine Service-Unit-Datei zu erstellen

$ podman generate systemd --name --new --files uptime-kuma
/home/tronde/container-uptime-kuma.service

Manpages zum Nachschlagen:

• podman-auto-update(1)
• podman-generate-systemd(1)

Die erstellte Systemd-Unit aktivieren und starten

$ mv -Z container-uptime-kuma.service ~/.config/systemd/user/container-uptime-kuma.service
$ systemctl --user daemon-reload

• Der erste Befehl verschiebt die Service-Unit in einen Pfad, wo systemd sie findet und einlesen kann
• Die Option -Z stellt sicher, dass die Datei den SELinux-Kontext des Zielverzeichnisses zugewiesen bekommt, andernfalls kann systemd die Datei ggf. nicht verarbeiten
• Durch den zweiten Befehl wird die Unit-Datei systemd bekannt gemacht
• An dieser Stelle ist der neue Systemd-Service geladen, jedoch inaktiv

$ systemctl --user status container-uptime-kuma.service
○ container-uptime-kuma.service - Podman container-uptime-kuma.service
     Loaded: loaded (/home/tronde/.config/systemd/user/container-uptime-kuma>
     Active: inactive (dead)
       Docs: man:podman-generate-systemd(1)
$ podman stop uptime-kumauptime-kuma
$ podman rm uptime-kumauptime-kuma
$ systemctl --user start container-uptime-kuma.service
$ systemctl --user status container-uptime-kuma.service
● container-uptime-kuma.service - Podman container-uptime-kuma.service     Loaded: loaded (/home/tronde/.config/systemd/user/container-uptime-kuma>     Active: active (running) since Tue 2023-08-22 21:59:56 CEST; 14s ago
…

• Der erste Befehl in obigen Code-Block prüft den aktuellen Status des Service
• Der zweite und dritte Befehl stoppen und entfernen den laufenden Container, den wir weiter oben gestartet haben
• Befehl Nummer 4 startet den Uptime-Kuma-Service
• Befehl Nummer 5 prüft den neuen Status des Service; dieser ist nun up-and-running

Manpages zum Nachschlagen:

• mv(1)
• systemd.unit(5)
• systemctl(1)

Auf neue Container-Images prüfen

$ podman auto-update --dry-run --format "{{.Image}} {{.Updated}}"
docker.io/louislam/uptime-kuma:latest false

• Durch die Option --dry-run wird sichergestellt, dass nur auf die Verfügbarkeit neuer Images geprüft wird, es werden jedoch keine Pull-Operationen ausgeführt und keine Container neu erstellt
• Es wird eine Liste von Container-Images ausgegeben, die mit dem Label io.containers.autoupdate=registry gestartet wurden
• Die erste Spalte enthält den Image-Namen
• Die zweite Splate zeigt an, ob ein Update verfügbar ist; in diesem Fall ist kein Update verfügbar (false)

Container (automatisch) aktualisieren

Wurde die Konfiguration erfolgreich abgeschlossen, können die entsprechenden Container durch folgenden Befehl manuell aktualisiert werden:

$ podman auto-update
            UNIT                           CONTAINER                   IMAGE                                  POLICY      UPDATED
            container-uptime-kuma.service  df21116f2573 (uptime-kuma)  docker.io/louislam/uptime-kuma:latest  registry    false

Leider ist aktuell kein Update verfügbar, weshalb es hier nichts zu tun gibt und der Status von Updated gleich false ist.

Podman bringt bei der Installation die beiden systemd units podman-auto-update.timer und podman-auto-update.service mit, welche zumindest unter RHEL 9 manuell aktiviert werden müssen:

$ systemctl --user enable podman-auto-update.{service,timer}
Created symlink /home/tronde/.config/systemd/user/default.target.wants/podman-auto-update.service → /usr/lib/systemd/user/podman-auto-update.service.
Created symlink /home/tronde/.config/systemd/user/timers.target.wants/podman-auto-update.timer → /usr/lib/systemd/user/podman-auto-update.timer.

$ systemctl --user start podman-auto-update.timer
$ systemctl --user status podman-auto-update.{service,timer}
○ podman-auto-update.service - Podman auto-update service
     Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.service; enabled; preset: disabled)
     Active: inactive (dead)
TriggeredBy: ● podman-auto-update.timer
       Docs: man:podman-auto-update(1)

● podman-auto-update.timer - Podman auto-update timer
     Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.timer; enabled; preset: disabled)
     Active: active (waiting) since Sat 2023-09-02 20:56:09 CEST; 1s ago
      Until: Sat 2023-09-02 20:56:09 CEST; 1s ago
    Trigger: Sun 2023-09-03 00:12:22 CEST; 3h 16min left
   Triggers: ● podman-auto-update.service

• Der Timer startet jeden Tag um Mitternacht den Auto-Update-Service
• Der Service prüft, ob aktualisierte Container-Images verfügbar sind und führt ggf. ein Update der Container durch
• Schlägt ein Start nach Aktualisierung des Container-Images fehl, wird der Dienst automatisch von der vorherigen Image-Version gestartet; siehe --rollback in podman-auto-update(1)
• Der folgende Code-Block zeigt den Status, nachdem ein Update durchgeführt wurde

$ systemctl --user --no-pager -l status podman-auto-update
○ podman-auto-update.service - Podman auto-update service
     Loaded: loaded (/usr/lib/systemd/user/podman-auto-update.service; enabled; preset: disabled)
     Active: inactive (dead) since Sun 2023-09-03 00:12:56 CEST; 7h ago
TriggeredBy: ● podman-auto-update.timer
       Docs: man:podman-auto-update(1)
    Process: 309875 ExecStart=/usr/bin/podman auto-update (code=exited, status=0/SUCCESS)
    Process: 310009 ExecStartPost=/usr/bin/podman image prune -f (code=exited, status=0/SUCCESS)
   Main PID: 309875 (code=exited, status=0/SUCCESS)
        CPU: 5.128s

Sep 03 00:12:50 example.com podman[309875]: Copying config sha256:d56b643e048f2d351ed536ec9a588555dfd4c70de3c8d510ed61078a499ba464
Sep 03 00:12:50 example.com podman[309875]: Writing manifest to image destination
Sep 03 00:12:50 example.com podman[309875]: Storing signatures
Sep 03 00:12:51 example.com podman[309875]: 2023-09-03 00:12:41.98296115 +0200 CEST m=+1.880671312 image pull  docker.io/louislam/uptime-kuma:latest
Sep 03 00:12:55 example.com podman[309875]:             UNIT                           CONTAINER                   IMAGE                                  POLICY      UPDATED
Sep 03 00:12:55 example.com podman[309875]:             container-uptime-kuma.service  814407c7312c (uptime-kuma)  docker.io/louislam/uptime-kuma:latest  registry    true
Sep 03 00:12:56 example.com podman[310009]: fb3a3565b2da641402e99594e09b3cdadd1b9aa84f59e7960b9961662da5ff65
Sep 03 00:12:56 example.com podman[310009]: 2023-09-03 00:12:55.421998943 +0200 CEST m=+0.020260134 image remove fb3a3565b2da641402e99594e09b3cdadd1b9aa84f59e7960b9961662da5ff65 
Sep 03 00:12:56 example.com systemd[686]: Finished Podman auto-update service.
Sep 03 00:12:56 example.com systemd[686]: podman-auto-update.service: Consumed 5.128s CPU time.

Ich hoffe, das Tutorial hat euch gefallen und konnte euch einen Eindruck vermitteln, wie man automatische Updates für Container konfigurieren kann.

Der Container-Manager LXD hatte bislang seine Heimat

Der Beitrag Container-Manager LXD gehört nicht mehr zum Linux-Containers-Projekt erschien zuerst auf LinuxCommunity.

Das auf Arch Linux basierende System BlendOS kann Softwarepakete aus anderen Distributionen installieren sowie Android-Apps ausführen. Die Programme laufen dabei ab sofort in Podman-Containern. Vereinfacht haben die Entwickler zudem die Installation von Arch-Linux-Paketen.

BlendOS kann unter anderem Fedora- und Ubuntu-Pakete einspielen. Die entsprechenden Anwendungen hatte bislang das Tool Distrobox in Containern verpackt und so voneinander isoliert. Im neuen BlendOS v2 haben die Entwickler die entsprechenden Funktionen auf Basis von Podman neu implementiert. Nach eigenen Angaben ermöglichte dies, deutlich einfacher weitere Funktionen nachzurüsten.

Die in den Containern gelandeten Programme tauchen in BlendOS v2 sofort nach ihrer Installation im Basissystem auf – wie man es vom „Überblenden“ beziehungsweise Mischen von mehreren Distributionen erwartet. Zudem kann man jetzt festlegen, welche Anwendung gegenüber identischen Kollegen aus anderen Distributionen den Vorzug erhält.

Über WayDroid kann das System von Haus aus Android Apps starten. Letztgenannte lassen sich über bekannte Stores wie Aurora oder F-Droid hinzuholen. Die Apps laufen dabei einträchtig neben den normalen Linux-Anwendungen.

Das Basissystem nutzt wahlweise Gnome 43.4 oder KDE Plasma 5.27. Die Gnome-Variante verwendet ein unmodifiziertes Gnome – mit einer Ausnahme: Der Desktop gruppiert automatisch Anwendungen, die zu verschiedenen Systemen und Kategorien gehören.

In BlendOS v2 kann man Programme direkt aus den Arch- und Chaotic-AUR-Repositories in das Basissystem hinzuholen. Dies ist beispielsweise nützlich, wenn man eine andere VPN-Software nutzen oder weitere Treiber nachinstallieren möchte.

Abschließend kann man sich auf der BlendOS-Website seinen ganz eigenen BlendOS-Remix zusammenstellen. Das ISO-Image unterstützt sowohl UEFI- als auch BIOS-Systeme. Die Nvidia-Treiber gehören zudem zum Lieferumfang.

Der Beitrag BlendOS v2 ersetzt Distrobox durch Podman erschien zuerst auf Linux-Magazin.

Immer wieder mal in den 8 Jahren LinuxNews kam die Idee auf, WordPress den Laufpass zu geben. Gescheitert ist es dann an der Migration.

Quelle

Zur KubeCon+CloudNativeCon Europe 2023 in Amsterdam hat die Cloud Native Computing Foundation (CNCF) die Version 2.8 von Harbor mitgebracht, der Open-Source-Registry für Container.

Als Projekt unter der Leitung der CNCF steht Harbor seit 2020. Ursprünglich von VMware entwickelt verspricht die Container-Registry-Implementierung Sicherheit und Skalierbarkeit.

Mit Version 2.8 von Harbor wird die Open Container Initiative Distribution Specification v1.1.0 unterstützt, die Verbesserungen für Multi-Architektur-Images und Image-Manifeste bieten soll. Die Specification v1.1.0 RC1 sei ein bedeutendes Upgrade, das es Benutzern ermögliche, OCI- und Docker-Images zu speichern und zu verteilen.

Harbor unterstütze zudem jetzt das Senden von Webhook-Payloads im CloudEvents-Format. Diese Funktionalität sei erheblich verbessert worden, um erweiterte Verwaltungs- und Debugging-Möglichkeiten bieten zu können, teilt die CNCF mit. Mit der zusätzlichen Unterstützung des CloudEvents-Formats falle die Integration mit anderen Systemen und Diensten leichter.

Das Jobservice Dashboard biete in der neuen Version Echtzeitdarstellung für den Fortschritt und den Status laufender Jobs. Das Update ermöglicht es den Benutzern, Protokolle für laufende Aufgaben anzuzeigen und abgelaufene Ausführungen automatisch zu bereinigen. Die Ankündigung von Harbor 2.8 nennt weitere Neuerungen und Änderungen.

Der Beitrag KubeCon+CloudNativeCon: Harbor 2.8 vorgestellt erschien zuerst auf Linux-Magazin.

Mirantis hat kürzlich in Zusammenarbeit mit dem Moby-Projekt die Mirantis Container Runtime (MCR) 23.0 vorgestellt. Neue Funktionen, Verbesserungen, Fehlerbehebungen und Sicherheitsupdates seien im ersten neuen Release nach zwei Jahren Entwicklungsarbeit enthalten, teilt Mirantis mit.

Moby ist unter anderem das Upstream-Open-Source-Projekt von Mirantis Container Runtime sowie von Docker und Docker Engine. Mit MCR 23.0 gleiche man die Upstream-Versionsnummern des Moby-Projekts an, teilt Mirantis weiter mit. Benutzer können dadurch zwischen der Open-Source-Community-Software Moby und der für den Unternehmenseinsatz konzipierten und entsprechend supporteten Mirantis Container Runtime wechseln, heißt es weiter.

Mirantis Container Runtime (MCR) biete eine schlanke und hochverfügbare Plattform für die Ausführung von containerisierten Anwendungen, die mit dem Moby-Projekt konsistent und mit den meisten Docker-kompatiblen Entwicklungs- und Workflow-Tools, Plattformen und Diensten kompatibel sei.

ZU den Neuerungen in Moby/MCR 23.0 zählt der bislang nur experimentelle Support für Container-Storage-Interface-Treiber (CSI) in Swarm, was die Verwaltung von Speicherressourcen über Container-Orchestrierungsplattformen hinweg erleichtern soll. Die CSI-Treiber seien identisch mit denen, die auch Kubernetes verwende. Entwickler könnten dadurch dieselben Speicher-Plugins nutzen.

MCR 23.0 biete Unterstützung für Oracle Linux 8, RHEL 9 und Windows Server 2022.

Der Beitrag Mirantis Container Runtime 23.0 veröffentlicht erschien zuerst auf Linux-Magazin.

Mit der Veröffentlichung von Kubernetes 1.26 mit dem Codenamen Electrifying wird das Container Runtime Interface (CRI) in der stabilen Version 1 zum alleinigen Standard.

Begonnen hat die Umstellung auf das CRI mit der Einführung in Version 1.24 und der damit einhergehenden Abschaffung von dockershim. CRI sei damit die einzige unterstützte und dokumentierte Methode, über die Kubernetes mit verschiedenen Container-Runtimes interagiere, teilt das Projekt mit.

In Version 1.26 geht diese Umstellung noch einen Schritt weiter, indem die Unterstützung für CRI v1alpha2 nun entfällt. Das führe nun definitiv dazu, dass das Kubelet den Knoten nicht registriert, wenn die Container-Laufzeitumgebung CRI v1 nicht unterstütze, heißt es weiter. Das bedeutet etwa, dass containerd in Version 1.5 und älter in Kubernetes 1.26 nicht unterstützt werde. Wer etwa containerd verwende, müssen auf Version 1.6.0 oder höher umstellen, bevor eine Aktualisierung des Knoten auf Kubernetes v1.26 erfolge. Dies gelte auch für alle anderen Container-Laufzeiten, die nur v1alpha2 unterstützen.

Eine weitere Umstellung betrifft die Container-Image-Registry. Version 1.26 von Kubernetes sei die erste Veröffentlichung, die ausschließlich in der neuen registry.k8s.io veröffentlicht werde. In der nun veralteten k8s.gcr.io-Image-Registry werden keine Container-Images-Tags für v1.26 veröffentlicht, heißt es in der Ankündigung. Nur Images von Versionen vor Kubernetes v1.26 werden weiterhin in k8s.gcr.io  aktualisiert, heißt es weiter.

Der Beitrag Kubernetes 1.26 wechselt auf CRI 1 erschien zuerst auf Linux-Magazin.

Die neue Version 4.4 von OpenShift basiert auf Kubernetes 1.17. Red Hat veröffentlicht auch eine Technology Preview von OpenShift Virtualization auf Grundlage von KubeVirt. Die Verwaltung Cloud-nativer Anwendungen vereinfacht Advanced Cluster Management for Kubernetes.