Eigene Skripte auf mehreren Servern: Best Practice?

[stillebucht]

Hallo,

ich betreibe mehrere kleine Server mit Debian. Für unterschiedlichste administrative Aufgaben habe ich mir eigene Skripte geschrieben, manche sind nur für einen Server bestimmt, aber die meisten davon nutze ich auf allen Installationen (teilweise mit leichten systemspezifischen Anpassungen). Mittlerweile bin ich jedoch an dem Punkt angelangt, bei dem ich die Wartung der Skripte - insbesondere das synchron halten über alle Systeme, wenn ich mal eine Änderung an einem Skript vornehme - als eher unpraktisch empfinde.

Daher frage ich mich: Wie verteilt und wartet man eigene Skripte (ggf. auch mit Konfigurationsdateien) am Besten über mehrere Systeme? Als erstes dachte ich an ein Git-Repository - dann müsste ich mir noch überlegen, wie ich die Verteilung am Besten umsetze. Ebenfalls dachte ich schon an das Bauen von Debian Paketen und ein lokales apt repository, sodass die Aktualisierung mit Systemwerkzeugen abläuft. Aber im Endeffekt erscheint mir diese Variante doch als recht aufwändig, nur um einzelne Skripte zu verteilen.

Insofern wollte ich die Frage an die Community weitergeben: Was sind best practices, wenn es um die Wartung und Verteilung von eigenen Skripten geht? Wie geht ihr da vor?

Danke und schöne Grüße,

Timo

[heisenberg]

Dafür gibt's Konfigurationsmanagement-Tools. Ich selbst verwende Opscode Chef. Das kann ich für Kleininstallationen allerdings nicht empfehlen. Der Einarbeitungsaufwand ist zu hoch.

Ich empfehle Dir mal ansible anzuschauen - das hat den Ruf viel einfacher zu sein. Oder evtl. Saltstack.

[ThorstenS]

Ich bin auch ein ansible Fan.
Das kopiert dir Dateien, ersetzt Platzhalter in templates/Dateien und kann dir Pakete nachinstallieren.

Wenn es dir aber lediglich um die Verteilung einiger Scripte geht, dann kannst du dich vllt. auch mit Paketierung beschäftigen:
Setz ein einfaches repository auf (ein Webserver oder FTP Server sind gängig, aber du kannst auch per ssh repositories zur Verfügung stellen).

Dann pack von mir aus generische Script in ein Paket und spezifische Skripte in ein einzelnes Paket. Ganz viele mit einem einheitlichen Namensschema (stillebucht-scripts-name_Version.deb).
Für jeden Server erstellst du dann ein Paket, welches als recommends eine Liste aller notwendigen Skripte nach sich zieht.
Auf deinen Servern installierst du das eine Paket dann mit z.b. apt install stillebucht-$(hostname) und sämtliche Skripte finden ihren Weg auf das System.
Sollten Anpassungen an den jeweiligen Host notwendig sein, so kannst du dafür das postinst-Script des debian Pakets dafür benutzen.
Der Vorteil an dem Vorgehen ist, dass du lediglich an einer Stelle (deinem git-Repo, wo du die Skripte pflegst) einen Paketbau triggerst, die Pakete automatisch per dput in das Repositorie laden lässt und deine Server entweder automatisch per unattended-updates oder durch einen einzigen Aufruf von dir (dsh -g server "apt updates ; apt-upgrade") sämtliche Server aktualisiert werden.

Ich finde den Ansatz über die Paketierung super interessant, hat Schlomo Schapiro in einigen Talks vorgestellt.
Aber trotzdem nutze ich eine Mischung aus ansible und eigenen Paketen.

Lass dich mal inspirieren, speziel bei dem Video „Configuration Management and Linux Packages“ unter http://www.heise.de/make/meldung/Magnet ... 05670.html

[heisenberg]

Der Ansatz aus dem Video ist sehr interessant.

Bei den meisten CFG-Management Lösungen muss irgend eine Form von Client auf den verwalteten Systemen sein. Das braucht zusätzliche Software(HDDSpeicher, RAM, CPU, Herabsetzung der Sicherheit, zusätzliche Kompatibilitätsanforderung, Erhöhung der Komplexität). Bei dem anderen werden nur Pakete installiert und fertig. Die Paketinfrastruktur zu aufzusetzen ist mit Sicherheit auch nicht trivial, aber in der Anwendung dann sehr einfach.

[ThorstenS]

Doch, ein Paketrepository setze ich dir mit 4 Zeilen Shellcode auf - das ist keine Zauberei.
ansible setzt als „client“ lediglich den sshd vorraus. Oder du bentutzt den pull modus, dann brauchst du nur cron und den ssh-client. Einfacher gehts nicht. KISS

Beispiel für ein lokales unsigniertes repository:

Code: Alles auswählen

mkdir -p /usr/local/packages/debs
cp meinpaket_1.0_all.deb /usr/local/packages/debs
cd /usr/local/packages
dpkg-scanpackages debs /dev/null | gzip > debs/Packages.gz
sed -i '1ideb [trusted=yes] file:///usr/local/packages debs/' /etc/apt/sources.list
apt update
apt-cache policy meinpaket

[smutbert]

jetzt bitte noch bitte eine Anleitung wie man möglichst einfach ein Paket mit einem oder mehreren eigenen Skripten für die Architektur all baut.
(Sollte eigentlich nicht so unverschämt fordernd klingen, noch dazu in einem fremden Thread, aber freuen würds mich wirklich, weil ich mich beim Paketbauen so unheimlich patschert anstelle.)

[ThorstenS]

Kein Problem, beschreib ich gerne:

Am einfachsten geht das mit dem ruby Tool fpm, welches nicht in debian enthaölten ist.
Du kannst davon aber ein deb bauen, mach das in einer VM oder einem Container oder dergleichen und du hast gleich das erste Paket für dein repo.

Code: Alles auswählen

apt install ruby rubygems -y
gem install fpm

fpm -s gem -t deb -d rubygems -d rubygems-json fpm
[…]
Created package {:path=>"rubygem-fpm_1.5.0_all.deb"}

Wenn du dann ein Paket mit dem Skript helloworld bauen willst, dann geht da so:

Code: Alles auswählen

echo -e "#!/bin/bash\necho 'hello world'" > helloworld
chmod +x helloworld
mkdir -p usr/local/bin
mv helloworld usr/local/bin/
fpm -s dir -t deb -n helloworld -v 1.0.2 .
[…]
dpkg -i helloworld_1.0.2_amd64.deb 
...
root@horst:~/tmp# helloworld
hello world
root@horst:~/tmp# dpkg -L helloworld
/.
/usr
/usr/local
/usr/local/bin
/usr/local/bin/helloworld
/usr/share
/usr/share/doc
/usr/share/doc/helloworld
/usr/share/doc/helloworld/changelog.gz

Wenn du dich allerdings ernsthafter mir dem Paketbau auseinandersetzen willst, gibt es bessere (aber nicht schnellere ) Möglichkeiten. Im alten Wiki gab es eine tolle Anleitung von Meillo glaub ich war die. Dort hat er erklärt, wie man ein signiertes repo baut. Mit mini-dinstall. Ich benutze mittlerweile reprepro und finde auch aptly von http://aptly.info sehr geil. Das ermöglicht dir neben dem managen eines eigenen repos das Spiegeln von offz. Quellen und mergen von div. Quellen, damit du nur eine einzige deb-Zeile in der sources.list haben müsstest. Aber das geht zu weit hier im Thread.

[smutbert]

Danke!

[rendegast]

Es gibt auch noch equivs,
mit der Option

Code: Alles auswählen

Package: ....
Version: ...
Section: lokal-admin
...
Files: usr/local/bin/bla.sh .
 usr/local/bin/foo.sh .
 ... .

Eventuelle Links werden dabei als Dateien hinzugefügt.

[stillebucht]

Hallo,

erst mal danke für die vielen Anregungen. Mit zwei Vorschlägen habe ich mich jetzt etwas mehr auseinandergesetzt: ansible und Paketierung der Skripte.

Da es mir wirklich nur um das Verteilen der Skripte geht und nicht um die Verwaltung der Server, ist mir ansible ein wenig zu viel des Guten, obwohl es mir vom Ansatz her sehr gut gefällt. Zudem habe ich mit dem Bauen von Paketen und Pflege eines lokalen deb-Repository schon etwas Erfahrung (für ein embedded-System erstelle ich regelmäßig eigene Kernelpakete einschl. eines Metapakets, sodass diese automatisch über das lokale Repository verteilt werden).

Das Aufsetzen des Repositorys empfand ich in der Tat als trivial. Das Bauen der Pakete übernimmt bisher ein Skript, das eigentlich praktisch alles manuell erledigt (z.b. control- und copyright-Datei erzeugen, usw.). Aus dem Grund habe ich gezögert, das auch für die Skripte umzusetzen. Aber fpm sieht da schon sehr viel einfacher aus. Insofern, werde ich mich da nochmal mit den vorgeschlagenen Tools auseinandersetzen und schauen, womit ich das künftig etwas einfacher oder eleganter lösen kann. Zur besseren Versionskontrolle, kombiniere ich das ganze vielleicht doch noch mit einem git-Repository

Danke!

Timo

[ThorstenS]

Schön, dass es dir hilft.

git init ist der 1. Befehl, den ich ausführe, wenn ich in einem neuen Ordner ein Script entwickeln mag. Die Verwendung von git ist für mich elementar wichtig und in Fleisch und Blut übergegangen.
Das kostet nur wenige Tastenanschläge und du hast für ewig die Historie deiner Scripte festgehalten. Neue features sind über einen eigenen „feature branch“ total einfach einbaubar (git checkout -b neuesFeature; vi $blafasel; testen; git add . ; git ci -m "neues feature fertig"; git checkout master; git merge neuesFeature).

Hier noch einige Links, über die zum Kontext Paketbau und repository passen:


Anleitung in deutsch:
http://www.pro-linux.de/artikel/2/1726/ ... orgen.html
http://www.freiesmagazin.de/mobil/freie ... 0_reprepro
http://www.freiesmagazin.de/mobil/freie ... shop_teil3
Golang package for Debian (deb) file generation (experimental): https://github.com/xor-gate/debpkg

Create authenticated repository https://help.ubuntu.com/community/Creat ... Repository
A dead simple apt repo server https://github.com/esell/deb-simple
Setting up signed APT repository with Reprepro https://wiki.debian.org/SettingUpSigned ... thReprepro
mächtiges repository Tool https://github.com/smira/aptly

dpkg manpage https://manpages.debian.org/cgi-bin/man.cgi?query=dpkg)
dpkg-deb manpage https://manpages.debian.org/cgi-bin/man.cgi?query=dpkg)
dpkg-sig manpage https://manpages.debian.org/cgi-bin/man ... y=dpkg-sig)
Debian New Maintainers' Guide https://www.debian.org/doc/manuals/maint-guide/)
Debian Policy Manual https://www.debian.org/doc/debian-policy/)

Desweiteren kann ich dir für ansible das ebook von hier empfehlen: http://www.jeffgeerling.com/ http://www.ansiblefordevops.com/
Hier kann man schonmal reinlesen: https://leanpub.com/ansible-for-devops/read
Seine github Beispiele sind übrigens sehr inspirierend.

Wenn du mal ein richtig cooles und gut integriertes ansible Projekt ansehen willst, dann schau mal hier: https://github.com/usableprivacy/upribox

[Cae]

Ich verwende schon recht lange Git fuer genau diese Aufgabe. Die Verteilung mache ich dann vereinfacht per

Code: Alles auswählen

for host in a b c; do
	ssh "$host" 'git -C /opt/shellkrams/ pull' &
done

Das initiale Hinzufuegen eines Hosts erledigt auch ein Shellskript, was so ein bisschen Ansible-artig bloss den Hostnamen braucht und sich auf dem Zielsystem nachinstalliert, was es halt braucht. Dabei ist es relativ portabel und kommt mit Debian, Ubuntu, CentOS und FreeBSD als Zielsystem klar.

Insbesondere finde ich gut, dass ich Anpassungen direkt auf dem Zielhost entwickeln kann und bei einer funktionierenden Version einfach den git diff-Output in das Hauptrepo uebernehmen kann (oder andernfalls alles per git checkout -- . wieder zuruecksetze). Es gibt natuerlich eine gewisse Redundanz, weil eigentlich Host-spezifische Skripte auf allen Hosts liegen, aber bisher hat mich das nicht gestoert.

Teilweise hatte ich das auch pakettiert, ich fand das aber einen unglaublichen Aufwand. Makefile, upstream-Konzept, .dsc, Signatur und dann der reprepro-Mist waren mir einfach zu viel Overhead.

Gruss Cae

[ThorstenS]

hehe, da sieht man deutlich deine UNIX Wurzeln Find ich gut

Das Paket pssh schlägt auch in diese Kerbe.
Ich habe einen alias alias pscp=parallel-scp -o /root/pssh -h /etc/dsh/group/machines. In der Datei machines sind die Hosts zeilenweise mit user@host aufgeführt, mehrere Gruppen (und somit aliase) sind möglich und somit teilen sich dsh und pscp eine Konfiguration.
Damit kann ich dann auch mal flott eine Datei auf alle Systeme kopieren: pscp 95checkvalid /etc/apt/apt.conf.d/

Der Output der Maschinen wird unter /root/pssh geloggt (Parameter -i für interactive ist auch interessant).

Für jemanden, der sich überhaupt keine Arbeit machen will, und dem eine lange .bash_history als Dokumentation reicht, ist das ein gutes adhoc Werkzeug.

[ThorstenS]

toller und sehr aktueller Artikel zum Thema packaging:
http://vincent.bernat.im/en/blog/2016-p ... aging.html

[OldGod78]

Dann pack von mir aus generische Script in ein Paket und spezifische Skripte in ein einzelnes Paket. Ganz viele mit einem einheitlichen Namensschema (stillebucht-scripts-name_Version.deb).

[r4pt0r]

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.

[ThorstenS]

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…