Docker pro und kontra (was: Ngnix-problem)

[drfuture]

Edit by dexter: Dieser Thread ist die Fortsetzung von hier.

Weiß ja nicht, aber halte irgendwie 0 von docker. Kann aber auch sein das ich das Thema nicht verstanden habe oder das es oft falsch implementiert ist...

Aber wenn ich bei mir einen docker Host installiere und eine fertige Instanz downloade und starte / deploye holt der sich zig Dienste für seine Umgebung die bei mir in zu meist aktuellere Version laufen und noch mehr Pakete wenn der Container auf einer anderen Distribution basiert.

Keine Frage der Spaß funktioniert danach...
Aber Resourcen sparend und *sicher* finde ich anders...
Wenn man mehrere Dienste laufen lässt hat man wenn man nicht genau auf Versionen der Dienste achtet und auf die Quelle, alles mehrfach laufen in zig Versionen... Das ganze dann nur schwer pflegbar?

Wenn man die Container selber erstellt verbessert sich das vermutlich, aber was ist dann besser die Anwendungen in Container zu sperren wenn ich die Dienste dann vermutlich über den paketmanager pflegen kann und nur links in die Container erstellt werden...

Kapseln könnte man ja z.b. Auch oder chroot etc.
Auch Zuweisung und Verwaltung der einzelnen sicher docker volumes (zumindest auf der Console) finde ich alles andere als übersichtlich und verschlimmbessert eine Umgebung für mich eher.... Wo ist wie viel Platz?

 

[ynbl]

Re: Ngnix problem

Docker ist fuer Entwicklungsumgebungen eine tolle Sache. Aber mir produktiv einen Anwendungscontainer der nicht gepatcht wird hinzustellen, .. nope. Not happening.

(Die Tatsache, dass LetsEncrypt urspruenglich Docker verwenden wollte hat mich erschaudern lassen ..)

 

[virtus]

Re: Ngnix problem

Keine Frage der Spaß funktioniert danach...
Aber Resourcen sparend und *sicher* finde ich anders...
Wenn man mehrere Dienste laufen lässt hat man wenn man nicht genau auf Versionen der Dienste achtet und auf die Quelle, alles mehrfach laufen in zig Versionen... Das ganze dann nur schwer pflegbar?

Doch, Docker ist durchaus sehr Ressourcen-sparend. Zum einen setzen sich Images aus mehreren, möglichst simplen Layern zusammen. Diese Layer können bei Bedarf wieder verwendet werden. Wegen der Versionierung: Gewöhnlich setzt man auf :latest, also auf die aktuellste Version. Ein Update "von unten" zieht sich entsprechend nach oben durch. Entwickler kümmern sich dann bottom-top darum, ihre eigenen Layer zu aktualisieren, sollte das durch ein Update des darunterliegenden Layers notwendig werden. Ein Update innerhalb eines Containers (VM) ist in der Regel nicht notwendig, weil du den Container wegwirfst, sein Image in einer neuen Version lädst und daraus einen neuen Container baust. Normalerweise lassen sich Anwendungsdaten entweder über Bindungen zum Hostsystem oder durch entsprechende Zugänge (z.B. SSH) sichern.
Zur Sicherheit: Ja, Docker ist kein Hochsicherheitstrakt und bietet keine 100% saubere Isolation, allerdings wurde daran auch bereits viel gearbeitet. Da du ohnehin der Software, die du installierst, trauen können solltest, musst du das natürlich auch hier tun.

Docker ist fuer Entwicklungsumgebungen eine tolle Sache. Aber mir produktiv einen Anwendungscontainer der nicht gepatcht wird hinzustellen, .. nope. Not happening.

Es ist prinzipiell auch möglich Software im Container zu patchen. Das gewöhnliche Vorgehen ist aber eher, den Container weg zu werfen und einen neuen Container aus einer neueren Version des Images zu bauen. - Natürlich kann es auch abhängig von dem konkreten Projekt sein, dass ein anderes Vorgehen zu präferieren ist..

 

[drfuture]

Re: Ngnix problem

Ja aber woher das "neue" image?
Zum verteilen oder in größeren Organisationen um 5000x Wordpress zu deployen evtl. - wobei sich mir da der Vorteil trotzdem nicht erschließt.
Aber in dem Fall hier müsste der TS statt ein einfaches apt-get update / upgrade (oder ähnliche befehle) + evtl. Dienstneustart / Server-Neustart WESENTLICH mehr machen um seine Dienste aktuell zu halten. - nur Wozu das dann?

Und Docker verwendet die Dienste / Dll's wenn sie einmalig vorhanden sind - startet aber z.B. wohl 10x den Apache wenn der zur Anwendung im Image gehört statt 1x einen Apache am Host laufen zu haben und passende vhosts?
Bzw. wenn man eben unterschiedliche Versionsstände hat (Den Fall gibt es aber wie beschrieben wohl nur wenn man div. fertige Container von Projekten verwendet) dann laufen unterschiedliche Mailserver, Webserver, php-versionen usw. auf einem Physikalischen System parallel obwohl sie dies eigentlich nicht müssten.
Keine Frage es gibt eine Menge Einsatzzwecke für so ein Szenario wo das wirklich Sinn macht und dann auch Zeit und Resourcen spart - ich finde aber a) hier nicht und b) in WESENTLICH weniger fällen als die Werbung *alles virtualisieren ist super* glauben machen möchte.

 

[sia]

Re: Ngnix problem

Aber in dem Fall hier müsste der TS statt ein einfaches apt-get update / upgrade (oder ähnliche befehle) + evtl. Dienstneustart / Server-Neustart WESENTLICH mehr machen um seine Dienste aktuell zu halten. - nur Wozu das dann?

Warum das denn? Der Container besteht vermutlich aus einem Webserver und einem Datenbankserver, die kann man genau so aktualisieren, wie virtus das geschrieben hat. Also Image aktualisieren, Container löschen, neuen Container mit dem Image und den Daten anlegen.

Weitere Infos: http://www.offermann.us/2013/12/tiny-docker-pieces-loosely-joined.html

Und Docker verwendet die Dienste / Dll's wenn sie einmalig vorhanden sind - startet aber z.B. wohl 10x den Apache wenn der zur Anwendung im Image gehört statt 1x einen Apache am Host laufen zu haben und passende vhosts?

Abgesehen davon, dass es unter Linux shared libraries gibt, die natürlich auch unter den einzelnen Webserver-Images geteilt werden können, kannst du in einem Docker-Nginx natürlich auch VHosts anlegen.

Ob du die selbe Binary jetzt fünf- oder zehnmal startest, ist ja wohl wurst. Der Overhead ist minimal (wenige MB).

wenn man eben unterschiedliche Versionsstände hat (Den Fall gibt es aber wie beschrieben wohl nur wenn man div. fertige Container von Projekten verwendet) dann laufen unterschiedliche Mailserver, Webserver, php-versionen usw. auf einem Physikalischen System parallel obwohl sie dies eigentlich nicht müssten.

Du verwechselst Containerisierung mit reiner Virtualisierung. Die darunterliegenden Images werden doch aktualisiert, sämtliche darauf aufbauenden Container haben nach ihrem Neustart die aktuelle Version aus dem Image.

Oder man nutzt so etwas wie watchtower.

 

[virtus]

Re: Ngnix problem

Ja aber woher das "neue" image?

Woher kommt denn deine neue Software? Vom Hersteller meistens aus Repositories. Bei Docker ist das standardmäßig https://registry.hub.docker.com

Zum verteilen oder in größeren Organisationen um 5000x Wordpress zu deployen evtl. - wobei sich mir da der Vorteil trotzdem nicht erschließt.

Skalierbarkeit. Stell dir vor du willst auf 5000 Systemen eine Anwendung einrichten. Alle Maschinen in einem Salt Verbund zusammen gebunden und zentral überall via Docker die Anwendung shippen. Wenn die Anwendung das Ende ihres Lebenszyklus erreicht hat, killst du sie.

Aber in dem Fall hier müsste der TS statt ein einfaches apt-get update / upgrade (oder ähnliche befehle) + evtl. Dienstneustart / Server-Neustart WESENTLICH mehr machen um seine Dienste aktuell zu halten. - nur Wozu das dann?

Update mit Paketmanager:

[src=bash]service xyz stop
apt-get update -y
service xyz start[/src]

Stilisiertes Update eines Containers:

[src=bash]docker rm -f <altesImage>
docker pull <neuesImage>
docker run <neuesImage> // flags[/src]

Wenn du willst kannst du dir sogar ein Script schreiben, diese Schritte automatisch ausführt.

Und Docker verwendet die Dienste / Dll's wenn sie einmalig vorhanden sind - startet aber z.B. wohl 10x den Apache wenn der zur Anwendung im Image gehört statt 1x einen Apache am Host laufen zu haben und passende vhosts?

Das stimmt, wenn du 10x Webserver auf deinem System startest, dann laufen da 10 Webserver. Das Problem hast du auch, wenn du normale Software vorliegen hast.
Natürlich kannst du deinen Webserver auch so konfigurieren, dass er 10 vhosts konfiguriert hat.... aber das gleiche lässt sich mit Docker erreichen.
Das geht u.U. sogar noch einfacher, zum Beispiel baust du dir 10 Container, die jeweils einen vhost repräsentieren und linkst diese zu deinem Container, der den Apache-Server beinhaltet. Dann kannst du auch recht schnell vhosts von einer zu einer anderen Maschine umziehen.
Deiner Konfigurationsfreiheit sind dabei keine Grenzen gesetzt.

Bzw. wenn man eben unterschiedliche Versionsstände hat (Den Fall gibt es aber wie beschrieben wohl nur wenn man div. fertige Container von Projekten verwendet) dann laufen unterschiedliche Mailserver, Webserver, php-versionen usw. auf einem Physikalischen System parallel obwohl sie dies eigentlich nicht müssten.

Ich verstehe dein Problem nicht. Wenn du 20 Mailserver laufen lassen willst, dann ist das mit Docker möglich, das heißt aber nicht, dass du es deshalb machen musst. Es ist auch wunderbar möglich einen Mailserver in einem Dockercontainer zu halten und andere dockerisierte Applikationen anzuweisen diesen einen Mailserver zu verwenden.

 

[drfuture]

phre4k hat evtl. recht und ich verwechsle virtualisierung mit containern ... oder vermische das Thema.
Letzter Versuch war eine Software die als als Docker gab bei mir auszuprobieren.

Ich habe den Container gedownloadet und lokal bei mir eingebunden.
Dabei hat er gefühlt ein halbes Linux installiert da die Software für ubuntu "gedacht" war und ich suse am laufen habe.
Da er dabei auch einen eigenen mysql-server, nginx in einer komplett veralteten Version, php uralt usw. mitgebracht hat - obwohl ich das schon alles am laufen hatte - fand ich das nicht sonderlich toll.
Wenn man nun einen hübschen Container wie ihr beschreibt selber baut scheint das wohl anders zu laufen - das werde ich mir noch mal genau durchlesen.
Nur ist es dann schade das "andere" das so nicht nutzen.

zum Thema Apache - oder bei mir nginx oder was auch immer...
ein vhost ist ja normal "nur" eine config-datei die einzelne Datei in einen Container stecken ist doch genauso portabel wie wenn ich diese einzeln im Dateisystem liegen habe?

Bei mir kommt noch eine .txt aller domains hinzu über die ssl-zertifikate erstellt werden - könnte die von einem neuen container dann mitgepflegt werden?
im Falle des Webservers ist der Memory-Overhead noch egal - bei DB-Servern kann man das normal nicht so minimal halten.

Ich bin halt kein Freund davon etwas mutwillig zu abstrahieren und "noch" eine Schicht dazwischen bauen zu müssen wenn nicht zwingend nötig. Umso mehr Software dazwischen umso fehleranfälliger ist das ganze und umso schwerer wird auch die Fehlersuche weil jeder Teil der dazwischen liegt den Fehler haben könnte.

 

[virtus]

Klar ein gewisses Grundsystem muss eben geschaffen werden, wenn der Container dies voraus setzt.
Normalerweise ist es kein guter Stil "viel" in einem Container zusammen zu packen. Docker lebt u.a. von Modularität.
Da kann es sein, dass du einfach ein schlechtes Beispiel erwischt hast.

Ein guter Stil wäre Datenbankserver, Webserver und Anwendung in jeweils getrennten Containern zu betreiben.
Es kann natürlich sein, dass sich da jemand dachte, dass es bestimmt viel einfacher ist, wenn man alles zusammen packt. In der Tat macht das das Shipping dann einfacher und der Nutzer braucht sich später um gar keine Konfiguration mehr zu kümmern. Das führt aber zu dem Phänomen, das du beobachtet hast, nämlich hoffnungslos veralteten Paketen und Dienst-Dopplung.

Klar, du musst auch nicht für jede Datei einen extra Container erstellen.
Du kannst auch deine ganzen Config-Files in ein Verzeichnis legen, welches später von dem Container gemountet wird.
Dann kannst du auch den Container bedenkenlos löschen, ohne dass deine Konfiguration flöten geht.

 

[0xFADED]

Ich habe den Container gedownloadet und lokal bei mir eingebunden.
Dabei hat er gefühlt ein halbes Linux installiert da die Software für ubuntu "gedacht" war und ich suse am laufen habe.

Das klingt (zumindest für mich) ein bisschen seltsam.
Im Normalfall sind Docker Container "ready-to-run".
Nach dem pull sollte der ohne weitere Installationen starten.
Der Unterschied Suse/Ubuntu sollte hier auch nichts ausmachen, da Docker sich mit dem Host nur den Linux Kernel teilt und nicht Bibliotheken oder Programme.

Wenn man nun einen hübschen Container wie ihr beschreibt selber baut scheint das wohl anders zu laufen - das werde ich mir noch mal genau durchlesen.
Nur ist es dann schade das "andere" das so nicht nutzen.

Es ist wie virtus gesagt hat.
Meistens packst du dir deinen Webserver/DB-Server/... in jeweils eigene Container die du dann untereinander verlinken kannst.
Das löst das Problem der veralteten Software, da du "mal eben so" zb den SQL Container updaten/austauschen kannst
ohne einen anderen Container zu stoppen oder die Configs anzupassen.

zum Thema Apache - oder bei mir nginx oder was auch immer...
ein vhost ist ja normal "nur" eine config-datei die einzelne Datei in einen Container stecken ist doch genauso portabel wie wenn ich diese einzeln im Dateisystem liegen habe?

Bei privaten Umgebungen stimme ich dir da vollkommen zu.
In Firmen ist es aber so, dass du durch Docker eine gekapselte Umgebung schaffen kannst die überall gleich aussieht und gleich funktioniert.
Dadurch fällt die "Bei mir gehts aber" Ausrede weg weil jeder Entwickler, der Testserver, der Liveserver und der Kunde die selben
Programme, Versionen, Configs und Umgebungen haben.

 

[Schattenfresser]

Wenn man nun einen hübschen Container wie ihr beschreibt selber baut scheint das wohl anders zu laufen - das werde ich mir noch mal genau durchlesen.
Nur ist es dann schade das "andere" das so nicht nutzen.

A fool with a tool is still a fool. Das gilt bei Docker genauso wie anderswo.
Du kannst das tollste Werkzeug toal falsch benutzen. Das macht das Werkzeug nicht schlechter. Wenn jemand als einen verkorksten Container anbietet liegt das nicht an Docker, sondern dem Anbieter.

 

[sia]

@drfuture: welche Software war es denn? Vielleicht können wir exemplarisch daran nachverfolgen, was genau mit dem entsprechenden Image schief gelaufen ist und wie man (=Distributor) es hätte richtig machen können.

 

[drfuture]

War Guacamole

und davor eine cloud-lösung - seafile war es glaube ich nicht - komme gerade nicht drauf - die werben extra damit das man nur einen container läd und startet und schon geht es ... irgendwas mit p...
Bei dem dann auch veraltete Server-Komponenten verbaut waren.

Ich sehe den Vorteil von Containern wenn ich z.B. eine Farm an Wordpress betreibe und an einem Tag 500 Instanzen brauche und dann 1000 von eigentlich dem "gleichen" - dann kann ich schnell mal ein paar mehr starten und das ohne weiteren Aufwand - und Pflege das eine Image.

Aber in der realität sieht es für mich halt so aus das "normal / früher"
Server-Admin installiert Webserver, Datenbank usw... und ist verantwortlich diese zu Pflegen. Das macht er mal... mal nicht.

"Heute" (Je nach Software natürlich... aber als Wunschbild das man auf Container setzen soll..)
Software wird als Docker zur Verfügung gestellt, Datei kommt "alles" mit was die Software benötigt.
Je nach Server-Admin habe ich dann den gleichen Dienst 2x laufen - 1x im Grundsystem 1x im Docker-Image
Der Software-Entwickler bietet das Docker-Image an um den Einstieg zu erleichtern - pflegt aber selber lieber seine Server + Software und das Docker-Image veraltet extrem.
Müsste man auch nicht wegen nur 10kb Sicherheitslücke in z.B. php - wenn das im Docker-Image ist - das ganze Docker-Image neu downloaden? Oder geht das als Differenz?

Docker ist nicht grundsätzlich mist - aber genauso wie Virtualisierung muss man sich den Einsatzzweck anschauen und solche Dinge wie VDI, Docker und ähnliches wird oft als Lösung für "Alles" hingestellt und das so die ganze IT-Welt schöner, einfacher, besser wird.
Ich bin eher der Meinung man sollte die Strukturen "einfach" halten und schlicht für das geplante Projekt die richtige Lösung wählen - mit allen Abhängigkeiten.

Da hilft es auch relativ wenig wenn man sagt "das wird dann halt falsch verwendet" - wenn ein Tool im großen und ganzen falsch verstanden wird - dann ist es vielleicht dafür auch nicht geeignet (Wie zum Beispiel Software-Lösungen für Jedermann zum Betrieb als Docker-Image zum Download anzubieten).
Dann gehört Docker in vielleicht in die oben genannten Farmen die viele Instanzen von ein und dem selben Dienst zur Verfügung stellen - wobei es sicher noch mehr Anwendungsfälle dafür gibt.