LXC und Docker wasn nun?

[Colttt]

Hallo,

aktuell existiert ja ein kleiner Hype um Docker, obwohl es mittlerweile auch etwas umstritten ist und alternativen entwickelt wurden (Bsp: Rocket. Ursprünglich setzte Docker ja auf LXC auf mittlerweile hat es seine eigene API zum Kernel.

Nun stellt sich mir die frage was hat vor und nachteile? Lohnt es sich noch in LXC ein zu arbeiten oder sollte man gleich Docker nehmen? Ich hatte gelesen das Docker auschliesslich für Anwendungsvirtualisierung gut ist, LXC man eher eine VM hat.

Also, was sollte man nehmen/eher ein arbeiten, was sind die vor und nachteile? Kann man mit LXC/Docker auch Virtualisierunstypische sachen machen wie Snapshots, Data/Hostmigration?

Danke schonmal für die Infos/Hilfe!

[Colttt]

Keiner?

[TRex]

Stand kürzlich vor der selben Frage, habs mir aber selbst noch nicht beantwortet...

[peschmae]

Ditto, benutze derzeit noch LXC weils das halt schon länger gibt und ich weiss wies geht.

Die Docker-Tutorials die ich bisher durchgeblättert habe waren mir zu nervig, technisch zu wenig konkret und voll marketingsprechbla, Und haben imo wichtige Sachen ausgelassen (updates, wie macht man docker-container selber, wie gehen all diese abstrakten Service-Konzepte denn wirklich auf Netzwerkebene (wer spricht mit wem wie) etc, genau das was ich eigentlich wissen wollte. Ein Grossteil der wirklich interessanten Sachen sind wohl auch eher erst mal noch Visionen).

Allerdings ists nicht ausgeschlossen dass Docker genau meine aktuellen Probleme (wie deploye ich einen LXC-Container auf viele Maschinen und halte die synchron und aktuell) ganz nett lösen könnte. Hatte bisher nur noch nicht die Zeit mich da reinzufummeln.

MfG Peschmä

[Colttt]

mal gucken ob die Kollegen etwas mehr sagen können..

http://forum.ubuntuusers.de/topic/lxc-u ... -wasn-nun/

[rendegast]

Und haben imo wichtige Sachen ausgelassen ....

Das scheint schon irgendwo zu stehen, da wohl massenhaft fertige docker-Container zum Download stehen.

Ich sehe das Problem eher bei diesen fertigen Containern, die hinz und kunz wohl hochladen resp. anbieten kann.
Die Dinger werden angeboten wie apps, obwohl sie lauffähige Betriebssysteme darstellen,
hallo Backdoor.

[novalix]

Ich unterschreibe @peschmaes Aussage. Habe mich vor einigen Monaten mal mit docker auseinander gesetzt und wusste nicht wirklich, was das jetzt soll, wenn ich lxc schon zur Hand habe. Das heisst selbstverständlich nicht, dass es keine Gründe gibt docker zu verwenden. Ich habe sie nur nicht gefunden.

[peschmae]

Und haben imo wichtige Sachen ausgelassen ....

Das scheint schon irgendwo zu stehen, da wohl massenhaft fertige docker-Container zum Download stehen.

Ich sehe das Problem eher bei diesen fertigen Containern, die hinz und kunz wohl hochladen resp. anbieten kann.
Die Dinger werden angeboten wie apps, obwohl sie lauffähige Betriebssysteme darstellen,
hallo Backdoor.

Genau, die will ich natürlich nicht benutzen. Das wäre ja noch schöner.

Das muss schon irgendwie aus Debian-Repos gebaut werden. Und genau der Teil fehlt mir bisher in den Anleitungen (die ich ohne da jetzt Stunden zu verbraten gefunden habe)...

MfG Peschmä

[rendegast]

https://docs.docker.com/userguide/dockerimages/
"Building an image from a Dockerfile"

Code: Alles auswählen

$ mkdir sinatra
$ cd sinatra
$ touch Dockerfile

...
(Dockerfile:)

Code: Alles auswählen

# This is a comment
FROM ubuntu:14.04
MAINTAINER Kate Smith <ksmith@example.com>
RUN apt-get update && apt-get install -y ruby ruby-dev
RUN gem install sinatra

Daran stört mich nur das 'FROM ...'.
Wird wohl letztendlich ein tar (o.ä.) oder fs-Image eines debootstrap o.ä. sein.
(Bei 'lxc-create' wäre es eine Kopie einer Vorlage aus /var/cache/lxc/,
im Falle eines debian ein debootstrap-Template.)
Mal ein paar docker-Images herunterladen, analysieren und nachbauen.

Das automatische failback auf die Registry ("app-store") ist wohl ein Teil des Geschäftsmodells.

[peschmae]

Hmm, ja, die Doku sieht ja ganz ordentlich aus. Dem war noch nicht so als ich das letzte mal da reinguckte. Und in der Zwischenzeit hab ich immer nur die Sales-Pitches mitgekriegt...

Muss mir das noch mal genauer angucken.

Wobei da liest man dann so Sachen

Avoid RUN apt-get upgrade or dist-upgrade, since many of the “essential” packages from the base images will fail to upgrade inside an unprivileged container. If a base package is out of date, you should contact its maintainers. If you know there’s a particular package, foo, that needs to be updated, use apt-get install -y foo and it will update automatically.

und überlegt sichs vielleicht doch noch mal anders... - updates war genau das Problem was ich mit Docker lösen wollte u.A.

Wobei andererseits müsste ich dann wohl eh selber Images maintainen, von dem her müsste ich mich selber kontaktieren um das zu tun.

MfG Peschmä

[rendegast]

Es geht da nicht um Upgrade an sich, sondern um Upgrade (essentieller) Pakete in einem unpriviliged Container:

Avoid RUN apt-get upgrade or dist-upgrade, since many of the “essential” packages from the base images will fail to upgrade inside an unprivileged container.

Die entsprechenden Pakete benutzen wohl Sachen, die in einem unpriviliged Container einfach nicht zur Verfügung stehen.

Ich denke da an vielleicht /dev/pts/* ...

Der Container müßte dann vielleicht mal priviliged gestartet werden,
vielleicht sind entsprechende Ressourcen auch zur Laufzeit zuteilbar/entziehbar.

[Debian_anwaerter]

Hallo,
zuerst muss ich erwähnen das lxc und Docker recht gut an mir vorbeigegangen ist. Erst seit ein paar Tagen entdecke ich langsam die Vorteile der Container-Idee.
Ich habe zuerst mit Docker angefangen und die Vorteile liegen auf der Hand. Schnelle Installation, mit einer einfachen Datei (Dockerfile) sein eigenes Betriebssystem zusammenbauen und somit auch austauschen. Die Container lassen sich gut unter den Betriebssystemen austauschen. Der Nachteil ist selbst bei einer Dockerfile das Backdoor in das eigene OS. Im realen Betrieb lese ich mir selbst keine ganze Dockerfile durch ob dabei Schadcode mitgeliefert wird.

Bin aber von Docker weggefallen weil ich die Container für Spiele benutzen wollte und mit Docker konnte ich keine OpenGL Spiele starten. Deshalb habe ich LXC installiert und gemerkt so einfach ist LXC nicht. Alleine als normaler Benutzer ein LXC-Container einzurichten ist eine kleine Herausforderung und dauert mitunter einige Tage. Den größten Ärger habe ich LXC aber unter verschiedenen Host-Systeme. Bis vor 2 Tagen hatte ich Linux Mint 17 auf meiner Festplatte installiert, dabei war LXC als unprivileged Nutzer zu starten nicht ganz so schwer. Jetzt habe ich Linux Debian 8 und die Konfigurationaufgabe ist teilweise eine zu große Hürde.
Selbst das einstellen des Netzwerkes ist unter Debian 8 komplexer als unter Linux Mint 17, dabei musste ich keine Brücke installieren und es funktionierte fast nativ. Mit Debian 8 musste ich eine Brücke auf dem Host installieren und das Guest-System nochmals richtig einstellen.

Ich Kämpfe momentan immernoch mit dem Sound und der Grafikkarte, was unter Linux Mint 17 funktioniert hat bringt mich bei Debian Jessie nicht gerade weiter. Wenn LXC von der Konfiguration leichter wird würde ich eine uneingeschränkte Empfehlung geben. Es ist einfach kein SchnickSchnack herum welches versucht mich zu beeinflussen sondern ein einfaches "Chroot auf Steroide".

[TRex]

Du kannst auch libvirt/virt-manager als Verwaltungshilfe für LXC einsetzen... das geht recht zügig.

[ThorstenS]

Die nächst größere Lösung wäre das neue Proxmox 4. Es beherrscht neben der KVM Virtualisierung auch LXC - als Ablösung für openvz.
Ist flott eingerichtet und läßt sich bequem bedienen.

P.S.
Seit einigen Tagen nutze ich lokal systemd-nspawn unter jessie als Spielwiese für Kleinigkeiten wie Paketbau.
Ist nix persistentes, aber ermöglicht reproduzierbar eine definierte Umgebung, die pfeilschnell zur verfügung steht.
Einfach mal nen debootstrap von wheezy/jessie oder testing hochziehen, git für das komplette / einrichten und sehen, was die einzelnen Pakete so ins System bringen. Ist ne tolle Sache.

[peschmae]

Ich habe in letzter Zeit für einige Sachen angefangen Docker zu benutzen. Ist ganz nett, und die Dokumentation ist wirklich sehr gut.

Vorteile die ich sehe gegenüber LXC

• man wird zu einem "infrastructure as code" setup gedrängt - alles zum Einrichten eines Containers notwendige kommt ins Dockerfile; d.h. man kann den Container später auch mal von Grund auf neu bauen solange man nur ein Backup hat (gleichzeitig überschneidet sich das wohl dann auch etwas mit Systemen wie Chef&Puppet, aber die benutze ich bisher eh nicht)
• die ganze unprivileged-Container Geschichte wird da von Anfang an gemacht (bei LXC müsste man das Mapping von UIDs glaub ich irgendwie selber machen)
• man kriegt ausm Stand etwas das was tut (Netzwerk-Bridge, etc steht schon) - eine kleine Kommandozeile und schon steht da ein Debian-Container
• es ist eine homogene Plattform - Docker ist auf allen Linuxen gleich; mit LXC hatte ich *immer* jede Menge Distributions- und Versionsspezifische hacks (container autostart, devices erstellen, etc) die sich andauernd änderten

Nicht so toll an Docker finde ich bisher

• das Networking - mit 1.9 gibts zwar sehr nette Sachen um Container zu verknüpfen, aber viele der Dinge die ich will erfordern trotzdem Handarbeit; typischerweise alles damit der Container sich in die existierende Infrastruktur integriert (i.e. einen Container an eine bereits existierende Bridge hängen; einem Container verbieten nach aussen zu kommunizieren, etc, das Handzustricken ist oft mühsam und irgendwie muss man dann doch oft die ganzen netten Automatiken abstellen und alle IPs händisch verteilen damit man das in iptables ordentlich verdrahten kann)
• der unbedingte Drang pro Container nur einen Service zu haben - in vielen Fällen macht das die Geschichte ganz nett modular, aber auch gerne mal etwas aufwändiger weil dann alles übers Netzwerk muss
• im Dockerfile steht halt nicht alles; ich habe dann typischerweise pro Container ein Dockerfile, ein handgestricktes shellscript zum image bauen, ein handgestricktes shellscript zum Container ausführen
• durch die zusätzlichen nötigen Verdrahtungsarbeiten führe ich viel öfter Kommandos als root (oder docker-user was quasi das gleiche ist) auf dem Docker-Host aus als vorher mit LXC
• die Verwaltung persistenter Daten mittels Volumes ist ein ziemlicher hack; insbesondere was Backups angeht

MfG Peschmä

[catdog2]

die ganze unprivileged-Container Geschichte wird da von Anfang an gemacht (bei LXC müsste man das Mapping von UIDs glaub ich irgendwie selber machen)
man kriegt ausm Stand etwas das was tut (Netzwerk-Bridge, etc steht schon) - eine kleine Kommandozeile und schon steht da ein Debian-Container
es ist eine homogene Plattform - Docker ist auf allen Linuxen gleich; mit LXC hatte ich *immer* jede Menge Distributions- und Versionsspezifische hacks (container autostart, devices erstellen, etc) die sich andauernd änderten

Ja die normalen lxc tools lassen von der Bedienung her schon noch einige Wünsche offen. Verbessern soll das wohl https://linuxcontainers.org/lxd/introduction/ , hab ich aber auch noch nie benutzt.