In unserem ersten Beitrag haben wir bereits gezeigt, wie wir unseren Ansible-Arbeitsplatz einrichten um anfangen zu k\u00f6nnen. Im zweiten Teil wollen wir uns mit dem Anlegen von Hosts besch\u00e4ftigen, zu denen wir uns verbinden k\u00f6nnen. Wie immer gilt, wir versuchen keine vollst\u00e4ndige Dokumentation von Ansible oder eine \u00dcbersetzung. Sicherlich gibt es tausend Tutorials im Netz, die erheblich tiefere Informationen bieten – wir wollen Euch hier zeigen, wie wir damit arbeiten und welche \u00dcberlegungen wir dabei hatten um so die grobe Grundstruktur zu erkl\u00e4ren.<\/p>\n
<\/p>\n
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.<\/p>\n
<\/p>\n
In unserem Repository legen wir zuerst die Hosts-Datei an:<\/p>\n
$ touch hosts<\/pre>\nIn dieser Datei werden die verf\u00fcgbaren Ger\u00e4te angelegt. Das werden mit der Zeit sowieso mehr, also werden wir hier sofort anfangen, diese in Gruppen aufzuteilen.<\/p>\n
<\/p>\n
Vorwegnehmend auf Teil 3, wollen wir, dass sich Benutzer auf den Ger\u00e4ten per SSH einloggen k\u00f6nnen. Dies wird sich bestimmt auch wieder unterscheiden, wer sich wo einw\u00e4hlen 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.<\/p>\n
[ssh_access_ff_general]\r\n192.168.1.2\r\n<\/pre>\nDie IP steht hier nur als Platzhalter, nat\u00fcrlich m\u00fcsstet Ihr da Eure IP reinsetzen und die Datei dann speichern.<\/p>\n
<\/p>\n
Wenn Ihr die \u00c4nderung in Euer Git-Repo versionieren wollt, k\u00f6nnt ihr diese \u00c4nderung Euch nun anzeigen lassen:<\/p>\n
$ git status<\/pre>\nHier sollte eine neue Datei in der R\u00fcckgabe zu erkennen sein.<\/p>\n
<\/p>\n
Diese Datei k\u00f6nnt ihr dann zum n\u00e4chsten commit adden:<\/p>\n
$ git add hosts<\/pre>\nDamit ist die Datei zur Versionierung vorgemerkt.<\/p>\n
<\/p>\n
Dann wollt ihr diese \u00c4nderung committen, dadurch wird ein neuer Commit erstellt.<\/p>\n
$ git commit<\/pre>\nDas System wird Euch in Euren File-Editor werfen, damit ihr dort eine Commit-Nachricht oder eine Beschreibung Eurer \u00c4nderung hinterlasst. Beim allerersten mal werdet Ihr auch den Editor mit einer Zahl aus der Liste der installierten Editoren ausw\u00e4hlen m\u00fcssen. Mit speichern und schlie\u00dfen des Editors ist der Commit fertig.<\/p>\n
<\/p>\n
Damit Eure \u00c4nderung auch allen anderen, die mit Euch Arbeiten, im Repo auf Github oder Gitlab zur Verf\u00fcgung stehen, muss die \u00c4nderung noch “gepushed” werden.<\/p>\n
$ git push<\/pre>\nDabei 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.<\/p>\n
<\/p>\n
erste Kommandos mit Ansible<\/strong><\/p>\n
<\/p>\n
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\u00dferdem gibt es so Leute wie mich, die Ansible in mehreren Rollen in verschiedenen Organisationen einsetzen. Es w\u00e4re also au\u00dferordentlich 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.<\/p>\n
Was ich dort mache, ist eine Konfigurationsdatei f\u00fcr Ansible Anlegen, mit der ich den Default-Pfad “\u00fcberschreiben” kann und dadurch hin und herwechseln kann, je nachdem in welcher Zeile ich mit einer Raute auskommentiere. Dies m\u00f6chte ich hier gerne mit zeigen:<\/p>\n
Wir gehen also nach \/etc\/ansible<\/p>\n
$ cd \/etc\/ansible<\/pre>\nHier liegt eine Datei die sich “ansible.cfg” nennt. Diese beinhaltet bereits alle m\u00f6glichen Dinge in auskommentiert. Meine Ansible-Repos lege ich in der Regel im Home-Verzeichniss ab, somit ergibt sich dann folgende \u00c4nderung:<\/p>\n
inventory = ~\/your-folder-ansible-repository\/hosts<\/pre>\nDadurch kennt Ansible jetzt diese hosts-Datei an dieser Stelle.<\/p>\n
<\/p>\n
Ein relativ einfaches und dennoch sehr leistungsstarkes Kommando ist Ping. Wenn ihr also \u00fcberhaupt wissen woll, ob Ihr Eure Ger\u00e4te erreicht, ohne Euch alle IPs oder cryptische DNS-Namen und so zu merken, \u00fcbernimmt das dann Ansible f\u00fcr Euch.<\/p>\n
Das Kommando ist lauf Dokumentation:<\/p>\n
$ ansible all -m ping<\/pre>\nWer das nun 1:1 in die Komandozeile feuert, wird wahrscheinlich einen Fehler zur\u00fcck bekommen, der sich ungef\u00e4hr so liehst:<\/p>\n
192.168.1.2 | UNREACHABLE! => {\r\n\"changed\": false,\r\n\"msg\": \"Failed to connect to the host via ssh: andreas@45.152.126.232: Permission denied (publickey,password).\",\r\n\"unreachable\": true\r\n}<\/pre>\nDer Grund ist relativ simple: Ansible f\u00fchrt hier keinen reinen “Netzwerk-Ping” aus, sondern pr\u00fcft, ob es auf dem Zielsystem “arbeiten” k\u00f6nnte. Damit Ansible arbeiten kann, muss es sich per SSH einw\u00e4hlen k\u00f6nnen. In der Regel dann auch in roter Schrift.<\/p>\n
<\/p>\n
Wenn ihr nur Eure Daheim-Ger\u00e4te in Euren privaten Netzwerken veransibeln wollt, wird ein SSH-Zugriff mit Benutzer und Kennwort reichen. Dann w\u00e4re das vollst\u00e4nde Kommando in etwa so:<\/p>\n
$ ansible all -m ping -u meinbenutzer --ask-pass<\/pre>\nBeim Verbinden wird Ansible Euch nach dem Kennwort fragen.<\/p>\n
<\/p>\n
Wenn Ihr sicher seid und einen Public- und Privatekey f\u00fcr Eure SSH-Connections nutzt, dann sieht das vollst\u00e4ndige Kommando in etwa so aus:<\/p>\n
$ ansible all -m ping -u meinbenutzer --private-key .\/pfad\/zum\/private_key_file<\/pre>\n<\/p>\n
Die Antwort sollte in Gr\u00fcner Schrift folgenderweise aussehen:<\/p>\n
192.168.1.2 | SUCCESS => {\r\n \"ansible_facts\": {\r\n \"discovered_interpreter_python\": \"\/usr\/bin\/python\"\r\n },\r\n \"changed\": false,\r\n \"ping\": \"pong\"\r\n}<\/pre>\nGl\u00fcckwunsch.<\/p>\n
<\/p>\n
Schauen wir uns noch kurz den Befehl an:<\/p>\n
$ ansible <\/pre>\nruft Ansible auf. all sagt dass wir dies f\u00fcr 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\u00e4rt.<\/p>\n
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\u00e4ren m\u00fcssen.<\/p>\n
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:<\/p>\n
$ ansible all -a \"systemctl status nginx.service\" -b -K<\/pre>\nDies w\u00fcrde auf allen Hosts schauen, ob der Webserver gestartet ist, wof\u00fcr erh\u00f6hte Rechte je nach Distribution und Konfiguration n\u00f6tig sein k\u00f6nnen. -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.<\/p>\n
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\u00f6nnte:<\/p>\n
$ ansible all -a \"free -h\" -u andreas --ask-pass\r\nSSH password:\r\n192.168.1.2 | CHANGED | rc=0 >>\r\ntotal used free shared buff\/cache available\r\nMem: 31Gi 305Mi 31Gi 25Mi 420Mi 31Gi\r\nSwap: 47Gi 0B 47Gi<\/pre>\nDas ist am Ende das gleiche, wie sich in jeden einzelnen Rechner per SSH einzuloggen und dort genau diesen Befehl auszuf\u00fchren.<\/p>\n
<\/p>\n
Hosts gruppieren mit Ansible<\/strong><\/p>\n
<\/p>\n
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.<\/p>\n
Ansonsten kann man in jede Gruppe viele Hosts hinzuf\u00fcgen und jeden Host auch mehrfach in verschiedenen Gruppen zuordnen. Das ist ziemlich flexibel.<\/p>\n
<\/p>\n
<\/p>\n
Euch hat dieser Beitrag gefallen? Es fehlt etwas oder man k\u00f6nnte noch etwas besser erkl\u00e4ren? Irgendwas ist outdatet und k\u00f6nnte im Beitrag aktualisiert werden? Lasst uns doch einen Kommentar da. Wenn Ihr uns helfen oder Unterst\u00fctzen wollt, freuen wir uns \u00fcber eine Mitgliedschaft oder eine Spende.<\/p>\n","protected":false},"excerpt":{"rendered":"
In unserem ersten Beitrag haben wir bereits gezeigt, wie wir unseren Ansible-Arbeitsplatz einrichten um anfangen zu k\u00f6nnen. Im zweiten Teil wollen wir uns mit dem Anlegen von Hosts besch\u00e4ftigen, zu denen wir uns verbinden k\u00f6nnen. Wie immer gilt, wir versuchen keine vollst\u00e4ndige Dokumentation von Ansible oder eine \u00dcbersetzung. Sicherlich gibt […]<\/p>\n","protected":false},"author":6,"featured_media":1842,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1,84,47],"tags":[85,87],"_links":{"self":[{"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/posts\/1825"}],"collection":[{"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/comments?post=1825"}],"version-history":[{"count":0,"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/posts\/1825\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/media\/1842"}],"wp:attachment":[{"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/media?parent=1825"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/categories?post=1825"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/freifunk-kitzingen.de\/index.php\/wp-json\/wp\/v2\/tags?post=1825"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}