Es gibt immer mehrere Wege zum Ziel. Ein vernünftig klassisch gemangtes System hat seinen Wert, seine Berechtigung und ohne Grund sollte man keine Software einsetzten. Das gilt auch für Docker.
Während der Entwicklungsphase sicher super, im Produktivbetrieb dagegen weniger, da dort andere Anforderungen gelten. Möglichst viele Abstraktionsschichten unter und über die Datenbank zu legen um sie bei ihrer effizienten Arbeit zu behindern, gehört da eher nicht dazu.
Ja, das ist ein Feature für die Entwicklung. Vor allem, wenn man für verschiedene Projekte und Branches entwickelt.
Ein Projekt steht und fällt mit seiner Dokumentation. Wenn diese so schlecht ist, dass das System in akzeptabler Zeit nicht neu installiert werden kann, lässt man am Besten die Finger davon.
Dieser Ansatz, wir schieben einfach fertige Container zu unseren Kunden, dann müssen wir uns mit der Installation und Dokumentation nicht mehr beschäftigen führt in absehbarer Zeit nur dazu, dass dann auch niemand mehr in der Lage sein wird eine Installation durchzuführen.
Mich interessiert vor allem die Entwicklersicht. Auch für Testssysteme gilt, dass man die erstmal komplett einrichten muss. Warum soll ich da nichts nehmen, was schon alle Dependencies drin hat und dann auch einfach wieder raus geht (ja ich weiß - das kann man auch mit fast jeder modernen Paketverwaltung). Übrigens auch ohne, dass sich da was beißt. Man muss sich z.B. nicht zwischen PHP5 und PHP7 entscheiden. Es geht einfach beides. Wohl gemerkt - in der Entwicklung gibt es dauernd solche Fälle.
Und auch produktiv: Cloudsysteme, die hoch und runterskaliert werden sollen, bei denen kann man Docker sicher gut benutzen.
Das schwächste System wird den Angriff nicht standhalten. Und da du plötzlich für die *gesamte* Software welche du im Container deines Produktes auslieferst verantwortlich bist, hast du plötzlich Arbeit am Hals welche dir sonst die Distributionen abgenommen haben.
Für Container gibt es ganz genau so Distributionen. Im Zweifel sind das die gleichen Linux-Distributionen, die halt nur minimalistisch im Container laufen. Da ist häufig nicht mal ein curl, ping, apt/dnf/rpm oder sudo dabei (Edit: häufig aber auch doch, aber zumindest nichts, was über die minimalen Standardtools hinausgeht). Wenn das keine Verringerung der Angriffsfläche darstellt, dann weiß ichs auch nicht.
Dein Container ist demnach ein Workaround für ein falsch gewähltes oder aufgesetztes Hostsystem. Denn bei einem geeigneten Hostsystem stellt sich diese Problematik nicht.
Nein. Die Dienste sind einfach voneinander isoliert.
Ein akademisches Beispiel: Gitlab, Nexus, Apache/Nginx und Jenkins wissen nur voneinander die Ports, die durchgeroutet werden. Ansonsten wird man aus einem Reverse Proxy kein Maven oder Java aufrufen können. Selbst durch einen Bug in Nginx nicht. Denn diese Programme sind nur beim Jenkins verfügbar.
Trotzdem läuft alles auf einem einzigen Host.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Okt 2019 um 16:26.
Und auch produktiv: Cloudsysteme, die hoch und runterskaliert werden sollen, bei denen kann man Docker sicher gut benutzen.
Cloudsysteme laufe doch in der Regel nicht auf der Bare-Metall-Hardware sondern in virtuellen Maschinen, welche diese Features seit längerem mitbringen.
Für Container gibt es ganz genau so Distributionen. Im Zweifel sind das die gleichen Linux-Distributionen, die halt nur minimalistisch im Container laufen. Da ist häufig nicht mal ein curl, ping, apt/dnf/rpm oder sudo dabei (Edit: häufig aber auch doch, aber zumindest nichts, was über die minimalen Standardtools hinausgeht). Wenn das keine Verringerung der Angriffsfläche darstellt, dann weiß ichs auch nicht.
Du erhöhst erstmal die Komplexität indem du zahlreiche Dinge mehrfach vorhältst und ungeklärt ist, wer sich überhaupt um die Aktualität der einzelnen, völlig unterschiedlichen Systeme kümmert. Und in der Praxis werden dort dann auch wieder zahlreiche Tools der Entwickler und fürs Troubleshooting auch auf den an Endkunden ausgelieferten Systemen vorhanden sein. Ob da überhaupt noch etwas vom Versprechen der geringeren Angriffsfläche übrig bleibt, kann allerhöchstens im Einzelfall geklärt werden.
Nein. Die Dienste sind einfach voneinander isoliert.
Ein akademisches Beispiel: Gitlab, Nexus, Apache/Nginx und Jenkins wissen nur voneinander die Ports, die durchgeroutet werden. Ansonsten wird man aus einem Reverse Proxy kein Maven oder Java aufrufen können. Selbst durch einen Bug in Nginx nicht. Denn diese Programme sind nur beim Jenkins verfügbar.
Trotzdem läuft alles auf einem einzigen Host.
Für diese Anwendung brauchst du nur keine Container. Es gibt unter Linux zahlreiche Möglichkeiten einzelne Dienste voneinander abzuschotten, ohne gleichzeitig den Angriffsvektor durch das mehrfache Vorhandensein der selben Bibliotheken und Standardtools zu erhöhen.
Aus Entwicklersicht in einer Entwicklerumgebung alles wunderbar, kein Thema. Ich habe nur ein Problem mit der Argumentation "alles wird viel sicherer" mitzugehen, wenn dafür die Komplexität erhöht, identische Sicherheitslücken plötzlich zigfach auf dem System vorhanden sind und die Wartungssituation sowie dessen Mehraufwand ungeklärt sind.
Sicherlich. Ich würde ohne weitere Überlegungen auch kein System mit "Gitlab, Nexus, Apache/Nginx und Jenkins" im Docker aufsetzen, das nach außen sichtbar ist. Das braucht man wirklich nicht beim Kunden. Wenn es auf einen kleineren Benutzerkreis beschränkt ist und z.B. durch ein VPN geschützt ist dann allerdings ja. Geht halt einfach schnell und ist flexibel.
Und es ist natürlich eine Option, wenn es wirklich groß wird und man wirklich anfängt, dynamisch Knoten zu verschieben. Aber dann erstellt man wohl auch die Dockerfiles selbst.
Container sind einfach minimale VMs. Ansonsten klar - da hast du recht und ich betreibe warte keine Server. Ich schreibe nur die Software dafür.
Kleine Korrektur: Unter Windows ist eine Virtualisierung notwendig. Hat man kein Windows 10 Pro oder höher (mit Hyper-V), benötigt man unter Windows eine Virtualisierungslösung wie z.B. Virtualbox.
Unter Linux scheint wohl nur Namespaces und Cgroup verwendet zu werden. Wie das Docker genau macht, müsste ich mir also selbst noch mal ansehen. Allerdings bleibt es dabei, dass Container eine vom Hostsystem unabhängige komplette aber meist sehr kleine Linuxinstallation mitbringen und nur über genau definierte Schnittstellen mit der Außenwelt interagieren dürfen.
Es gibt immer mehrere Wege zum Ziel. Ein vernünftig klassisch gemangtes System hat seinen Wert, seine Berechtigung und ohne Grund sollte man keine Software einsetzten. Das gilt auch für Docker.
Ja, das ist ein Feature für die Entwicklung. Vor allem, wenn man für verschiedene Projekte und Branches entwickelt.Mich interessiert vor allem die Entwicklersicht. Auch für Testssysteme gilt, dass man die erstmal komplett einrichten muss. Warum soll ich da nichts nehmen, was schon alle Dependencies drin hat und dann auch einfach wieder raus geht (ja ich weiß - das kann man auch mit fast jeder modernen Paketverwaltung). Übrigens auch ohne, dass sich da was beißt. Man muss sich z.B. nicht zwischen PHP5 und PHP7 entscheiden. Es geht einfach beides. Wohl gemerkt - in der Entwicklung gibt es dauernd solche Fälle.Und auch produktiv: Cloudsysteme, die hoch und runterskaliert werden sollen, bei denen kann man Docker sicher gut benutzen.
Für Container gibt es ganz genau so Distributionen. Im Zweifel sind das die gleichen Linux-Distributionen, die halt nur minimalistisch im Container laufen. Da ist häufig nicht mal ein curl, ping, apt/dnf/rpm oder sudo dabei (Edit: häufig aber auch doch, aber zumindest nichts, was über die minimalen Standardtools hinausgeht). Wenn das keine Verringerung der Angriffsfläche darstellt, dann weiß ichs auch nicht.Nein. Die Dienste sind einfach voneinander isoliert.
Ein akademisches Beispiel: Gitlab, Nexus, Apache/Nginx und Jenkins wissen nur voneinander die Ports, die durchgeroutet werden. Ansonsten wird man aus einem Reverse Proxy kein Maven oder Java aufrufen können. Selbst durch einen Bug in Nginx nicht. Denn diese Programme sind nur beim Jenkins verfügbar.
Trotzdem läuft alles auf einem einzigen Host.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 03. Okt 2019 um 16:26.Cloudsysteme laufe doch in der Regel nicht auf der Bare-Metall-Hardware sondern in virtuellen Maschinen, welche diese Features seit längerem mitbringen.
Du erhöhst erstmal die Komplexität indem du zahlreiche Dinge mehrfach vorhältst und ungeklärt ist, wer sich überhaupt um die Aktualität der einzelnen, völlig unterschiedlichen Systeme kümmert. Und in der Praxis werden dort dann auch wieder zahlreiche Tools der Entwickler und fürs Troubleshooting auch auf den an Endkunden ausgelieferten Systemen vorhanden sein. Ob da überhaupt noch etwas vom Versprechen der geringeren Angriffsfläche übrig bleibt, kann allerhöchstens im Einzelfall geklärt werden.
Für diese Anwendung brauchst du nur keine Container. Es gibt unter Linux zahlreiche Möglichkeiten einzelne Dienste voneinander abzuschotten, ohne gleichzeitig den Angriffsvektor durch das mehrfache Vorhandensein der selben Bibliotheken und Standardtools zu erhöhen.
Aus Entwicklersicht in einer Entwicklerumgebung alles wunderbar, kein Thema. Ich habe nur ein Problem mit der Argumentation "alles wird viel sicherer" mitzugehen, wenn dafür die Komplexität erhöht, identische Sicherheitslücken plötzlich zigfach auf dem System vorhanden sind und die Wartungssituation sowie dessen Mehraufwand ungeklärt sind.
Sicherlich. Ich würde ohne weitere Überlegungen auch kein System mit "Gitlab, Nexus, Apache/Nginx und Jenkins" im Docker aufsetzen, das nach außen sichtbar ist. Das braucht man wirklich nicht beim Kunden. Wenn es auf einen kleineren Benutzerkreis beschränkt ist und z.B. durch ein VPN geschützt ist dann allerdings ja. Geht halt einfach schnell und ist flexibel.
Und es ist natürlich eine Option, wenn es wirklich groß wird und man wirklich anfängt, dynamisch Knoten zu verschieben. Aber dann erstellt man wohl auch die Dockerfiles selbst.
Container sind einfach minimale VMs. Ansonsten klar - da hast du recht und ich betreibe warte keine Server. Ich schreibe nur die Software dafür.
Kleine Korrektur:
Unter Windows ist eine Virtualisierung notwendig. Hat man kein Windows 10 Pro oder höher (mit Hyper-V), benötigt man unter Windows eine Virtualisierungslösung wie z.B. Virtualbox.
Unter Linux scheint wohl nur Namespaces und Cgroup verwendet zu werden. Wie das Docker genau macht, müsste ich mir also selbst noch mal ansehen. Allerdings bleibt es dabei, dass Container eine vom Hostsystem unabhängige komplette aber meist sehr kleine Linuxinstallation mitbringen und nur über genau definierte Schnittstellen mit der Außenwelt interagieren dürfen.