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
- Buildah.io
- Ansible Collection tronde.nextcloud
- Mein Wochenendprojekt Nextcloud im Container
- Podman Images im Red Hat Catalog
- Buildah and Podman Relationship von Tom Sweeney
- About Ansible Molecule
- How to use Podman inside of a container by Dan Walsh
- Using podman containers
- Having trouble getting started with rootless podman running rootless podman inside a Debian 12 image #23838
- Recommendations for tagging and versioning container images
Anmelden
Mit Version 1.33 bringt Kubernetes ein umfangreiches Funktionspaket. Die neue Version trägt den Codenamen „Octarine“ – eine Anspielung auf die unsichtbare Zauberfarbe aus Terry Pratchetts Scheibenwelt. Insgesamt umfasst das Update 64 Änderungen, darunter 18 stabile Features. Besonders hervorzuheben ist die Stabilisierung des Sidecar-Patterns. Damit lassen sich Zusatzcontainer für Logging, Netzwerk oder Monitoring fest in den […]
Microsoft hat die Bereitstellung von Skype für Linux umgestellt: Künftig gibt es die Anwendung nur noch im Snap-Format. Nutzer, die den Messenger bisher über .deb- oder .rpm-Pakete installiert haben, müssen umsteigen, denn diese Repositories wurden geschlossen und gelten nun als veraltet. Die Entscheidung folgt einer bereits vor über einem Jahr angekündigten Strategie. Während Microsoft einige […]
Das beliebte Linux-Framework Flatpak wurde auf Version 1.16 aktualisiert. Dieses große Update bringt neue Funktionen und Verbesserungen mit. Zweieinhalb Jahre nach Version 1.14 bietet Flatpak 1.16: Neu ist auch die Zulassung des modify_ldt-Systemaufrufs mit –allow=multiarch.Dies wird benötigt, um 16-Bit-Programme mit Wine auszuführen. Ein HTTP-Backend-Variable in flatpak.pc wurde hinzugefügt. Das erleichtert Projekten wie GNOME Software die […]
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 […]
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...