Container als Produktivlösung

Snakeeater

Commander
Registriert
Aug. 2004
Beiträge
2.854
Ich würde hier generell gerne eine Diskussion zum Thema Containerlösungen (bspw. Docker) in Produktivbetrieb starten. Meine eigene Kenntnis zum Thema ist sehr begrenzt. Grundlegend würde ich meine momentane Sicht zu dem Thema wie folgt beschreiben (das ist eine vereinfachte Sicht, mir ist bewusst das viele der Punkte im Detail nicht korrekt formuliert sind):

Generell sind Container dazu gedacht die Applikationen vom Hauptsystem abzutrennen. Dies hat in der Theorie den Vorteil einfacher Handhabung, da man so flexibel Container auf Maschinen deployen kann und diese alles mitbringen um die App zum Laufen zu bringen.
Viele Services und Applikationen im Netz bieten bspw. Docker Images an, besonders wenn sie sich noch stark in der Entwicklung befinden.
In (meiner) Realität ist es allerdings eher so, dass man solche Images relativ (!) einfach in den Betrieb bekommt. Falls sich jedoch Probleme ergeben, die Fehlersuche (aufgrund der Containerisierung) deutlich aufwendiger ist. Hinzu kommt aus meiner Erfahrung das man seine Infrastruktur schon für Container ausrichten muss, um diese richtig betreiben zu können, bspw. sowas wie Portainer.

Hiervon getrennt zu betrachten wäre dann aber der Sicherheitsaspekt den man mit Containern überdenken muss. Aufgrund der Abhängigkeiten die alle bereits im Container integriert sind, verschiebt man hier das Vertrauen für Aktualität/Sicherheitsfixes von Maintainern einer Distro/Repo auf eben den Anbieter der Dockerfiles. Dies könnte theoretisch dazu führen, dass bspw. irgendwelche packages/libs im Container keine aktuellen Updates enthalten (hier begebe ich mich auf Glatteis und würde mich gern über eine Richtigstellung freuen). Hier greift zwar der Vorteil der Trennung vom Hostsystem, aber wozu solche Sicherheitslücken dann dennoch genutzt werden könntet übersteigt meinen aktuellen Kenntnisstand.

Bin ich hier komplett auf einem Holzweg? Wie handhabt ihr das wenn ihr aktiv Serversysteme administriert?
 
Infrastruktur: Wieso Portainer? In der Regel nutzt man OpenShift / Kubernetes.

Die Fehlersuche in Prod sollte, wenn alles auf http-Requests läuft, auch nicht schwerer als vorher sein. Für die Entwickler in Entwicklung gibt es schon lange direkte Integration in die IDE: https://www.jetbrains.com/help/idea/docker.html . Dazu kommt, man kann jederzeit sich eine Kommandozeile im Container öffnen und wie in einer Linux Bare Metal / VM Umgebung agieren.

Für Security untersucht man die Container (wie alles andere auch, oder?) mit Tools wie z.B. JFrog XRay oder CheckMarx. Aber eher baut man die Images aber von Scratch selbst auf Basis von RedHat Ubi, Alpine, etc.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dermoritz
Sehe ich ähnlich wie @JumpingCat : Produktive Containerumgebungen brauchen einen Orchestrator wie eben Kubernetes. Der Kontrolliert das starten und stopen von containern - je nach Konfiguration. Unabdingbar für produktive Umgebungen.

Alle Dockerfiles sind opensource und du hast volle Kontrolle welches base image (Distribution und Version) benutzt wird.

Heutzutage ist es eher umgekehrt: Infrastruktur die nicht auf Container setzt ist nicht mehr für produktive Umgebungen geeignet (natürlich gibt es Ausnahmen).
 
Naja...

Kubernetes brauchst du nicht, wenn du keine Anforderung an HA hast.

Grundsätzlich bist du aber für die Images verantwortlich die du ausrollst. Entweder direkt oder indirekt. Images einfach so wie Sie sind laufen lassen ist ähm naja gewagt würde ich sagen.

Ich würde mir da immer mein eigenes Image auf Grundlage von eigenen Base Images bauen.

Ist etwas mehr Arbeit aber absolut gerechtfertigt.

Wie du was wann wo genau machst hängt halt stark davon ab was du jetzt genau machen willst.

Docker würde ich aber nicht benutzen.
 
Moin, @JumpingCat, wieso Portainer?, die Aussage halte ich für ein Gerücht, die meisten Anwender die Docker nutzen nutzen meiner Meinung auch Portainer.
 
Verstehe auch nicht so ganz wieso man direkt jetzt auf Orchestrierung springt wenn ich davon spreche einzelne Container in Produktivumgebungen einzusetzen.

Heutzutage ist es eher umgekehrt: Infrastruktur die nicht auf Container setzt ist nicht mehr für produktive Umgebungen geeignet (natürlich gibt es Ausnahmen).
Halte ich für eine sehr gewagte These.
 
  • Gefällt mir
Reaktionen: nebulein, Skysnake und JumpingCat
Teuti schrieb:
die meisten Anwender die Docker nutzen nutzen meiner Meinung auch Portainer.
Die meisten Docker Anwender sind aber keine Admins in Unternehmen.

Snakeeater schrieb:
verschiebt man hier das Vertrauen für Aktualität/Sicherheitsfixes von Maintainern einer Distro/Repo auf eben den Anbieter der Dockerfiles.
Weswegen man vorzugsweise Container Images direkt vom Maintainer nimmt.

Snakeeater schrieb:
Wie handhabt ihr das wenn ihr aktiv Serversysteme administriert?
Die paar Sachen, die per Docker laufen und produktiv im Einsatz sind, sind komplett in einem anderen Netz gekapselt und sind nur per Internet, ggf. mit Einschrankung der Quell-IP erreichbar. Nichts davon ist mission-critical.

Sollte ein Container Image gekapert werden und geht in dem Netz berserk, so be it. Dafür isses getrennt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Naturtrüb
h00bi schrieb:
Weswegen man vorzugsweise Container Images direkt vom Maintainer nimmt.
Verstehe ich nicht ganz die Aussage, der Maintainer eines docker images kann Hinzundkunz sein. Den Maintainern von Debian packages schenke ich da schon deutlich mehr Vertrauen.

Oder missverstehen wir uns hier irgendwo?
 
Snakeeater schrieb:
Verstehe ich nicht ganz die Aussage, der Maintainer eines docker images kann Hinzundkunz sein
Nehmen wir mal den nginx webserver. Installierst du den auf dein System, vertraust du den Damen und Herren von nginx. Warum solltest du denen dann nicht bei Containern vetrauen?
https://hub.docker.com/search?q=nginx
Es gibt zig Anbieter für nginx Images. Bleib einfach bei nginx, denen du ja vertraust, sonst würdest du deren Webserver nicht verwenden.
 
h00bi schrieb:
denen dann nicht bei Containern vetrauen?
https://hub.docker.com/search?q=nginx
Na geht ja das Problem schon los.
Wenn ich auf hub.docker.com was suche, woher soll ich dann wissen, das ich dann das bekomme, was dem von nginx entspricht?
Idealerweise gibts direkt auf nginx.com einen Link da hin oder zumindest Prüfsummen zum verifizieren.

h00bi schrieb:
Es gibt zig Anbieter für nginx Images.
Eben das ist das Problem. Woher soll ich wissen, welcher Anbieter vertrauenswürdig ist.
 
Indem du die Quelle prüfst. Gibt durchaus Leute die versuchen durch ähnliche Namen Schindler zu treiben...
 
  • Gefällt mir
Reaktionen: konkretor und h00bi
Wenn ich auf hub.docker.com was suche, woher soll ich dann wissen, das ich dann das bekomme, was dem von nginx entspricht?
Wenn du prime95 auf CB runterlädst, woher sollst du wissen.....
Wenn du 7zip auf chip.de.....

Es ändert sich bei Containern eigentlich überhaupt nichts gegenüber jedem anderen Softwaredownload.
 
Warum Orchestrierung:
Wenn ich "produktiv" lese, verbinde ich damit ein bestimmte Qualität des Services. z.b. 99,9% Verfügbarkeit oder Reaktionszeit < 1s (was auch immer).

und genau das macht ein orchestrator: fällt ein container aus wird neugestartet oder auf den letzten lauffähigen stand zurückgerollt.

Übersteigt die CPU Last bestimmte Schwellwerte, werden automatisch weitere Container gestartet.

All sowas manuell zu überwachen ist nicht professionell und damit nicht produktiv-fähig IMHO.

(oben sind nur die zwei primitivsten Beispiele später will man vielleicht auch A-B-Deployment etc.)
Ergänzung ()

h00bi schrieb:
Wenn du prime95 auf CB runterlädst, woher sollst du wissen.....
Wenn du 7zip auf chip.de.....

Es ändert sich bei Containern eigentlich überhaupt nichts gegenüber jedem anderen Softwaredownload.

Da ist schon ein Unterschied. Auf Docker hub sind images die vom jeweiligen Hersteller bereitgestellt werden mit "official" gekennszeichnet. Z.b. : ngnix official

Lade am besten nie Software bei Chip oder Computerbase, sondern immer von der offiziellen Seite oder von der Offiziellen Seite auf Github etc - wo auch immer der Hersteller direkt die Software anbietet.
(kleine Relativierung: ich bin vor mehr als 20 Jahren zu Computerbase gekommen weil sie die beste Quelle für Downloads war. heute bin ich eigentlich nur wegen euch hier - der Community :-P)
 
Zuletzt bearbeitet:
Das ist mir schon klar. Ich habe aber den Eindruck dass manche User das Thema absichtlich überkompliziert machen wollen.
Eine Downloadquelle muss jeder für sich selbst als vertrauenswürdig einstufen. Egal ob es ein Softwareinstaller, ein apk Paket oder eben ein Container Image ist.
Die User haben es vermutlich bereits seit mehreren Jahren hinbekommen Programme aus sicheren Quellen zu laden, aber bei Containern soll das plötzlich ein Problem sein.

Wie sind hier immerhin im "Professionelle IT-Netze und -Systeme" Unterforum, da kann man Grundkenntnisse schon voraussetzen.

Wer in diesem Beispiel auf die ersten Container reinfällt und denkt das wären vertrauenswürdige Nextcloud AIO Images (welches übrigens unter nextcloud/all-in-one läuft) der würde auch statt 7zip irgendeine Malware runter laden.

1740671924706.png
 
h00bi schrieb:
Wenn du prime95 auf CB runterlädst, woher sollst du wissen.....
Wenn du 7zip auf chip.de.....
Exakt das gleiche Problem. Deshalb mache ich das nicht.
Warum sollte ich es auch woanders laden, als beim Originalhersteller?
Und wie gesagt, wenn man das schon macht, sollte man den Download auch via Prüfsumme verifizieren.
Ergänzung ()

h00bi schrieb:
Wer in diesem Beispiel auf die ersten Container reinfällt und denkt das wären vertrauenswürdige Nextcloud AIO Images
Es gibt doch Sicherheitsmechanismen die man nutzen könnte. Damit man eben nicht darauf angewiesen ist "aufzupassen". Genau das unterscheidet übrigens professionelle Vorgehensweise von den Downloads dies Lieschen Müller zuhause macht.
 
h00bi schrieb:
Das ist mir schon klar. Ich habe aber den Eindruck dass manche User das Thema absichtlich überkompliziert machen wollen.
Eine Downloadquelle muss jeder für sich selbst als vertrauenswürdig einstufen. ...
bei Containern ist es eben was anderes denn man lädt kein Image runter! Sondern offenen Quellcode. Z.B. bei NgninX: Container Sourcen verlinkt natürlich von der Docker-Hub-seite.

Das image wird dann lokal bei dir gebaut "docker build". und man kann genau sehen was es macht - wenn man will. Das ist eben was ganz anderes als fertig kompilierte Dinge oder Pakete runterzuladen.

Lange Rede kurzer Sinn: Professionelle Serversystem setzen heute mehr oder weniger alle auf Containerisierung (inkl alle Namhaften Cloudanbieter).
 
Zuletzt bearbeitet:
dermoritz schrieb:
Warum Orchestrierung:
Wenn ich "produktiv" lese, verbinde ich damit ein bestimmte Qualität des Services. z.b. 99,9% Verfügbarkeit oder Reaktionszeit < 1s (was auch immer).
Dafür brauchst du keimen Orchestrator. Das schafft docker bzw Podman auch allein auf einem Blech. Zur Not noch Pacemaker und Corosync und du hast auch echtes HA.

Absolut ausreichend wenn du nicht all zu weit horizontal skalieren musst.

Und so ne Kiste mit >100 cores, > 1.5TB RAM und > 400G Netzwerkanbibdung kann dir verdammt viel alleine stemmen. Das reicht für einen Großteil der Leute absolut aus. Vor allem bekommst du damit auch noch nen PB an Flash oder Disk angebunden per JBOD bzw auch mit HW RAID.

Das reicht für sehr sehr sehr viele Leute absolut aus.

Drüber raus kann man sich dann über Kubernetes Gedanken machen. Aber wenn es nicht nötig ist würde ich mir diese Komplexität nicht ans Bein binden und ich hatte auch Hochverfügbarkeitssysteme im Kritis unter meinen Fingern.
 
  • Gefällt mir
Reaktionen: TomH22, konkretor und Snakeeater
Skysnake schrieb:
Dafür brauchst du keimen Orchestrator. Das schafft docker bzw Podman auch allein auf einem Blech. Zur Not noch Pacemaker und Corosync und du hast auch echtes HA.

...
ich habe nie behauptet das irgendwas nicht ausreicht. Ich habe nur gesagt wie professionelle produktiv Umgebungen heutzutage Betrieben werden. Bei geringeren Ansprüchen die auch in Zukunft nicht wachsen sicherlich Overkill.

Hat man aber vor sich mit modernen professionellen Infrastrukturen zu beschäftigen geht kein Weg an einem Orchestrator vorbei - geht man in die Cloud ists Kubernetes.
 
Ähm.... nein falsch. Du kennst aus deiner Bubble heraus nur nichts anderes.

Dein 1s Ausfall kann je nachdem nämlich schon deutlich zu viel sein.

Der klassische Weg wäre zum Beispiel ein echter Hochverfügbarkeitsserver. Da stinkt dein Kubernetes nämlich nicht ohne weiteres gegen an. Wobei ich mir wirklich nicht sicher bin ob man das überhaupt auf das Level gehoben bekommt. Bei HW HA behalte ich ja den kompletten state und muss maximal ein TCP retransmit machen. Das wars dann aber auch.

Bei ner Kubernetes Lösung muss ich eigentlich davon ausgehen, dass das ne REST API hat. Wenn da aber ein Container während der Verarbeitung flöten geht dann muss der Client die Anfrage eigentlich nochmals stellen. Ich bin mir jetzt aber nicht 100% sicher wie das mit HA Load Balancern gelöst wird.

Aber seis drum. Der Ansatz hat auch seine Schwächen und die muss man immer selbst bewerten.

Und ich kann dir sagen, daß ich durchaus Kunden hatte die an ner Container Lösung mit nem Orchestrator starke Zweifel hatten und man denen das erst verkaufen musste. Also Sie gefragt hat ob Sie die Sekunde Ausfall hin und wieder wirklich umbringt und Sie daher sehr viel höhere Kosten akzeptieren würden oder nicht.

Am Ende war es dann immer "gut genug". Aber es ist definitiv NICHT der Goldstandard und die eierlegende Wollmilchsau wie du es hier darstellst.

Und bezüglich Cloud. Auch da ist das nicht zwingend.

Wobei -und das ist jetzt bewusst provokant geschrieben, da du ebenso provokant agierst- wenn man sich eben mit der Cloud zufrieden gibt und keine eigenen georedundanten Datencenter mit eigener redundanter Fiber dazwischen hat, und seinem eigenen redundanten Anschluss ans DE-CIX hat, und einem das was die bieten ausreicht, dann kann man das schon machen aber wirklich professionell ist das dann halt leider doch nicht.

Merkste was?

Und nein das ist jetzt kein geblubber sondern ein Setup das ich selbst betrieben habe.

Am Ende kochen die Cloud-Anbieter nämlich auch alle nur mit Wasser und egal ob Azure oder AWS. Das was die da oft abliefern in meinem Bereich ist absolut Hahnebüchen. Für ne schnelle Hochglanzdemo zu gebrauchen wenn man auf ner grünen Wiese anfängt. Wenn man aber etablierte Services mit Lastenheften portiert fehlen ganz oft essenzielle Enterprise Features out of the Box. Das sieht halt immer und immer wieder nach minimal added value Angeboten aus bei denen noch SEHR viel Funktionalität fehlt.

Und langsam sind die oft genug auch. Aber wie gesagt wenn es den jeweiligen Ansprüchen genügt dann go for it.
 
  • Gefällt mir
Reaktionen: TomH22, konkretor, andy_m4 und eine weitere Person
dermoritz schrieb:
bei Containern ist es eben was anderes denn man lädt kein Image runter! Sondern offenen Quellcode. Z.B. bei NgninX: Container Sourcen verlinkt natürlich von der Docker-Hub-seite.

Das image wird dann lokal bei dir gebaut "docker build". und man kann genau sehen was es macht - wenn man will. Das ist eben was ganz anderes als fertig kompilierte Dinge oder Pakete runterzuladen.

Lange Rede kurzer Sinn: Professionelle Serversystem setzen heute mehr oder weniger alle auf Containerisierung (inkl alle Namhaften Cloudanbieter).
Du vermischst hier Themen miteinander nur um deine fragwürdige These zu untermauern. Das macht vorne und hinten keinen Sinn was du da zusammen trägst und ich finde es sehr schade das der Thread für so etwas missbraucht wird.
 
  • Gefällt mir
Reaktionen: h00bi und Teuti
Zurück
Oben