Container bzw. Docker-Images erklärung
Hallo zusammen,
ich habe etwas wegen dem o. g. Thema gegoogelt und fand heraus, dass diese Technik
im Prinzip einfach nur da ist, um Betriebssysteme bzw. einzelne Anwendungen zu virtualisieren.
In Linux gibt es diese Umgebungen schon lange und soll nun ab dem neuen
Windows Server 2016 auch in der Windows Welt durchbrechen.
Habt ihr eine etwas genauere erklärung was genau diese Docker-Images bzw Containers sind?
Danke euch.
Lg.
M.Marz
ich habe etwas wegen dem o. g. Thema gegoogelt und fand heraus, dass diese Technik
im Prinzip einfach nur da ist, um Betriebssysteme bzw. einzelne Anwendungen zu virtualisieren.
In Linux gibt es diese Umgebungen schon lange und soll nun ab dem neuen
Windows Server 2016 auch in der Windows Welt durchbrechen.
Habt ihr eine etwas genauere erklärung was genau diese Docker-Images bzw Containers sind?
Danke euch.
Lg.
M.Marz
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 292085
Url: https://administrator.de/forum/container-bzw-docker-images-erklaerung-292085.html
Ausgedruckt am: 10.05.2025 um 18:05 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
ich hol mal etwas weiter aus.
Früher hat man in der Regel sehr viele Server gebraucht um zu vermeiden das sich verschiedene Anwendungen gegenseitig stören.
Sprich in der Regel hatte jedes wichtige System seinen eigenen Server im Idealfall.
Später kamen hat man dann Platzbedingt Bladetechnik eingeführt. Kleine Servermodule die in einem Schelf waren und auf ein Zentrales Storage System zugegriffen haben (Das mit dem Storage hat man auch schon früher gemacht).
Dann kam die Virtualisierungstechnik. Man war Hardwareunabhängig, konnte die Leistung besser nutzen aber man hat ziemlich viel Overhead da man immer noch für jede eigene Anwendung ein kpl. OS mit betreiben muss.
Jetzt kommt Docker. Man kapselt einzelne Anwendungen und deren Abhängigkeiten. Die sollten sich gegenseitig nicht behindern (was auch die Sicherheit erhöhen soll) und kann diese Container relativ einfach von einem Rechner zu einem anderen kopieren. Ohne den Overhead mehrere OS Systeme.
Zudem sind dadurch auch Testsysteme relativ einfach möglich da man einfach das Programm in ne Entwicklungsumgebung kopieren kann ohne viel einrichten zu müssen.
ich hol mal etwas weiter aus.
Früher hat man in der Regel sehr viele Server gebraucht um zu vermeiden das sich verschiedene Anwendungen gegenseitig stören.
Sprich in der Regel hatte jedes wichtige System seinen eigenen Server im Idealfall.
Später kamen hat man dann Platzbedingt Bladetechnik eingeführt. Kleine Servermodule die in einem Schelf waren und auf ein Zentrales Storage System zugegriffen haben (Das mit dem Storage hat man auch schon früher gemacht).
Dann kam die Virtualisierungstechnik. Man war Hardwareunabhängig, konnte die Leistung besser nutzen aber man hat ziemlich viel Overhead da man immer noch für jede eigene Anwendung ein kpl. OS mit betreiben muss.
Jetzt kommt Docker. Man kapselt einzelne Anwendungen und deren Abhängigkeiten. Die sollten sich gegenseitig nicht behindern (was auch die Sicherheit erhöhen soll) und kann diese Container relativ einfach von einem Rechner zu einem anderen kopieren. Ohne den Overhead mehrere OS Systeme.
Zudem sind dadurch auch Testsysteme relativ einfach möglich da man einfach das Programm in ne Entwicklungsumgebung kopieren kann ohne viel einrichten zu müssen.
Das bedeutet also das man Anwendungen wie Beispielsweise den Exchange Virtuell auf dem selben OS wie das Hostsystem betreiben kann, ohne das es aber den Host selbst oder anderen virtualisierte Anwendungen negativ beeinträchtigt.
Also ist die virtualisierte Anwendung in einem Container drin?
Also ist die virtualisierte Anwendung in einem Container drin?
Nein, das heisst es nicht. Natürlich brauchst du weiterhin z.B. Den RAM, cpu usw. Also beeinflusst dein Container natürlich den Host. Aber z.b. In der SW Entwicklung kannst du damit schnell Testmaschinen erzeugen und/oder das deployment vereinfachen.
Du sparst halt gegenüber vollständigen vm's den OS overhead (je nach os ja auch einige GB!) und ggf erlaubst du dem Anwender seine serverdienste zu konfigurieren während das OS selbst tabu ist
Du sparst halt gegenüber vollständigen vm's den OS overhead (je nach os ja auch einige GB!) und ggf erlaubst du dem Anwender seine serverdienste zu konfigurieren während das OS selbst tabu ist
Interessiert mich auch.
Ich hab das so verstanden dass der Container quasi nur die Schnittstellen/APIs eines Betriebssystem (virtuell) zur Verfügung stellt.
Also:
Applikation1 <--> Betriebssystemschnittstelle(n) <--> Container1 <--> →→ ↓
Applikation2 <--> Betriebssystemschnittstelle(n) <--> Container2 <--> → Docker <--> Betriebssystem
Applikation3 <--> Betriebssystemschnittstelle(n) <--> Container3 <--> →→ ↑
Ist das so korrekt?
Viele Grüße
pelzfrucht
Ich hab das so verstanden dass der Container quasi nur die Schnittstellen/APIs eines Betriebssystem (virtuell) zur Verfügung stellt.
Also:
Applikation1 <--> Betriebssystemschnittstelle(n) <--> Container1 <--> →→ ↓
Applikation2 <--> Betriebssystemschnittstelle(n) <--> Container2 <--> → Docker <--> Betriebssystem
Applikation3 <--> Betriebssystemschnittstelle(n) <--> Container3 <--> →→ ↑
Ist das so korrekt?
Viele Grüße
pelzfrucht
Hi,
ich denke, man muss sich das wie große Sandboxen vorstellen, oder wie das Streaming bei Citrix.
Diese Pakete sind nach wie vor abhängig vom Betriebssystem darunter. Jedoch ist es möglich, je Paket komplette Installationen zu packen. Mit eigenen Registry-Einstellungen und sogar mit einigen abweichenden Systemdateien. Ich schätze, das mit den Systemdateien fängt dann aber erst oberhalb des Kernels an. Aber möglicherweise wäre es sogar denkbar, dass z.B. ein Druckertreiber in verschiedenen Versionen in den Paketen enthalten sein können. Oder Java und/oder .Net in verschiedenen Versionen, ohne dass eine Anwendung Probleme bekommt, weil mehrere Java Versionen parallel installiert sind.
Und weil in diesen Paketen alles drin ist, was die Anwendung benötigt, kann man so ein Paket von einem Server zum nächsten kopieren und einfach ausführen, vorausgesetzt, das Betriebssystem darunter (hier also Windows) entspricht den Anforderungen, welche im Paket definiert sind. Oder man legt solche Pakete in eine Freigabe und kann es von dort auf mehreren Servern mounten und ausführen.
E.
ich denke, man muss sich das wie große Sandboxen vorstellen, oder wie das Streaming bei Citrix.
Diese Pakete sind nach wie vor abhängig vom Betriebssystem darunter. Jedoch ist es möglich, je Paket komplette Installationen zu packen. Mit eigenen Registry-Einstellungen und sogar mit einigen abweichenden Systemdateien. Ich schätze, das mit den Systemdateien fängt dann aber erst oberhalb des Kernels an. Aber möglicherweise wäre es sogar denkbar, dass z.B. ein Druckertreiber in verschiedenen Versionen in den Paketen enthalten sein können. Oder Java und/oder .Net in verschiedenen Versionen, ohne dass eine Anwendung Probleme bekommt, weil mehrere Java Versionen parallel installiert sind.
Und weil in diesen Paketen alles drin ist, was die Anwendung benötigt, kann man so ein Paket von einem Server zum nächsten kopieren und einfach ausführen, vorausgesetzt, das Betriebssystem darunter (hier also Windows) entspricht den Anforderungen, welche im Paket definiert sind. Oder man legt solche Pakete in eine Freigabe und kann es von dort auf mehreren Servern mounten und ausführen.
E.
