Vagrant: Warum diese Open-Source-Software euer Deployment vereinfacht – eine Einführung
Wer heute Web-Anwendungen entwickelt, weiß: Mit einem Tool oder einer Library ist es nicht mehr getan. Es gibt verschiedenste Server, Programmier- und Skript-Sprachen sowie Datenbanken, die eingesetzt werden. Kurzum: Die Komplexität, um Anwendungen entwickeln zu können ist, im Vergleich zu den klassischen PHP-/MySQL-Projekten aus der Zeit, in der noch die Browser-Kriege gewütet haben, gestiegen.
Hier kann und will Vagrant Entwicklern helfen – in Gestalt einer Shell. IT-Admins wiederum können Vagrant einsetzen, um ihre Provisioning-Prozesse zu vereinfachen.
Admin oder Entwickler: Warum du Vagrant nutzen solltest
Die Open-Source-Software Vagrant hat sich, neben Docker oder klassischen virtuellen Maschinen, schnell zu einem Entwickler-Tool der Superlative entwickelt. Warum? Weil ihr mit Vagrant die Zeit, die ihr für das Aufsetzen der Entwicklungsumgebung benötigt, drastisch verkürzen könnt. Früher hat sich jeder Entwickler lokal alle Tools installiert, die er braucht. Wer dieses Konzept ins Heute überträgt, merkt schnell: Dieser Workflow ist nicht mehr zeitgemäß, neben unterschiedlichen Ziel- und Entwicklungssystem oder der Entwicklung innerhalb eines Teams gibt es weitere Nachteile:
- Die Entwickler müssen ihre Tools, die vielleicht sogar OS-abhängig sind, manuell installieren und warten.
- Mehrere Projekte sind nicht komfortabel zu warten, denn jedes Projekt benötigt üblicherweise eine eigene Konfigruation.
- Die Installation ist oft nicht so schwierig wie die Konfiguration der eingesetzten Software.
- Unterschiedliche Betriebssysteme innerhalb eines Entwickler-Teams sind ebeso eine Herausforderung wie der Versuch, die Entwicklungsumgebungen samt der Entwickler synchron zu halten. Jeder Entwickler hat seine eigene Entwicklungsumgebung – und das lokal.
All diese Probleme kann Vagrant lösen, indem die Software die komplette Installation, Konfiguration und Wartung einer kompletten Entwicklungsumgebung samt Betriebssystem übernimmt.
Du möchtest wissen, wie OKR deine Unternehmensführung modernisieren kann? Dann melde dich zum Seminar „OKR ganzheitlich verstehen und anwenden“ an! Auf 20 Teilnehmende limitiert!
Vagrant: Warum nicht Container oder klassische Virtualisierung?
Natürlich könnt ihr alles, was Vagrant leistet, auch mit einer klassischen Virtualisierung erreichen. Allerdings wäre der Aufwand nicht gerade trivial, gerade bei Cross-Plattform-Szenarien. Außerdem stellen euch Container wie zum Beispiel Docker beziehungsweise LXC oder OpenVZ keine Virtualisierung zur Verfügung, sondern kapseln Software in Umgebungen, die den selben Kernel nutzen. Der große Vorteil: Sie haben nicht den selben Overhead wie eine Virtualisierung, da sie einfach nur ein weiterer Prozess innerhalb eines Systems sind. Der Nachteil: Ihr könnt nur den Kernel laufen lassen, der am Gast-System verfügbar ist – also beispielsweise keinen Windows-Container auf einem Linux-System.
Darüber hinaus sind Container vom Betriebssystem abhängig: OS X oder Windows unterstützen keine Container, FreeBSD nutzt Jails und Linux unterstützt LXC und OpenVZ. Somit wird ein ganzes Team gezwungen, auf einem bestimmten Betriebssystem unter der Verwendung neuer Tools zu entwickeln. Vagrant verfügt außerdem über das sogenannte „Vagrant-File“, das über herkömmliche Versionsverwaltung an alle Entwickler verteilt werden kann. Somit kann jeder Entwickler mit dem Zauberwort vagrant up
eine Entwicklungsumgebung erschaffen, ohne sich darüber bewusst sein zu müssen, wie das System konfiguriert wurde oder welche Infrastruktur darunter liegt. Über die Vagrant-Shell ist es außerdem ein Leichtes, die virtuelle Maschine zu starten, zu pausieren oder zu zerstören.
Vagrant ermöglicht euch somit den Einsatz der eigenen Tools und Editoren, das effiziente Zusammenarbeiten im Team – unabhängig von der darunterliegenden Infrastruktur oder dem Gast-System.
Ihr könnt euch den Vagrant-Installer auf GitHub oder der offiziellen Seite herunterladen. In einem weiteren Artikel erklären wir euch in Kürze, wie genau ihr Vagrant einsetzen könnt.
Setzt ihr Vagrant in eurem Workflow ein?
Vagrant is toll.
Dito! :)
Mit Technik lösen wir Probleme, die wir ohne sie nicht hätten. Ich habe immer einen Klon meines Live-Servers im Netz, auf dem ich bei Bedarf einen neuen Account anlegen und mit einem vHost verknüpfen kann.
Der Aufwand liegt bei Minuten, ist auch genauso schnell wieder gelöscht und das Ganze kann von jedem Ort und auch von jedem Kollegen genutzt werden, sollte man mal spontan krank oder abwesend sein. Nicht so nerd-isch, aber reicht in 98% der Fälle. :)
Geht das jetzt nicht am Thema vorbei? Angenommen Sie haben eine Rails 2 Applikation im Netz auf einem „Entwicklungsserver“ was würde es mir als Entwickler helfen wenn ich darauf per SSH zugreifen kann?
Für sehr stark verbreitete Skriptsprachen (PHP/Javascript) mag ihre Lösung sicherlich funktionieren. Wenn aber Dependencies verlangt werden, die nicht jeder Rechner mit einem One-Click-Installer erlangen kann sehe ich den Sinn der Sache nicht ;-)
Ich bin tatsächlich mehr in der PHP-Ecke zu Hause und Vagrant hat sicherlich seine Berechtigung, insbesondere bei großen Projekten oder halt Rails, ich wundere mich nur manchmal über den Aufwand, den manche selbst für kleinste Projekte betreiben – gefühlt, einfach weil sie es können. Vagrant war hier letztens auch mal wieder das Buzzword, ohne dass mir zumindest in unserem Kontext wirklich jemand erklären konnte, wo genau der Vorteil liegt (außer dass es state of the art ist und alle professionellen Entwickler das verwenden und so). Daher konnte ich mir den Kommentar nicht verkneifen …
@Thomas D.: Aufwand? Bei mir ist innerhalb weniger Minuten (eigentlich nur 20 bis 45 Sekunden) eine Box einsatzbereit.
Gibt es die schon komplett voreingerichtet oder wie kriegst du da so schnell die ganze benötigte Software in der richtigen Version drauf?
Vagrant steht zumindest immer noch auf meiner todo-Liste, aber ich hatte da mal so ein cooles und schwer zu toppendes Cloning-Feature, das mir immer meinen kompletten Live-Server in eine neue Instanz gespiegelt hat. Letztendlich muss die Entwicklungsumgebung vor allem mit dem späteren Produktiv-System synchron laufen und ich persönlich bin auch kein Fan von lokalen Installationen, da ich sehr häufig von verschiedenen Orten und Rechnern arbeite und da ist ein echter Server kaum zu toppen.
Du kannst das vielfältig Handhaben. Canonical stellt z.B. mittlerweile abgespeckte Images als Vagrant-Box bereit, die du nutzen kannst. Das wird in deinem Vagrant-File gespeichert, zusammen mit ein paar Einstellungen wie z.B. Ports oder Freigaben.
Ich nutze für meine PHP-Entwicklungen immer ein einfaches Shell-Skript, was per apt-get die üblichen LAMP-Anwendungen installiert und meine eigene Apache- und PHP-Konfiguration importiert.
Wir uploaden dann direkt aus der ide in die Maschine, da der Shared Folder etwas langsamer ist ;)
Hallo,
entspannt euch. Vagrant hat sicherlich seine Vor- und Nachteile für mich als Webentwickler sicher nicht so gut zu gebrauchen wie für andere. Ich selbst deploye dann lieber mit Git. Das Geht schnell und das hin und her springen geht auch besser. Zumal ich meine Projekte eh immer alle in der IDE habe.
Bei meinem Lokalen XAMPP kann ich dann auch noch schnell selber den aktuellen Pfad zu Config ändern.
Ich finde es ein wenig übertrieben. Zumal sich die Software so weit ich weiß auch nicht von alleine Updatet in der Box oder?
Irgendwie sieht hier keiner die Vorteile von Vagrant.
ALSOOO .. mit einer kleinen Datei die man quasi mit jedem teilen kann, können die gleichen Bedingungen auf allen Rechnern erzeugt werden. Dies beinhaltet auch einen Ordner der in der virtuellen Maschine eingebunden wird. Ich bearbeite also in der ganz normalen IDE die Daten (wie bisher auch) und wechsel dann in den Browser (wie bisher auch) wo ich einfach auf den Guest zugreife. Wenn ich dann noch localhost auf die Guest-IP lege merke ich auch hier keinen Unterschied.
Bei uns haben wir uns aber entschieden localhost.dev zu nutzen. Fertig. Und es ist KEIN FUCKING AUFWAND!
Ich habe gerade mal ein wenig nach gelesen. Is ja schön und gut was damit geht und was nicht. Aber ich sehen davon immer noch nicht den großen nutzen.
ich sehe eher das Problem das es wieder eine Stelle gibt die mir Probleme macht. Linux, XAMPP, Git, Jenkins, Div Frameworks, Composer und so weiter und so fort. Alle das bringt irgendwie Probleme und immer mehr Einarbeitungszeit mit sich. Einfach los programmieren wie früher ist wohl unerwünscht.
@Jens
Das Schön ist ja, dass man mit Vagrant wenig kennen/können muss. Ja gut einer muss die Konfiguration schreiben, aber alle anderen müssen sie einfach nur nutzen und sich nie wieder Gedanken um die Entwicklungsumgebung machen. Kleine Dreingabe, die Konfiguration entspricht 100% dem Livesystem.
Wir verwenden Vagrant schon lange, heute kam jemand zum Probearbeiten, ein „vagrant up“ kurz warten und die Umgebung steht. Leichter gehts echt nicht.
@Jens
Linux, XAMPP( er meint eigentlich LAMP[Linux, Apache, Mysql, Php/Perl ???]),… machen probleme. lol. auf welchem system/software meinst du denn das deine software deployed wird… und du hast recht, einfach los programmieren ist nicht erwünscht, wars aber auch noch nie, man sollte sich schon gedanken über den entwicklungsprozess machen.
schau mal her, auf windows web andwendungen entwickeln, also auf diesem komischen xampp stack, macht doch eh wenig sinn wenn deine anwendungen wo anders laufen sollen, daher vagrant, da kann vagrant so tun als wär es dein server…
ach ja, php ohne composer, framework, versionsverwaltung is ja eh quatsch, also ohne diese „probleme“ kannste es ja eh vergessen irgendwas anständiges in php zu programmieren…
und, kein anständiges projekt oder firma kommt mehr ohne vagrant daher, guck ma auf github, manchmal kann man auch von anderen leuten was lernen :) …
grüße,
jan
Um mal den Arbeitsflow zu beschreiben, eventuell wird es somit einigen klar:
Mein Team und ich erstellen bspw. auf https://puphpet.com/ eine Konfigurationsdatei. Dazu laden wir uns noch Vagrant und (Programm deiner Wahl – ich habe Oracle VM Box) runter. Die Konfiguration einfach irgendwo ablegen. In der Shell ein vagrant up. Dann beim ersten Start ~5 Minuten warten. Dann läuft es. Fertig. Und jeder hat das gleiche OS zum entwickeln.
Durch die Einbindung von Scripten kann man Datenbanken erstellen, Software installieren oder sonst irgendwas machen.
Ich bleibe dabei: Vagrant ist toll.