Virtual Appliances und Co. - Frage nach Auto-Installations-Skripts

P

pi()

0
Hallo werte Gesellen!
Ich hatte vor kurzem eine Idee: Ich baue mir eine virtuelle Maschine (VM), einen Ubuntu Server, auf dem ich alle Serversoftware installiere, die ich brauche.Diese VM sichere ich zusätzlich noch und schon bin ich perfekt ausgerüstet, um in einem Unternehmen einen Server binnen weniger Zeit bereit zu stellen.

Dazu habe ich mir gedacht, dokumentiere ich jeden Schritt - in erster Linie als Bash-Skript, sodass ich, auf einem frischen _reellen_ System derselben Version das Skript nur ausführen muss und schon ist ein einfach konfigurierter, funktionstüchtiger Server da.

Nun zum Punkte: Nach einer kurzen Recherche fand ich heraus, dass es sowas (die Idee mit der VM) schon gibt, und dass dies "Virtual Appliance" heißt.Man braucht eigentlich nur noch in Google "virtual Applicance +$Serversoftware" eingeben und man bekommt eine fix-fertige VM mit der Serversoftware installiert zum download angeboten.

Das ist ja wundertoll, ABER: Was ich noch nicht gefunden habe, war die Sache mit den Scripts.
Meine Frage: Gibt es im Internet auch schon eine Quelle für Skripts, die man auf einem System nur ausführen braucht und dann hat man die Anwendung in einer Grundkonfiguration schon fehlerfrei laufen?
Ich meine, APT nimmt wem zB in den neusten Ubuntu Versionen schon eine Menge Arbeit ab (Siehe Nagios3), aber sowas geht nicht immer - zB bei https-Support für Apache2 muss man sich immer noch ein Zertifikat selbst bauen usw.

Ich bin für jede hilfreiche Antwort dankbar!
liebe Grüße, pi()
 
Jeder Admin, den ich kenne inkl. mir selbst nutzt dafür selbst geschriebene Skripte, da die Erfahrung zeigt, dass die Skripte anderer Admins immer irgendwo nicht passen. Server sind nämlich eher selten so gleichartig, dass sie mit "Standard-Systemen" laufen können. Da sind Cronjobs, die in die Crontab eingefügt werden müssen, Web- oder sonstige hauseigene Software, die in die VM eingebracht werden muss und nicht zuletzt unterscheiden sie sich natürlich in ihren Konfigurationen. Virtual Appliance macht daher zumeist nur Sinn, wenn man ein Server-Cluster zu verwalten hat, wo alle Server bis auf wenige Unterschiede (zumeist nur der Netzwerk-Konfiguration) identisch sind.

Beispiel: Kunde 1 und Kunde 2 haben jeweils Java-Application-Server am laufen. Schon bei einer so simplen Sache können die Unterschiede drastisch sein:
- unterschiedliche Server-Software (Tomcat, JBoss, Glassfish etc.)
- verschiedene Konfigurationen der Server (Ports, SSL ja/nein, Parameter der Java-VM etc.)
- verschiedene Datenverzeichnisse (der eine nutzt ein NFS-Mount, der nächste spielt Daten prinzipiell via Versionsverwaltung ein, wobei auch wieder verschiedene in Frage kommen wie Git, SVN, CVS u.a)
- verschiedene Sicherheitsanforderungen (mal mit WAF, mal nur mit iptables, mal mit IDS und mal ohne, wobei auch hier wieder unterschiedliche Software zum Einsatz kommen kann)
- verschiedene Standard-Cronjobs
- verschiedene Backup-Verfahren, die auch wiederum verschiedene Software-Anforderungen haben können
uvm.

Standard-Systeme kann man daher nur auf ein Minimum begrenzen und das sind die klassischen LAMP-Systeme, wie sie von jedem durchschnittlichen Server-Hoster für Spottpreise in Massen angeboten werden. Die haben übrigens zum Erstellen der VM-Templates und zugehöriger Skripte auch wiederum Admins und Entwickler, die den Kram firmenintern machen. Systeme, die darüber hinaus gehen, wirst du mit einem Skript nicht eingerichtet bekommen, es sei denn du erstellst für jeden Kunden ein individuelles Skript. Und diese sind nunmal zum Grossteil nutzlos für andere, weswegen man so wenige "in the wild" findet.
Und Templates mit Anwendungen in der Grundkonfiguration macht man nicht via Skript. Man richtet eine entsprechende VM ein, zieht ein Template davon und die Sache ist gegessen.
 
Ich selbst benutze auf der Arbeit OpenSuSE (nicht meine Wahl) und Autoyast, da keine ausreichend starke Hardware für VM Installationen vorhanden ist. Kombiniert mit PXE ist die Neu-Installation von Rechnern praktisch nur: Einschalten, Netzwerk-Boot auswählen, Autoyast-Konfiguration auswählen, Fertig. Alles andere passiert komplett automatisch. Darüber hinaus kann man den Fortschritt noch per VNC beobachten. Ich habe sogar einen kleinen Framebuffer-Treiber geschrieben, der auf dem Client so etwas wie einen "DO NOT TURN OFF!" Schirm ausgibt, damit niemand denkt, der Computer wäre abgestürzt oder könnte benutzt werden (bei Windows-Benutzern sitzt ein STRG-ALT-ENF ja immer sehr locker).

Das Resultat ist ein neu installierter Rechner, der alle laufenden Updates sogar noch während der Installation eingespielt bekommt. Praktisch ist der Rechner ca. 30 Minuten nicht zu benutzen und anschließend wieder in Funktion, als ob nichts gewesen wäre.

Client-spezifische Templates lassen sich per MAC-Adresse über PXE steuern (Rechner1 bekommt Template 1, R2 bekommt T2, usw. ..).

Unter Debian basierten Systemen nennt sich diese Funktion Preseeding.

In erster Linien sind beide Methoden so komplex, dass man (fast) keine eigenen Skripte mehr braucht. Aber die Erstellung eines Templates dauert auch seine Zeit und erfordert etwas Geduld. Der Vorteil gegenüber des VM-Templates ist hierbei (bitte korrigiert mich, wenn ich falsch liege), dass man das VM-Template immer mit Updates versorgen muss, damit es nicht veraltet. Dafür ist es natürlich um einiges schneller, einfach ein Template an den VM-Server anzugliedern, als sozusagen komplett "neu" zu installieren.
 
VMs nutzt man ja nicht nur als Ersatz für ein einzelnes installiertes System, sondern um eine möglichst optimale Auslastung der Hardware zu erreichen, indem man mehrere Kunden mit einer Hardware bedient, was wiederum geringere Kosten und somit geringere Preise ermöglicht. Da kommt man dann mit einem einzelnen System nicht unbedingt weiter, wenn man seinen Kunden Rootzugriff bieten will. Gerade bei Servern ist es auch wichtig, dass ausgefallene Systeme ggf. vollautomatisch auf anderer Hardware gestartet werden können und das mit minimaler oder garkeiner Downtime. So muss man nicht für jeden Kunden einen Failover-Server bereit halten, sondern nur für alle 50-100 Kunden einen, auf dem man dann bei Bedarf die VMs einer Maschine einfach hochfahren kann. Und man kann selbst bei Hardware-Schaden eine Downtime von 5 Minuten bieten und nicht von einer halben Stunde. Das macht sich in der Vermarktung erfahrungsgemäß besser. ;)
Die Einsatzgebiete von VMs und PXE sind allerdings zu verschieden, als dass man wirklich Vergleiche ziehen könnte. Das Prinzip ist aber bei beiden das gleiche... beide "steuert" man primär mittels der Templates. Bei VM-Software kommt dann zumeist hinzu, dass man diverse Einstellungen dann händisch anpassen muss, die sich von System zu System unterscheiden (Netzwerk-Einstellungen, VHosts, SSH-Hostkeys etc.). Das geht bei VMs nunmal nur mit Skripten oder händischen Anpassungen, da Unterscheidungsparameter anhand der Hardware wie MAC-Adressen o.ä. nicht vorhanden sind. Beispiel des Netzwerk-Devices einer OpenVZ-Maschine:

Code: 
venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.0.103  P-t-P:192.168.0.103  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
 
Ich sehe das jetzt so, als ob man im Endeffekt kaum möglichkeiten zur Effizienzsteigerung bei der Konfiguration von Servern hat - denn selbst die vorgeschlagenen Lösungen sind keine Allgemeinen und die Skripts lassen sich nur eingeschlränkt nutzen und meistens auch nur dann, wenn man sie selbst erstellt hat.Ist das in etwa, was ihr gemeint habt?

Grüße - und vielen Dank!
 
Naja, es gibt schon Wege zur effizienteren und schnelleren Einrichtung eines Servers. Allerdings sind das, wie schon erwähnt, oft eigene Workflows (teilweise in Form von Scripten, teilweise bestimmte Arbeitsabläufe oder durch bereits verwendete Configs). Diese eignet man sich im Laufe der Zeit selbst an oder schaut sie sich halt woanders ab.
Es führen da viele Wege zum Ziel. Welcher Weg nun für einen am schnellsten ist kommt auf die spezifische Situation an, die Kenntnisse und die Erfahrung.
 
Zuletzt bearbeitet von einem Moderator:
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben