da uns immer fürchterlich langweilig ist, wir aber von Natur aus sehr faul sind, mussten wir mal etwas Lustiges ausprobieren.
Man nehme eine fertig konfigurierte Supernode, in diesem Fall bei uns ffrg4, und schreibe den vorgepipeten Output von DD /dev/vda direkt in die ftp Session **. Beispielsweise in die ftp Session vom Image Server des vServer Anbieters.
Das natürlich riesige über Nacht erzeugte und unmittelbar in die ftp Session geschriebene Image kann man dann tofte verwenden, um weitere Server direkt vom Image installieren zu lassen, bei denen nur noch nachkonfiguriert werden muss. In unserem Fall ffrg5, ffrg6, ffrg7 und ffrg8.
Mal sehen was uns morgen so einfällt…
**
ftp Session einleiten, anmelden, ins richtige Verzeichnis wechseln, dann:
Ich hatte ein wenig bammel das wenn ich was anderes als native raw zum Hoster schiebe, das Image dann nicht mehr als installierbares Image erkannt wird.
Um das lästige Nachkonfigurieren von einfach allem kommt man natürlich leider nicht drum rum, Host Keys, IP’s, MAC’s, rsync Keys, DHCP Bereiche, und so weiter, und so weiter.
Aber das war auch eher nen Gimmick zum Ausprobieren, ob das funzt
Aber warum kann man den snapshot nicht vom Host-System des Quell-Servers ziehen? dann kann man den Krempel nochmal zum Nachkonfigurieren mounten bevor man es durch’s bzip piped…
Kannste natürlich auch erst woanders hinschieben, dann wäre da Netcat auch ganz hilfreich. Aber wenn es zum Hoster soll, dann gab es da nur den ftp Upload…
Clonen von offenen Filesystemen ist auch eine gute Möglichkeit, die Robustheit von eben diesen und die von transaktionsgestützte Datenbanken zu testen…
(ich weiss, ein Supernode macht in der Richtung nichts weltbewegendes…)
VServer-Umzug/-Kopie per Rsync dürfte bei nicht allzu voller Festplatte schneller gehen. War bisher meine Methode der Wahl (geht auch ohne Rescue-System, allerdings sollte dann die Verbindung nicht zwischendurch abreißen …)
Andere Leute trennen Server und Storage, so dass man gar keine Daten übers Netz bewegt werden müssen, um neue Instanzen einzurichten.
Gerade bei wenig Festplattenintensiven Jobs (wie ich es bei fastd/exitnodes unterstelle) sollte das eine Option sein.
Ich arbeite gerade an einem Cookbook für Chef. Maschinen mittels DD und Co zu klonen halte ich für wenig sinnvoll.
Den FFRL-Mailserver setzen wir auch mittels Chef auf und können innerhalb von 5 minuten ein System komplett mit der erwünschten Funktion aufsetzen.
DD und Co sind ziemlich „90ties“ wenn es um klonen bzw replizieren von Setups geht
Aufwändig ist ja nicht das Problem
Auf jeden Fall ist es sicherer was Konfigurationsfehler angeht als das man noch Config Files verändern muss usw.
Gerade wenn es um Haftung und Co geht wäre ich da doppelt vorsichtig, braucht ja nur mal der ganze Traffic von der VM nach außen geroutet werden anstatt über das FFRL Backbone.
Natürlich lohnt sich der Aufwand nicht wenn man 2-3 Supernodes hat, aber wir haben ja mehrere Systeme die davon profitieren würden
Außerdem gibt es dem Admin Team mehr Überblick, denn wenn man Chef in Verbindung mit einem Chef-Server nutzt hat man auch ein automatisches Inventory. Das ist natürlich nicht notwendig, aber sehr praktisch.
Dazu kann man wie bei den Node Autoupdates wesentlich einfacher Änderungen einplanen und zeitgleich auf allen Servern anwenden.
Beruflich arbeite ich mit etwa 600 Servern die per Chef verwaltet werden, das ist natürlich von der Größe noch ein großer unterschied aber wäre auch ohne Configuration Management unmöglich.
Gibt es auch ein simples Configuration Management, dem ich einfach nur sagen kann welche Files wie sein sollen und entsprechend Variablen zur Verfügung habe, um die Änderungen pro Host mit einzuarbeiten?
Das wäre schon sehr hilfreich, ich ertrinke nämlich gerade in Servern, wenn Änderungen gemacht werden müssen.
Ich habe von den Tülchens aktuell keine Vorstellung, egal ob Puppet, Chef oder den restlichen zwei Dutzend „echten“ Configuration Management Systemen.
Immer wenn jemand, so wie gerade Linus, was dazu geschrieben hat klang es so aufwendig, dass der erste Gedanke bei mir war „ne, das tust Du Dir jetzt nicht auch noch an“
Dafür könntest du z.b. Fabric verwenden. Ist allerdings kein Configuration Management sondern ein remote execution framework.
Siehe: http://www.fabfile.org/
Ist allerdings eher ein programmatischer Ansatz da man dazu Scripts in Python schreibt.
MIt Puppet habe ich auch schon gearbeitet, allerdings finde ich den Gedanken nicht schön das es eine eigene Sprache für die Rezepte nutzt welche sonst wo unbrauchbar ist und daher unnötig zu lernen ist.
Chef hingegen verwendet Ruby mit ein paar Eigenheiten. Wer jetzt sagt „Igitt Ruby“ dem sei gesagt das die Unit Tests für Puppet auch in Ruby geschrieben werden. Demnach muss man für Puppet 2 Sprachen lernen wovon eine sonst nirgends Nutzung findet.
Daher verwende ich eher Chef als Puppet
Ach und ich glaube Puppet nutzt YAML für die Config-Files, da kann einem das ganze schon wegen einem Leerzeichen zu viel um die Ohren fliegen.
Ist auch der Grund meiner persönlichen „Abneigung“ gegenüber Python. Leerzeichen, Absätze und sonstige nicht sichtbare Satzzeichen sind keine gute Idee in der Programmierung. Da macht man meist die häufigsten Fehler (z.b. Tabulator und Leerzeichen vertauscht oder ähnliches)
Ist schwer zu sagen, für mich ist es gefühlt trivial. Allerdings kenne ich mich damit aus und arbeite seit über zwei Jahren damit.
Wir nutzen momentan Chef-Zero was im Grunde ein abgespecktes Chef Setup ist. Dafür hat man seine Workstation mit Chef-Client und auf den VMs Chef-Client.
Im „Zero Mode“ simuliert die Workstation einen Server währned man Änderungen anwendet.
Daher ist es im Grunde nur das aufsetzen des Clients was etwas Zeit in anspruch nimmt.
Für Supernode Cookbook würde dann mittels Data Bags, im Grunde nur JSON Dateien, die Config bereitsgestellt.
Man pflegt keine Config Files an sich sondern nur Data Bags und evtl feste Default-Werte in den einzelnen Cookbooks.
Dies mag anfangs gewöhnungsbedürftig sein aber wenn man später manuell an Config-Files schraubt fragt man sich oft wie es ohne ging.
Selbst privat verwalte ich damit meine 4 VMs, ist einfach wesentlich komfortabler.
