Forum: PC Hard- und Software Wie funktioniert Docker?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Taucher (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Ich habe eine Web-Anwendung, die aus 3 Docker-Containern besteht, die 
alle drei auf dasselbe OS-Image aufsetzen. Nach viel Gefummel, habe ich 
die Chose zum Starten bekommen, nur scheint die interne Struktur des 
Konstrukts etwas anders zu sein, als ich dachte: jeder Container hat 
seine eigene OS-Instanz mit eigenem Dateibaum. (Ich dachte ursprünglich, 
die würden mit docker-compose zu einem System zusammengeschraubt…)

Jetzt meine Frage: Wie kann ich den Hauptspeicherbedarf der einzelnen 
Container feststellen?

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
Taucher schrieb:
> jeder Container hat
> seine eigene OS-Instanz mit eigenem Dateibaum

jup. Jeder Container hat seine eigene Betriebsystem-Installation mit 
Paketen, die aktualisiert werden möchten, wenn es Sicherheits-Updates 
gibt.

Wird gerne vernachlässigt, weil "ist ja im Container eingesperrt". Aber 
dem Cracker ist es egal, ob er deine Datenbank aus einem gedockerten 
oder "normalen" MySQL herunterläd...

Taucher schrieb:
> Wie kann ich den Hauptspeicherbedarf der einzelnen
> Container feststellen?

"docker stats"

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
2 lesenswert
nicht lesenswert
Taucher schrieb:
> jeder Container hat
> seine eigene OS-Instanz mit eigenem Dateibaum.

Das ist der Normalfall um mit vielen Hostsystemen kompatibel Images zu 
erhalten. Man packt ein halbes Betriebssystem und mindestens alle von 
der Anwendung benötigten Bibliotheken in ein Image. Besondere Künstler 
schmeißen, aus Faulheit oder Versehen, noch ihre halbe 
Entwicklungsumgebung ins Image. Da kannst du manchmal interessante Dinge 
finden wie SSH Keys, Lizenzkeys oder persönliche Daten.

Für einen, sagen wir mal ersten Angriff auf Docker Images 
https://github.com/wagoodman/dive

Gelegentlich findest du auch Images in denen sich nur ein oder ein paar 
wenige Binaries mit ihren Bibliotheken befinden. Entweder hat da jemand 
das verwendet Betriebssystem extrem aufgeräumt oder ganz ernsthaft mit 
"FROM scratch" gearbeitet.

> (Ich dachte ursprünglich,
> die würden mit docker-compose zu einem System zusammengeschraubt…)

Docker compose ist schon fast wieder überholt. Der geneigte 
Hipster-Jünger filetiert seine Anwendung mittlerweile in Form von 
Microservices und verwendet einen Kubernetes Cluster um alles wieder 
zusammenzukleben. Images werden in Pods gruppiert und Sätze von Pods 
werden z.B. mit einem Deployment deklariert und im Cluster zur 
Ausführung gebracht. Wer auf seinem PC mal dran lecken möchte 
https://minikube.sigs.k8s.io/docs/

von Jemand (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> jup. Jeder Container hat seine eigene Betriebsystem-Installation mit
> Paketen, die aktualisiert werden möchten, wenn es Sicherheits-Updates
> gibt.

Auf der darüber liegenden Ebene werden dieselben Dateisystemlayer 
allerdings zwischen den Images gesharet, so daß -- anders als bei  einer 
traditionellen Virtualisierungen -- dasselbe Basisimage nur einmal 
Speicherplatz auf dem Host belegt. Da die unteren Layer ohnehin nicht 
beschreibbar sind, funktioniert das prima.

> Wird gerne vernachlässigt, weil "ist ja im Container eingesperrt". Aber
> dem Cracker ist es egal, ob er deine Datenbank aus einem gedockerten
> oder "normalen" MySQL herunterläd...

Schon merkwürdig, daß dieses Gelaber immer nur im Zusammenhang mit 
Docker und anderen Containertechnologien kommt. Dabei ist eigentlich 
jedem klar, daß man Software regelmäßig aktualisieren muß, unabhängig 
davon, ob sie auf bare metal, in einer klassischen Virtualisierung oder 
in einem Container läuft. Aber nur bei Docker -- wo das mit der 
Aktualisierung besonders einfach und fehlerunanfällig ist -- kommen 
immer wieder diese überflüssigen Unkenrufe...

von Jemand (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Hannes J. schrieb:
> Taucher schrieb:
>> jeder Container hat
>> seine eigene OS-Instanz mit eigenem Dateibaum.
>
> Das ist der Normalfall um mit vielen Hostsystemen kompatibel Images zu
> erhalten. Man packt ein halbes Betriebssystem und mindestens alle von
> der Anwendung benötigten Bibliotheken in ein Image. Besondere Künstler
> schmeißen, aus Faulheit oder Versehen, noch ihre halbe
> Entwicklungsumgebung ins Image. Da kannst du manchmal interessante Dinge
> finden wie SSH Keys, Lizenzkeys oder persönliche Daten.

Als ob man die in "normalen" Sourcecode-Repositories nicht fände...

> Für einen, sagen wir mal ersten Angriff auf Docker Images
> https://github.com/wagoodman/dive

"Angriff"? Ernsthaft?

> Gelegentlich findest du auch Images in denen sich nur ein oder ein paar
> wenige Binaries mit ihren Bibliotheken befinden. Entweder hat da jemand
> das verwendet Betriebssystem extrem aufgeräumt oder ganz ernsthaft mit
> "FROM scratch" gearbeitet.

Üblicherweise betrifft das die Go-Leute, die ja ohnehin gerne statisch 
linken -- übrigens um damit genau die Deployment-Probleme zu verhindern, 
die Docker und andere Containertechnologien wirksam lösen.

>> (Ich dachte ursprünglich,
>> die würden mit docker-compose zu einem System zusammengeschraubt…)
>
> Docker compose ist schon fast wieder überholt. Der geneigte
> Hipster-Jünger filetiert seine Anwendung mittlerweile in Form von
> Microservices und verwendet einen Kubernetes Cluster um alles wieder
> zusammenzukleben. Images werden in Pods gruppiert und Sätze von Pods
> werden z.B. mit einem Deployment deklariert und im Cluster zur
> Ausführung gebracht. Wer auf seinem PC mal dran lecken möchte
> https://minikube.sigs.k8s.io/docs/

Nö, Docker Compose ist keineswegs überholt -- und es hat einen ganz 
anderen Fokus als Kubernetes. Docker Swarm ist überholt, weil es 
dieselben Ziele wie Kubernetes (und andere Technologien wie Nomad, 
Apache Mesos oder OpenStack) verfolgt und sich gegen die Wettbewerber 
nicht durchsetzen konnte. Aber bei Docker Compose geht es nur um die 
Orchestrierung mehrerer Container auf einem einzelnen Host, während es 
bei den anderen genannten Technologien um den Betrieb von Containern 
(und zum Teil auch klassischen VMs) auf einem Cluster aus mehreren 
Commputern geht.

von dave4 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Jemand schrieb:
> Schon merkwürdig, daß dieses Gelaber immer nur im Zusammenhang mit
> Docker und anderen Containertechnologien kommt.

Das ist einfach nur das gleiche Geschwätz und die gleichen Bedenken die 
vor 20 Jahren bei VMs kam. In ein paar Jahren ist das vergessen.

Taucher schrieb:
> jeder Container hat
> seine eigene OS-Instanz mit eigenem Dateibaum. (Ich dachte ursprünglich,
> die würden mit docker-compose zu einem System zusammengeschraubt…)
>
> Jetzt meine Frage: Wie kann ich den Hauptspeicherbedarf der einzelnen
> Container feststellen?

Naja, es ist keine OS Instanz. Der Kernel und die Serviceprozesse fehlen 
im Container und es sind deutlich weniger Pakete installiert (sollten 
sie jedenfalls). Der Speicherbedarf ist der gleiche wie die Prozesse 
außerhalb der Container laufen zu lassen. Wenn die Container aus den 
gleichen Images kommen funktionieren auch die Shared Libraries.

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
Jemand schrieb:
> dasselbe Basisimage nur einmal
> Speicherplatz auf dem Host belegt.

Sogar noch besser, die doppelten Bibliotheken etc. belegen auch nur 
einmal RAM. (abhängig vom Storage-Treiber)

Jemand schrieb:
> Aktualisierung besonders einfach und fehlerunanfällig ist -- kommen
> immer wieder diese überflüssigen Unkenrufe...

Erfahrungswert. Viele sind von Linux gewöhnt dass ("unattended 
upgrades") Sicherheits-Patches automatisch installiert werden oder beim 
Login eine Fette Meldung erscheint "xxx Pakete aktualiserbar, davon YY 
Sicherheitskritisch"...
Bei Docker gibt's das out-of-the-box nicht, insofern wird da auch nicht 
zu Updates gedrängelt.
Jetzt misch da noch schlecht gewartete "dockerhub" - Images mit dazu, 
und das Desaster ist komplett...
Und damit sind noch nichtmal die images mit integrierten Backdoors oder 
Crypto-Minern gemeint.
https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabilities/

Deshalb nochmal der "Unkenruf": Docker ist kein "fire-and-forget ­— 
alles ist sofort und für immer absolut sicher"-System. Der Admin muss 
sich auch bei Docker selber um die Sicherheit kümmern.

von dave4 (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Erfahrungswert. Viele sind von Linux gewöhnt dass ("unattended
> upgrades") Sicherheits-Patches automatisch installiert werden oder beim
> Login eine Fette Meldung erscheint "xxx Pakete aktualiserbar, davon YY
> Sicherheitskritisch"...
> Bei Docker gibt's das out-of-the-box nicht, insofern wird da auch nicht
> zu Updates gedrängelt.
> Jetzt misch da noch schlecht gewartete "dockerhub" - Images mit dazu,
> und das Desaster ist komplett...
> Und damit sind noch nichtmal die images mit integrierten Backdoors oder
> Crypto-Minern gemeint.

Genau so.

Der eigentliche Gedanke war ja mal, dass das Patching wird zum Teil des 
Softwarewartungs- UND TEST-Prozess wird und damit aus der Entwicklung 
aktuelle, getestete und schlanke Appliances rausfallen die fast überall 
laufen und von den Applikationsdaten soweit getrennt sind, dass man für 
Updates nur ein Image austauschen muss und es danach weitergeht.

Wenn man allerdings den Griffel fallen lässt sobald die Web-UI live ist 
geht es in die Hose. Man nennt es dann aber effizient... oder so...

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Εrnst B. schrieb:
> Jemand schrieb:
>> dasselbe Basisimage nur einmal
>> Speicherplatz auf dem Host belegt.
>
> Sogar noch besser, die doppelten Bibliotheken etc. belegen auch nur
> einmal RAM. (abhängig vom Storage-Treiber)

Ja, natürlich.

> Jemand schrieb:
>> Aktualisierung besonders einfach und fehlerunanfällig ist -- kommen
>> immer wieder diese überflüssigen Unkenrufe...
>
> Erfahrungswert. Viele sind von Linux gewöhnt dass ("unattended
> upgrades") Sicherheits-Patches automatisch installiert werden oder beim
> Login eine Fette Meldung erscheint "xxx Pakete aktualiserbar, davon YY
> Sicherheitskritisch"...
> Bei Docker gibt's das out-of-the-box nicht, insofern wird da auch nicht
> zu Updates gedrängelt.

Auf Linux-Servern gibt es das auch nicht ootb, sondern man muß sowas wie 
cron-apt installieren. Ebenso bietet es sich an, unter Docker den 
containerrr/watchtower zu installieren: der checkt in periodischen 
Abständen alle laufenden Container gegen die Version im Repository und 
aktualisiert die Images und die laufenden Container vollautomatisch, 
wenn im Repo eine aktuellere Version verfügbar ist.

> Jetzt misch da noch schlecht gewartete "dockerhub" - Images mit dazu,
> und das Desaster ist komplett...

Man benutzt ja auch nur offizielle Images der betreffenden Projekte -- 
und ansonsten gilt das Gesagte für jede Art von Software, egal, ob sie 
vom Distributor, aus einem PPA, einer dritten Paketquelle wie Perls 
CPAN, Pythons PyPi, PHPs PEAR oder PECL, oder von irgendwoher als 
Quellcode heruntergeladen und manuell installiert worden ist. Man darf 
eben nur vertrauenswürdige Software aus vertrauenswürdigen Quellen 
installieren und benutzen -- und ist auch dann nicht 100%ig sicher. Das 
ist bei Docker nicht anders als sonst auch.

> https://www.infoq.com/news/2020/12/dockerhub-image-vulnerabilities/

Überraschung: eine mir bis dato unbekannte "security firm" namens 
"Prevasio", die ein Vulnerability Scanning Tool (also quasi einen 
Virenscanner für Docker-Images) verhökern möchte, findet angeblich 
massenhaft Sicherheitslücken... Ich habe mir die Webseite von denen mal 
kurz angeschaut und finde schon auf der Startseite Aussagen, die 
zumindest ein bisschen merkwürdig und reißerisch daher kommen... naja. 
Und in ihrem Whitepaper listen sie allerlei Dinge auf... zum Beispiel 
haben sie in 1269 Images sogenannte "Hacking Tools" und in 2842 Images 
"Coin Miners" (zusammen 64% der insgesamt gefundenen 0,16% "böser" 
Images) gefunden. Ach, nein: dürfen Bitcoin-Miner und Nutzer von 
Hacking-Tools etwa kein Docker benutzen? Höchstwahrscheinlich ist da 
auch einer meiner Container im Docker-Hub dabei, denn da ist ufonet 
drin, das ich für Streßtests benutze. ;-)

Lustigerweise sagen sie auch in ihrem Whitepaper, daß die allermeisten 
dieser "Coin Miner"-Images ganz genau das sind: Images, in denen 
containerisierte Coin Miner sind und deren Beschreibung im Docker-Hub 
haargenau das aussagt. Ebenso schreiben sie in ihrem Whitepaper, daß 
"Hacking Tools" nicht per se böse seien, aber womöglich in einer 
Unternehmensumgebung unerwünscht, vor allem Portscanner... lustig, ich 
kenne etliche Admin-Kollegen, die ihre gesamten Umgebungen ebenso wie 
meine Leute und ich regelmäßig mit solchen Tools abklappern, um mögliche 
Konfigurationsprobleme und die bösen Scheisserchen unter den Usern zu 
finden.

Lustigerweise gibt es gleich mehrere CVE-Scanner, mit denen man die 
eigenen Images selbst scannen kann: Aqua Security Trivy, das auch die 
Leute von Prevasio benutzt haben, RedHats Clair, Anchore, Quay und GCR. 
Allerdings gibt es da noch so einen Aspekt: beim Bau eines Image mit 
einem Dockerfile fügt jede Dockerfile-Instruktion dem Image einen neuen 
Dateisystemlayer hinzu. Wenn ich also ein uraltes Ubuntu-Image nehme und 
die erste RUN-Instruktion meines Dockerfile mit "apt-get update -y && 
apt-get dist-upgrade -y" beginnt, werden die bereits in dem Image 
vorhandenen Layer mit eventuell veralteten Versionen derselben Pakete 
nicht gelöscht, sondern bleiben im Image -- aber durch das Stacking der 
Images sind die Dateien aus den veralteten Paketen gar nicht mehr 
erreichbar, weil in höheren Layern die aktuellen Versionen liegen. Wenn 
nun ein Werkzeug wie zum Beispiel das genannte Trivy alle Image-Layer 
durchsucht, findet es auch die veraltete, vermeintlich unsichere, jedoch 
komplett unerreichbare Version... Da kann man sicher trefflich drüber 
streiten, wie sinnig solche Ergebnisse sind, andere Scanner wie Clair 
machen das darum nicht.

Insofern, sorry: verglichen mit der reißerischen Ankündigung fällt die 
Nummer recht schnell in sich zusammen, wenn man das etwas genauer 
betrachtet. Zumal Docker alle Images auf seinem Hub ja schon selbst 
scannt...

Wie dem auch sei: alles, was für "normale" Software gilt -- sogar für 
die Pakete eines Distributors -- gilt auch für Docker-Images. Und zwar 
wirklich alles, ohne Ausnahme. Beim Debian-Projekt gab es vor einigen 
Jahren mal einen Einbruch in die Server, im PyPi gab es Python-Pakete 
mit ähnlichen Namen, die Schadcode enthielten, und was man in den 
diversen PPAs und anderen Drittanbieter-Respositories so alles finden 
kann, will ich gar nicht wissen. Trau, schau, wem. Gilt immer und 
überall, dabei ist Docker keine Ausnahme und behauptet es auch nicht -- 
ganz im Gegenteil. (Nebenbei: das gilt auch für die Auswahl von 
Informationsquellen... ;-))

> Deshalb nochmal der "Unkenruf": Docker ist kein "fire-and-forget ­—
> alles ist sofort und für immer absolut sicher"-System. Der Admin muss
> sich auch bei Docker selber um die Sicherheit kümmern.

Ja, genau, aber das ist keine Besonderheit: nicht bei 
Bare-Metal-Software, nicht bei Software in VMs, nicht bei Software des 
Distributors und natürlich auch nicht bei Docker-Images. Bei 
Docker-Images ist es allerdings ganz besonders einfach und meist mit 
minimalster Downtime möglich, seine eigenen Images neu zu bauen, in ein 
Repo zu pushen und sie dann, wahlweise vollautomatisch mit 
containerrr/watchtower oder gar manuell, zu aktualisieren. In meinen 
Projekten reicht dazu docker-compose: "pull", "build", "push" -- all das 
macht ein Cronjob zweimal täglich, oder ich stoße es von Hand an wenn 
ich eine Änderung gemacht habe -- und den ganzen Rest erledigt auf den 
Containerhosts dann containerrr/watchtower oder ebenfalls ein manueller 
Anstoß.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.