Incus 6.2 übernimmt weitere Änderungsvorschläge von Studenten
Als Fork des Container-Managers LXD entstanden, entfernt sich die Version 6.2 von Incus weiter von seinem Vorbild.
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.
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:
systemd
-Service mit Auto-Update-FunktionWer 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.
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.
Darüber hinaus solltet ihr Manpages lesen können.
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.
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 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 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--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-d
wird der Container im Hintergrund gestartet und die Container-ID auf STDOUT ausgegeben-p 3001:3001
wird der Host-Port 3001 mit dem Port der Anwendung (ebenfalls 3001) im Container verbunden-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-IDdocker.io/louslam/uptime-kuma:latest
Manpages zum Nachschlagen:
$ 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
--name
verwendet den Namen des Containers anstelle der Container-ID im Dateinamen der Service-Unit (hier: container-uptime-kuma.service)--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--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:
$ mv -Z container-uptime-kuma.service ~/.config/systemd/user/container-uptime-kuma.service
$ systemctl --user daemon-reload
systemd
sie findet und einlesen kann-Z
stellt sicher, dass die Datei den SELinux-Kontext des Zielverzeichnisses zugewiesen bekommt, andernfalls kann systemd
die Datei ggf. nicht verarbeitensystemd
bekannt gemacht$ 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
…
Manpages zum Nachschlagen:
$ podman auto-update --dry-run --format "{{.Image}} {{.Updated}}"
docker.io/louislam/uptime-kuma:latest false
--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 erstelltio.containers.autoupdate=registry
gestartet wurdenfalse
)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
--rollback
in podman-auto-update(1)$ 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.
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 Android-App Nestbox bietet Linux-Container in einer VM und bedient sich dabei des neuen Virtualization Framework von Android 13.
Podman ist Red Hats Antwort auf Docker. Gerade erschien Podman 4.2.0 mit einem umfangreichen Changelog, das die anhaltende Intensität der Entwicklung belegt.
Fedora Core OS hofft, mit Fedora 37 neben den bestehenden Angeboten für Workstation, Server und IoT als offizielle Edition aufgenommen zu werden.
Zwei Jahre sind seit der Veröffentlichung von LXC 4.0 vergangen. In dieser Zeit haben die Entwickler von Linux Containers (LXC) verschiedene Neuerungen in LXC 5.0 LTS aufgenommen.
Mit der neuen Version werde “autotools” durch “meson” als Build-Tool ersetzt, heißt es in der Ankündigung. Diese Änderung sei besonders für Paketierer relevant und habe ansonsten keine für den Benutzer sichtbaren Auswirkung.
LXC unterstütze zudem das Einrichten eine Time-Namespaces. Dies werde durch zwei neue Optionen begleitet: “lxc.time.offset.boot” und “lxc.time.offset.monotonic”. Damit werde ein Offset (von einigen Nanosekunden bis hin zu Stunden) auf die Hauptuhr des Systems angewendet, heißt es weiter. Die Ankündigung nennt weitere Änderungen.
LXC 5.0 erhält nun Support bis Juni 2027. Das aktuelle LTS-Release LXC 4.0 wechsle zu einem langsameren Wartungstempo nur erhalte noch kritische Bugfixes und Sicherheitsupdates.
Der Beitrag LXC 5.0 LTS: Linux Containers mit Langzeitsupport erschien zuerst auf Linux-Magazin.
Das Container-Format LXC 5.0 LTS kommt demnächst mit fünf Jahren Unterstützung sowie neuen Control Groups und Namespaces in die Distributionen.
Herzlich willkommen zu Teil 6 meiner Reihe Nextcloud im Container. Dieser Teil behandelt das Thema Updates. Zum Verständnis empfehle ich, zuerst Teil 1 und Teil 2 zu lesen.
Nun wünsche ich euch viel Spaß beim Lesen und gute Unterhaltung.
Meine Nextcloud-Instanz läuft in einem Podman-Pod. Das sieht im Terminal wie folgt aus:
$ podman pod ps
POD ID NAME STATUS CREATED INFRA ID # OF CONTAINERS
e84bec6108d1 nc_pod Running 2 months ago 5e52555c5060 3
Dieser Pod besteht aus den folgenden drei Container-Instanzen:
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5e52555c5060 k8s.gcr.io/pause:3.2 2 months ago Up 7 days ago 127.0.0.1:40671->80/tcp e84bec6108d1-infra
c6571aa338ce docker.io/library/mariadb:10.5.7 mysqld 2 months ago Up 7 days ago 127.0.0.1:40671->80/tcp nc_mariadb
21739d36eef1 docker.io/library/nextcloud:23-apache apache2-foregroun... 2 months ago Up 7 days ago 127.0.0.1:40671->80/tcp nextcloud
Diese Container-Instanzen sind zustandslos und ephemeral (engl. für kurzlebig, vergänglich oder flüchtig). Persistent zu speichernde Daten werden außerhalb der Container-Instanzen gespeichert. Diese Eigenschaften erlauben es, Container einfach entfernen und durch neue Instanzen ersetzen zu können.
Um die Nextcloud zu aktualisieren, wird in dieser Umgebung also nicht die Anwendung innerhalb des Containers aktualisiert. Stattdessen werden die Container-Instanzen entfernt und Container-Images mit aktuelleren Versionen der Anwendung und Datenbank instanziiert.
Die aktuell laufenden Versionen von Nextcloud und MariaDB sind obigen Codeblock zu entnehmen. Diese Images wurden durch die beiden folgenden Zeilen in der Datei {role_path}/defaults/main.yml
definiert:
MARIADB_IMAGE: docker.io/library/mariadb:10.5.7
NC_IMAGE: docker.io/library/nextcloud:23-apache
Hier kann man nun die gewünschten Versionen der zu verwendenden Container-Images eintragen. Alternativ kann man die Default-Werte auch durch entsprechende Einträge in {role_path}/vars/main.yml
überschreiben. Die Einträge sehen dann bspw. wie folgt aus:
MARIADB_IMAGE: docker.io/library/mariadb:10.5.9
NC_IMAGE: docker.io/library/nextcloud:23.0.3-apache
Nun kann das Playbook mit der Ansible-Rolle aus Teil 2 dieser Reihe erneut ausgeführt werden:
$ ansible-playbook -i hosts deploy_nextcloud.yml --ask-vault-pass
Vault password:
PLAY [localhost] **************************************************************************************************
TASK [Gathering Facts] *******************************************************************************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Main folder, needed for updating] *************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for installed/modified apps] ***********************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for local configuration] ***************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the actual data of Nextcloud] ******************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Volume for the MySQL data files] **************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create the podman-pod(1)] *********************************
changed: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create MariaDB container] *********************************
changed: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Wait for DB to initilize] *********************************
ok: [localhost]
TASK [ansible_role_deploy_nextcloud_with_mariadb_pod : Create Nextcloud container] *******************************
changed: [localhost]
PLAY RECAP *******************************************************************************************************
localhost : ok=10 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Nun kann man sich auf dem Zielsystem davon überzeugen, dass die neuen Container-Images zur Instanziierung verwendet wurden:
$ podman ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
5e52555c5060 k8s.gcr.io/pause:3.2 2 months ago Up 7 days ago 127.0.0.1:40671->80/tcp e84bec6108d1-infra
248f87e1135b docker.io/library/mariadb:10.5.9 mysqld 35 seconds ago Up 36 seconds ago 127.0.0.1:40671->80/tcp nc_mariadb
59ac1aad168c docker.io/library/nextcloud:23.0.3-apache apache2-foregroun... 10 seconds ago Up 11 seconds ago 127.0.0.1:40671->80/tcp nextcloud
Fertig. Schon kann Nextcloud in Version 23.0.3 mit einer MariaDB 10.5.9 genutzt werden.
Mit diesem Artikel habe ich das letzte noch offene Ziel Nr. 5 „Konfiguration und Test automatischer durch Ansible gesteuerter Updates“ erreicht. Der Update-Prozess folgte dem Container-Paradigma, die Container komplett zu ersetzen und nicht die Anwendung innerhalb der Container zu aktualisieren.
Es handelte sich im dokumentierten Fall um Updates auf ein neues Patch-Release, bei denen das Risiko für Fehler ohnehin sehr gering ist. Ob das Update auch bei Minor- bzw. Major-Releases so gut funktioniert, muss sich noch zeigen. Ich werde diesen Artikel aktualisieren, wenn es Erkenntnisse dazu gibt.
Mit diesem Artikel endet meine Reihe „Nextcloud im Container“. Ich hoffe, ich habe euch damit ein wenig unterhalten und konnte euer Wissen durch die ein oder andere Information erweitern.
Herzlich Willkommen zu Teil 4 meines Wochenend-Projekts „Nextcloud im Container“. Diesem gingen die folgenden Teile voraus:
Nach Teil 3 habe ich die Zwei-Faktor-Authentisierung über TOTP für meine Nutzerkonten aktiviert, die Bookmark-, Calendar- und Contact-App installiert bzw. aktiviert, ein paar Kalendertermine erstellt und ein paar Dateien hochgeladen. Nichts Wichtiges. Lediglich ein paar Daten, die ich nach einem Backup zerstören kann, um anschließend den Restore-Prozess zu testen. Zuvor möchte ich aber noch ein paar Dinge festhalten, die mir bisher aufgefallen sind.
In den Grundeinstellungen der Nextcloud werden Hintergrund-Aufgaben konfiguriert. Diese sind laut des dortigen Hinweises wichtig, um die optimale Geschwindigkeit zu erreichen:
Um die optimale Geschwindigkeit zu erreichen ist es wichtig, dass die Hintergrund-Aktivitäten richtig konfiguriert sind. Für größere Installationen ist ‚Cron‘ die empfohlene Einstellung. Weitere Informationen findest Du in der Dokumentation.
Grundeinstellungen in den Nextcloud-Einstellungen
Die Überschrift ist der Titel des GitHub-Issues #1695. Dieser beschäftigt sich damit, dass Cron in der Container-Instanz nicht läuft. Halt genau so, wie Cron dies bei mir auch nicht tut.
Der Benutzer beryl03, welcher den Issue eröffnet hat, beschreibt, dass Cron in der Container-Instanz nicht verfügbar ist und er in der Dokumentation keinen Hinweis darauf gefunden hat. Um das Problem zu mitigieren hat beryl03 einen Cronjob auf seinem Container-Host konfiguriert, welcher sich mit der Container-Instanz verbindet und darin die Datei cron.php
ausführt. Welch elender Workaround. Aber immerhin gibt es einen. Denn die Hintergrund-Aufgaben mit AJAX auszuführen, scheitert leider ebenfalls. Schade, so habe ich mir das tatsächlich nicht vorgestellt.
Im Verlauf von Issue #1695 wird darauf hingewiesen, dass zur Verwendung von Cron ein weiterer Container benötigt wird (siehe [3]). Dies wird in den Beispielen zu den Compose-Dateien beschrieben (siehe [4]). Da ich Podman und Ansible statt Docker-Compose verwende, habe ich mir diese Beispiele natürlich nicht angesehen. Das ist dem Projekt nicht anzulasten, da ich mich ja bewusst für einen anderen Weg entschieden habe. Doch denke ich, dass man das Thema Hintergrund-Aufgaben innerhalb der Projekt-Dokumentation als auch in der Nextcloud-Dokumentation etwas ausführlicher behandeln könnte und sollte. Doch wie gehe ich nun mit dem Problem um, dass meine Hintergrund-Aufgaben nicht ausgeführt werden?
Tatsächlich habe ich einen Artikel gefunden, welcher beschreibt, wie man Docker-Compose ab Podman 3.0 nutzen kann. Allerdings bietet dieser nur eine Lösung für den Fall, dass man Podman als User root bzw. mit Root-Rechten ausführt. Da Podman bei mir rootless läuft, kommt die Lösung für mich nicht in Frage.
Nach etwas weiterer Recherche habe ich einen RFE gefunden, welcher diese Funktionalität auch für rootless-Podman fordert. Die gute Nachricht lautet, dass diese Funktion mit Podman 3.2 veröffentlicht wurde. Pech für mich, dass unter Debian stable lediglich Podman 3.0.1 in den Quellen verfügbar ist.
Tatsächlich erscheint mir aktuell der Workaround von beryl03 (siehe [1]) der beste Weg zu sein, um die Hintergrund-Aufgaben ausführen zu lassen. Dazu führe ich auf meinem Container-Host folgenden Befehl aus:
$ podman exec -u 33 -t nextcloud php -f /var/www/html/cron.php
Damit wird das Skript cron.php
innerhalb der Container-Instanz mit der Nextcloud ausgeführt. Mit -u 33
wird die UID von www-data
innerhalb der Container-Instanz angegeben. Für eine genaue Erklärung des Befehls und seiner Optionen siehe podman-exec(1).
Da ich nicht gern lange Befehle in die Crontab schreibe, erstelle ich ein kurzes Skript namens nextcloud_cron.sh
, welches obigen Befehl aufnimmt und welches ich alle 5 Minuten von Cron ausführen lasse. Damit werde ich sich noch sehr lange arbeiten, denn nicht umsonst sagen manche: „Nichts hält so lange, wie ein gutes Improvisorium.“
Ich hoffe, die Artikelserie hat euch bis hierhin ein wenig unterhalten. Wer nach einer einfachen Lösung gesucht hat, bei der man ein bis zwei Container-Images aus dem Regal nimmt, ein paar Variablen mit Werten füllt, sie auf einen Container-Host provisioniert, ausführt und fertig ist, wird sicher gemerkt haben, dass er diese Lösung in dieser Artikelreihe nicht findet.
Auch ich habe mir zu Beginn nicht vorgestellt, dass es so hakelig werden würde. Schließlich soll mit Containern doch alles einfacher werden, nicht wahr? Warum mache ich also weiter und lasse das ganze Wochenend-Projekt nicht einfach fallen? Neugier, Sturheit, eine nutzbare Nextcloud-Instanz und auch ein bisschen Spaß bilden die Antwort auf vorstehende Frage. Und deshalb mache ich auch weiter. In Teil 5 wird es um Backup und Restore gehen.
Wie betreibt ihr eure Nextcloud? Mit Container oder ohne? Unter Docker, K3s, K8s, Podman, OpenShift oder einer noch ganz anderen Lösung? Lasst es mich gern in den Kommentaren wissen. Habt ihr über eure Erfahrungen in eurem eigenen Blog geschrieben, lasst mir gern einen Link hier. Macht es gut, bis nächste Woche.