Normale Ansicht

Es gibt neue verfügbare Artikel. Klicken Sie, um die Seite zu aktualisieren.
Gestern — 27. März 2024Haupt-Feeds
Ältere BeiträgeHaupt-Feeds

Ubuntu 24.04 treibt die Debian Paket zu Snap Transformation voran

Von: MK
08. Februar 2024 um 07:44

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.

Ubuntu 24.04 treibt die Debian Paket zu Snap Transformation voran

Von: MK
08. Februar 2024 um 07:44

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.

Suse bringt Rancher Prime 2.0

07. November 2023 um 09:00

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.

Container mit podman-auto-update automatisch aktualisieren

28. August 2023 um 05:00

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.

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

Umgebung und verwendetes Container-Image

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.

BlendOS v2 ersetzt Distrobox durch Podman

26. April 2023 um 07:29

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.

KubeCon+CloudNativeCon: Harbor 2.8 vorgestellt

18. April 2023 um 10:35

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 Container Runtime 23.0 veröffentlicht

15. März 2023 um 09:42

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.

Kubernetes 1.26 wechselt auf CRI 1

13. Dezember 2022 um 10:03

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.

LXC 5.0 LTS: Linux Containers mit Langzeitsupport

24. Juni 2022 um 09:39

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.

OpenSuse Leap Micro 5.2: Leichtgewicht für Container

19. Mai 2022 um 10:14

Mit Opensuse Leap Micro bringt die Community ein Pendant zu Suse Linux Enterprise Micro heraus. Die Leap Micro-Ausgabe ist für Workloads in containerisierten und virtualisierten Umgebungen gebaut.

Angeboten wird Opensuse Leap Micro auch als Offline-Image mit Installer. Die Raw- und Selbstinstallation ermögliche eine Anpassung durch Combustion oder manuell im Image, nachdem es auf die Festplatte geschrieben wurde. Combustion ist ein minimales Modul für dracut, das ein vom Benutzer bereitgestelltes Skript beim ersten Start eines Systems ausführt. Es gibt Leap Micro auch eine Option für einen Echtzeit-Kernel.

Aus Sicherheitsgründen sei kein Root-Passwort gesetzt, Nutzer müssten, sofern sie nicht die Offline-Installation verwenden, Ignition oder Combustion verwenden, um es einzurichten, heißt es in der Ankündigung.

Die neue Distribution lässt sich in VMs testen, die entweder auf Xen oder KVM laufen, teilt Opensuse mit. In Verbindung mit Raspberry Pi oder anderer System-on-Chip-Hardware lasse sich das vorkonfigurierte Image zusammen mit der Combustion-Funktionalität für den Boot-Prozess verwenden. Sowohl die vorkonfigurierten als auch die selbst installierten Images seien für die Verwendung mit Combustion vorbereitet, das sich auf einen USB-Stick schreiben lässt, um die gewünschte Konfiguration bei jedem ersten Start zu ermöglichen. Das Projekt stellt auf Youtube eine Installations-Demo mit Combustion bereit. Die Release Notes verlinken die Dokumentation..

Der Beitrag OpenSuse Leap Micro 5.2: Leichtgewicht für Container erschien zuerst auf Linux-Magazin.

Docker Desktop für Linux erschienen

11. Mai 2022 um 10:42

Nach Windows und MacOS gibt es den Docker Desktop nun auch für Linux-Systeme. Der Docker Desktop soll eine einfach zu installierende Anwendung darstellen, mit der sich containerisierte Anwendungen und Microservices erstellen und gemeinsam nutzen lassen.

Wie Dockers Produktmanager Chris McLellan weiter mitteilt, wird der Docker Desktop zusammen mit Container-Tools wie Kubernetes, Docker Compose, BuildKit und Schwachstellen-Scanning geliefert. Für die Entwicklung des Docker Desktops für Linux habe man sich entschieden, um Benutzern der verschiedenen Betriebssysteme eine einheitliche Oberfläche zu liefern. Auch der unmittelbare Zugang zu neuen Funktionen, etwa den Docker Extensions, die bisher nur auf dem Desktop für Windows und Mac verfügbar waren, seien ein Grund gewesen, so McLellan.

Docker Desktop für Linux auf Ubuntu. Quelle: Docker

Entwickler, die mit der Docker Engine unter Linux zufrieden seien, könnten die natürlich auch weiterhin nutzen, schreibt der Produktmanager. Der Desktop für Linux stelle lediglich sicher, dass Linux-Entwickler alle neuen Funktionen nutzen können, die in Docker Desktop integriert sind, ohne Kompromisse bei ihren bestehenden CLI-basierten Arbeitsabläufen eingehen zu müssen.

Um mit dem Desktop für Linux zu starten sei ein Blick in die Docker-Docs angeraten, um Informationen für die gewählte Distribution zu finden. Zum Start seien deb- und rpm-Pakete verfügbar. Ubuntu, Debian und Fedora erhalten dabei spezifische Unterstützung. Für ArchLinux stehe ein experimentelles Paket zur Verfügung. In den kommenden Wochen soll zudem noch Unterstützung für 64-Bit-Varianten von Raspberry Pi OS hinzugefügt werden.

Der Beitrag Docker Desktop für Linux erschienen erschien zuerst auf Linux-Magazin.

LXD 5.0 LTS bringt Neuerungen

27. April 2022 um 07:46

Der von Canonical entwickelte Linux Container Daemon (LXD) ist in Version 5.0 mit Long Term Support erschienen.  LXD-Maintainer Stéphane Graber hebt hervor, dass in der neuen Version virtuelle Maschinen jetzt praktisch die gleichen Funktionen wie Container haben und viele Netzwerkoptionen hinzugefügt worden seien.

LXD 5.0 LTS wird bis Juni 2027 mit Updates versorgt, so Graber in der Ankündigung. Die Vorversion LXD 4.0 bekomme in naher Zukunft ein letztes Bugfix-Release auf 4.0.10 und gehe dann für die verbleibenden 3 Jahre Supportzeit in den reinen Wartungsmodus über.

Neuerungen gibt es unter anderem auch im Netzwerkbereich. Dort wird nun das Open Virtual Network (OVN) unterstützt. Ein- und ausgehende Netzwerkverbindungen müssen zudem TLS 1.3 unterstützen.

Während LXD bisher Rückwärtskompatibilität bis hin zur Version 0.1 angeboten hat, ist für LXD 5.0 LTS nur ein Upgrade von LXD 4.0.x möglich. Das Beibehalten der Rückwärtskompatibilität habe zu viele Ressourcen verschlungen, so Graber.  Zu den neuen Paketen zählt der Maintainer Kernel 5.4, Go 1.18, LXC 4.0.x und QEMU 6.0.

Der Beitrag LXD 5.0 LTS bringt Neuerungen erschien zuerst auf Linux-Magazin.

❌
❌