docker-compose health-checks container-dependencies

Gerade beim Deployment von ganzen Stacks mit Docker-Compose kommt es vor, dass Container untereinander Abhängigkeiten haben. Simples Beispiel - ein einfacher Service mit einer Abhängigkeit auf eine Datenbank oder einen KV-Store. Werden beide Container gleichzeitig gestartet könnte der Service Probleme bekommen, wenn die Datenbank beim Startup noch nicht da ist. Man kann das über einen halbwegs stabilen Retry lösen, indem man versucht, sich immer wieder gegen die Datenbank zu verbinden bis es klappt. Zusätzlich macht es aber Sinn, eines der neuen Features in Docker zu verwenden - depends on mit healthchecks.

Spätestens im Cluster mit mehreren Knoten wird es schwierig, den Überblick über die Logs aller Container auf allen Hosts zu behalten. Es ist einfach nicht mehr praktikabel und zeitgemäß, sich auf einem Knoten einzuloggen, um dort die Logfiles in /var/log/ manuell mit less und tail zu durchforsten.

Besser ist der Einsatz eines zentralel Logging-Servers. Hierfür gibt es viele Beispiele und wir werden uns noch einige genauer betrachten. Für den Anfang nehmen wir den kampferprobten ELK-Stack. Elk kennt mittlerweile wahrscheinlich beinahe jeder, und steht für E - ElasticSearch, L - Logstash, K - Kibana.

Docker inspect erlaubt es uns, einen Blick in die Tiefen und Untiefen eines Containers zu werfen.

Hierfür starten wir zunächst einen einfachen Container im eigenen Netzwerk, der nichts tut außer warten.

docker network create -d bridge test-bridge
docker volume create test

docker run -d -p 8080:8080 -v test:/test -v /tmp:/tmp/test --network test-bridge --name runner effectivetrainings/runner
# das Portmapping ist völlig unnötig, dient uns nur zur Veranschaulichung von Ports in der inspect-Ausgabe.

Inspizieren wir den laufenden Container, bekommen wir eine ganze Menge Informationen, für die wir üblicherweise gar keine Verwendung haben. Das geht besser.

Im letzten Eintrag haben wir uns mit Health Checks in Containern beschäftigt. Das alleine ist schon eine sehr wichtige Funktionalität, entwickelt ihr Potential allerdings erst in Zusammenarbeit mit einem Scheduler der das aktiv unterstützt. In diesem Artikel konzentrieren wir uns auf Docker Swarm im Swarm Mode (ab 1.12)

Anwendungen zu deployen ist einfach, und Docker Container zu starten ist noch einfacher. Ein einfaches docker run und schon sind wir live. Das funktioniert auch eine ganze Zeit bis zum ersten Problem - sei es nun eine Lastspitze, ein Bug, ein Amoklaufender Prozess oder einfach ein temporäres Netzwerkproblem. Die Anwendung ist nicht erreichbar, unsere E-Commerce-Plattform ist für die Kunden nichts weiter als eine 500 - Wir arbeiten an einer Lösung und bis wir diese gefunden haben ist die Bestellung meistens schon bei der Konkurrenz gelandet.