Die Paketierung ist ein interessanter Weg. Solange man nur mit "identischen" Systemen (debian und selbes Release) zu tun hat sicherlich hilfreich. Wenn es tendenziell mehr Systeme werden, sollte man sich aber frühzeitig um ein Konfigurationsmanagement oder "Orchestrierung" kümmern.
Ansible kann ich aus eigener Erfahrung wärmstens empfehlen - ausser SSH und (leider) python hat es keine Voraussetzungen auf den Clients (=kein eigenes Clientmodul). Python ist bei fast allen Betriebssystemen in der Basisinsstallation, somit funktioniert Ansible überall out-of-the-box. (Überall = auf den Betriebssystemen die >95% aller Serverinstallationen ausmachen...)
Windows wird mittlerweile auch unterstützt falls man sich das auf nem Server antun will... Um Windows brauchbar zu automatisieren muss aber vieles nachinstalliert werden; am besten per chocolatey für eine richtige Softwareverwaltung und vor allem den NSSM (non-sucking service manager) damit man überhaupt einen Servicemanager hat der funktioniert
Configdateien (z.B. auch vimrc, screenrc), SSH-Keys und eigene Scripte verteile ich per Ansible aus einem lokalen git-repo. Mit etwas Planung kann man diese "persönliche Minimalkonfiguration" dann universell für Systeme mit linux, BSD oder Illumos verwenden - ggf per Templates um unterschiedliche Pfade zu berücksichtigen. Lässt sich dann bequem und einheitlich in playbooks für physische Rechner, VMs, Jails/Container/Zonen und Cloudinstanzen verwenden.
Weiterer Vorteil von vollständigem Konfigurationsmanagement: Playbooks sind gleichzeitig die Dokumentation für jedes System und die Wiederherstellung (disaster recovery) oder Neuprovisionierung wird erheblich beschleunigt und vereinfacht. Für viele Systeme spart man sich so aufwändige/große fullbackups und sichert nur die tatsächlichen "Nutzdaten". Das Installieren zusätzlicher Webserver für load-balancing/HA oder eines backup-MX wird damit absolut trivial.
Die Lernkurve für Ansible ist ziemlich steil - YAML ist trivial zu verstehen/lernen; der syntax der DSL ist simpel und selbsterklärend, ohne obskure Abkürzungen o.ä. und man hat in <1h bereits ausreichend Grundkentnisse um die ersten VMs automatisiert zu provisionieren. Man kommt auch mit geringem Vokabular schon erstaunlich weit; es gibt aber viele Funktionen oder Module die komplizierte Dinge einfacher machen.
Die Dokumentation ist auf den Punkt und nicht unnötig mit Füllsätzen aufgepumpt - sprich sehr gut für das schnelle erweitern der Grundkentnisse. Für den Einstieg aber etwas heftig; da kann ich das "Kuh-Buch" von O'Reilly (Ansible up&running) empfehlen - das erklärt sehr gut die Grundlagen und man wird exemplarisch über immer komplexere Provisionierungen geführt (z.B. vollständiger stack für Webapplikationen mit mehreren Servern). Danach ist man schon recht gut für den Praxiseinsatz gerüstet.
Das "schwierigste" am Anfang ist IMHO, sich das manuelle Konfigurieren direkt an den Servern abzugewöhnen und Einzellösungen/"Hacks" zu vermeiden, sonst beißt sich irgendwann eine manuelle änderung auf einem System mit einer Konfiguration die für viele/alle Systeme gültig sein soll. Der Vergleich "Cattle vs Pets" passt hier am besten - Server sollen Nutzvieh sein, keine Haustiere. Dadurch hält man automatisch die Änderungen/Anpassungen gering und verringert dadurch auch meistens Fehler.
Eigene Skripte auf mehreren Servern: Best Practice?
Re: Eigene Skripte auf mehreren Servern: Best Practice?
Super geschrieben - schau mal in deine PN!
Wer sich mit ansible beschäftigen will, dem empfehle ich nochmal das ebook, was gerade eine Aktion hat:
Ansible for DevOps for $6.99 (until June 5th): http://leanpub.com/ansible-for-devops/c/fsgJMHVFDFSG
lohnt sich zu lesen…
Wer sich mit ansible beschäftigen will, dem empfehle ich nochmal das ebook, was gerade eine Aktion hat:
Ansible for DevOps for $6.99 (until June 5th): http://leanpub.com/ansible-for-devops/c/fsgJMHVFDFSG
lohnt sich zu lesen…