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?
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"
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/
Ε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...
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.
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.
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.
Ε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...
Ε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ß.
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
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten