Container als Produktivlösung

@Snakeeater Ich gehe insbesondere auf deine Fragen/ Anmerkungen bzgl Sicherheit in deinem ersten Beitrag ein: Bei Containern hat man jederzeit die volle Kontrolle über jedes Detail ( von Distribution über jede Version von Komponenten). Wie ein anderer schrieb ist es durchaus üblich und sinnvoll die bereitgestellten Dockerfiles insbesondere für den Produktiveinsatz den eigenen (Sicherheits)Bedürfnissen anzupassen.

Ich kann nur aus meiner Erfahrung sagen, dass insbesondere Systeme mit sehr hohem regulatorischen und Sicherheitsanspruch (Banken, Versicherungen, Gesundheit) ausschließlich in Containerumgebungen betrieben werden.

Das heiß wie schon mehrfach erwähnt, dass es keine Alternativen gibt. Ich habe lediglich dein Begriff "produktiv" mit "professionell" verbunden - für mich kaum trennbar. und ich schildere meine Erfahrung aus meinem Beruf.

nicht professionell betreibe ich einen Mincraft Server einfach als VM in der Cloud - da es so schön einfach ist einzurichten. Würde ich ihn professionell betreiben wollen - zero downtime etc - würde ich ihn containerisieren.

Bitte nächstes Mal konkreter beschreiben was an meinen Posts für dich eine These war und was davon fragwürdig. Wahrscheinlich hab ich mich nur unverständlich ausgedrückt - das passiert oft. Aber das betreiben von produktiven Umgebungen ist mein täglich Brot. In den letzten Jahren werden in meinem Umfeld kaum noch reine VMs betrieben als wird containerisiert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: JumpingCat
Du versteigst dich da noch immer. Wie gesagt mit VMs und insbesondere Containern kannst du nur HA machen. Du hast also bei jedem Restart in der Regel eine gewisse Nichtverfügbarkeit.

Es mit HA Servern, bzw eigentlich müsste man von FaultTolerant Servern sprechen ist das nicht mehr der Fall. Da kann dir tatsächlich einfach ein Blech wegsterben und du merkst genau 0 davon.

Aber das sind halt die feinen Unterschiede zwischen SelfHealing/Residenzen, HighAvailability und FaultTolerance. Ich musste das einem staatlichen Kunden auch mal erklären das er nur HA gekauft hat und kein FaultTolerance...

Und wie gesagt FaultTolerance bekommst du mit Containern nicht realisiert. Das ist unmöglich

Deswegen komm mal von deinem hohen Ross runter. Professionell ist das was die Anforderungen erfüllt ohne mit Atombomben auf Spatzen zu schießen.
 
  • Gefällt mir
Reaktionen: TomH22
ich glaube du weißt nicht wie große Rechenzentren Laufen und hast glaube auch noch nie von Chaosmonkey gehört. (Das ist ein ein Programm was Prozessen oder ganzen VM den Stecker zieht - warum: es macht alles stabiler)
--> Schau dir mal an we Netflix und andere FaultTollerance hinbekommen.
https://medium.com/@abhishekv965580...ey-transformed-system-resilience-59082412591e

Netflix und Containermanagement: https://www.datacenterknowledge.com...ontainer-management-system-is-now-open-source

Netflix ist nur ein Beispiel.
Also die größten / stbilsten und Fehlertolerantesten Systeme laufen in Containern.

Kann man auch leicht kleine Server oder Apps im Container betreiben - ohne QOS garantien, ohne Orchestrator: ja

Haben Container nachteile: Ja - hauptsächlich Overhead. Blankes Blech oder VM is wahrscheinlich schneller. Aber heutzutage ist nicht CPU und RAM der teuer ist, sondern Arbeitskraft. Du willst möglichst wenig Arbeitskraft brauchen um große System zu betreiben: kein Admin muss mehr vor Ort kommen wenn neues Blech geliefert wird. Ein Dienstleister schließt blech an, und es laufen Skripte, fertig.
Muss man das toll finden?: Nein
Wird ops immer mehr zu einer Art programmieren: ja - Stichwort GitOps
Werden viele altgediente Admins von ihren Arbeitgebern im Stich gelassen: ja (sehr ich leider in letzter Zeit immmer öfter)

(ich spreche allein aus persönlicher Erfahurng aus meinem Beruf: vor 20 JAhren Bare MEtal, Danach Esxi/VM und heute Cloud und Container)

Ich rate jedem sich mit dem Thema zumindest mal persönlcih zu beschäftigen.

Ich steigere mich nirgends rein - versuche nur die Realität in der ich mich beruflich bewege zu Erläutern. Was man mit den Infos mach sei jedem selbst überlassen.
 
dermoritz schrieb:
Haben Container nachteile: Ja - hauptsächlich Overhead. Blankes Blech
Container haben nahezu null Overhead. Nur so btw. Daher merkst du an sich keinen Unterschied.

Wenn brauchen Sie nur etwas mehr Speicher bzw Plattenplatz für das Image bzw den Container.

dafür kann ein Container aber auch z.b. bei Python oder Matlab Anwendungen deutlich schneller sein, weil der IO in großen Blöcken kommt für das Image und dann der kleine IO für die Libs lokal läuft. Je nachdem sogar im RAM.
dermoritz schrieb:
oder VM is wahrscheinlich schneller.
nö, nen Container auf bare Metal ist wahrscheinlich schneller als ne VM.
dermoritz schrieb:
Aber heutzutage ist nicht CPU und RAM der teuer ist
das ist doch wieder eine totale Verallgemeinerunh die so generell nicht gilt. Bei mir kostet das Blech deutlich mehr als die Leute die es betreiben. Vor allem wenn du die Software noch dazu nimmst.

Paar hundert bzw tausend Server kosten ne ganze Stange Geld.
dermoritz schrieb:
sondern Arbeitskraft. Du willst möglichst wenig Arbeitskraft brauchen um große System zu betreiben:
Du brauchst so viel Arbeitskraft wie du halt brauchst. Das hat aber nicht viel mit der Anzahl der Systeme zu tun. Ob ich jetzt tausend oder zweitausend Server betreibe macht kaum nen Unterschied. Was nen Unterchied macht ist die Anzahl der einzigartigen Configs. Bzw Anzahl der Anwendungsstacks.

dermoritz schrieb:
kein Admin muss mehr vor Ort kommen wenn neues Blech geliefert wird.
Das stimmt aber schon sehr sehr sehr lange. Light Put Management hat soooooo nen Bart....

dermoritz schrieb:
Wird ops immer mehr zu einer Art programmieren: ja -
Nennt sich DevOps und Infrastructure as a Code und ist auch schon Jahrzehnte alt.

dermoritz schrieb:
Ist nur nen Werkzeug und konnte man such schon mit SVN oder bitbucket machen und hat man auch gemacht. GIT hat seine Vorteile aber es hat nichts komplett neues gebracht.

dermoritz schrieb:
Werden viele altgediente Admins von ihren Arbeitgebern im Stich gelassen: ja (sehr ich leider in letzter Zeit immmer öfter)
Naja, man muss sich halt weiterbilden. DevOps bzw DevOpsSec. Den Turnschuh Admin braucht man nicht mehr. Wenn dann nen Service Techniker, das hat mir Admin aber nichts zu tun.

dermoritz schrieb:
(ich spreche allein aus persönlicher Erfahurng aus meinem Beruf: vor 20 JAhren Bare MEtal, Danach Esxi/VM und heute Cloud und Container)
Ich auch. Zwar nur aus 15 Jahren, aber viel Legacy übernommen. Die Werkzeuge haben sich geändert, aber an den Prinzipien nicht so viel.

So und nü?

Wieviel Systeme betreibst du denn so?

100, 200, 300 oder tausend?

Und btw les bitte mal was der Unterschied zwischen HA und FaultTolerance ist. Mit Containern kannst du kein FaultTolerance machen und das ist die Königsdisziplin und ist schon verdammt alt.

HA reicht halt nur oft genug, weil die Clients auch noch entsprechend gestaltet werden. Für nen Börsensystem wäre das aber zum Beispiel nicht ausreichend.

Und wie gesagt, 1s Ausfall ist teils schon zu viel. Da machst du dann nichts mehr. Vor allem nicht wenn der Client kein Replay machen darf sondern immer jede Anfrage beantwortet werden muss. Aber dad ist halt wahrscheinlich einfach außerhalb deiner Bubble.
 
Da sin wir uns ja einig. Super. Container sind ein guter und etablierter Standard für produktivumgebungen - das war ja deine Frage :-).

"Und btw les bitte mal was der Unterschied zwischen HA und FaultTolerance ist. Mit Containern kannst du kein FaultTolerance machen und das ist die Königsdisziplin und ist schon verdammt alt."

Lies mal die Artikel die ich verlinkt hab übner Netflix und deren Containermanagement. Netflix beherrscht diese Königsdisziplin. Inzwische aber auch andere - mit Containern.

auch zum Thema: Fault-Tolerant Containers Using NiLiCon

Ich danke für die angeregte Diskussion! Ich glaube gemau das wolltest initiieren :-)
 
Interessant. Der Performance Hit ist aber natürlich heftig. Leider funktioniert der Link nicht so das ich nicht das ganze Paper lesen kann.

Am Ende wird da aber wohl nen Software Layer eingezogen. Aber trotzdem spannend, dass das geht.

Geht das auch vernünftig für Datenbanken? Da hätte ich tatsächlich für ne MariaDB nen Anwendungsgsfall.

Ich hoffe du teilst da aber meine Ansicht, dass das jetzt eher weniger mit Containern an sich zu tun hat sondern trotz Container geht.

Ich kann nur leider das Paper nicht lesen um mich zu den Details auszulassen...
 
Ich hau die Frage nochmal hier rein, da sie wohl passt.

Wenn ich etwas wie Portainer oder Dockge nutzen möchte um Container einfacher zu verwalten. Muss ich dann die Container alle auf einer VM laufen haben? Oder kann ich damit auch remote Container steuern?

Wie gesagt wir nutzen eigentlich wenig Container und haben dafür keine Infrastruktur und ich überlege gerade wie man das relativ einfach umsetzen kann, bzw. was es dafür bedarf.
 
Podman ist wie docker single host. Bei diesem Dockge bin ich mir nicht ganz sicher, würde aber auch von single hist ausgehen.

Was du brauchst ist ein Orchestrator wie Swarm oder Kubernetes.

Wobei die mehr liefern als du willst.

Eventuell reicht auch Ansible oder so.
 
Okay das heißt ich brauch "Portainer" auf jedem Host mit Containern. Got it.
 
Also ist schon ziemlich Kuddelmuddel, ich spiele immer noch mit Dockge rum und bin momentan dabei vom simplen docker-compose up -d zu rootless podman zu wechseln. Heute hab ich Quadlets entdeckt.
Ich bin mir nicht sicher ob sich das noch it Dockge irgendwie überwachen lässt, mal schauen. Aber rootless podman ist schon eine Hausnummer zumindest auf Debian.
 
Zurück
Oben