Vagrant oder Docker?

[sbrosch]

Hallo PHP-Community,

ich habe gestern bemerkt das MAMP im Moment nur bis PHP 5.5 verfügbar ist. Da ich aber PHP 5.6 brauch um PHPUnit auszuführen, habe ich mich etwas umgeschaut. Neben XAMPP bin aber auch auf das Thema Vagrant und Docker gestoßen. Dabei hat mir Vagrant wirklich sehr zugesagt, da ich hier alles konfigurieren kann. So hätte ich in Zukunft auch die Möglichkeit eine neue PHP-Version zu installieren ohne groß was ändern zu müssen.

Hat von euch schon jemand mit Vagrant gearbeitet und ein paar Erfahrungen teilen kann?

Ich tendiere momentan zu Vagrant da mir das recht einfach aussieht.

Gruß S. Brosch

[ChristianK]

Ich behaupte, dass man Docker und Vagrant nicht auf die gleiche Schiene setzen kann. Beide lösen ähnliche Aufgaben, jedoch ist es eben ganz und gar nicht das gleiche. Docker bietet eine Virtual Environment an, während Vagrant eine virtuelle Maschine anbietet. Siehe dazu z.B. auch: https://www.scriptrock.com/articles/docker-vs-vagrant .

Ich persönlich setze Vagrant ein, das allerdings mehr aus dem Grund, da ich mit Docker in den ersten Minuten nicht gleich klargekommen bin.

[ericle]

Mir fällt dazu ein, dass sich bei Docker nicht mal eben schnell etwas nachrüsten / upgraden lässt (Software, libs etc). Es müsste dann das image + container neu gebaut werden.
Ich denke daraus resultiert auch folgendes: http://www.golem.de/news/studie-dock...05-114310.html

[rudygotya]

Mir fällt dazu ein, dass sich bei Docker nicht mal eben schnell etwas nachrüsten / upgraden lässt (Software, libs etc). Es müsste dann das image + container neu gebaut werden.

Nö, musste nicht. https://docs.docker.com/reference/commandline/commit/

Was die Sicherheitslücken aus dem golem-Artikel anbelangt, hat das beim lokalen Entwickeln wenig Bedeutung. Beim Produktiveinsatz wird bspw. die SSL-Konfiguration i.d.R. per Volume in den container gemountet. Und ohne code review (egal ob vagrant box oder dockerfile) übernimmt bestimmt kein Admin einfach so ein image.

Vagrant boxes sind schnell hochgezogen. Wenn du schnell eine Entwicklungsumgebung willst, du nicht viel Zeit in die Einarbeitung investieren möchtest und sich dein setup & deine tools nicht groß ändern (bspw. du immer mit einem standard lamp stack arbeitest), ist das der einfachere/bequemere Weg.

Docker rentiert sich dann, wenn du oft flexible Anforderungen lokal abbilden willst und das Produktivsystem auch auf Linux läuft. docker-compose ist echt geil und der Overhead im Vgl. zu vagrant deutlich kleiner (arbeite hier auf nem Linux Desktop, kA, wie das mit docker machine auf dem Mac aussieht).

[JPlace]

Ich kann dir zwei Szenarien für die genannten Art und Weisen nennen.

Vagrant ist eher besser für den Entwickler geeignet, weil es Systemnaher mit dem Betriebssystem des Entwickler agiert. Die Dienste laufen alle auf dem eigentlichen Rechner und werden nur durchgereicht, also nur eine emulierte Virtualisierung.

Docker hingegen ist ein Container, der eigenständiger agiert und beim hochfahren aus dem Image immer wieder den selben Zustand hat. Hat bei mir auf der Arbeit den Sinn und zweck für autom. Release-Tests, die auf den verschiedenen Versionen laufen. Diese laufen dann meist nur im Speicher und werden nach Abschluss wieder zerstört.

[rudygotya]

Vagrant ist eher besser für den Entwickler geeignet, weil es Systemnaher mit dem Betriebssystem des Entwickler agiert. Die Dienste laufen alle auf dem eigentlichen Rechner und werden nur durchgereicht, also nur eine emulierte Virtualisierung.

Mhm - eigentlich nicht so wirklich. I.d.R. virtualbox/vmware als Provider (https://docs.vagrantup.com/v2/providers/index.html) => virtuelle Maschine. Im Unterschied zu docker muss man sich bei einer VM nicht um den initrd kümmern (PID1). Bei docker linkt man abhängige Dienste wie MySQL dynamisch in den Anwendungscontainer (bspw nginx + php fpm), in der VM laufen die Dienste i.d.R. alle in der VM.

Docker hingegen ist ein Container, der eigenständiger agiert und beim hochfahren aus dem Image immer wieder den selben Zustand hat. Hat bei mir auf der Arbeit den Sinn und zweck für autom. Release-Tests, die auf den verschiedenen Versionen laufen. Diese laufen dann meist nur im Speicher und werden nach Abschluss wieder zerstört.

@JPlace: Schönes Beispiel! Ein `docker run` erzeugt eigentlich immer einen persistenten Container auf der HDD, hast du die Container auf einem tmpfs liegen?
@TE: Dafür ist es wichtig, sich den Unterschied Image/Container bewußt zu machen. Wenn du die Container-Instanz nicht zerstörst, kannst du diese auch wieder ganz normal starten (docker start/stop containerid).

[ericle]

Nö, musste nicht. https://docs.docker.com/reference/commandline/commit/

Kommt immer darauf an. Ein OpenSSL update mit seinen 90 Dateien (bei Debian) stell ich mir mit einem commit schwierig vor. Hinzu kommt, dass dir niemand sagt was im Image geupdatet werden sollte. Oder gibt es mittlerweile ein paket manager fürs OS?

Aber stimmt schon. Für lokale Umgebungen kann man das vernachlässigen.

[rudygotya]

Oder gibt es mittlerweile ein paket manager fürs OS?

Hö? Natürlich

Ian Murdock has commented that package management is "the single biggest advancement Linux has brought to the industry", that it blurs the boundaries between operating system and applications, and that it makes it "easier to push new innovations [...] into the marketplace and [...] evolve the OS"

was debian anbelangt:security updates kann man sich auch automatisiert installieren lassen. Hier mal ne Übersicht für die verschiedenen Distros/Paketmanager: https://wiki.archlinux.org/index.php/Pacman_Rosetta

[ericle]

Hö? Natürlich

Hehe...

Ich meine doch fürs docker image OS.

[rudygotya]

Nur Verrückte bootstrappen container ohne Paketmanager.

[ericle]

Schon klar. Was ich meine:
Man benötigt doch in jedem Fall ein OS base image layer (debian, ubuntu, opensuse etc). So, und wenn ich jetzt in diesem OS base image eine lib aktualisieren will ?

[rudygotya]

Naja, da haste verschiedene Möglichkeiten, je nachdem, was du machen willst und was dir die Repos anbieten. Bspw. kannst du einen docker hub auch selbst hosten
1) image neu bauen und committen (docker hub baut das image dann über einem post commit hook getriggert neu)
2) remote docker image update `docker pull imagename`

Macht man eigentlich nur zum Testen/während der Entwicklung/wenn's mal schnell gehen muss:
3) Paketverwaltung (apt, yum,...)
4) von Hand kompilieren, Paket erstellen und übe Paketverwaltung installieren (bspw debian configure, make, checkinstall)
5) Paket an der Paketverwaltung vorbei von Hand übersetzen und installieren (configure, make, make install). Macht man eigentlich nicht.

zu 1) damit das Caching über das docker FS schneller geht, sind ADD/COPY Befehle im Dockerfile so weit hinten wie möglich. Damit werden dann Updates aus den Repositories während der Entwicklung nach einmaligem Ausführen gecacht. Um ein Update zu erzwingen, setzt man an den Anfang des Dockerfiles einen Timestamp.
https://github.com/shoifele/nginx/bl.../Dockerfile#L8
Um das Update zu erzwingen, musste an der Stelle das Datum austauschen und die weiteren Schichten aus dem Docker FS werden invalidiert. https://github.com/shoifele/nginx/bl...r/Makefile#L16

[ericle]

Ok. Danke!

SUSE hat da was nettes zum Thema image patching:
https://github.com/SUSE/zypper-docker

Aber ich glaube es wird OT

[mbunge]

Wenn du deinen xampp, mamp, wamp ersetzen willst, dann empfehle ich vagrant und dazu noch Scotch.box von http://scotch.io. Alternativ sollte man ein Auge auf http://ottoproject.io werfen.