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.
Um Docker Container zu verwalten, gibt es viele Tools, da wäre zum Beispiel Portainer oder Rancher.
Aber es gibt auch schlichte Tools wie Lazy Docker.
Das in Go geschriebene Programm läuft über die Konsole, ist interaktiv und bietet schnellen Zugriff auf die wichtigsten Docker oder Docker Compose Funktionen. Folgende Funktionen werden aktuell (Version 0.8) unterstützt.
Die Installation ist sehr einfach und kann direkt über wget oder via brew erledigt werden.
Der Einfachheit halber werde ich den ersten Weg wählen.
Voraussetzung ist eine bestehende und laufende Docker Installation (ansonsten wäre die Nutzung des Programms wenig sinnvoll).
Anmelden
wget https://github.com/jesseduffield/lazydocker/releases/download/v0.18.1/lazydocker_0.18.1_Linux_x86_64.tar.gz
tar xvzf lazydocker*.tar.gz
sudo install lazydocker /usr/local/bin/
sudo systemctl status docker
sudo lazydocker
Die Steuerung erfolgt über die Pfeiltasten, das Menü lässt sich über x aufrufen und das Tool via Esc beenden.
Eine komplette Liste der Shortcuts findet ihr hier. Im Prinzip selbsterklärend.
Wer sich nicht selbst reinfinden möchte, der kann auch auf das Videotutorial zurückgreifen.
Praktisches Tool, welches ohne Webserver oder dergleichen auskommt und etwas mehr Überblick bietet, als die üblichen Konsolenbefehle.
Container sind nach wie vor in alle Munde. Wer, der Einfachheit halber, mit Docker hantiert, der sollte regelmäßig die Aktualität der verwendeten Images prüfen. Nicht erst seit Log4j verbergen sich unerwünschte Sicherheitslücken in veralteten Images.
Das Open-Source-Tool Trivy bietet die Möglichkeit lokale Images, direkt im Filesystem oder entfernte Repositorys nach Lücken zu scannen. Das Programm scannt unter anderen Base Images wie Alpine, Debian, Ubuntu, CentOS, SUSE, Photon OS, Paketmanager und andere Abhängigkeiten mithilfe der eigenen Schwachstellendatenbank ab.
Die Trivy Datenbank basiert auf NVD und diverser Security Meldungen einzelner Programmiersprachen (siehe).
sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy
Um die Übersicht der Scanergebnisse zu behalten, empfiehlt es sich, die Ausgabe auf kritische Lücken zu beschränken
trivy image --severity HIGH,CRITICAL IMAGENAME
Das Tool erlaubt es ebenfalls einen HTML Report zu veröffentlichen
trivy image --format template --template "@contrib/html.tpl" -o report.html golang:1.12-alpine
Trivy kann auch das Filesystem untersuchen.
trivy fs /path/to/project
Schlussendlich kann auch direkt via GitHub gescannt werden.
trivy repo https://github.com/knqyf263/trivy-ci-test
Wer Docker im Einsatz hat, sollte die verwendeten Images regelmäßig auf Sicherheitslücken und Abhängigkeiten prüfen. Der Profi baut seine Images sicher selbst und weiß, was er tut, allerdings übersieht ein DevOp auch dort mal Abhängigkeiten. Auch hier schafft Trivy praktische Abhilfe, denn es lässt ich schnell in CI Workflows, beispielsweise von Gitlab integrieren.
Dies ist der Beginn meines zweiten Container-Projekts. Nach Kanboard im Container möchte ich diesmal eine Nextcloud-Instanz als Container, zusammen mit einem Datenbank-Container, in einem Podman-Pod betreiben.
Da ein einzelner Artikel vermutlich zu lang wird, teile ich das Projekt in mehrere Artikel auf. Wie viele es genau werden, kann ich jetzt noch nicht sagen. Am Ende der Reihe werde ich hier eine Übersicht einführen und die einzelnen Teilen entsprechend miteinander verbinden.
In diesem ersten Teil geht es um meine Motivation, das eigentliche Ziel und den groben Plan.
Ihr könnt mich durch diese Reihe begleiten und euch von meinen Erlebnissen und Erkenntnissen unterhalten lassen. Dabei dürft ihr nicht annehmen, dass es sich bei dem von mir beschriebenen Vorgehen um eine gute Praxis handelt. Hier gilt eher: Der Weg ist das Ziel.
Ihr seid herzlich eingeladen, die Artikel zu kommentieren und über das Vorgehen und Alternativen dazu zu diskutieren. Gern in der Kommentarsektion unter den jeweiligen Beiträgen oder als Artikel in euren eigenen Blogs.
Ich plane die Artikel im Wochenrhythmus, wenigstens monatlich, zu veröffentlichen. Bitte verzeiht, wenn es etwas unregelmäßig wird. Dies ist ein Hobby, dem nur begrenzt Zeit zur Verfügung steht.
Bei Linux-Containern handelt es sich um eine Technologie, die gekommen ist, um zu bleiben. Sie hat bereits in vielen Branchen Fuß gefasst und immer mehr Projekte bieten ihre Anwendungen zusätzlich oder ausschließlich in Form von Containern an.
Als Sysadmin mittleren Alters werden mich Linux-Container sicher noch viele Jahre begleiten. Um praktische Erfahrungen mit dem Betrieb zu sammeln, möchte ich einige private Projekte in Containern betreiben.
Beruflich arbeite ich überwiegend mit RHEL. Red Hat engagiert sich stark in den Projekten Ansible und Podman, welche ich auch unter anderen Distributionen, wie z.B. Debian, einsetze. Ich möchte das Projekt als Chance nutzen, mein Wissen auch in diesen Werkzeugen zu festigen und auszubauen.
Ich spiele schon seit einiger Zeit mit dem Gedanken, wieder eine eigene Nextcloud-Instanz zu betreiben. Da auf dem zur Verfügung stehenden Server bereits eine Nextcloud-Instanz läuft und ich meine Anwendung von der bestehenden Instanz getrennt und möglichst losgelöst vom Betriebssystem betreiben möchte, habe ich mich entschieden, Nextcloud im Container zu betreiben.
Ziel dieses Projekts sind das Deployment und der Betrieb einer Nextcloud-Instanz als Podman-Pod. Im Einzelnen sollen folgende Ziele erreicht werden:
Für die Umsetzung des Projekts steht mir ein Virtual Private Server (VPS) mit genügend Ressourcen zur Verfügung. Dieser wird in einem Rechenzentrum in Deutschland betrieben. Auf diesem sind Debian Bullseye, NGINX, ein OpenSSH-Server, Podman 3.0.1 (rootless) und Python 3.9.2 installiert. Damit erfüllt dieses System die Voraussetzungen, um mit Ansible konfiguriert zu werden und Container ausführen zu können.
Ansible selbst läuft in meiner privaten Arbeitsumgebung auf meinem Debian-PC und einem Fedora-35-Notebook.
Zu Beginn habe ich mich etwas in der Nextcloud-Dokumentation und den verfügbaren Nextcloud-Images belesen. Besagte Dokumentation sowie die der verwendeten Werkzeuge sind im folgenden Abschnitt verlinkt.
Um die oben formulierten Ziele zu erreichen, werde ich in einem Python Virtual Environment eine Ansible-Version installieren, mit der ich die Collection containers.podman nutzen kann. Hiermit werde ich eine Ansible-Rolle entwickeln, die ich wiederverwenden kann, um Nextcloud-Instanzen in einer rootless-Podman-Umgebung zu deployen. Die Ansible-Rolle wird anschließend auf meinem GitHub-Account veröffentlicht.
Die Konfiguration von NGINX und acme.sh für die TLS-Zertifikate erfolgt manuell.
In diesem Abschnitt liste ich Links zu Artikeln und Dokumentationen auf, welche ich im Vorfeld gelesen habe und deren Kenntnis ich für die Umsetzung als nützlich erachte. Zur besseren Übersicht gliedere ich diese in die Unterabschnitte Hintergrundwissen, Dokumentation und Eigene Artikel.
In diesem Teil beschreibe ich die Konfiguration von NGINX als Reverse-Proxy für mein Wochenend-Projekt „Nextcloud im Container“. Und was so langweilig klingt, wie lediglich die Direktive proxy_pass in die NGINX-Konfiguration einzufügen, dauerte dann doch überraschend lange.
Darüber hinaus dokumentiere ich die Konfiguration von fail2ban, um die Anmeldemaske der Nextcloud vor Brute-Force-Angriffen zu schützen.
Falls ihr Teil 1 und Teil 2 dieser Reihe noch nicht kennt, empfehle ich euch, diese Teile zuerst zu lesen.
Bevor ich zur aktuellen Konfig komme, möchte ich kurz die Fehlschläge auf dem Weg dorthin festhalten.
Auf meinem Server läuft bereits ein Dienst, welcher unter der URL https://www.example.com/service1 erreichbar ist. Mir gefiel die Idee, die Nextcloud unter einer URL wie https://www.example.com/service2 erreichbar zu machen.
Die Dokumentation des Container-Repos [3] ist in meinen Augen zu kurz geraten und reicht für eine erfolgreiche Konfiguration längst nicht aus.
Nachdem ich einiges über die Generierung von Back-to-URLs und Redirects gelesen und im Nextcloud-Forum gestöbert hatte, ließ ich die Idee fallen. Ich warte mal ab, wie sich Issue #401 entwickelt. Vielleicht greife ich die Idee später nochmal auf.
Im nächsten Versuch, sollte Nextcloud unter einer eigenen Domain wie nextcloud.example.com erreichbar sein. Doch auch hier klemmte es zunächst. Zuerst stolperte ich in den bekannten Untrusted-Domain-Fehler.
trusted_domains in config.php nicht korrekt gesetzt ist.Diesen Fehler konnte ich schnell abstellen, da ich lediglich vergessen hatte die Variable NEXTCLOUD_TRUSTED_DOMAINS mit einem Wert zu belegen. Als Wert ist der FQDN einzutragen, unter dem die Nextcloud erreichbar sein soll. Dieser ist explizit anzugeben, da der Apache-Prozess innerhalb des Nextcloud-Containers den FQDN, auf den der NGINX-Reverse-Proxy lauscht und welcher im HTTP-Header übertragen wird, nicht kennt.
Des Weiteren musste ich noch die Variablen NEXTCLOUD_OVERWRITEPROTOCOL und NEXTCLOUD_OVERWRITECLIURL in vars/main.yml mit Werten belegen, um die entsprechenden Umgebungsvariablen für die Container-Instanz zu setzen (vgl. [3]). Dies ist notwendig, da die Anwendung im Nextcloud-Container andernfalls Back-to-URLs für das HTTP-Protokoll generiert. Versucht der Browser diese aufzurufen, erscheint ein Fehler oder man landet in einer endlosen Redirect-Schleife.
Nachdem ich die Nextcloud mit Hilfe der Ansible-Rolle [2] erneut deployt habe, war der Login-Screen erreichbar:
Der Weg hierher war für meinen Geschmack aufwändiger als er hätte sein müssen. Nur durch Lektüre und Recherche der Quellen unter [4], [5] und [6] konnte ich mich von Problem zu Problem hangeln und diese lösen. Hier ist in meinen Augen noch Raum für Verbesserungen.
Meine NGINX-vHost-Konfiguration habe ich mir mithilfe von [4], [5] und [6] zusammengesucht und bin bei folgender Konfig gelandet (es werden nur relevante Abschnitte wiedergegeben):
server {
listen 80;
listen [::]:80;
server_name nextcloud.example.com;
root /var/www/nextcloud.example.com;
index index.html;
[...]
return 301 https://$server_name$request_uri;
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/www/nextcloud.example.com;
}
location = /.well-known/acme-challenge/ {
return 404;
}
}
server {
# Listen on Port 443
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name nextcloud.example.com;
[...]
root /var/www/nextcloud.example.com;
[...]
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/www/nextcloud.example.com;
}
location = /.well-known/acme-challenge/ {
return 404;
}
location / {
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
add_header Front-End-Https on;
proxy_pass http://127.0.0.1:40231;
}
location /.well-known/carddav{
return 301 $scheme://$host/remote.php/dav;
}
location /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}
}Ob dies eine gute Konfiguration ist, mag ich nicht beurteilen. Sie funktioniert zumindest. Die Nextcloud ist erreichbar und über die Weboberfläche können weitere Einstellungen vorgenommen, Nutzerkonten erstellt und Apps installiert werden.
Nun steht die Nextcloud mit ihrer Login-Maske im Wind. Sie stellt damit ein schönes Ziel für Brute-Force-Angriffe dar. Um es den Angreifern nicht zu leicht zu machen, habe ich für den Nextcloud-Admin keinen einfach zu erratenen Namen wie Admin, Nextcloud-Admin oder meinen Namen verwendet. Um Angreifer weiter auszubremsen, konfiguriere ich fail2ban. Wie dies installiert wird, schlagt bitte in der Dokumentation eurer Distribution nach. Ich gehe hier nicht auf die Installation ein.
Damit fail2ban fehlgeschlagene Anmeldeversuche erkennt, habe ich die Datei /etc/fail2ban/filter.d/filter.d/jk_nextcloud.conf mit folgendem Inhalt erstellt:
[Definition]
_groupsre = (?:(?:,?\s*"\w+":(?:"[^"]+"|\w+))*)
failregex = ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Login failed:
^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Trusted domain error.
datepattern = ,?\s*"time"\s*:\s*"%%Y-%%m-%%d[T ]%%H:%%M:%%S(%%z)?"Dieser Filter wird in der Datei /etc/fail2ban/jail.d/jk_nextcloud.local referenziert:
[jk_nextcloud]
backend = auto
enabled = true
port = 80,443
protocol = tcp
filter = jk_nextcloud
maxretry = 3
bantime = 86400
findtime = 43200
logpath = /home/tronde/.local/share/containers/storage/volumes/nc_data/_data/nextcloud.logWenn innerhalb der findtime von 43200 Sekunden von einer IP-Adresse mehr als drei fehlgeschlagene Anmeldeversuche (maxretry) registriert werden, wird die entsprechede IP-Adresse für 86400 Sekunden (bantime) gesperrt. Eine Statusabfrage ist wie folgt möglich:
$ sudo fail2ban-client status jk_nextcloud
[sudo] password for tronde:
Status for the jail: jk_nextcloud
|- Filter
| |- Currently failed: 1
| |- Total failed: 5
| `- File list: /home/tronde/.local/share/containers/storage/volumes/nc_data/_data/nextcloud.log
`- Actions
|- Currently banned: 0
|- Total banned: 1
`- Banned IP list:Es ist zu erkennen, dass aktuell keine IP-Adresse gesperrt ist. In der Vergangenheit wurde jedoch bereits eine IP gebannt.
Für mich stellt fail2ban einen Baustein zur Sicherung der Nextcloud bereit. Zusätzlich werde ich eine Zwei-Faktor-Authentisierung konfigurieren, um die Sicherheit weiter zu steigern.
An diesem Punkt meines Wochenend-Projekts kann ich eine Nextcloud-Instanz mit meiner Ansible-Rolle deployen und hinter einem Reverse-Proxy nutzen. Bisher schützt fail2ban vor Brute-Force-Angriffen. Zukünftig wird jedoch eine Zwei-Faktor-Authentisierung diesen Schutz verstärken.
Eine lauffähige Konfiguration zu erstellen, hat dabei länger gedauert, als ich mir vorgestellt habe. Dabei hat mir missfallen, dass dies nicht mit der Dokumentation allein gelang, sondern das Forum [5] und die Internetsuchmaschine meines geringsten Misstrauens zurate gezogen werden mussten. Damit ist dieses Projekt jedoch bei weitem kein Einzelfall.
307 offene Issues (Stand 05.02.2022) zeugen davon, dass hier noch längst nicht alles rund läuft. Von der Idee, dass es sich hierbei um ein Fire-and-Forget-Projekt handeln könnte, verabschiede ich mich lieber. So bin ich auch gleich in das unter [7] beschriebene Problem getreten. Erfreulicher Weise hat die dort beschriebene Lösung funktioniert, so dass meine Cloud mir jetzt E-Mails senden kann. Ich werde mir Gedanken machen, wie die entsprechenden Abschnitte in der Dokumentation verbessert werden können und dem Projekt einen Pull-Request senden. Mal schauen wie man darauf reagiert.
Damit sind die in Teil 1 formulierten Ziele 1-3 erreicht. In Teil 4 beschäftige ich mich mit einigen weiteren Steinen, über die ich gestolpert bin, bevor ich mich dann in Teil 5 dem Thema Backup & Recovery widme.
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.phpDamit 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.
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 3Dieser 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 nextcloudDiese 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-apacheHier 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-apacheNun 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=0Nun 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 nextcloudFertig. 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.
Mit Canonicals Linux Container Daemon LXD lassen sich Betriebssysteme in Container oder VMS stecken. LXD 5.0 LTS verbessert unter anderem das Netzwerken.
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.
Docker liefert mit einigen Jahren Verzögerung Docker Desktop für Linux aus. Mit im Paket sind unter anderem Docker Compose und Kubernetes.
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.
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.
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.
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.
Fedora Core OS hofft, mit Fedora 37 neben den bestehenden Angeboten für Workstation, Server und IoT als offizielle Edition aufgenommen zu werden.
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.
Die neue Android-App Nestbox bietet Linux-Container in einer VM und bedient sich dabei des neuen Virtualization Framework von Android 13.
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.
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.
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.
Immer wieder mal in den 8 Jahren LinuxNews kam die Idee auf, WordPress den Laufpass zu geben. Gescheitert ist es dann an der Migration.
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.
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.
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-kumaUm 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
ad7b049d9b84962311f5bafb5329f59961d8a031e54a571f079b8243ea8059eepodman 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:latestManpages 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.serviceManpages zum Nachschlagen:
$ mv -Z container-uptime-kuma.service ~/.config/systemd/user/container-uptime-kuma.service
$ systemctl --user daemon-reloadsystemd 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 falseLeider 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.
