/ Server

Docker im Produktivbetrieb

Der riesige Hype um Docker scheint (schon) wieder vorbei zu sein und manche Sysadmins stehen der Technologie skeptisch gegenüber.
Nachdem ich Docker in meiner Bachelorarbeit zum ersten Mal richtig eingesetzt habe, war ich zumindest von meiner Seite aus begeistert. Nachdem ich in einem älteren Post bereits angesprochen habe, dass meine originale Openshift Installation mangels Updates ihr Lebensende erreicht hat (nach nicht mal 3 Jahren), wollte ich zuerst auf das neue Openshift, das auf Kubernetes aufbaut umsteigen. Schnell habe ich aber begriffen, dass ohne kostspielige Infrastruktur wie einem privaten (V)LAN (das bei Netcup immerhin mehr als 3x so viel wie mein Server kostet, Openvpn kommt aus Performancegründen nicht mehr in Frage) die Installation eines Docker/Kubernetes-Clusters viel zu aufwendig ist und ich die meisten Funktionen davon gar nicht benötige.
Die Idee, "puren" Docker zu verwenden und die verschiedenen Anfragen über einen Reverse-Proxy an den gewünschten Endpunkt weiterzureichen war deshalb ziemlich schnell geboren. Auch die Idee, alle Dienste mittels Letsencrypt auf eine SSL-Verbindung umzustellen wollte ich unbedingt verwirklichen.

Die Vorteile, die mir Docker bei diesem Projekt bietet sind vielfältig:

  • Es gibt für die meisten Dinge, die ich verwende (und verwenden möchte) bereits ein Fertiges Image, welches ich einfach installieren kann.
  • Durch geschickten Einsatz von Docker Volumes kann ich alle Daten an einem zentralen Ort speichern, sichern und wiederherstellen - das Backup geht so viel einfacher, weil ich die Daten nicht mühsam über duzende Ordner zusammensammeln muss, was vor allem bei dem Zurückspielen eines Backups aufwendig sein kann.
  • Auch das Upgrade von Diensten ist einfach, wenn man die Volumes richtig einsetzt. Bei Ghost zum Beispiel reicht ein docker pull, um das neue Image zu holen und dann muss man nur mehr den Container neu starten und fertig (im Idealfall ;) )
  • Durch Docker kann ich einfach verschiedene Versionen von Programmen gleichzeitig einsetzen, ohne dass sie sich gegenseitig behindern würden. So funktioniert out-of-the-box z. B. ein Legacy Postgres Server mit einem aktuellen zusammen, ohne mühsames Installieren und Konfigurieren.
  • Es gibt garantiert nur einen "Einstiegspunkt". Das ist jetzt zwar nicht unbedingt ein Docker-Ding, würde ich alles per Hand machen, wäre auch der Reverse-Proxy der einzige Einstiegspunkt, wie ich aber später erklären werde, gibt es ein Docker-Image, das alle Funktionen liefert, die ich brauche.
  • Umzug auf einen anderen, stärkeren Server ist denkbar einfach. Zuerst werden die Volumes des Containers auf den neuen Server übertragen, dann wird einfach das selbe Image am neuen Server gestartet und fertig.

Die Architektur

Folgende Systemarchitektur habe ich mir für dieses Projekt ausgedacht:

In einem Container ist der nginx Reverse-Proxy. Dies ist gleichzeitig der einzige Container, der Zugriff "in die Außenwelt" hat, und zwar über den HTTP und HTTPS Port. Dieser Container ist mit einem internen Docker-Netzwerk mit den Webapp Container verbunden, in denen die verschiedenen Webseiten und Dienste laufen. Diese haben, je nach Bedarf, über jeweils eigene Netze Zugriff auf Datenbankcontainer oder Container mit anderen Diensten.
Diese Trennung der Funktionen hat den Vorteil, dass jeder Dienst nur auf die Unterdienste Zugriff hat, die er benötigt, um zu funktionieren. Theoretisch könnte man dies über Overlay-Netzwerke sogar ausweiten und den Zielcontainer auf einer anderen Physischen Maschine starten. Aber das ist Thema eines anderen Posts.

Sobald es in dieser Serie weiter geht, gibt es hier die Links zu den anderen Teilen.

Folgende Teile hab ich mir mal ausgedacht (Änderungen vorbehalten)

  1. Docker im Produktivbetrieb
  2. nginx-Reverse-Proxy in Docker
  3. Backup
  4. Der erste Dienst im Docker
  5. Eigenes "Github"
  6. Website von Git holen und updaten.
  7. Eigene Docker-Registry für private Images (gratis "Dockerhub Pro")