Ansible: Block/Rescue Pattern

[Ralph Aichinger]

Ist hier die richtige Gruppe für Ansible? Nein, es ist nicht
strictly Linux, aber ich vermute doch, dass sich die Anwendung
im Wesentlichen auf Linux konzentriert? Vorschläge für besser
passende NGs werden angenommen.

Egal: Ich mach gerade relativ viel mit Ansible, und wollte mal
rumfragen, was die allgemeine Meinung über das "block/rescue"
(also quasi Exceptions) bei Ansible ist. Ich ertappe mich
derzeit dabei, dass ich das sehr oft mache, z.B. wenn ich
ein Zertifikat installieren will: Vorher checken ob es schon
installiert ist, und wenn ein Error kommt (es nicht installiert
ist) im "rescue" Teil die eigentliche Installation rein.

Vorteil: Keine irritierenden Changes wenn gar nichts gemacht
werden soll. Man kann auch sein Playbook noch mal laufen lassen,
und sieht daran, dass eben nix passiert, dass die abgefragte
Bedingung eingehalten ist (und kein Fehlerzustand passiert).

Nachteil: Man hat im "regulären" ersten Lauf einen Fehler im Log drin,
auch wenn gar nichts kaputt ist. Ich schreib immer zu der jeweiligen
Task dazu dass hier ein Fehler passieren darf.

Ist das eurer Meinung nach OK, sowas so zu lösen? Gibt es ein
eleganteres Konstrukt, das umfangreichere Bedingungen
(also nicht z.B. die Existenz einer einzelnen Datei, die man mit
"creates" nutzen kann) verwendet um Code auszuführen, das man
verwenden sollte. Was für mich auch den Charme von "block"/"rescue"
ausmacht, ist, dass die Bedingung "durchfällt", selbst wenn ein
*anderer* Fehler als eigentlich gedacht auftritt.

/ralph

[Marc Haber]

Post by Ralph Aichinger
Ist hier die richtige Gruppe für Ansible? Nein, es ist nicht
strictly Linux, aber ich vermute doch, dass sich die Anwendung
im Wesentlichen auf Linux konzentriert? Vorschläge für besser
passende NGs werden angenommen.
Egal: Ich mach gerade relativ viel mit Ansible, und wollte mal
rumfragen, was die allgemeine Meinung über das "block/rescue"
(also quasi Exceptions) bei Ansible ist. Ich ertappe mich
derzeit dabei, dass ich das sehr oft mache, z.B. wenn ich
ein Zertifikat installieren will: Vorher checken ob es schon
installiert ist, und wenn ein Error kommt (es nicht installiert
ist) im "rescue" Teil die eigentliche Installation rein.
Vorteil: Keine irritierenden Changes wenn gar nichts gemacht
werden soll. Man kann auch sein Playbook noch mal laufen lassen,
und sieht daran, dass eben nix passiert, dass die abgefragte
Bedingung eingehalten ist (und kein Fehlerzustand passiert).
Nachteil: Man hat im "regulären" ersten Lauf einen Fehler im Log drin,
auch wenn gar nichts kaputt ist. Ich schreib immer zu der jeweiligen
Task dazu dass hier ein Fehler passieren darf.

Weiterer Nachteil: Je komplex, desto langsam. Das wird Dich früher
oder später tödlich nerven.

Grüße
Marc

[Peter J. Holzer]

Post by Marc Haber

Post by Ralph Aichinger
Ich mach gerade relativ viel mit Ansible, und wollte mal
rumfragen, was die allgemeine Meinung über das "block/rescue"
(also quasi Exceptions) bei Ansible ist. Ich ertappe mich
derzeit dabei, dass ich das sehr oft mache, z.B. wenn ich
ein Zertifikat installieren will: Vorher checken ob es schon
installiert ist, und wenn ein Error kommt (es nicht installiert
ist) im "rescue" Teil die eigentliche Installation rein.
Vorteil: Keine irritierenden Changes wenn gar nichts gemacht
werden soll.

Hmm. Da würde ich eher bei der Aktion ansetzen. Wenn nichts zu tun ist,
sollte ja eigentlich kein Change angezeigt werden.

Post by Marc Haber

Post by Ralph Aichinger
Nachteil: Man hat im "regulären" ersten Lauf einen Fehler im Log drin,
auch wenn gar nichts kaputt ist. Ich schreib immer zu der jeweiligen
Task dazu dass hier ein Fehler passieren darf.

Weiterer Nachteil: Je komplex, desto langsam. Das wird Dich früher
oder später tödlich nerven.

Performance ist bei Ansible ohnehin etwas, das mich nervt. Das ist
fürchterlich langsam. Wenn man ausreichend viele Rechner konfigurieren
will, wird das durch Parallelisierung entschärft, aber bei einem
einzelnen Rechner kann das schon nerven.

hp

[Ralph Aichinger]

Post by Peter J. Holzer

Post by Ralph Aichinger
Vorteil: Keine irritierenden Changes wenn gar nichts gemacht
werden soll.

Hmm. Da würde ich eher bei der Aktion ansetzen. Wenn nichts zu tun ist,
sollte ja eigentlich kein Change angezeigt werden.

Stimmt, ich hätte dazuschreiben sollen, dass ich das oft bei
ansible.builtin.command oder .shell oder sowas mache, d.h. bei
Konstrukten wo man kein sinnvolles Feedback über den Status kriegt.

Ja, man kann vermutlich fast alles ohne command und shell lösen,
aber vor die Wahl gestellt irgendwelche obskuren Ansible Galaxy-Module
zu installieren oder 1-2 Zeilen Shell einzubauen, tu ich oft letzteres.

Post by Peter J. Holzer
Performance ist bei Ansible ohnehin etwas, das mich nervt. Das ist
fürchterlich langsam. Wenn man ausreichend viele Rechner konfigurieren
will, wird das durch Parallelisierung entschärft, aber bei einem
einzelnen Rechner kann das schon nerven.

Ja, vor allem auch während man Dinge ausprobiert und testet. Wirklich
jede Fehlerbedingung durchzutesten, oder zu probieren was passiert wenn
man mit Ansible eine Software installiert, dann deinstalliert, dann
wieder installiert, das kann schon mal dauern.

/ralph

[Ralph Aichinger]

Post by Marc Haber
Weiterer Nachteil: Je komplex, desto langsam. Das wird Dich früher
oder später tödlich nerven.

Tut es schon, mit oder ohne dieses Konstrukt. Letztendlich ist Ansible
immer mit kleinen Kaffeepausen verbunden (die Kaffeemaschine ist nah,
ein Espresso geht sich in manchen Ansible-Läufen gut aus ;)

Aber während Ansible selbst natürlich auch langsam ist, ist vieles an
Wartezeit einfach in dem drin, was Ansible auslöst, also den
Konfigurationsschritten am Zielsystem, die man vermutlich auch mit
"schnelleren" Systemen (z.B. Salt dürfte schneller sein?) nicht los
wird. Großes Paket XY zu installieren dauert einfach.

/ralph