{"id":15774,"date":"2025-10-24T11:40:24","date_gmt":"2025-10-24T09:40:24","guid":{"rendered":"https:\/\/www.cloudandheat.com\/?p=15774"},"modified":"2025-10-27T10:57:25","modified_gmt":"2025-10-27T09:57:25","slug":"use-of-open-container-initiative-oci-container-images-as-linux-container-lxc-in-proxmox-ve","status":"publish","type":"post","link":"https:\/\/www.cloudandheat.com\/en\/nutzung-von-open-container-initiative-oci-container-images-als-linux-containern-lxc-in-proxmox-ve\/","title":{"rendered":"Use of Open Container Initiative (OCI) container images as Linux Containers (LXC) in Proxmox VE"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In diesem Blogpost wird gezeigt, wie sich OCI<\/a>-konforme Container-Images direkt als LXC-Container<\/a> in Proxmox Virtual Environment (Proxmox VE) verwenden lassen. Es wird dabei insbesondere auf die Portierung der Container und den dauerhaften Betrieb via Systemd eingegangen.<\/p>

Um die Unterschiede zwischen OCI-Containern und LXC-Containern zu verstehen, lohnt sich ein kleiner Exkurs auf die zugrunde liegenden Virtualisierungskonzepte und ihre jeweiligen St\u00e4rken.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Warum nutzen wir Virtualisierung?\n<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Virtualisierung erm\u00f6glicht eine bessere Verteilung von Ressourcen<\/strong> und\u00a0 eine Effizienzsteigerung im Betrieb von Cloud-Infrastrukturen. Dar\u00fcber hinaus tr\u00e4gt sie zur Stabilisierung und Beschleunigung<\/strong> von Deployment-Prozessen bei, da sich Testumgebungen schneller und einfacher in ihren Ursprungszustand zur\u00fcckversetzen lassen. Insbesondere profitiert die Softwareentwicklung (ebenso wie die Governance) davon, weil Abh\u00e4ngigkeiten der eingesetzten Software besser bestimmt und passgenau bereitgestellt werden k\u00f6nnen.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Welche Arten der Virtualisierung gibt es?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Es gibt verschiedene Arten der Virtualisierung, die jeweils auf unterschiedliche Einsatzszenarien zugeschnitten sind. Betriebssystemvirtualisierung<\/strong> wird h\u00e4ufig genutzt, um Legacy-Anwendungen, die sehr spezifische Anforderungen an das Betriebssystem stellen, weiterhin sicher betreiben zu k\u00f6nnen. Durch die Abstraktion vom zugrunde liegenden physischen System k\u00f6nnen solche Anwendungen auch auf moderner Hardware lauff\u00e4hig gemacht werden. Weiterhin tr\u00e4gt diese Virtualisierungsart dazu bei, die Hardwareregeneration sicherzustellen. Technisch umgesetzt wird dies typischerweise mit (Kernel-basierten) virtuellen Maschinen (KVMs) oder falls es sich um Linux basierte Applikationen handelt mit LXC-Containern.<\/p>

Bei der Anwendungsvirtualisierung<\/strong> liegt der Fokus auf der Isolation einzelner Anwendungen samt ihrer Laufzeitumgebung. Dies hat den Vorteil, dass weniger Systemressourcen ben\u00f6tigt werden, da lediglich die f\u00fcr die Anwendung erforderlichen Softwarekomponenten \u2013 in Form des Root-Filesystems (rootfs) \u2013 als Paket geb\u00fcndelt werden. Diese geb\u00fcndelte Einheit wird dann als geschlossene Anwendung ausgef\u00fchrt. Typische Vertreter dieser Virtualisierungsform sind OCI-konforme Container-Images, die mit Tools wie Docker, Podman oder systemd-nspawn\u00a0 gestartet werden k\u00f6nnen, ebenso aber auch ein klassisches chroot.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Virtualisierungsansatz mit Proxmox VE<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Der Ansatz von Proxmox VE setzt prim\u00e4r auf Betriebssystemvirtualisierung<\/strong> und nutzt Anwendungsvirtualisierung \u00fcblicherweise erst innerhalb der Gastsysteme<\/strong>. Aus meiner Sicht ist dies grunds\u00e4tzlich sinnvoll: Es erm\u00f6glicht die klare Kapselung von Zust\u00e4ndigkeiten – zwischen dem System, das die eigentlichen Hardwareressourcen verwaltet, und den Gastsystemen, die Laufzeitumgebungen bereitstellen (insbesondere eigenst\u00e4ndige Kernel mit dedizierten IP-Stacks). Diese Trennung von Zust\u00e4ndigkeiten und Abh\u00e4ngigkeiten sorgt nicht nur f\u00fcr Stabilit\u00e4t, sondern erleichtert auch die Wartung und Updates des Systems. Damit wird die Grundlage f\u00fcr einen langfristig stabilen und sicheren Betrieb gelegt. Durch die Kapselung wird auch der Hypervisor gesch\u00fctzt, was zus\u00e4tzlich die Stabilit\u00e4t der parallel ausgef\u00fchrten Workloads erh\u00f6ht. Ein weiterer Vorteil ist auch, dass die Transferleistung f\u00fcr den Betrieb der einzelnen Workloads in den VMs niedriger ist, da Betriebssystemvirtualisierung bekannte Konzepte aus dem Betrieb physikalischer Maschinen \u00fcbertr\u00e4gt.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Vorteile der Virtualisierung und warum sie direkt auf dem Hypervisor eingesetzt wird<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Ein anschauliches Beispiel<\/strong> f\u00fcr die Bedeutung der Trennung von Applikationen und der darunterliegenden Hardwareressourcenverwaltung stammt aus meiner Zeit bei einem fr\u00fcheren Arbeitgeber, der \u00fcber 300 Linux-Server im Einsatz hatte. Dort wurde eine Jira-Applikation betrieben, die von bestimmten Java-Runtime-Versionen abh\u00e4ngig war. Offizieller Support war damals – noch vor meiner Zeit – nur f\u00fcr eine \u201eEnterprise“-Linux-Distribution vorhanden. Als Red Hat-affines Unternehmen entschied man sich f\u00fcr RHEL 5. Die Situation wurde kompliziert, als Jira aus lizenzrechtlichen Gr\u00fcnden nicht mehr updatef\u00e4hig war. Um die Kompatibilit\u00e4t zur mitgelieferten Java-Runtime zu gew\u00e4hrleisten, wurde die gesamte Betriebssystemversion auf RHEL 5 \u201eeingefroren\u201c (sehr zur Freude der IT-Security, denn damit lief nach 10 Jahren auch die Versorgung mit Security Patches aus). Weder die Anwendungsbetreiber noch das zust\u00e4ndige Linux-\/Unix-Betriebsteam hatten ausreichend Ressourcen, um diese Altlast dauerhaft zu pflegen. \u00c4hnliche Probleme traten auch \u00f6fter bei Anwendungen auf, die auf veraltete Python- oder PHP-Versionen angewiesen waren.<\/p>

Diese Anekdote verdeutlicht, wie wichtig die Anwendungsvirtualisierung ist<\/strong>. In gr\u00f6\u00dferen Cloud-Umgebungen bieten sich hierf\u00fcr L\u00f6sungen wie Tarook<\/a>\u00a0, ein Open-Source Lifecycle Management Tool f\u00fcr Kubernetes, an. In kleineren Setups hingegen sind Werkzeuge wie Docker oder Podman, betrieben innerhalb von Virtuellen Machines, alternative L\u00f6sungen. Auch dieser Ansatz profitiert dabei von den Hochverf\u00fcgbarkeitsmechanismen der Proxmox VE L\u00f6sung.<\/p>

Ein zentraler Vorteil der Anwendungsvirtualisierung, insbesondere durch den Einsatz von OCI-Images<\/strong>, liegt in der Standardisierung. Diese Standardisierung und der Erfolg von Docker sowie vergleichbaren L\u00f6sungen haben ein breit gef\u00e4chertes \u00d6kosystem hervorgebracht, welches es erm\u00f6glicht, getestete Anwendungen schnell und einfach \u00fcber Container-Registries zu verteilen.<\/p>

Als Unternehmen, das Kubernetes mit OCI-basierte Images f\u00fcr die Bereitstellung der eigenen OpenStack-Deployments bereits verwendet, bietet es sich f\u00fcr Cloud&Heat an, L\u00f6sungen, die auf diese Weise bereits bereitgestellt werden, auch f\u00fcr die Konfiguration von Proxmox-VE-Deployments zu verwenden. Obwohl die Proxmox VE Umgebungen selbst keine direkte Abh\u00e4ngigkeit zu OCI-Images haben, werden diese intern verwendet, um vorhandene L\u00f6sungen (z.B. f\u00fcr das Usermanagement) zu portieren. Praktischerweise bieten die von Proxmox VE mitgelieferten LXC-Services hierf\u00fcr ein Kompatibilit\u00e4tslayer an.<\/strong><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t

\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Implementierung von OCI-Images als LXC-Containern in Proxmox VE<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t
Technische Voraussetzungen<\/strong><\/h5>

Um OCI-Images aus Registries beziehen zu k\u00f6nnen, ist unter Proxmox VE die Installation der Pakete skopeo und umoci notwendig:<\/p>

apt install skopeo umoci<\/pre>
Nach der Installation finden sich auf dem System einige typische Konfigurationsdateien, wie man sie in \u00e4hnlicher Form bereits von Docker- oder Podman-Installationen kennt. Ein Beispiel daf\u00fcr ist die Datei \/var\/lib\/containers\/cache\/blob-info-cache-v1.boltdb<\/em>. Diese Datei wird verwendet, um die OCI-Layer zu tracken.<\/p>
Weiterhin finden sich Konfigurationen zu sogenannten „Well-Known“ Images und Registries unter:<\/p>
root@pve:~# tree \/etc\/containers\/\n\/etc\/containers\/\n\u251c\u2500\u2500 policy.json\n\u251c\u2500\u2500 registries.conf\n\u2514\u2500\u2500 registries.conf.d\n\u2514\u2500\u2500 shortnames.conf<\/pre>
Und schlie\u00dflich besteht auch die M\u00f6glichkeit, Credentials f\u00fcr protected Registries zu hinterlegen unter:<\/p>
root@pve:~# cat ~\/.docker\/config.json\n{\"auths\":\n{\u00a0 \"<registry url e.g. gittlab-registry.cloudandheat.com>\":\n{ \"auth\": \"<token_name + token_value | b64encoded>\" } }\n}<\/pre>
\u00a0<\/strong><\/p>
Konfiguration der Container<\/strong><\/h5>
Nach der Konfiguration der Containerquellen ist es nun m\u00f6glich, \u00fcber die LXC cli tools entsprechende Container zu erstellen. Die LXC-Container, die via der Proxmox VE WebUI bzw. dem pct cli tool erstellt werden, werden ebenfalls als LXC-Container unter \/var\/lib\/lxc\/<\/em> erstellt. Sie werden durch die Proxmox VE- eigenen Verwaltungstools so konfiguriert, dass die LXC-Services sie starten und verwalten k\u00f6nnen.<\/p>
Dieses Vorgehen ist auch f\u00fcr die Konfiguration der LXC-Container aus OCI-Images notwendig, wenn man nicht den Komfort der PVE-Tools nutzt. Container, die \u00fcber die PVE-Tools erstellt werden, werden im \u00dcbrigen unter \/var\/lib\/lxc\/<id><\/em> erstellt. Dies sollte man bei der Erstellung weiterer manueller LXC-Container beachten.<\/p>
Ein weiterer wichtiger Punkt: Die PVE Tools ignorieren die Standardwerte, die f\u00fcr neu erstellte LXC-Container aus der Datei \/etc\/lxc\/default.conf<\/em> \u00fcbernommen werden. Das bedeutet, dass globale Anpassungen f\u00fcr Default-Werte hier durchaus gesetzt werden k\u00f6nnten, ohne mit den Proxmox-Containern zu kollidieren.<\/p>
Wenn wir nun einen neuen LXC-Container mit der Option –template=oci<\/em> erstellen, z.B.:<\/p>
root@pve:~# lxc-create --name bash --template=oci -- --url docker:\/\/bash:devel-alpine3.22\nCopying blob ed9f46a56c4c skipped: already exists\nCopying blob 9824c27679d3 skipped: already exists\nCopying blob 1926526997ec skipped: already exists\nCopying blob 429cd906597a skipped: already exists\nCopying config 376e768ec4 done\nWriting manifest to image destination\nStoring signatures\nmfpath=\/var\/lib\/lxc\/bash\/oci\/blobs\/sha256\/8c4dd3f704a443e34a1aa9952b304de5148c54388ff6aed80d0a2b06db1da65d conf=\/var\/lib\/lxc\/bash\/oci\/blobs\/sha256\/376e768ec4e15b92ee8ddb2ea388c2418902684b24eb8ef58421ba85478ab296\nmediatype=application\/vnd.oci.image.layer.v1.tar+gzip\nUnpacking tar rootfs<\/pre>
wird die entsprechende Container-Konfiguration unter \/var\/lib\/lxc\/<container_name><\/em> erzeugt:<\/p>
root@pve:~# ls \/var\/lib\/lxc\/bash\nconfig\u00a0 oci\u00a0 rootfs<\/pre>
Beim Erstellen sollte man sich von der URL-Option nicht verunsichern lassen: \u201edocker:\/\/<\/em>\u201c spezifiziert hierbei das verwendete Protokoll, um die Registry zu erreichen. Danach kann jede URL verwendet werden, die sich gem\u00e4\u00df der Konfiguration unter \/etc\/containers\/registries.conf*<\/em> aufl\u00f6sen l\u00e4sst. Hierf\u00fcr wird skopeo verwendet, das auch weiterf\u00fchrende Informationen auf den Manpages bereitstellt.<\/p>
Nach erfolgreicher Erstellung eines Containers findet sich im Pfad \/var\/lib\/lxc\/<container_name><\/em> folgende Struktur:<\/p>