Eigene Skripte auf mehreren Servern: Best Practice?

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Eigene Skripte auf mehreren Servern: Best Practice?

Beitrag von r4pt0r » 26.05.2016 20:44:55

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 :roll:

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.

Benutzeravatar
ThorstenS
Beiträge: 2875
Registriert: 24.04.2004 15:33:31

Re: Eigene Skripte auf mehreren Servern: Best Practice?

Beitrag von ThorstenS » 29.05.2016 17:09:17

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…

Antworten