News Linux-Kernel: Container von Docker und CoreOS Rocket aktualisiert

[fethomm]

Die Teams von Docker und CoreOS haben ihre Container-zentrierten Laufzeitumgebungen aktualisiert. Docker 1.10 und CoreOS Rocket 1.0 setzen beide auf verstärkte Sicherheit. Beide nutzen dazu unterschiedliche Funktionen des Linux-Kernels.

Zur News: Linux-Kernel: Container von Docker und CoreOS Rocket aktualisiert

 

[Tumbleweed]

Zudem kann Compose sich jetzt in Repositories bedienen anstatt alle Images selbst zu bauen.

Wenn ich dich nicht falsch verstehe - das ging schon ewig (immer?). Statt selbst zu bauen konnte man wie beim FROM-Befehl einfach ubuntu:latest o.ä. schreiben.
Ich bin generell ein ziemlicher compose hater. Ich liebe Docker, aber compose ist der sinnloseste Schnulli, den ich seit langem gesehen habe. Es ist nichts weiter als eine alternative Syntax für 'docker run' plus ein paar convenience-Befehle wie 'docker-compose rm', was man sich aber auch selbst basteln kann, mit einfachsten Shell-Mitteln. Compose ist für banale Anwendungsfälle ganz nett, aber ich muss oft dynamisch zur Startzeit verschiedene umgebungsabhängige Werte bestimmen, die ich dann als Parameter in den Container stecke. Das geht mit compose einfach nicht, weil man im YAML gefangen ist. Da lobe ich mir doch ein normales Shell-Script, in dem ich mich austoben kann und die volle Kontrolle über die 'docker run'-Parameter habe.

Aber abgesehen davon - Docker ist für mich einer der wenigen Hypes, wo wirklich was Handfestes dahinter steckt. Schön, dass es sich so etabliert hat und aktiv vorangetrieben wird.

 

[Ganjaware]

Ich habe leider nicht viel Verstanden, ist das was ähnliches wie in Windows eine Anwendung in einer 'Sandbox' laufen zu lassen?

 

[mensch183]

Docker ist für mich einer der wenigen Hypes, wo wirklich was Handfestes dahinter steckt.

*hust* Was denn? Um ordentliche Softwareintegration zu vermeiden, wird versucht, das "Problem" mit gewaltigen zusätzlichen Ressourcen und einer zusätzlichen Komplexitätsschicht zu erschlagen? Yeah!

 

[vincez]

Wünschen Sie etwa, dass Ihre Software in einem Datenzentrum mit Software anderer Nutzer ungefragt integrieren kann?

 

[Tumbleweed]

Docker erlaubt saubere Trennung verschiedener Technologiestacks auf einem Host ohne den Host mit Abhängigkeiten zu verschmutzen. Zudem ist ein vernünftig gebauter Container auf allen Umgebungen von Dev bis Production nutzbar. Oft genug ist es doch so, dass Dev und Live nichts miteinander zu tun hat und man so unter völlig unrealistischen Bedingungen entwickelt hat.

Seit es Container gibt schrecke ich auch nicht mehr davor zurück Kram vom Source zu kompilieren, wenn es keine passenden Binarys gibt. Ich kann mir z.B. wunderbar einen Apache/Nginx mit passenden Modulen zusammenbasteln und ihn auf verschiedenen Umgebungen reproduzierbar und gleichbleibend ausrollen ohne jedes Mal den gleichen Krampf zu haben (ja ich weiß sowas geht mit ansible und co. auch, aber diese Technologien widersprechen sich ja nicht).

@Ganjaware: im Prinzip ja, aber nicht so schwergewichtig wie eine VM.

 

[mensch183]

Docker erlaubt saubere Trennung verschiedener Technologiestacks

oder ohne Schönsprech:
"erlaubt und fördert gedankenlose Mehrfachinstallation gleicher Softwarestacks, damit niemand über den eigenen Tellerand schauen muss und die Leichen im eigenen Keller nicht beim Nachbarn zu riechen sind"

 

[Tumbleweed]

Aha, dein Argument ist also "man sollte lieber korrekt arbeiten, dann hat man das Problem nicht". Sag ich ja auch immer. Deswegen verstehe ich die ganze TDD-Bewegung nicht. Schreibt doch einfach korrekten Code!

Was ist denn deine Antwort auf das Problem? Ansible/Chef/Puppet? PaaS? Oder gute alte Handarbeit von Admins, die wissen, was sie tun?

 

[toxic999]

Kann das irgendjemand für DAUS erklären? Ich kenne mich ein wenig mit Linux aus, aber was bedeuten diese ganzen Container, Docks usw?

 

[Tumbleweed]

Container nutzen ein paar Kernel-Features, um Prozesse voneinander zu isolieren. Jeder Container ist sein eigenes kleines Ökosystem, mit eigenen Libs, eigenen Usern, eigenen Netzwerkinterfaces (die über eine Bridge des Hosts nach draußen funken). Aus dem Container rausfunken (ins Netzwerk) darf alles. Will man allerdings rein, geht das nur über geforwardete Ports.

Die Container werden aus Images gebaut, die wiederum aus einer Art "Rezept", einer Beschreibung in Docker-Syntax erstellt werden. Da steht sowas wie:
- basiert auf Ubuntu
- apt-get install dies und das
- starte als Prozess mit ID 1 jenes

Das heißt du kannst zum Beispiel einen Debian-Container mit einem Apache machen, daneben stellst du einen CentOS-Container mit MySQL, daneben ein Ubuntu mit Postfix. Die Container kannst du auch miteinander verbinden (linken), um Interaktion zu erlauben. So hast du also deine kleine Systemlandschaft definiert und kannst sie mit verschiedenen Tools (wie compose oder swarm) bequem managen.

Alle diese Container laufen dann z.B. auf einem RHEL-Host. Die einzige Limitierung ist der Kernel des Hosts. Der muss frisch genug sein. Du kannst also nicht einen nagelneuen Ubuntu-Container auf einem uralten RHEL 5 nutzen, denn obwohl da scheinbar eigene OS in den Containern laufen, ist es doch nichts weiter als ein Durchreichen der Kernelbefehle an den Host. Es sind eben keine virtuellen Maschinen. Dadurch kannst du viele von ihnen nebeneinander betreiben, wobei dir bei echten VMs schnell der RAM ausgehen würde, weil soviel OS-Ballast mit hochfährt.

Das Filesystem von Containern sind zahlreiche übereinander liegende read-only Schichten. Das Filesystem eines Ubuntu-Baseimage ist quasi ein Snapshot eines Filesystems, nachdem eine minimale Installation durchgeführt wurde. Möchtest du daran etwas ändern, änderst du nicht diese Schicht, sondern es wird nach dem "copy on write"-Prinzip im Moment des Schreibens eine weitere Schicht draufgelegt, auf der du dich dann auslassen kannst.

Für GUI-Anwendungen ist es z.B. ziemlich ungeeignet. Man kann zwar mit VNC rumfummeln oder den X-Server-Socket mounten, allerdings finde ich das alles zu frickelig. Man merkt einfach, es ist dafür nicht gemacht. Vielleicht ändert sich das später mal, aber der hauptsächliche Anwendungsfall sind Konsolenanwendungen auf Servern.

Weiß nicht, ob das jetzt wirklich "DAU"-gerecht war, aber für den unbedarften Enduser ist der ganze Kram auch nicht so interessant, daher mach dir nichts daraus, wenn du es nicht komplett verstehst. Du verpasst da nichts.

 

[chithanh]

Seit es Container gibt schrecke ich auch nicht mehr davor zurück Kram vom Source zu kompilieren, wenn es keine passenden Binarys gibt. Ich kann mir z.B. wunderbar einen Apache/Nginx mit passenden Modulen zusammenbasteln und ihn auf verschiedenen Umgebungen reproduzierbar und gleichbleibend ausrollen ohne jedes Mal den gleichen Krampf zu haben

Ich würde sagen, dann verwendest du einfach die falsche Distribution. Unter Gentoo ist es kein Problem, dem Paketmanager mitzuteilen, welche nginx-Module gewünscht sind, und welche nicht.

 

[Tumbleweed]

Zig Server mit Gentoo betreiben, echt? Und das bei Tagessätzen von über 1k €. Da würde mich aber der Kunde doof angucken, warum alles so lange dauert und dementsprechend kostet.

Nein danke, Gentoo tue ich mir nicht einmal auf dem Desktop an. Auf dem Server wäre das ein Himmelfahrtskommando. Selbst wenn ich Vollzeit-Admin wäre - auch die haben Besseres zu tun.

 

[Bruddelsupp]

@Tumbleweed: Ne war super danke!