Faustregel: Software, die zwangsläufig in einem "Container" laufen will, gehört da auch hin... also in den Container.
… der in einen weiteren Container gepackt wird, so dass kein Ausbruch/keine Verbindung zwischen "Originalcontainer" und Host möglich ist, die man nicht 100% kontrolliert (sowohl vom technischen als auch vom fachlichen Verständnis).
… der in einen weiteren Container gepackt wird, so dass kein Ausbruch/keine Verbindung zwischen "Originalcontainer" und Host möglich ist
Aus Dockercontainern auszubrechen ist ein beliebter Sport unter Sicherheitsforschern. Wie dem auch sei: Wer das dringende Bedürfnis hat, eine bestimmte Software zu nutzen, aber ihr nicht hinreichend über den Weg traut, so dass er nach möglichst komplizierten Möglichkeiten sucht, sie in Ketten zu legen, der sollte eventuell noch mal 2-3 Schritte zurückgehen und ganz wesentliche Fragen an sich selbst stellen.
(Zum Beispiel: Traue ich mir zu, einen Internetserver zu administrieren? Sollte ich genau diese Software nutzen? ...)
Wenn Container dann nur rootless Podman. Allerdings ziehe ich auch uncontainerisiertes vor 
Wundert mich, dass hier so viele Leute unterwegs sind, die Docker so kritisch sehen. Ich sehe das grundlegend anders und stehe Docker sehr positiv gegenüber:
- Es löst das "aber auf meinem Rechner läuft es" Problem
- Es löst das Problem der Notwendigkeit von unterschiedlichen Versionen der gleichen Sache (PHP, Datenbanken u.v.m.)
- Es baut genial aufeinander auf, man kann einen anderen Container als Basis für eigene Container nehmen, das "schon fast da ist".
- Es ist ressourcensparend.
- Auch und gerade komplexe Systeme sind damit einfach umsetz- und weitergebbar: man sehe sich nur mal ein docker-compose von Mailcow an. Viel Spaß, da alles manuell installieren zu wollen.
- Updates sind mit neuen Containerversionen einfach realisierbar, die Updates auch teil oder komplett automatisierbar.
- Durch einfache Updates erhöht sich die Sicherheit (insbesondere wenn automatisiert), da damit Schwachstellen nicht lange online rumhängen.
- Container sind KEINE Blackbox: jede(r) kann in die Dockerfiles und docker-compose Files reinschauen. Insbesondere Anpassungen an compose Files sind quasi immer nötig.
- Fehler, die nicht rückgängig gemacht werden können, können kaum passieren. Schlicht die letzte funktionierende Version nochmal pinnen und ziehen.
- Container internes Networking (man kommt von außen nicht ran) und die Integration eines Proxy Containers ermöglicht es, auch ohne Firewall einen DB Port nicht online zu haben.
Ich finde, daß Docker (bzw. das Containerprinzip an sich) die beste Sache seit geschnitten Brot ist - insbesondere für Linux. Ich habe >20 Jahre den "manuellen Weg" gemacht und darauf absolut keine Lust mehr. HowTos manuell nachstricken? Ne danke. Da kommt auch kein "besseres" oder "sichereres" System dabei raus.
Bevor ich mich nicht darauf eingelassen hatte, dachte ich das wäre zu umständlich und unnötig. Aber wenn der Groschen mal gefallen ist, wird man nichts anderes mehr machen wollen.
Ja, man braucht, wenn man Container aus dem Hub verwendet Vertrauen (kann aber wie gesagt immer auch nachsehen was passiert), aber das ist doch mit allen Open Source Programmen so (man schaue sich nur das "xy" Paket Unterwanderungsthema mal an).
EDIT: Ne Ergänzung noch... Für mich gilt: wenn etwas NICHT als Docker Container installierbar ist, dann werde ich es nicht in Betracht ziehen.
- Es löst das "aber auf meinem Rechner läuft es" Problem
Übersetzt: "Es löst das 'Problem', dass Entwickler schlechter Software zu faul für Unittests und/oder CI sind."
- Es löst das Problem der Notwendigkeit von unterschiedlichen Versionen der gleichen Sache (PHP, Datenbanken u.v.m.)
Übersetzt: "Es löst das 'Problem', dass Entwickler schlechter Software arrogante Schnösel sind, die glauben, außer ihrer Software müsste auf einem Zielsystem nix laufen."
- Es baut genial aufeinander auf, man kann einen anderen Container als Basis für eigene Container nehmen, das "schon fast da ist".
- Es ist ressourcensparend.
Übersetzt: "Es stellt eine unnötig komplizierte Infrastruktur bereit, die sich mit weit weniger RAM und Plattenplatz auch mit chroot und shared libraries abbilden ließe."
- Auch und gerade komplexe Systeme sind damit einfach umsetz- und weitergebbar: man sehe sich nur mal ein docker-compose von Mailcow an. Viel Spaß, da alles manuell installieren zu wollen.
Mailcow oder, wie ich es nenne, zehn Minuten Handarbeit. Keine Ahnung, warum das jetzt ausgerechnet in einem Container besser aufgehoben wäre als nativ im Betriebssystem, wo es anständig (kernelseitig!) gekapselt wird und trotzdem performant und ressourcensparend ist.
- Updates sind mit neuen Containerversionen einfach realisierbar, die Updates auch teil oder komplett automatisierbar.
Übersetzt: "Container ignorieren Sicherheitspatches des Betriebssystems, aber das macht ja nichts, weil man mit ihnen auf die viel besseren Sicherheitspatches von Drittanbietern angewiesen sein kann." (?)
- Durch einfache Updates erhöht sich die Sicherheit (insbesondere wenn automatisiert), da damit Schwachstellen nicht lange online rumhängen.
Dafür gibt es übrigens auch Lösungen, die ganz ohne Container funktionieren. Man nennt sie... Moment, ich hab's gleich... Dings... ach ja: Systemupdates. (Wenn Docker hier ein Problem für dich löst, weil du dich dazu entschieden hast, ohne technische Notwendigkeit auf einem Internetserver ein System einzusetzen, das keine schnellen Sicherheitsupdates bekommt, dann würde ich ja bei der Problemlösung woanders ansetzen als beim "Container"...)
Insbesondere Anpassungen an compose Files sind quasi immer nötig.
Übersetzt: "Man hat mit Containern mehr Handarbeit als ohne sie."
- Fehler, die nicht rückgängig gemacht werden können, können kaum passieren. Schlicht die letzte funktionierende Version nochmal pinnen und ziehen.
Das kann jeder gute Paketmanager. Dein System hat keinen guten Paketmanager? Dann siehe zwei Punkte weiter oben.
- Container internes Networking (man kommt von außen nicht ran) und die Integration eines Proxy Containers ermöglicht es, auch ohne Firewall einen DB Port nicht online zu haben.
Übersetzt: "Container wie Docker erfinden Solaris-Zonen, FreeBSD-Jails und/oder einfaches UNIX-chroot mitsamt loopback device noch mal neu, nur halt schlechter."
Ich finde, daß Docker (bzw. das Containerprinzip an sich) die beste Sache seit geschnitten Brot ist - insbesondere für Linux.
Weil Linux das letzte System war, das noch keine mindestens gleichwertige Lösung im Kernel hatte? 
Für mich gilt: wenn etwas NICHT als Docker Container installierbar ist, dann werde ich es nicht in Betracht ziehen.
Prima. Dann bin ich ja vor deinen Bugreports sicher. 
Pffff...
Da dachte ich, die Luft wäre raus, aber das Trollen geht weiter.
Ich möchte dringend davon abraten, an einer Diskussion mit Fremden im Internet dahingehend teilzunehmen, dass man sie des Trollens bezichtigt.
Ich würde mir wünschen,
- Serveradmins hörten endlich auf, das Hosten einer fremden Blackbox ("Dockercontainer") auf einem frei im Internet verfügbaren Server für eine gute Idee zu halten, und
- Ent(jaja)wickler hörten endlich auf, ihre Software so unübersichtlich wachsen zu lassen, dass Docker die einzige "dokumentierte" Installationsweise ist. Erstens wegen 1., zweitens, weil auf hinreichend vielen Betriebssystemen gar kein Docker läuft.
Faustregel: Software, die zwangsläufig in einem "Container" laufen will, gehört da auch hin... also in den Container.
Geht mir auch regelmässig auf die Nerven. Ja, sicherlich gibt es einige Fälle, bei denen die Containisierung durchaus "nett" ist, vor allem bei irgendwelchen Python oder Ruby-Anwendungen, die bei der kleinsten Versionsänderung kaputt sind.
Vor einigen Wochen habe ich mal versucht, den Joplin Server, den es nur als Docker-Image gibt, für's AUR unter Arch zu paketieren. nodejs-Foo ist ja auch die Hölle (aus Admin-Sicht).
nodejs-Foo ist ja auch die Hölle (aus Admin-Sicht).
Stimmt, und Deno macht das auch nur bedingt besser. Da ist aber das Problem "die Software wurde mit einem wirklich schrecklichen Framework entwickelt" auch nicht mit einem Container zu lösen.
Oh, alles ausverkauft in US? 
Nur ARM ist verfügbar? 
...und während tuxproject.de noch seinen Kernel von Hand kompiliert und Mailcow mal eben in 10 Minuten "von Hand" installiert, hat sich die Welt weitergedreht und jede(r) andere nimmt Container her. Weil sie schlicht praktisch sind. Normative Kraft des Faktischen.
Das kann jeder gute Paketmanager. Dein System hat keinen guten Paketmanager? Dann siehe zwei Punkte weiter oben.
Und er hat Debian ne schlechte Distribution genannt. 
Und er hat Debian ne schlechte Distribution genannt.
Gibt es denn auch noch andere brauchbare und zuverlässige Distributionen? 
...und während tuxproject.de noch seinen Kernel von Hand kompiliert
Nein.
und Mailcow mal eben in 10 Minuten "von Hand" installiert
Ja. Und darum genau weiß, was jedes einzelne Paket auf seinem Server warum tut. Und bei dir so?
jede(r) andere nimmt Container her
Nein, wie oben mehrfach ersichtlich.
Weil sie schlicht praktisch sind.
Und eine enorm dumme Idee, wie dargelegt.
Nur schade, dass ...
Normative Kraft des Faktischen.
... von dir keine Antwort auf die faktenbasierte Darlegung kam. Beweis durch Behauptung, das alte Problem. Mit manchen Menschen ist eine technische Diskussion überflüssig, man erkennt sie am "isso weil isso" - denn damit lässt sich deine Antwort auf meine ausführliche Begründung, warum Docker das falsche "Problem" "löst", letztendlich zusammenfassen. Schade.
Und er hat Debian ne schlechte Distribution genannt.
Nein, da hast du etwas falsch verstanden: Paketmanager, die dieses supitolle supigeile supiinnovative Docker-"Feature" - Versionen anpinnen - nicht haben, sind schlecht. (Ich würde ja nach Gegenargumenten fragen, aber ich gehe nicht davon aus, dass du welche hast.) Nur trifft das auf Debians apt nicht zu, denn apt kann das. Sicher wusstest du das aber schon. 
Gibt es denn auch noch andere brauchbare und zuverlässige Distributionen?
Wenn ich mich heute unbedingt für eine Linuxdistribution entscheiden müsste, dann wäre es wahrscheinlich Gentoo. Weil ich genau das Gegenteil von dem mache, was Dockerfans machen.
Für die, denen das zu viel Gebastel ist (und die trotzdem nicht auf BSD upgraden wollen...), openSUSE, weil es von den "großen" Distributionen die einzige ist, die auch mal halbwegs aktuelle Sicherheitspatches hat und nicht alle Naslang wegen irgendeiner Upstreamzankerei (-> Fedora/CentOS/Red Hat/...) wahlweise abgekündigt oder ohne technische Notwendigkeit komplett über den Haufen geworfen wird. (Und auf ARM64 sturzfrei funktioniert, aber das ist noch nur am Rande interessant.)
Ich sehe LXC, Docker, VM und Co. eher als technologisch komplementär und nicht konkurrierend.
Wir haben Konstellationen, da bietet sich Docker an....aber auch LXC oder eine ganze VM mit allem Kladderadatsch.
Vor allem: Ich bin Angehöriger der Bundeswehr und unsere Umgebungen unterliegen sehr scharfen Härtungsvorgaben (die Härtung eines Debian-Servers bspw. umfasst 170 Seiten in aktueller Fassung)...und nötige Abweichungen müssen begründet und mit Risikoanalyse unterlegt sein.
Und alle 2 Jahre kommt ein Prüfteam und zerlegt dir die Bude eine Woche lang auf IT-Sicherheit.
Und je nach Situation kann man bei uns schlicht kein Docker nehmen....da kann aber Docker nichts für 
jede(r) andere nimmt Container her. Weil sie schlicht praktisch sind. Normative Kraft des Faktischen.
shyze muss gut sein, millionen fliegen können nicht irren.
Wir sollten ein Docker Thema aufmachen und uns dann im Kreis aufstellen, während sich hardcore Jünger beider Seiten in der Mitte zerreißen.
Modernes Kolosseum, wenn man es so will 
Ich sehe LXC, Docker, VM und Co. eher als technologisch komplementär und nicht konkurrierend.
"System Container" wie LXC und VMs sind ja nochmal was anderes und absolut notwendig. Vor allem mit LXC habe ich mich durch Proxmox echt angefreundet, da es für die meisten Anwendungen reicht und einen winzigen Ressourcenverbrauch hat 
(die Härtung eines Debian-Servers bspw. umfasst 170 Seiten in aktueller Fassung)
"Hey Manu, kannst du uns bitte mal eben einen neuen Debian Server aufsetzen?"
"Ja klar, kein Ding, ich lass das Setup Skript mal eine halbe Stunde durchrattern und feintune dir das dann bis übermorgen!"
Wir sollten ein Docker Thema aufmachen
Richtig, gehört bei der Diskussion inzwischen nicht mehr zum 'Small Talk' im längsten Thema und hat ja auch was mit Servern zu tun.
Wir sollten ein Docker Thema aufmachen
die Härtung eines Debian-Servers bspw. umfasst 170 Seiten in aktueller Fassung
Ist das Dokument oeffentlich verfuegbar, oder ist das vertraulich?
Ich muss ja nicht alles umsetzen, aber fuer hilfreiche Anregungen bin ich immer dankbar.
