Schlagwort-Archive: Docker

adlerweb // BitBastelei 2023-10-26 20:33:59

Neu im : - Container-Zombies blockieren Netzwerk-Löschung (und damit auch Neustart per docker-compose).

Falls ihr also mal ein "error while removing network: network application_network id XXX has active endpoints" an den Kopf bekommt (oder ist es vergessen hab und suchen gehe): There is the solution.

adlerweb.info/blog/2023/10/26/

Docker: Container-Zombies blockieren Netzwerk-Löschung

(Achtung, Rant-Character. Wer das nicht mag findet die Lösung in den letzten 3 Absätzen)

Heute also mal wieder Docker. Ein stetiger Quell an Problemen. Ursprünglich war meine Anforderung gar nicht so kompliziert: Per docker-compose soll eine Multi-Container-Applikation aus- und wieder eingeschaltet werden. Also: docker-compose down und warten. Leider scheiterte der Prozess bereits an dieser Stelle aufgrund eines Timeouts. Das Schreiben großer Caches beim Beenden benötigt eben seine Zeit. Sicher, es gäbe -t oder stop_grace_period, aber wie das oft so ist: Wer auch immer vorher damit gearbeitet hat, hat es natürlich nicht dokumentiert oder konfiguriert.

Nunja, der docker-daemon sollte die zugehörigen Container trotz des Timeouts im Frontend noch abarbeiten – entsprechend war nach kurzer Bedenkzeit in docker ps -a auch kein Container mehr zu sehen, der zur Applikation gehört.

Alles gut? Leider nein. Das folgende docker-compose up weigerte sich beharrlich die Container wieder zu starten. Es versuchte immer noch, die Überreste der alten Struktur, insbesondere die Netzwerke, zu löschen, und scheiterte:

ERROR: error while removing network: network application_network id XXX has active endpoints

Active? Interessant, denn in docker ps -a war ja definitiv nichts mehr aktiv. Auch ein manuelles docker network remove application_network behauptete weiterhin, dass es die ID noch gäbe.

Error response from daemon: error while removing network: network application_network id XXX has active endpoints.

Ein docker network inspect application_network verriet: Die nicht mehr gelisteten Container sind wohl doch noch da – zumindest so halb. Also gehen wir auf Zombie-Jagd.

Die Lösung: Erst trägt man mit docker network inspect application_network | grep Name die Namen der verbliebenen Containerreste zusammen. Im Anschluss kann man über docker network disconnect ein Entfernen erzwingen.

for i in application_db_1 application_es_1 application_redis_1 application_nginx_1 ;do docker network disconnect -f application_network $i ;done

Abschließend entfernt man mit docker network remove application_network das Netzwerk. Danach sollte einem erneuten Start nichts mehr im Wege stehen.

PostgreSQL-Update im Docker-Stil

Docker. Eigentlich ja ganz praktisch, wenn man „mal schnell“ ein Softwarepaket trotz überschaubarer Wartbarkeit mit überschaubarem Aufwand ausrollen möchte, ab und an aber auch ein zuverlässiger Quell für Facepalm-Momente. So auch Heute: Nach dem Update einer mit docker-compose zusammengesetzten Anwendung ging nichts mehr. Der Maintainer hatte dort von postgres:10 auf postgres:11 aktualisiert. Kleines Update sollte man meinen, die PostgreSQL-Images für Docker sind jedoch technisch nicht in der Lage Daten älterer Installationen zu migrieren. Folglich zeigte sich im Log vor dem Absturz folgende Meldung:

postgres_1 | FATAL: database files are incompatible with server
postgres_1 | DETAIL: The data directory was initialized by PostgreSQL version 10, which is not compatible with this version 11.6.

Was auf „normalen“ Servern mit pg_upgrade schnell geregelt und bei einigen Distributionen gar automatisiert ist, wird mit Docker ein paar Nummern komplizierter. Der Offizielle Weg: Backup machen, neu aufsetzen, importieren. Eigentlich wollte ich durch Docker Arbeit sparen, nicht mir weitere aufhalsen.

Glück im Unglück: Tianon Gravi hat auf GitHub und Docker Hub ein passendes System bereitgestellt, mit welchem man die Daten schnell zwischen verschiedenen PostgreSQL-Versionen migrieren kann.

Im Folgenden gehe ich davon aus, dass ein Named Volume „postgres-data“ existiert und alle darauf zugreifenden Container gestoppt sind.

Achtung, Fallstrick: Nutzt man docker-compose, so ändern sich die Volume-Namen. Ein Named Volume „postgres-data“ der Applikation „foobar“ heißt in Wahrheit „foobar_postgres-data„. Im Zweifel nochmal mit „docker volume ls“ prüfen.

  1. Fangen wir mit dem üblichen an: Backups. Bei Bind-Mounts kopiert man einfach den Quellordner passend zurecht, bei Named Volumes kann man diese üblicherweise unter /var/lib/docker/volumes/ finden oder mit docker-clone-volume duplizieren. Ich hatte postgres-data hierzu auf postgres-data-src und postgres-data-bck dupliziert.
  2. Weiter geht es mit dem Umwandeln der Datenbank. Hierzu nimmt man das Image mit den passenden Versionsnummern für Quell- und Zielversion.
    docker run --rm -v postgres-data-src:/var/lib/postgresql/10/data -v postgres-data-dst:/var/lib/postgresql/11/data tianon/postgres-upgrade:10-to-11
    Hiermit wird ein neues, mit PostgreSQL 11 kompatibles, Volume erzeugt, welches alle bisherigen Daten enthalten sollte.
  3. Leider gibt es in der aktuellen Version einen bekannten Bug, welche die Zugriffe in pg_hba.conf abweichend von den Dateien der offiziellen Images konfiguriert. Dies führt mit vielen Images zu Zugriffsfehlern. Um die Datei per hand zu editieren startet man entweder einen passenden Container oder greift über das Dateisystem des Hosts auf diese zu. In meinem Fall nutzte ich letztere Methode über die Datei /var/lib/docker/volumes/postgres-data-dst/_data/pg_hba.conf. An das Ende dieser wird folgende Zeile angefügt:
    host all all all md5
  4. Am Ende ändert man entweder den Volume-Eintrag seiner docker-compose.yml oder kopiert das neue Image passend zurück. In meinem Fall klang letzteres sinnvoller. Einen Befehl zum Umbenennen von Volumes ist Docker bis Heute nicht bekannt, daher bleibt hier nur das ursprüngliche Volume mit docker volume rm postgres-data zu löschen und postgres-data-dst – wie zuvor – mit docker-clone-volume oder im Dateisystem zum korrekten Volume-Namen zu klonen.

Warum man das nicht automatisiert erschließt sich mir nicht so ganz. Vermutlich beschränkt sich der Benutzerkreis hauptsächlich auf Entwickler, die ohnehin immer von 0 starten, und Enterprise-Häuser, die gemäß Fire-and-forget Systeme ohne Update bis zur Explosion betreiben.

Docker: Start mit aktivem IPv6 nicht möglich

Docker kann bei mir nach wie vor zwei Lager bedienen: Die Idee von Containern klingt gut, die mangelnde Stabilität und viele Konzepte der Implementierung lassen mich aber nur den Kopf schütteln. Heutiges Thema: IPv6. Prinzipiell nicht wirklich nutzbar, da die meisten Orchestration-Systeme wie Kubernetes oder Swarm bisher laut Doku und Bugtrackern bestenfalls rudimentäre Unterstützung bieten. Docker selbst soll – laut Anleitung – jedoch mit wenigen Handgriffen IPv6-fähig gemacht werden können.

Klingt einfach? Tja, nach einem Neustart ließ sich der Docker-Daemon nicht mehr starten. Im Log fand sich folgendes:

dockerd: Error starting daemon: Error initializing network controller: Error creating default "bridge" network: could not find an available, non-overlapping IPv6 address pool among the defaults to assign to the network

Die Abhilfe ist recht einfach: Ein festes Netz vergeben. Hierzu in der daemon.json einen passenden fixed-cidr-v6-Eintrag machen:

{
"ipv6": true,
"fixed-cidr-v6": "2a01:1234:5678:9abc:def0::/112"
}

BitBastelei #289 – Container vs. VMs: Ein Blick auf Docker

BitBastelei #289 - Container vs. VMs: Ein Blick auf Docker

(458 MB) 00:52:09

2018-06-24 10:00 🛈
Containersysteme wie Docker versprechen nach der Virtualisierung den nächsten großen Schritt bei der zusammenführung von IT-Ressourcen zu sein. Im Gegensatz zu einer VM wird auf das Betriebssystem verzichtet, stattdessen laufen Programme in einem abgesperrten Bereich.
Also werfen wir mal einen groben Blick darauf was diese Container sind, wie man sie mit Docker nutzt und was es alles so drumherum gibt.