Laden...

Docker Container mit Traefik in Dev und Prod verwalten

Erstellt von Cornflake vor einem Jahr Letzter Beitrag vor einem Jahr 762 Views
C
Cornflake Themenstarter:in
142 Beiträge seit 2007
vor einem Jahr
Docker Container mit Traefik in Dev und Prod verwalten

Hallo Leute

Für die Verwaltung von zwei Docker Container Webseiten unter Traefik in Produktiv und Development bräuchte ich zwei Tipps.
Zum Einen, wie die docker-compose.yml Datei für die Verwaltung der beiden Webseiten Container zu konfigurieren ist.
Zum Anderen, wie ich ein Script schreiben kann, dass automatisch aus der aktuellen development Image Version einen neues produktiv Image kopiert und das alte produktiv Image archiviert. Vmtl muss ich erst Thema 2 kapieren, bevor Thema 1 funktioniert.

Thema 1 docker-compose.yml

Aktuell läuft auf meinem Linux Server ein Docker Hub auf dem eine docker-compose.yml Datei folgende Zusammenstellung erzeugt.
Es wird ein Traefik Image geladen, dass sich für den https Zugang ein letsencrypt Zertifikat holt.
Unter einer speziellen URL wird dann mein Webseiten Image als Container zur Verfügung gestellt.
Zukünftig soll es eine Kopie als Produktiv Version von diesem geben. Dann kann ich Features im development Image testen und das produktiv Image nur wenn alles passt aktualisieren. Ich konnte schon rausfinden, dass ich mit profiles:["prod"] z.B. ein produktiv Profil in Docker Compose definieren kann. Aber ich vermute, ich brauche unterschiedliche Ports für den development Container, wenn ich im produktiv Container den Port 443 verwende.

Daher folgende Docker Szenario soll es geben:

  1. Traefik Container ist von außen erreichbar.
  2. Produktiv Webseiten Container ist unter der URL https://www.domain.de/webseite erreichbar.
  3. Development Webseiten Container ist unter der URL https://www.domain.de/dev/webseite erreichbar.

Mein Problem beide Container sollen unter dem Port 443 erreichbar bleiben nur die Url soll anders sein. Ich habe dazu auch schon unterschiedliche "traefik.http.routers.webseite.rule=" Werte konfiguriert.
Gibt es zu diesem Aufbau evtl. schon Tutorials oder Beispiel Compose Dateien?

Thema 2 Kopierscript

Das Script soll idealerweise folgende Schritte durchführen:

  1. Produktiv Container stoppen
  2. Produktiv Image mit aktuellem Datum in Archiv Ordner verschieben
  3. Development Image kopieren als neues Produktiv Image
  4. Produktiv Container starten.

Ich hoffe ihr habt so etwas schon mal umgesetzt und könnt mir evtl. ein paar Tutorial Links senden.
Unter Google habe ich bisher nichts gefunden, dass zu meinem Fall passt oder ich verstanden habe. Es gibt unter Docker ja export und save sowie load und import Befehle. Aber wie ich eine Kopie vom webseite:latest Image mit anderem Namen z.B. webseite_prod:latest erzeuge habe ich nicht verstanden.

Grüße Cornflake

16.807 Beiträge seit 2008
vor einem Jahr

Unter Google habe ich bisher nichts gefunden, dass zu meinem Fall passt oder ich verstanden habe.

Evtl weil Du ein eher nicht so weit verbreitet hast Setup hast.

  • In größeren / professionellen Umgebungen hat man nicht ganz so oft mehrere Stages pro Cluster; denn Changes an zentralen Dingen vom Cluster (zB durch Dev) können den ganzen Cluster offline nehmen, daher isoliert man eher auch den Cluster
  • Wenn man sich doch einen Cluster teilt, dann hat man "zentrale Services" wie zB. eben den Reverse Proxy / Ingress, den man nicht pro Stage ausrollt, sondern konfiguriert (zB via Traefik API - aber nicht via Docker Compose / Helm)
  • Man trennt auf Domain- und nicht auf Folder-Ebene
    Rein interessehalber, wieso machst Du das eher so ungewöhnlich, vor allem das Domain-Ding? Das wird mega komplex, weil Du die ganze Struktur wirst exkluden müssen.

Auch unter Kubernetes wäre das nicht anders.
In Kubernetes kann man traefik als Ingress zentral registrieren, und dann die Kubernetes API nutzen, um den Ingress durch Helm zu konfigurieren.
Vielleicht geht das so auch mit Compose?

Aber wie ich eine Kopie vom webseite:latest Image mit anderem Namen z.B. webseite_prod:latest erzeuge habe ich nicht verstanden.

Verwechselst Du gerade die Begriffe Container und Image?
Eine Image Copy kannst Du einfach mit docker tag erzeugen. Willst Du es auf eine andere Maschine bringen, dann exportierst es als tar und importierst es wieder.

Ein Container duplizierst Du zB mit docker commit

C
Cornflake Themenstarter:in
142 Beiträge seit 2007
vor einem Jahr

Hallo Abt

Danke für deine Antwort.
Naja es ist ja auch keine große Umgebung. Nur ein Server.
Mit Kubernetes habe ich noch gar nichts gemacht. Ich vermute, dass Kubernetes erst bei mehreren Servern und umfangreicheren Settings benötigt wird.

Auf dem Entwicklungs PC entwickle ich unter Visual Studio mein Docker Projekt und debugge es mit Docker Desktop ohne öffentliches Zertifikat. Wenn lokal alles läuft, exportiere ich es und lade die webseite.tar.gz Image Datei auf den Server.
Auf dem Server läuft Linux und Docker. Dort stoppe ich aktuell von Hand den Container und lösche dann Container und Image. Danach lade ich die Image Datei in den Docker Hub und starte das Image als Container. Danach läuft alles auf dem neuesten Stand mit öffentlichem Zertifikat durch Traefik.
Zukünftig soll es die zwei Stages Dev und Prod geben. Aber ich habe nunmal nur einen einfachen Server und keine Serverfarm mit mehreren Clustern etc.

In Zukunft wäre noch ideal, nachdem ich den Code, per Git Commit auf einen GitLab Account geladen habe, dann GitLab den Docker Container auf den neuesten Stand bringen würde, mit kompilieren, tests, als Image packen, altes Image sichern, und mit Freigabe als Produktiv Version, Container starten, etc.

Wegen docker commit bzw. docker tag. Ist dass dann eine richtige Kopie des Images oder nur so ein flaches Container Abbild mit anderem Namen, dass trotzdem auf das alte Image nur mit zusätzlicher "Zwiebel"-Schicht verweist?
Für mich sind die Images gewissermaßen eine calc.exe während der Container eine laufende calc.exe mit eingegebenen Werten und Verlauf darstellt. Wenn der Server neu starten muss, wird vom Image wieder neu der Container ohne die alten Werten geladen. Daher die calc.exe neu geöffnet. Volumes der Container persistieren dann nur die Daten zwischen den Containerausführungen und können einen Zugriff ausserhalb des Container ermöglichen. Sehe ich das richtig?

16.807 Beiträge seit 2008
vor einem Jahr

Docker Compose und Kubernetes sind beides Container Orchestratoren.
Daher - unabhängig davon, wie viel Blech drunter ist - ist die Funktionsweise ähnlich: konfigurieren beide Anhand von Config Files das Multi Container Hosting und die Zwischenkommunikation.
Docker Compose ist halt wirklich ein sehr sehr einfach gehaltenes, stupides Tool für mehrere Container ohne irgendein Stage-Verhalten. Du willst aber ein Stage verhalten, daher wirst Du um Workarounds nicht drum herum kommen.

In Deinem Fall ist es ja auch so, dass Du im Endeffekt ein Traefik Ingress haben willst, der dann den Traffic auf Dev Test Prod Whatever verteilt.
Das ist streng genommen halt auch kein isoliertes Setup: denn Du teilst Dir Traefik.
Es würde mich wundern, wenn das so 1:1 mit Docker Compose funktionieren würde.

In Zukunft wäre noch ideal, nachdem ich den Code, per Git Commit auf einen GitLab Account geladen habe, dann GitLab den Docker Container auf den neuesten Stand bringen würde, mit kompilieren, tests, als Image packen, altes Image sichern, und mit Freigabe als Produktiv Version, Container starten, etc.

Auch dafür ist Docker Compose nicht gemacht. Das war mal die Aufgabe von Docker Swarm, das retired ist - weil jeder Kubernetes verwendet.

Zukünftig soll es die zwei Stages Dev und Prod geben. Aber ich habe nunmal nur einen einfachen Server und keine Serverfarm mit mehreren Clustern etc.

Die Menge des Blechs ist für den Orchestrator irrelevant.
Auch Kubernetes kann auf einer einzelnen Maschine installiert werden, oder man verwendet sowas wie k3s, das exakt die gleiche API bietet - nur für Single Blech.
Dir geht es ja um die Features - und Docker Compose ist für Deine Anforderung / Idee nicht gerade ideal bzw. gedacht; zumindest nicht in dem Verhalten der Stages, Ingress und Versionierung bzw. CI.

Wenn der Server neu starten muss, wird vom Image wieder neu der Container ohne die alten Werten geladen.

Nein. Ein Image ist keine Laufzeitumgebung.
Nur Container können gestartet werden, keine Images. Container basieren auf Images.

Wenn ein Server neu startet, dann startet der Container exakt so neu, wie er gestoppt wurde - auch die Daten bleiben erhalten, egal ob embedded oder external Volume.
Erst wenn ein Container aktualisiert, verschoben oder kopiert werden soll spielt es eine Rolle, dass die Daten ein externes Volume haben; damit zB. bei einem Image-Update nichts verloren geht.

Datenbank-Container wie zB. MSSQL speichern teilweise Daten im Container (zB. Cache) aber eben auch Daten auf einem externen Volume (zB. die ganzen Datenbanken).
So kann der MSSQL Container aktualisiert oder auch skaliert werden und es gehen keine Datenbanken verloren.

C
Cornflake Themenstarter:in
142 Beiträge seit 2007
vor einem Jahr

Thx Abt
Ok dann wäre Kubernetes oder k3s der nächste Schritt, damit die Umgebung einigermaßen gescheit für die Zukunft wird.
Hast du da evtl. einen guten Einstiegs Link der etwas auf meine Situation passt (Visual Studio, GitLab, 2 Stages, HTTPS öffentliches Zertifikat, Updatescript)?
Fühle mich in dem Bereich noch ziemlich als Anfänger, auch wenn ich schon froh bin über Traefik und mit Docker Compose die Grundversion zum Laufen bekommen zu haben.

16.807 Beiträge seit 2008
vor einem Jahr

Ich kenne Kubernetes und hab die meisten Dinge im Griff, aber ich hasse nacktes Kubernetes und vermeide es, wann immer ich es kann 🙂
Kundenprojekte damit werden abgelehnt bzw. weitergeleitet. Meine Meinung dazu: https://twitter.com/Abt_Benjamin/status/1513470187198205952

Generell betreiben die wenigsten Kubernetes nackt.
Ich hab bisher sowohl auf Single Rechnern wie auch auf On Prem Clustern mit Rancher gearbeitet; nimmt den meisten nervenden Sch* bei Kubernetes einem ab.
Rancher bietet mittlerweile auch eine eigene Entwicklungsumgebung mit Rancher Desktop und gehört seit dem Acquiring zu SUSE.
Andere Kubernetes Management Systeme sind zB Tanzu oder OpenShift (bzw. dessen OCP).

Um nen gutes Gewissen zu haben würde ich Dich also eher in diese Richtung schicken, als auf das nackte Kubernetes zu schicken.

In Zusammenhang mit Rancher gibts auch viele Tutorials, wie man diese in CI/CD Umgebungen mit GitHub oder GitLab integriert.
Die Community und die Advocates von Rancher sind sehr aktiv.