Docker Container oder bare-metal?, Docker root Path

[schwimmcoder]

Heyho,

ich bin gerade dabei, mich in Docker einzuarbeiten, zum hautpsächlich aus persönlichem Interesse für meinen vServer, aber auch, weil es später im Berufsleben nützlich sein kann, nicht komplett ins kalte Wasser zu springen, wenn ich Docker dann nutzen muss.

Aktuell habe ich alles, was installiert ist, bare-metal, also direkt im OS (Debian) installiert und würde gerne vieles in Docker umziehen, alleine zum Üben.

Bei mir im Kopf schwebt der Gedanke, das es nicht sinnvoll ist, alles in einen Container zu verlagern, denke da an NGINX als Reverse Proxy, Crowdsec als Firewall, Wireguard, etc. Also Dienste, die entweder für den Server essentiell sind oder wie Wireguard mit dem Kernel/Hardware verzahnt sind. Wie seht ihr das?

Den Docker Root Path würde ich dann auch ändern wollen, von /var/lib/docker zu sowas wie /data/docker, kann man das so machen oder eher nicht?

Hoffe, ihr könnt meine wirren Gedanken etwas ordnen

 

[madmax2010]

Bei mir im Kopf schwebt der Gedanke, das es nicht sinnvoll ist, alles in einen Container zu verlagern, denke da an NGINX als Reverse Proxy, Crowdsec als Firewall, Wireguard, etc. Also Dienste, die entweder für den Server essentiell sind oder wie Wireguard mit dem Kernel/Hardware verzahnt sind. Wie seht ihr das?

Grundsaetzlich: Was auch immer im jeweiligen Szenario Sinn ergibt. Wenn dein Ziel ist moeglichst viel zu lernen, dann mach alles in Containern. Der hardware Kram geht in containern genau so gut wie im Host system.

Den Docker Root Path würde ich dann auch ändern wollen, von /var/lib/docker zu sowas wie /data/docker, kann man das so machen oder eher nicht?

Habe ich noch nie gemacht. Persistente Volumes lege ich immer nach /opt. Wo docker die images cached ist mir komplett egal. Zur not mappe ich halt nochmal 100GB auf die partition. Das man mal in den Ordner schaut, ist selten

 

[NJay]

Bei mir im Kopf schwebt der Gedanke, das es nicht sinnvoll ist, alles in einen Container zu verlagern, denke da an NGINX als Reverse Proxy, Crowdsec als Firewall, Wireguard, etc. Also Dienste, die entweder für den Server essentiell sind oder wie Wireguard mit dem Kernel/Hardware verzahnt sind. Wie seht ihr das?

Du sollst auf jeden Fall nicht alles in EINEN container packen, sondern alles in einzelne

Ansonsten kommt es halt immer an, was du erreichen willst. Viele wege fuehren nach Rom. Aber wenn du sehr viel auf einem VServer betreibst, kann es durchaus Sinn machen es per Container zu trennen.

Den Docker Root Path würde ich dann auch ändern wollen, von /var/lib/docker zu sowas wie /data/docker, kann man das so machen oder eher nicht?

Kann man machen, aber wozu?

 

[schwimmcoder]

Grundsaetzlich: Was auch immer im jeweiligen Szenario Sinn ergibt.

Nur nach welchen Kriterien kann ich das später beurteilen? Geschwindigkeit? Flexibilität? Sicherheit wohl eher nicht. Klar, zum Lernen kann ich alles in einen Container jagen, was geht. Nur ob das sinnvoll ist, denke ich halt weniger. Oder ist das wirklich egal, eher eine Sache von persönlicher Preferenz des Admin?

Ergänzung (28. August 2023)

Du sollst auf jeden Fall nicht alles in EINEN container packen, sondern alles in einzelne

Klar, war etwas unglücklich formuleirt, ein Container pro Anwendung

Ansonsten kommt es halt immer an, was du erreichen willst.

Möchte halt mittelfristig vieles auch selbst hosten und halt Docker lernen, im Grunde werden da dann Anwendungen quer Beet laufen, Baikal, ne eigene kleine Website, BookStack, Compiler, RSS Feed, and so on.

Und da war für mich der Gedanke, wann ist es sinnvoller, es in einen Container zu packen? Oder anders ausgedrückt, gibt es Aspekte, durch die es unsinnig wird, eine Anwendung in einem Container zu packen?

 

[ReignInBlo0d]

Nur nach welchen Kriterien kann ich das später beurteilen? Geschwindigkeit? Flexibilität?

Die eine alles treffende Faustregel gibt es da nicht.
Ich würde allerdings nicht ungezwungen zu viel in einen Container packen.
Beispielsweise könnte es ja vorkommen, dass du mal deinen NGINX updaten willst - du willst in diesem Fall eigentlich ja genau eine Komponente neu bauen und updaten; es wäre umgekehrt total umständlich, deine anderen Anwendungen, die hinter dem NGINX liegen, nochmals mit in das neue Image einzubacken, obwohl sich daran gar nichts geändert hat.

Stattdessen kannst du docker-compose und entsprechende Manifeste nutzen, um Container-Gespanne und -Abhängigkeiten logisch zusammenzufassen. Dann hast du Flexibilität und Nachvollziehbarkeit (kann noch verstärkt werden indem man die Manifeste per Git versioniert).

 

[schwimmcoder]

Die eine alles treffende Faustregel gibt es da nicht.

Hatte auf Anhaltspunkte gehofft, um halt für später selbst Entscheidungen zu treffen. Scheint aber eher ein "Ist eigendlich egal, funkt beides gleich gut" Ding zu sein^^

Ich würde allerdings nicht ungezwungen zu viel in einen Container packen.
Beispielsweise könnte es ja vorkommen, dass du mal deinen NGINX updaten willst - du willst in diesem Fall eigentlich ja genau eine Komponente neu bauen und updaten; es wäre umgekehrt total umständlich, deine anderen Anwendungen, die hinter dem NGINX liegen, nochmals mit in das neue Image einzubacken, obwohl sich daran gar nichts geändert hat.

Ich hätte halt die offiziellen Images verwendet soweit verfügbar, wo eig jede Anwendungsfall einen eigenen Container hat, NGINX wäre dann ein Container, FreshRSS einen eigenen, etc. Und wenn ich den NGINX Container update, sollten die anderen Container doch nicht betroffen sein? (Von der möglichen Minimalen Nicht-Erreichbarkeit oder Anpassungen in der NGINX Config mal abgesehen)

 

[LieberNetterFlo]

Ich würde für jede Anwendung einen Container erstellen Stichwort: Microservices. Performanceverluste gibts da eigentlich nicht groß. Ich würde alles reinstecken.

Die Container laufen unabhängig voneinander.

Vielleicht willst du gleich von Beginn an anstatt auf Docker auf Podman setzten? Außer du machst gleich ganze Stacks, dann ist Dockerm it docker-compose einfacher zu lernen.

 

[Raijin]

In der Regel nutzt man für jeden Service einen Container. Sollte eine Anwendung als solche mehrere Komponenten umfassen wie zB Websever, Datenbank und dergleichen, bekommt jede Komponente einen eigenen Container und die Container selbst greifen entsprechend über die interne IP des Containers zu. Dadurch werden die Services gekapselt und man kann sie unabhängig voneinander aktualisieren oder ggfs sogar ersetzen (sofern kompatibel versteht sich).

 

[Firefly1337]

Ein weiterer Punkt wäre noch Abhängigkeiten der jeweiligen Anwendungen. Also zum Beispiel ein Programm, das Java (oder Python/PHP/Perl/Go/...) benötigt, um ausgeführt zu werden.

Das will man sich nicht unbedingt im Host OS installieren und müllt das System nur unnötig zu, ganz zu schweigen von Sicherheitsbedenken oder Kompatibilitätsproblemen untereinander (verschiedene Programme brauchen evtl. verschiedene Versionen).

Dann lieber abgekapselt im Container, den man upgraden oder eben hinterher wegwerfen kann.

 

[NJay]

Nur nach welchen Kriterien kann ich das später beurteilen? Geschwindigkeit? Flexibilität? Sicherheit wohl eher nicht. Klar, zum Lernen kann ich alles in einen Container jagen, was geht. Nur ob das sinnvoll ist, denke ich halt weniger. Oder ist das wirklich egal, eher eine Sache von persönlicher Preferenz des Admin?

Geschwindigkeitsunterschiede gibt es eigentlich keine, denn ein Container ist ja quasi nur ein Prozess mit ein paar besonderen Kernel flags (super vereinfacht gesagt).

Teilweise gibt es etwas Performanceverluste was Disk-IO angeht, aber das wird eher Relevant, wenn du eine dicke Datenbank betreibst, nichts, was man Zuhause hast.

Ich packe eigentlich alles, was ich als Server betreibe in Container. Die einzige Ausnahme ist Wireguard, aber hier habe ich auch einen eigenen VServer und alles in Ansible definiert, der Server ist also auch super einfach zu verwalten.

Solange Anwendungen irgendwie sinnvoll in Containern betreibbar sind, betreibe ich sie auch so. Aber wenn es keine offiziellen oder zumindestens weit verbreitete Images gibt, dann containerisiere ich sie nicht selbst, das ist mir dann zu viel Aufwand. Letzteres gilt natuerlich nicht fuer Code den ich selbst entwickelt habe, den containerize ich natuerlich auch selbst.

 

[schwimmcoder]

Vielleicht willst du gleich von Beginn an anstatt auf Docker auf Podman setzten? Außer du machst gleich ganze Stacks, dann ist Dockerm it docker-compose einfacher zu lernen.

Hat Podman sonst Vorteile? Docker-compose würde ich definitiv nutzen, Docker Stack wohl nicht, hätte aktuell keinen Fall, wo ich mehrere Container der gleichen Anwendung brauchen könnte.

Dadurch werden die Services gekapselt und man kann sie unabhängig voneinander aktualisieren oder ggfs sogar ersetzen (sofern kompatibel versteht sich).

Ein weiterer Punkt wäre noch Abhängigkeiten der jeweiligen Anwendungen. Also zum Beispiel ein Programm, das Java (oder Python/PHP/Perl/Go/...) benötigt, um ausgeführt zu werden.

Das will man sich nicht unbedingt im Host OS installieren und müllt das System nur unnötig zu, ganz zu schweigen von Sicherheitsbedenken oder Kompatibilitätsproblemen untereinander (verschiedene Programme brauchen evtl. verschiedene Versionen).

Daran hab ich ja bei den Containern noch garnicht gedacht, so langsam leuchtet es mir ein. Eigendlich alles in Container, schaden tuts wohl nicht.

Ich packe eigentlich alles, was ich als Server betreibe in Container. Die einzige Ausnahme ist Wireguard, aber hier habe ich auch einen eigenen VServer und alles in Ansible definiert, der Server ist also auch super einfach zu verwalten.

Wireguard, weil es den Kernel nutzt oder aus anderen Gründen?

Danke euch aber schonmal für alle eure Erklärungen und Ausführungen! Wirrungen im Kopf sind weniger geworden

 

[NJay]

Wireguard, weil es den Kernel nutzt oder aus anderen Gründen?

Ich verstehe nicht, was du damit meinst. Sobald du nicht die userspace Variante von Wireguard nutzt nutzt sie direkt die Kernel Variante, egal ob Docker oder nicht. Liess dich mal ein wie Container funktionieren.

Ich habe einfach einen getrennten Wireguard Server, weil es eine fuer mich sehr kritische Komponente ist. Da sonst nichts anderes auf dem servr laeuft und ich die Konfiguration komplett in Ansible habe, gaebe es keinen Vorteil von einem Container fuer mich.

 

[schwimmcoder]

Ich verstehe nicht, was du damit meinst. Sobald du nicht die userspace Variante von Wireguard nutzt nutzt sie direkt die Kernel Variante, egal ob Docker oder nicht. Liess dich mal ein wie Container funktionieren.

Und ich dachte, das ebend die, nennen wir es Abkapselung, Probleme mit Wireguard verursacht. Hab an ehesten bei Containern ne Sandbox im Kopf, wo jede Anwendung direkt auf dem OS läuft, aber abgeschirmt. Von Prinzip wie ein Snap Package unter Ubuntu, so gaanz grob. Und da gibts ja auch so gewisse Probleme, was die Abkapselung betrifft.

 

[Skysnake]

Nur nach welchen Kriterien kann ich das später beurteilen? Geschwindigkeit? Flexibilität? Sicherheit wohl eher nicht. Klar, zum Lernen kann ich alles in einen Container jagen, was geht. Nur ob das sinnvoll ist, denke ich halt weniger. Oder ist das wirklich egal, eher eine Sache von persönlicher Preferenz des Admin?

Es gibt einige Gründe warum man etwas nicht in Container packt

1. Die Lizenzbestimmungen erlauben es nicht
2. Die Admins sind davon überfordert
3. Du hast nur eine einzelne Instanz die sehr stark von configfiles dominiert wird und drölf Millionen Einstellungen hat. Also eine legacy Anwendung die ohne Container im Kopf erstellt wurde
4. Wenn du kein Podman nimmst dann ist systemd Paint in the ass im Container. In dem Fall kann allein das Vorhandensein eines funktionierenden systemd Frameworks Gold wert sein
5. Du hast das klassische Anfangswertproblem. Also z.b. dein docker braucht Infrastrucktur um zu laufen. Also z.b. nen ntp Server, das usw. Da gibt es immer nen Punkt wo du um Container mit Kubernetes oder Docker Swarm zu starten die Sachen selbst brauchst.
6. Du kannst gerade beim Netzwerk viel Performance liegen lassen bei manchen Sachen, weil du keine SharedMemory Kommunikation mehr hast

Und da war für mich der Gedanke, wann ist es sinnvoller, es in einen Container zu packen? Oder anders ausgedrückt, gibt es Aspekte, durch die es unsinnig wird, eine Anwendung in einem Container zu packen?

Wenn du durch das Containerisieren den State nicht vernünftig gekapseltst bekommst.

Also z.b. du brauchst nen shared Filesystem um den Storage für deine Container bereit zu stellen damit die HA fähig sind. Im Falle von SoftwareDefinedStorage kann das selbst wieder nen Container sein, aber da beißt sich irgendwann die Katze in den eigenen Schwanz und man muss übelste Verrenkungen machen damit wäre tut.

Ansonsten ist alles mit GUI eher schwierig in Cobtainer zu packen.

Ssh in Container ist ebenfalls ein NoGo. Und privileged Container sind auch ganz schlecht.

Startup von Containern ist teils auch langsamer als von bare metal weil die autoconfig Sachen durchlaufen bei jedem Start und checken ob das jetzt schon passiert ist oder nicht.

Die absoluten basic Sachen würde ich nicht in Container packen. Storage, LDAP, ntp Server, DNS und DHCP.

Ansonsten schau dir CoreOs an und was draußen wurde. Da war alles ein Container. Das war/ist teils einfach abartige Pain in the ass.....

Hat Podman sonst Vorteile? Docker-compose würde ich definitiv nutzen, Docker Stack wohl nicht, hätte aktuell keinen Fall, wo ich mehrere Container der gleichen Anwendung brauchen könnte.

Stack hilft dir auch bei einer Instanz. Du hast damit HA.

Podman ist halt deamon less und erlaubt ein praktikables systemd im Container.

Am Ende ist es halt wichtig das richtige Environment für eine Aufgabe zu nutzen. Sei dies nun

Podman
Docker
Apptainer/Singularity
Kubernetes
CharlieCloud
OpenShift
...

 

[ErsterSelbstbau]

Beispielsweise könnte es ja vorkommen, dass du mal deinen NGINX updaten willst - du willst in diesem Fall eigentlich ja genau eine Komponente neu bauen und updaten; es wäre umgekehrt total umständlich, deine anderen Anwendungen, die hinter dem NGINX liegen, nochmals mit in das neue Image einzubacken, obwohl sich daran gar nichts geändert hat.

Dass das umständlich wäre kann ich so nicht nachvollziehen.
Ist der Ansatz nicht, dass man einen Dockerfile schreibt welcher auf Befehl das Image erstellt?
Sollte man mal in einem Container eine andere Version einer Software benötigen, schreibt man das Dockerfile entsprechend um, führt den build-Befehl aus und hat ein neues, reproduzierbares Image. Das, also der Container als Softwarepaket, welcher alle Software enthält die man sonst einzeln in das BS installiert hätte, ist doch - meines Wissens - gerade ein wesentlicher Vorteil von Containern.

 

[ReignInBlo0d]

@ErsterSelbstbau grundsätzlich hast du recht und in den meisten Fällen dürfte das auch klappen.
Problematisch kann es dann werden, wenn deine im Image enthaltenen Services Abhängigkeiten haben, die z.B. in unterschiedlichen Versionen vorliegen müssen oder anderweitig in Konflikt stehen. Innerhalb des Containers teilen sie sich das Filesystem usw.
Diese Isolierung bekämst du im Zweifel in einem aufgeteilten Setup von deinen Containern geschenkt, ohne dir darüber Gedanken machen zu müssen.
Man könnte da sicher argumentieren, dass ja dann für n Container in Summe n Linuxe (?) als OS liegen. Aber die sind so klein und anspruchslos, dass das nicht ins Gewicht fallen sollte.

 

[ErsterSelbstbau]

im Image enthaltenen Services Abhängigkeiten haben, die z.B. in unterschiedlichen Versionen vorliegen müssen oder anderweitig in Konflikt stehen. Innerhalb des Containers teilen sie sich das Filesystem usw.
Diese Isolierung bekämst du im Zweifel in einem aufgeteilten Setup von deinen Containern geschenkt,

Ach so - das heißt, Software die in einem BS (oder im "Container-BS") Probleme bezüglich Kompatibilität aufweist, könnte eventuell auf mehrere Container verteilt doch zusammenarbeiten.
So herum habe ich das noch nie betrachtet - wieder was gelernt. Danke! 👍