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ß.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.