{"id":1701,"date":"2016-12-17T12:50:31","date_gmt":"2016-12-17T11:50:31","guid":{"rendered":"https:\/\/www.my-it-brain.de\/wordpress\/?p=1701"},"modified":"2021-01-25T13:01:34","modified_gmt":"2021-01-25T12:01:34","slug":"ansible-was-ich-am-ad-hoc-modus-schaetze","status":"publish","type":"post","link":"https:\/\/www.my-it-brain.de\/wordpress\/ansible-was-ich-am-ad-hoc-modus-schaetze\/","title":{"rendered":"Ansible – Was ich am Ad-hoc-Modus sch\u00e4tze"},"content":{"rendered":"

Schon seit einiger Zeit hilft mir Ansible[1. Ansible – IT-Automation f\u00fcr Jedermann<\/a>] fast t\u00e4glich dabei, meine Arbeit leichter zu gestalten. Heute m\u00f6chte ich euch ganz kurz erz\u00e4hlen, was ich am Ad-hoc-Modus sch\u00e4tze.<\/p>\n

Der Ad-hoc-Modus bietet die M\u00f6glichkeit, einfache Kommandos parallel auf einer Gruppe von Nodes ausf\u00fchren zu lassen, ohne zuvor ein Playbook erstellen zu m\u00fcssen. Ein Ad-hoc-Befehl besitzt z.B. den folgenden Aufbau:
\n
\nansible [-m module_name] [-a args] [options]
\n<\/code><\/p>\n

Ein einfaches Beispiel aus der Ansible-Dokumentation[2. Introduction To Ad-Hoc Commands<\/a> {en}] soll die Anwendung verdeutlichen:
\n
\n# ansible all -m ping -i staging --limit=e-stage
\nhost01.example.com | SUCCESS => {
\n\"changed\": false,
\n\"ping\": \"pong\"
\n}
\nhost02.example.com | SUCCESS => {
\n\"changed\": false,
\n\"ping\": \"pong\"
\n}
\nhost03.example.com | SUCCESS => {
\n\"changed\": false,
\n\"ping\": \"pong\"
\n}
\n<\/code><\/p>\n

Das Schl\u00fcsselwort all<\/code> gibt an, dass das Kommando auf allen Nodes ausgef\u00fchrt werden soll, welche in der Inventar-Datei enthalten sind. Mit -m ping<\/code> wird das zu verwendende Ansible-Modul spezifiziert. Da das verwendete Modul keine weiteren Argumente besitzt, findet -a<\/code> in diesem Beispiel keine Anwendung. Mit der Option -i<\/code> kann die zu verwendende Inventar-Datei angegeben werden. L\u00e4sst man diese Option weg, wird die Standard-Inventar-Datei \/etc\/ansible\/hosts<\/code> verwendet. Mit der Option --limit=e-stage<\/code> wird die Ausf\u00fchrung noch weiter eingeschr\u00e4nkt. So wird in diesem Fall das Modul ping<\/code> nur auf den Nodes der Gruppe e-stage<\/code> ausgef\u00fchrt. Das in diesem Beispiel verwendete Inventar besitzt den folgenden Aufbau:<\/p>\n

[e-stage]\r\nhost01.example.com\r\nhost02.example.com\r\nhost03.example.com\r\nhost06.example.com\r\nhost07.example.com\r\n\r\n[i-stage]\r\nhost04.example.com\r\n\r\n[p-stage]\r\nhost05.example.com\r\n<\/pre>\n
Verkn\u00fcpfung mit weiteren Kommandos<\/h2>\n
Selbstverst\u00e4ndlich lassen sich Ansible-Ad-hoc-Kommandos auf der Kommandozeile auch weiter verkn\u00fcpfen. Dies soll an zwei kleinen Beispielen verdeutlicht werden.<\/p>\n
Status eines Dienstes pr\u00fcfen<\/h3>\n
In diesem ersten Beispiel soll der Status des Dienstes chronyd<\/code> \u00fcberpr\u00fcft werden, ohne den aktuellen Status zu \u00e4ndern. Dabei soll das Kommando systemctl status chronyd.service<\/code> via Ansible parallel auf den Nodes ausgef\u00fchrt werden.<\/p>\n
Zuvor habe ich mir auf einem Node angesehen, wie die Ansible-Ausgabe in Abh\u00e4ngigkeit vom Dienststatus aussieht (Ausgabe gek\u00fcrzt):
\n
\n# Der Dienst auf dem Node ist gestartet
\nroot@ansible-control-machine>ansible all -m command -a'\/usr\/bin\/systemctl status chronyd.service' -i staging -l host01.example.com
\nhost01.example.com | SUCCESS | rc=0 >>
\n* chronyd.service - NTP client\/server
\nLoaded: loaded (\/usr\/lib\/systemd\/system\/chronyd.service; enabled; vendor preset: enabled)
\nActive: active (running) since Thu 2016-12-15 14:52:02 CET; 19h ago<\/code><\/p>\n
# Der Dienst auf dem Node ist gestoppt
\nroot@ansible-control-machine>ansible all -m command -a’\/usr\/bin\/systemctl status chronyd.service‘ -i staging -l host01.example.com
\nhost01.example.com | FAILED | rc=3 >>
\n* chronyd.service – NTP client\/server
\nLoaded: loaded (\/usr\/lib\/systemd\/system\/chronyd.service; enabled; vendor preset: enabled)
\nActive: inactive (dead) since Fri 2016-12-16 10:04:34 CET; 4s ago<\/p>\n
# Das Paket, welches den Dienst enthaelt ist nicht installiert
\nroot@ansible-control-machine>ansible all -m command -a’\/usr\/bin\/systemctl status chronyd.service‘ -i staging -l host01.example.com
\nhost01.example.com | FAILED | rc=4 >>
\nUnit chronyd.service could not be found.<\/p>\n
Anhand der Ausgaben ist zu erkennen, dass Ansible den Task als „| SUCCESS |“ markiert, wenn der Dienst l\u00e4uft und als „| FAILED |“, wenn der Dienst gestoppt bzw. gar nicht installiert ist. Durch Verkn\u00fcpfung des Kommandos mit grep<\/code> kann man sich nun schnell einen \u00dcberblick \u00fcber den Dienststatus auf seinen Rechnern verschaffen:
\n
\nroot@ansible-control-machine> ansible all -m command -a'\/usr\/bin\/systemctl status chronyd.service' -i staging --limit=e-stage | grep '| SUCCESS |\\|| FAILED |'
\nhost01.example.com | SUCCESS | rc=0 >>
\nhost02.example.com | SUCCESS | rc=0 >>
\nhost03.example.com | FAILED | rc=3 >>
\nhost06.example.com | SUCCESS | rc=0 >>
\nhost07.example.com | SUCCESS | rc=0 >>
\n<\/code><\/p>\n
Anhand der Ausgabe ist leicht zu erkennen, dass der Dienst chronyd<\/code> auf host03 nicht l\u00e4uft. Anhand des Return-Codes rc=3<\/code> l\u00e4sst sich weiterhin erkennen, dass das notwendige Paket offensichtlich installiert ist, der Dienst jedoch nicht gestartet wurde. Dies kann nun jedoch schnell durch folgenden Befehl korrigiert werden (Ausgabe gek\u00fcrzt):
\n
\nroot@ansible-control-machine>ansible host03.example.com -m systemd -a'name=chronyd state=started' -i staging
\nhost03.example.com | SUCCESS => {
\n\"changed\": true,
\n\"name\": \"chronyd\",
\n\"state\": \"started\",
\n\"status\": {...}
\n}
\n<\/code><\/p>\n
Eine erneute Ausf\u00fchrung des ersten Kommandos best\u00e4tigt, dass der Dienst nun auch auf dem Node host03 ausgef\u00fchrt wird.
\n
\nroot@ansible-control-machine> ansible all -m command -a'\/usr\/bin\/systemctl status chronyd.service' -i staging --limit=e-stage | grep '| SUCCESS |\\|| FAILED |'
\nhost01.example.com | SUCCESS | rc=0 >>
\nhost02.example.com | SUCCESS | rc=0 >>
\nhost03.example.com | SUCCESS | rc=0 >>
\nhost06.example.com | SUCCESS | rc=0 >>
\nhost07.example.com | SUCCESS | rc=0 >>
\n<\/code><\/p>\n
Paketversion \u00fcberpr\u00fcfen<\/h3>\n
In diesem Beispiel m\u00f6chte ich die installierte Version des Pakets tzdata<\/code> abfragen. Dies geschieht auf einem einzelnen Host mit dem Kommando rpm -qi <\/code>:
\n
\n# rpm -qi tzdata
\nName : tzdata
\nVersion : 2016i
\nRelease : 1.el7
\nArchitecture: noarch
\nInstall Date: Wed Nov 9 08:47:03 2016
\nGroup : System Environment\/Base
\nSize : 1783642
\nLicense : Public Domain
\nSignature : RSA\/SHA256, Fri Nov 4 17:21:59 2016, Key ID 199e2f91fd431d51
\nSource RPM : tzdata-2016i-1.el7.src.rpm
\nBuild Date : Thu Nov 3 12:46:39 2016
\nBuild Host : ppc-045.build.eng.bos.redhat.com
\nRelocations : (not relocatable)
\nPackager : Red Hat, Inc. <http:\/\/bugzilla.redhat.com\/bugzilla>
\nVendor : Red Hat, Inc.
\nURL : https:\/\/www.iana.org\/time-zones
\nSummary : Timezone data
\nDescription :
\nThis package contains data files with rules for various timezones around
\nthe world.
\n<\/code><\/p>\n
Mich interessiert lediglich die zweite Zeile, welche die Version des Pakets enth\u00e4lt. Die frage ich nun wie folgt ab:
\n
\nroot@ansible-control-machine> ansible all -m command -a'\/usr\/bin\/rpm -qi tzdata' -i staging --limit=e-stage | grep 'SUCCESS\\|Version'
\nhost01.example.com | SUCCESS | rc=0 >>
\nVersion : 2016f
\nhost02.example.com | SUCCESS | rc=0 >>
\nVersion : 2016g
\nhost03.example.com | SUCCESS | rc=0 >>
\nVersion : 2016i
\nhost06.example.com | SUCCESS | rc=0 >>
\nVersion : 2016i
\nhost07.example.com | SUCCESS | rc=0 >>
\nVersion : 2016i
\n<\/code><\/p>\n
Ohne Ansible h\u00e4tte ich diese Aufgaben entweder mit Iteration in einem kurzen Shell-Skript l\u00f6sen m\u00fcssen, oder zuerst ein Kochbuch, Manifest, etc. schreiben, welches dann anschlie\u00dfend ausgef\u00fchrt werden kann. So wurde mir hingegen einiges an Zeit gespart, die ich f\u00fcr andere Dinge verwenden konnte.<\/p>\n
Quellen und weiterf\u00fchrende Links<\/strong><\/p>\n