In unserem ersten Beitrag haben wir bereits gezeigt, wie wir unseren Ansible-Arbeitsplatz einrichten um anfangen zu können. Im zweiten Teil wollen wir uns mit dem Anlegen von Hosts beschäftigen, zu denen wir uns verbinden können. Wie immer gilt, wir versuchen keine vollständige Dokumentation von Ansible oder eine Übersetzung. Sicherlich gibt es tausend Tutorials im Netz, die erheblich tiefere Informationen bieten – wir wollen Euch hier zeigen, wie wir damit arbeiten und welche Überlegungen wir dabei hatten um so die grobe Grundstruktur zu erklären.
Ab diesem Kapitel wird es erforderlich, wenn Ihr das reproduzieren wollt, dass ihr Euch irgendwo ein kleines Linux-System installiert habt. Wo und wie werden wir hier hicht bearbeiten, dazu gibt es einige hundert verschiedene Wege.
In unserem Repository legen wir zuerst die Hosts-Datei an:
$ touch hosts
In dieser Datei werden die verfügbaren Geräte angelegt. Das werden mit der Zeit sowieso mehr, also werden wir hier sofort anfangen, diese in Gruppen aufzuteilen.
Vorwegnehmend auf Teil 3, wollen wir, dass sich Benutzer auf den Geräten per SSH einloggen können. Dies wird sich bestimmt auch wieder unterscheiden, wer sich wo einwählen kann, folglich legen wir mal eine generelle SSH-Benutzergruppe in dem Repository an. Hier kann jeder seinen Lieblingseditor verwenden, egal ob nano, vi oder vim.
[ssh_access_ff_general] 192.168.1.2
Die IP steht hier nur als Platzhalter, natürlich müsstet Ihr da Eure IP reinsetzen und die Datei dann speichern.
Wenn Ihr die Änderung in Euer Git-Repo versionieren wollt, könnt ihr diese Änderung Euch nun anzeigen lassen:
$ git status
Hier sollte eine neue Datei in der Rückgabe zu erkennen sein.
Diese Datei könnt ihr dann zum nächsten commit adden:
$ git add hosts
Damit ist die Datei zur Versionierung vorgemerkt.
Dann wollt ihr diese Änderung committen, dadurch wird ein neuer Commit erstellt.
$ git commit
Das System wird Euch in Euren File-Editor werfen, damit ihr dort eine Commit-Nachricht oder eine Beschreibung Eurer Änderung hinterlasst. Beim allerersten mal werdet Ihr auch den Editor mit einer Zahl aus der Liste der installierten Editoren auswählen müssen. Mit speichern und schließen des Editors ist der Commit fertig.
Damit Eure Änderung auch allen anderen, die mit Euch Arbeiten, im Repo auf Github oder Gitlab zur Verfügung stehen, muss die Änderung noch “gepushed” werden.
$ git push
Dabei wird Euch Git vermutlich nach Benutzername und Kennwort fragen. Das kann man auch dauerhaft konfigurieren oder einen Key verwenden, wenn man das Getippe leid ist. Wenn Euch das interessiert, machen wir dazu vielleicht mal nen eigenen Post – also schreibt es in die Kommentare.
erste Kommandos mit Ansible
Normalerweise geht Ansible in so einer Ubuntu-Box davon aus, dass die hosts Datei in /etc/ansible liegt. Das ist aber gar nicht erstrebenswert, weil dort wird diese Datei nicht mit versioniert. Außerdem gibt es so Leute wie mich, die Ansible in mehreren Rollen in verschiedenen Organisationen einsetzen. Es wäre also außerordentlich unpraktisch, ssh-Benutzer eines Freifunk-Vereins auf die Datenbanken meines Arbeitgebers oder anders herum zu konfigurieren. Daher liegt die jeweils verwendete hosts-Datei bei mir niemals unter /etc/ansible.
Was ich dort mache, ist eine Konfigurationsdatei für Ansible Anlegen, mit der ich den Default-Pfad “überschreiben” kann und dadurch hin und herwechseln kann, je nachdem in welcher Zeile ich mit einer Raute auskommentiere. Dies möchte ich hier gerne mit zeigen:
Wir gehen also nach /etc/ansible
$ cd /etc/ansible
Hier liegt eine Datei die sich “ansible.cfg” nennt. Diese beinhaltet bereits alle möglichen Dinge in auskommentiert. Meine Ansible-Repos lege ich in der Regel im Home-Verzeichniss ab, somit ergibt sich dann folgende Änderung:
inventory = ~/your-folder-ansible-repository/hosts
Dadurch kennt Ansible jetzt diese hosts-Datei an dieser Stelle.
Ein relativ einfaches und dennoch sehr leistungsstarkes Kommando ist Ping. Wenn ihr also überhaupt wissen woll, ob Ihr Eure Geräte erreicht, ohne Euch alle IPs oder cryptische DNS-Namen und so zu merken, übernimmt das dann Ansible für Euch.
Das Kommando ist lauf Dokumentation:
$ ansible all -m ping
Wer das nun 1:1 in die Komandozeile feuert, wird wahrscheinlich einen Fehler zurück bekommen, der sich ungefähr so liehst:
192.168.1.2 | UNREACHABLE! => {
"changed": false,
"msg": "Failed to connect to the host via ssh: andreas@45.152.126.232: Permission denied (publickey,password).",
"unreachable": true
}
Der Grund ist relativ simple: Ansible führt hier keinen reinen “Netzwerk-Ping” aus, sondern prüft, ob es auf dem Zielsystem “arbeiten” könnte. Damit Ansible arbeiten kann, muss es sich per SSH einwählen können. In der Regel dann auch in roter Schrift.
Wenn ihr nur Eure Daheim-Geräte in Euren privaten Netzwerken veransibeln wollt, wird ein SSH-Zugriff mit Benutzer und Kennwort reichen. Dann wäre das vollstände Kommando in etwa so:
$ ansible all -m ping -u meinbenutzer --ask-pass
Beim Verbinden wird Ansible Euch nach dem Kennwort fragen.
Wenn Ihr sicher seid und einen Public- und Privatekey für Eure SSH-Connections nutzt, dann sieht das vollständige Kommando in etwa so aus:
$ ansible all -m ping -u meinbenutzer --private-key ./pfad/zum/private_key_file
Die Antwort sollte in Grüner Schrift folgenderweise aussehen:
192.168.1.2 | SUCCESS => {
"ansible_facts": {
"discovered_interpreter_python": "/usr/bin/python"
},
"changed": false,
"ping": "pong"
}
Glückwunsch.
Schauen wir uns noch kurz den Befehl an:
$ ansible
ruft Ansible auf. all sagt dass wir dies für alle in der hosts-Datei angegebenen Hosts tun wollen. -m ping definiert das Modul ping, welches uns dann mit einem Pong geantwortet hat. -u meinbenutzer definiert den SSH-Benutzer auf dem Zielsystem und den Rest haben wir ja schon erklärt.
Den Benutzer und den Rest lassen wir ab hier jetzt dann auch weg wenn wir hier zeigen, wie wir mit Ansible arbeiten. Das kann man sich auch permanent einrichten aber das zeigen wir Euch in einem anderen Teil, weil wir dazu noch paar andere Dinge erklären müssen.
Ping-Pong ist auch nicht das Ende, was man hier treiben kann. Man kann hier jedes Beliebige Linux-Commando gegen eine beliebige Anzahl an Rechnern feuern. Sogar mit Admin-Rechten:
$ ansible all -a "systemctl status nginx.service" -b -K
Dies würde auf allen Hosts schauen, ob der Webserver gestartet ist, wofür erhöhte Rechte je nach Distribution und Konfiguration nötig sein können. -b oder auch –become ist die Option, um als Admin oder Root auf dem Zielsystem zu kommen, -K ist die Option um das Administrator- oder Root-Kennwort interaktiv anzugeben.
Sehr oft will man aber sehr viel einfachere Dinge wissen – zum Beispiel ob noch freier Arbeitspeicher auf den Zielsystemen existiert – was dann zum Beispiel so aussehen könnte:
$ ansible all -a "free -h" -u andreas --ask-pass SSH password: 192.168.1.2 | CHANGED | rc=0 >> total used free shared buff/cache available Mem: 31Gi 305Mi 31Gi 25Mi 420Mi 31Gi Swap: 47Gi 0B 47Gi
Das ist am Ende das gleiche, wie sich in jeden einzelnen Rechner per SSH einzuloggen und dort genau diesen Befehl auszuführen.
Hosts gruppieren mit Ansible
In der Hosts haben wir jetzt genau eine Gruppe und genau einen Host angelegt. Die Befehle haben wir noch mit der Gruppe “all” gerufen, die Ansible automatisch kennt und die jegliche Unterteilung ignoriert.
Ansonsten kann man in jede Gruppe viele Hosts hinzufügen und jeden Host auch mehrfach in verschiedenen Gruppen zuordnen. Das ist ziemlich flexibel.
Euch hat dieser Beitrag gefallen? Es fehlt etwas oder man könnte noch etwas besser erklären? Irgendwas ist outdatet und könnte im Beitrag aktualisiert werden? Lasst uns doch einen Kommentar da. Wenn Ihr uns helfen oder Unterstützen wollt, freuen wir uns über eine Mitgliedschaft oder eine Spende.
