Provisionierung von VMs - Wie macht ihr es?

teqqy

teqqy

Enthusiast
Thread Starter
Mitglied seit
30.07.2012
Beiträge
1.162
Ort
Rheinhessen
tl;dr: Der Beitrag richtet sich primär an diejenigen die mit ihren Server auch mal richtig nutzen.

Hallo zusammen,

ich komme immer wieder zu dem Punkt dass ich diverse Dienste oder Funktionen testen möchte wofür ich eine Mehrzahl (> 2) VMs benötigte. Diese würde ich gerne etwas schneller zur Verfügung stellen als das jetzt möglich ist. Zwar setze ich mit ESX 6u2 einen Hypervisor ein, welcher auch mit Templates umgehen kann (mit etwas tricksen in der freien Version) aber dennoch etwas umständlich ist.

Ich würde gerne auf einmal mehrere gleiche VMs mit einer bestimmen vorab Konfiguration erstellen lassen welche ich dann nach so 2 - 5 Minuten vollständig nutzen kann. Anfangs dache ich erst an OpenStack, was allerdings etwas überdimensional wäre, wenn ich nur mit 1 - 2 physikalischen Hosts arbeite. Ganz gut wäre wohl die Arbeitsweise mit Vagrant (via VirtualBox) und Ansible/Puppet für die anschließende Konfiguration. Der große Vorteil wäre hier, dass Windows und Linux VMs schnell aus dem Boden gezogen werden können. Da ich allerdings derzeit primär im Linux Umfeld mich privat fortbilde würde es mir hier schon reichen.

Daher die Frage:
Nutzt ihr daheim überhaupt ähnliche Technologien, oder nehmt ihr euch einfach die Zeit und installiert 4 VMs in Ruhe hintereinander und richtet anschließend eure normale Umgebung ein?

P.S. Ich gucke mir gern alle Lösungen an, solange sie entweder kostenfrei oder für den Heimgebrauch finanzierbar sind! VMUG Lizenz wäre sonst die Notlösung. (Etwas ausführlicher beschreibe ich mein Problem in einem Blogbeitrag bei mir).
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Chef erstellt mir aber ja nicht die VM und installiert das OS, oder? Mir geht es ja eher um diesen Vorgang. Anschließend tendiere ich derzeit eher zu Ansible.
 
Wenn du nur eine simple Testumgebung hochziehen willst, dann wäre ein PowerCLI Script eine relativ simple Lösung.
 
teqqy schrieb:
Nutzt ihr daheim überhaupt ähnliche Technologien, oder nehmt ihr euch einfach die Zeit und installiert 4 VMs in Ruhe hintereinander und richtet anschließend eure normale Umgebung ein?
Zum Vergrößern anklicken....
Habe ich ehrlich gesagt noch nie verstanden, warum manche Leute für jeden Krempel eine extra VM hochziehen. Zu Hause habe ich nur Win 10 in einer VM, weil ich auf das Dual Booten keine Lust mehr hatte. Für den HTPC mache ich Kodi in einen LXC Container rein, aber das nur, weil ich früher mit verschiedenen Home Verzeichnissen und Benutzern rumgefummelt habe, um zwischen verschiedener HTPC Software umschalten zu können.

Bei der Arbeit wäre vermutlich Docker die erste Wahl, wenn die VMs fast identisch sein sollen. Sonst ist Vagrant mit Ansible sicher nicht schlecht und wir machen heutzutage möglichst viel mit Ansible, weil es ein sehr flexibles Tool ist.
 
VirtuGuy schrieb:
Wenn du nur eine simple Testumgebung hochziehen willst, dann wäre ein PowerCLI Script eine relativ simple Lösung.
Zum Vergrößern anklicken....

Aber mit PowerCLI lege ich ja nur die VM an sich an und habe dann noch kein installiertes OS da drin.

fax668 schrieb:
Habe ich ehrlich gesagt noch nie verstanden, warum manche Leute für jeden Krempel eine extra VM hochziehen. Zu Hause habe ich nur Win 10 in einer VM, weil ich auf das Dual Booten keine Lust mehr hatte. Für den HTPC mache ich Kodi in einen LXC Container rein, aber das nur, weil ich früher mit verschiedenen Home Verzeichnissen und Benutzern rumgefummelt habe, um zwischen verschiedener HTPC Software umschalten zu können.

Bei der Arbeit wäre vermutlich Docker die erste Wahl, wenn die VMs fast identisch sein sollen. Sonst ist Vagrant mit Ansible sicher nicht schlecht und wir machen heutzutage möglichst viel mit Ansible, weil es ein sehr flexibles Tool ist.
Zum Vergrößern anklicken....

Es ist einfach immer besser Dinge voneinander zu trennen die nix miteinander zu tun haben. Ich administriere recht viele Windows Netzwerke und wir übernehmen von anderen IT Dienstleistern viele Netzwerke, da gibts einfach so ungeheuer viel scheiße da draußen was nach einiger Zeit so unendlich viele Probleme macht.
Docker schön und gut. Wenn ich nur eine einzelne Anwendung bereit stellen möchte okay. Docker ist mir aber zu "flüchtig". Die Dinge die ich testen möchte sollen länger bestehen und vor allen Dingen auch mehrere Neustarts aushalten ohne große Griffe machen zu müssen, dass die Container weiterhin bestehen bleiben.
 
Also eine komplette Automatisierung muss nicht sooo schwer sein, hat aber ihre Tücken.
Puppet wird bspw. meist in Verbindung mit Foreman eingesetzt. In Foreman klickst du dir eine VM in deinem vCenter zusammen, die dann per PXE bootet, vom DHCP eine IP bekommt und per Kickstart installiert wird. Danach rennt Puppet los und pumpt deine Standardconfig drauf, sowie evtl andere Software. Ich finde Puppet allerdings unnötig komplex, bzw. gefällt mir deren Sprache die man nutzt um Klassen und co zu schreiben nicht so recht. Das ist allerdings Geschmackssache.

Du kannst das ganze auch mit Ansible machen. Da hast du halt keine schicke WebGui, sondern musst die Variablen für die Vm in einem Textfile setzen und ab gehts. Ansible macht auch ohne den Tower Sinn wie ich finde, zur Not baust du dir dann mal selbst eine WebGui. Mit Django geht sowas recht fix. Ansible hat aus meiner Sicht außerdem den Vorteil, dass es einfach ssh nutzt und nicht noch zusätzliche Services einbaut. Mit Ansible kommt man wie ich finde sehr schnell zu Ergebnissen und versteht auch schnell wie der Hase läuft.

Im Grunde ist das jetzt viel zu kurz gehalten und sehr undetailliert, aber wenns detaillierter sein soll sag bescheid.

Chef, Saltstack und wie sie alle heißen habe ich mir ebenfalls mal angesehen und für mich entschieden sie nicht zu nutzen, jeweils aus unterschiedlichen Gründen.
 
Mit dieser Variante lebe ich vielleicht noch hinterm Mond, aber für mich persönlich reicht es.
Eine VM z.B. mit Debian aufsetzen. Ganz normal installieren ohne GUI, Updates fahren. DANN: ein Skript schreiben, welche mir die Netzwerk-Settings abfragt (IP-Adresse, Netzmaske, Gateway, Hostname) und sich danach aus dem "Autostart" entfernt. Dieses Skript in den "Autostart" legen. Diese VM bleibt immer aus und aus ihr klone ich meine VMs, wenn ich ein Linux-System (Debian) brauche. Die VM fährt dann hoch, fragt mich nach der Netzwerkkonfiguration und rebootet dann ncoh einmal. Fertig.

Dauert mit Klonen nur Sekunden bis wenige Minuten.


Um mir den wirklichen Nutzen mal vor Augen zu führen, weil ich dachte, dass es nicht so viel Zeit fressen würde immer wieder neue VMS aufzusetzen und zu installieren, habe ich mal die Zeit gemessen.

Für 3 VMs für ein Ceph-Test z.B. braucht es per:
* Klonen und die Netzinfos eintippen: 3 Minuten
* VMs aufsetzen und installieren: 30 Minuten.


Das ist kein repräsentativer Test, da es das Downloaden der Pakete bei und nach der Installation enthält. Aber es zeigt deutlich wie viel man sparen kann.
 
teqqy schrieb:
Da ich allerdings derzeit primär im Linux Umfeld mich privat fortbilde würde es mir hier schon reichen.

Daher die Frage:
Nutzt ihr daheim überhaupt ähnliche Technologien, oder nehmt ihr euch einfach die Zeit und installiert 4 VMs in Ruhe hintereinander und richtet anschließend eure normale Umgebung ein?
P.S. Ich gucke mir gern alle Lösungen an, solange sie entweder kostenfrei oder für den Heimgebrauch finanzierbar sind!
Zum Vergrößern anklicken....

Hi, ich kenne die Situation.

Mein Problem mit ESXI war die API, die ist nicht kostenlos und viel zu teuer. Über die API könnte man per Kommando automatisch VMs anlegen lassen.
Deswegen bin ich zu Proxmox gewechselt. Die API ist hier offen verfügbar für jeden.

Für die API habe ich mir ein CLI Tool programmiert und bin sehr glücklich.

Was mich nervte: VMs/CTs von Hand anlegen.
Heute dauert es 1 Minute und ein Container (CT) ist fertig installiert (bspw. Ubuntu + Apps und Konfigs).
Ich lege mir hier eine Konfigurationsdatei als Vorlage an (OS, Cores, RAM, HDD, DHCP) und geb nur noch die Benennung für den Container in das CLI Tool ein.
Hier legt man sich natürlich mehrere an, je nach Szenario.

Was mich auch nervte: VMs/CTs von Hand starten oder stoppen.
Ich lege mir hierfür eine Datei, mit den entsprechenden VMs/CTs, an und starte dann per Dateiname mit dem CLI Tool, je nachdem was benötigt wird.
Hier legt man sich natürlich mehrere an, je nach Szenario.
Das dauert heute 5 Sekunden.

Wenn man schnell was ausprobieren will ist das einfach Klasse.
 
+1 für Ansible. Braucht zwar ein bisschen Handarbeit (Shell Skripte für die Provisionierung schreiben), dauert je nach gewünschten Funktionen und Flexibilität schon mal eine ganze Arbeitswoche, dann hast du aber im Groben und Ganzen bei den Servern nichts mehr zu tun, außer vielleicht vor dem Starten in der sshd_config das Root-Login zu erlauben (Debian). Für deine Zwecke reicht wahrscheinlich schon ein einziges yml und/oder shell-Skript aus, da du keine Sonderwünsche abbilden musst. Ansible kann auch für die Abfrage von aktuellen Softwareständen ganz nützlich sein, bei entsprechender Konfiguration kann man auf einen Schlag die installierten Versionen einer bestimmten Software auf allen Servern abfragen. In meinen Skripts die absolute Lieblingsfunktion. Ich würde jedoch empfehlen, die Ansible-Version von Debian Sid zu verwenden, da in der aktuellen Stable einige Funktionen noch nicht verfügbar sind und eine gewaltige Sicherheitslücke nicht geschlossen wird (verwaltete Hosts können den Ansible Server übernehmen)
 
Kann Ansible auch nur empfehlen!
Um Playbooks zu testen nutze ich Vagrant mit Virtualbox.
 
Huch, in dem Thread tut sich ja noch was :d
Lange nicht reingeschaut.

@Colttt: ich habe mich gegen Salt entschieden, weil es quasi Puppet mit einem anderen Namen ist. Zumindest was die Architektur angeht. (Ich sollte anmerken, dass meine Erfahrung mit Salt eine Weile her ist, kann sich natürlich vieles geändert haben)
Man hat halt wieder einen Master und verteilt von dort alles, es wird wieder über Ports kommuniziert die nicht Standard sind und man muss wieder Keymanagement betreiben(wobei ich mir bei letzterem gerade etwas unsicher bin). Außerdem hat es eine Menge Abhängigkeiten, oder?
Ansible ist schlicht unglaublich einfach und erzeugt deshalb sehr schnell Resultate. Du brauchst ja nur einen Client mit SSH und auf dem Server auch SSH. Und das ist meist eh schon freigeschaltet in der Firewall. Dazu noch git/svn/whatever und du bist fertig. Das finde ich deutlich besser als die anderen Systeme.
War jetzt nicht sonderlich ausführlich, aber ich denke du verstehst was ich meine. Nutzt du Salt?
 
Ok danke für die Info.. wir sind aktuell dabei salt bei uns ein zu führen.

Dein wissen über Saltstack ist nicht mehr ganz aktuell ;) Saltstack kann auch Masterless betrieben werden und Salt kann auch über SSH only betrieben werden, aber wer will das schon ;)

Bei Salt Master/Minion kombi wird ein tunnel vom Minion zum Master aufgebaut und dann ein reversetunnel so das eine Bidirektionale Verbindung zustande kommt. Passiert also immer alles instant, daher ratten schnell. Also muss nur der master erreicht werden da bei uns ssh nicht immer offen ist, sehr gut ;)
Abhängigkeiten sind auch nur Python..

Auch hat uns die Modulvielfallt vei Salt gefallen, da ist alles dabei zabbix, PostgreSQL, LXC, vmware uvm..

Ohne mir Ansible genauer an geguckt zu haben, ein paar fragen.. Kann ich in Ansible States/Rezepte oder wie es da heisst anlegen die sich dann nur auf ein bestimtes OS beziehen? Bsp setze befehl XY nur an Debiansystemen Wheezy ab die mehr als 12GBRam haben. Kannst Du da mal bitte was posten?
 
Du legst dir einfach eine Hostgruppe (z.B. [debian_stable_bigger_than_12G]) an (in /etc/ansible/hosts), diese Gruppe fügst du ins yml-Skript ein. Mehrfachnennungen von Servern im Hostfile sind natürlich möglich, so dass der Server beispielsweise in der einerseits bigger_than_12G Gruppe drinnen ist, aber auch in der Gruppe DNS_Servers. Du kannst das ganze natürlich mit ein bisschen Eigenleistung dynamisieren, indem du zuerst die Informationen abfragst, danach eine neue, temporäre Gruppe bildest und deine Aufgaben/Queries/... durchführst. Habe ich auch schon einmal für die Patchanalyse verwendet: zuerst alle Server nach einer gewissen Software mit der Version x.y überprüfen, alle Server, bei denen der Stand nicht übereinstimmt, in eine neue Gruppe zusammenfassen und dort ein Update durchführen.
Bei Ansible gibt es sehr, sehr wenige Sachen, die man nicht realisieren kann. Das Meiste funktioniert nach ein bisschen Eigenleistung garantiert, wie man es möchte.
In der Arbeit verwalte ich derzeit ca. 50 Debian-Server mit Ansible, hauptsächlich nutze ich es für die Provisionierung von neuen Servern und die laufende Überprüfung von Sicherheitsupdates. Die Skripte habe ich alle selbst entworfen mit ein bisschen Unterstützung von Google :)

Nachtrag: die Hostgruppen kann man natürlich auch kaskadieren. Mir gefällt die simple Umsetzung sehr gut, da man einen sehr großen Spielraum für eigene Ideen und div. Extrawürste hat. Nebenbei kann man die yml-Skripts und bash-Skripts wunderbar kombinieren und bei Bedarf erweitern.
 
Zuletzt bearbeitet:
Dem Beitrag von oachkatzlschwoaf94 zur Frage von Colttt ist eigentlich nur hinzuzufügen, dass Ansible ja "Facts" über die verwalteten Systeme sammelt. In diesen Facts steht auch drin, welches OS in welcher Version du verwendest.
Mein Playbook zum patchen aller Systeme unterscheidet zwischen versch. Distributionen und wählt je nach Distribution dann das richtige Modul um das System zu patchen. Kann man sogar relativ einfach auch cluster-aware machen.

Ich persönlich finde es sehr praktisch, dass Ansible SSH nutzt. Das ist (bei mir) eh immer frei, so muss ich nicht in der Firewall immer noch andere Ports freigeben, die dann wieder Angriffsfläche bieten.
Wie du schon schreibst, mittlerweile ist es möglich auch Salt masterless zu betreiben und über SSH, aber das will offenbar keiner, weil das nun mal nicht das Konzept ist.
Ansible ist ebenfalls "batteries included", da kommen also auch für alles mögliche Module mit. Hab bisher nichts gefunden was ich damit nicht steuern konnte. Und wenn man sowas findet, lässt sich das relativ fix selbst bauen.

Freut mich aber zu hören, dass du mit Salt so zufrieden bist, vielleicht ist es dann doch nochmal einen Blick wert.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh