Block<\/code> usw. Je besser Sie Ansible kennen, desto mehr Nuancen k\u00f6nnen Sie f\u00fcr eine \"clevere\" L\u00f6sung benennen. Eine einfache L\u00f6sung \u2014 die Verwendung einer nat\u00fcrlichen Trennung zwischen pre\/roles\/post \u2014 verursacht keine Nuancen.<\/p>\n<\/p>\n
Und zur\u00fcck zu unserem 'foo'. Wo soll es platziert werden? In pre, post oder in roles? Offensichtlich h\u00e4ngt das davon ab, ob wir die Ergebnisse des Handlers f\u00fcr foo ben\u00f6tigen. Wenn nicht, muss foo weder in pre noch in post platziert werden \u2014 diese Abschnitte haben eine spezielle Bedeutung \u2014 das Ausf\u00fchren von Aufgaben vor und nach dem Hauptcode-Array.<\/p>\n
<\/p>\n
Jetzt reduziert sich die Antwort auf die Frage \"Rolle oder Aufgabe\" darauf, was bereits im Play vorhanden ist \u2014 wenn dort Aufgaben (tasks) vorhanden sind, muss das in die Aufgaben geschrieben werden. Wenn es Rollen (roles) gibt, muss eine Rolle erstellt werden (auch wenn es nur aus einer Aufgabe besteht). Ich erinnere daran, dass Aufgaben und Rollen nicht gleichzeitig verwendet werden.<\/p>\n
<\/p>\n
Ein Verst\u00e4ndnis der Grundlagen von Ansible liefert fundierte Antworten auf Fragen, die auf den ersten Blick nach Geschmacksfragen aussehen.<\/p>\n
<\/p>\n
Tasks und Rollen (Teil zwei)<\/h1>\n <\/p>\n
Lassen Sie uns nun die Situation besprechen, in der Sie gerade anfangen, ein Playbook zu schreiben. Sie m\u00fcssen foo, bar und baz erledigen. Handelt es sich um eine Aufgabe, eine Rolle oder drei Rollen? Allgemeiner gesagt: Ab wann sollten Rollen geschrieben werden? Wozu ist es sinnvoll, Rollen zu schreiben, wenn man auch Aufgaben schreiben kann? \u2026 Was ist eigentlich eine Rolle?<\/p>\n
<\/p>\n
Einer der gravierendsten Fehler (ich habe dar\u00fcber bereits gesprochen) ist zu glauben, dass eine Rolle wie eine Funktion in einer Bibliothek eines Programms ist. Wie sieht die allgemeine Beschreibung einer Funktion aus? Sie nimmt Argumente entgegen, interagiert mit Nebeneffekten, erzeugt Nebenwirkungen und gibt einen Wert zur\u00fcck.<\/p>\n
<\/p>\n
Jetzt, Achtung. Was davon kann in einer Rolle gemacht werden? Nebenwirkungen (side effects) aufrufen \u2014 immer gerne, das ist die Essenz von Ansible \u2014 Nebenwirkungen erzeugen. Side causes haben? Elementar. Aber bei \"Wert \u00fcbergeben und zur\u00fcckgeben\" \u2014 hier gibt es ein Problem. Erstens k\u00f6nnen Sie keinen Wert an eine Rolle \u00fcbergeben. Sie k\u00f6nnen eine globale Variable haben, deren Lebensdauer die des Plays hat, im Abschnitt vars f\u00fcr die Rolle. Eine globale Variable mit einer Lebensdauer innerhalb der Rolle setzen? Oder sogar mit einer Lebensdauer des Playbooks.set_fact<\/code>\/register<\/code>). Aber Sie k\u00f6nnen keine "lokalen Variablen" haben. Sie k\u00f6nnen keinen "Wert empfangen" und "ihn zur\u00fcckgeben".<\/p>\n<\/p>\n
Daraus folgt das Wesentliche: Man kann in Ansible etwas schreiben, ohne dass es Nebenwirkungen gibt. Das \u00c4ndern von globalen Variablen ist immer eine Nebenwirkung f\u00fcr eine Funktion. In Rust beispielsweise ist die \u00c4nderung einer globalen Variablen unsafe<\/code>. In Ansible gibt es jedoch nur eine Methode, um die Werte f\u00fcr eine Rolle zu beeinflussen. Achten Sie auf die verwendeten Worte: nicht "Wert an die Rolle \u00fcbergeben", sondern "Werte \u00e4ndern, die die Rolle verwendet". Es besteht keine Isolation zwischen den Rollen. Es gibt keine Isolation zwischen Aufgaben und Rollen.<\/p>\n<\/p>\n
Insgesamt: Eine Rolle ist keine Funktion.<\/strong>.<\/p>\n<\/p>\n
Was ist also gut an einer Rolle? Erstens hat eine Rolle Standardwerte (\/default\/main.yaml<\/code>), zweitens gibt es in einer Rolle zus\u00e4tzliche Verzeichnisse, um Dateien zu speichern.<\/p>\n<\/p>\n
Was ist gut an Standardwerten? Aufgrund der etwas verzerrten Priorit\u00e4tstabelle der Variablen in Ansible sind die Standardwerte der Rolle die am wenigsten priorisierten (mit Ausnahme der Befehlszeilenparameter von Ansible). Das bedeutet, wenn Sie Standardwerte bereitstellen m\u00f6chten und sich keine Sorgen machen wollen, dass diese die Werte aus dem Inventory oder Gruppenvariablen \u00fcberschreiben, sind die Standardeinstellungen der Rolle der einzig richtige Ort f\u00fcr Sie. (Ich l\u00fcge ein wenig \u2013 es gibt noch |d(your_default_here)<\/code>, aber wenn es um station\u00e4re Pl\u00e4tze geht \u2013 dann nur die Standardrollen).<\/p>\n<\/p>\n
Was ist noch gut an Rollen? Sie haben eigene Kataloge. Diese Kataloge sind f\u00fcr Variablen gedacht, sowohl f\u00fcr feste (d.h. f\u00fcr die Rolle berechnete) als auch f\u00fcr dynamische (es gibt dieses Muster oder Anti-Muster \u2013 include_vars<\/code> , indem es {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>). Diese Kataloge sind f\u00fcr files\/<\/code>, templates\/<\/code>. Au\u00dferdem erm\u00f6glichen sie Rollen, eigene Module und Plugins zu haben (library\/<\/code>). Aber im Vergleich zu Aufgaben in Playbooks (wo auch all dies m\u00f6glich sein kann) liegt der Vorteil hier nur darin, dass die Dateien nicht in einem einzigen Haufen, sondern in mehreren separaten Haufen abgelegt sind.<\/p>\n<\/p>\n
Ein weiterer Aspekt: Man kann versuchen, Rollen zu erstellen, die f\u00fcr wiederkehrende Nutzung (\u00fcber Galaxy) verf\u00fcgbar sind. Nach dem Erscheinen von Collections kann die Verbreitung von Rollen als fast vergessen betrachtet werden.<\/p>\n
<\/p>\n
Somit haben Rollen zwei wichtige Merkmale: Sie haben Standards (eine einzigartige Eigenschaft) und sie erm\u00f6glichen eine Strukturierung des Codes.<\/p>\n
<\/p>\n
Zur\u00fcck zu der urspr\u00fcnglichen Frage: Wann sollten Aufgaben und wann Rollen erstellt werden? Aufgaben im Playbook werden meist entweder als \"Kleber\" vor\/nach Rollen verwendet oder als eigenst\u00e4ndiges Bauelement (in diesem Fall sollten keine Rollen im Code vorhanden sein). Eine Ansammlung normaler Aufgaben gemischt mit Rollen ist eindeutig unordentlich. Es sollte ein klarer Stil eingehalten werden \u2013 entweder Aufgaben oder Rollen. Rollen bieten eine Trennung der Entit\u00e4ten und Standardwerte, w\u00e4hrend Aufgaben es erm\u00f6glichen, den Code schneller zu lesen. Normalerweise umfasst eine Rolle den \u201estation\u00e4reren\u201c (wichtigen und komplexen) Code, w\u00e4hrend im Aufgabenstil unterst\u00fctzende Skripte geschrieben werden.<\/p>\n
<\/p>\n
Es ist m\u00f6glich, import_role als Task zu verwenden, aber wenn du das tust, sei bereit, dir selbst zu erkl\u00e4ren, warum du das machen m\u00f6chtest.<\/p>\n
<\/p>\n
Ein aufmerksamer Leser k\u00f6nnte anmerken, dass Rollen weitere Rollen importieren k\u00f6nnen, dass Rollen eine Abh\u00e4ngigkeit \u00fcber galaxy.yml haben k\u00f6nnen und dass es noch das erschreckende und furchtbare gibt. include_role<\/code> Denkt daran, wir verbessern unsere F\u00e4higkeiten in Ansible, nicht in rhythmischer Gymnastik.<\/p>\n<\/p>\n
Handler und Tasks<\/h1>\n <\/p>\n
Lassen Sie uns eine weitere offensichtliche Sache diskutieren: Handler. Die korrekte Verwendung von Handlern ist fast schon eine Kunst. Wo liegt der Unterschied zwischen einem Handler und einer Task?<\/p>\n
<\/p>\n
Da wir die Grundlagen auffrischen, hier ein Beispiel:<\/p>\n
<\/p>\n
- hosts: group1\n tasks:\n - foo:\n notify: handler1\n handlers:\n - name: handler1\n bar:<\/code><\/pre>\n<\/p>\n
Die Handler liegen in rolename\/handlers\/main.yaml. Handler werden zwischen allen Teilnehmern des Plays geteilt: pre\/post_tasks k\u00f6nnen die Handler der Rolle aufrufen, und die Rolle kann Handler aus dem Play aufrufen. Allerdings f\u00fchren \"cross-role\" Aufrufe von Handlern zu viel gr\u00f6\u00dferem Verwirrung als die Wiederholung eines trivialen Handlers. (Ein weiteres Element der Best Practices ist, zu versuchen, die Namen der Handler nicht zu wiederholen).<\/p>\n
<\/p>\n
Der Hauptunterschied besteht darin, dass eine Task immer (idempotent) ausgef\u00fchrt wird (plus\/minus Tags und when<\/code>), ein Handler \u2013 zur Status\u00e4nderung (notify wird nur ausgel\u00f6st, wenn etwas ge\u00e4ndert wurde). Was bedeutet das? Zum Beispiel, dass bei einem erneuten Start, wenn es keine \u00c4nderungen gab, auch kein Handler ausgef\u00fchrt wird. Warum kann es jedoch n\u00f6tig sein, den Handler auszuf\u00fchren, auch wenn bei der generierenden Aufgabe keine \u00c4nderungen festgestellt wurden? Zum Beispiel, weil etwas kaputt gegangen ist und \u00c4nderungen vorgenommen wurden, aber der Ausf\u00fchrung des Handlers nicht nachgekommen wurde. Zum Beispiel, weil das Netzwerk vor\u00fcbergehend ausgefallen war. Die Konfiguration wurde ge\u00e4ndert, der Dienst wurde nicht neu gestartet. Bei der n\u00e4chsten Ausf\u00fchrung wird die Konfiguration nicht mehr ge\u00e4ndert, und der Dienst bleibt mit der alten Konfiguration.<\/p>\n<\/p>\n
Die Situation mit der Konfiguration ist nicht l\u00f6sbar (genauer gesagt, man k\u00f6nnte sich selbst ein spezielles Protokoll f\u00fcr den Neustart mit Datei-Flags ausdenken usw., aber das ist schon nicht mehr 'basic ansible' in irgendeiner Form). Es gibt jedoch eine andere h\u00e4ufige Geschichte: Wir haben die Anwendung installiert und sie aufgezeichnet. .service<\/code>-Datei erstellt und wollen sie jetzt daemon_reload<\/code> und state=started<\/code>. Der nat\u00fcrliche Ort daf\u00fcr scheint ein Handler zu sein. Aber wenn man ihn nicht als Handler, sondern als Aufgabe am Ende der Taskliste oder Rolle einf\u00fcgt, wird er jedes Mal idempotent ausgef\u00fchrt. Selbst wenn das Playbook mitten drin kaputtgeht. Das l\u00f6st das Problem mit dem Attribut restarted nicht (man kann keine Aufgabe mit dem Attribut restarted ausf\u00fchren, da die Idempotenz verloren geht), aber es ist definitiv sinnvoll, state=started zu setzen. Die allgemeine Stabilit\u00e4t der Playbooks erh\u00f6ht sich, da die Anzahl der Abh\u00e4ngigkeiten und dynamischen Zust\u00e4nde verringert wird.<\/p>\n<\/p>\n
Ein weiteres positives Merkmal des Handlers ist, dass er die Ausgabe nicht \u00fcberlappt. Wenn es keine \u00c4nderungen gab, gibt es keine \u00fcberfl\u00fcssigen 'skipped' oder 'ok' in der Ausgabe \u2013 es ist leichter zu lesen. Das ist allerdings auch ein negatives Merkmal \u2013 wenn Sie einen Tippfehler in einer linear ausgef\u00fchrten Aufgabe beim ersten Durchlauf finden, werden die Handler nur bei 'changed' ausgef\u00fchrt, d.h. unter bestimmten Bedingungen \u2013 sehr selten. Zum Beispiel das erste Mal in meinem Leben nach f\u00fcnf Jahren. Und nat\u00fcrlich wird es dort einen Tippfehler im Namen geben, und alles wird kaputt gehen. Und ein zweites Mal k\u00f6nnen sie nicht gestartet werden \u2013 es gibt ja keine \u00c4nderung.<\/p>\n
<\/p>\n
Es ist wichtig, \u00fcber die Verf\u00fcgbarkeit von Variablen zu sprechen. Wenn Sie beispielsweise notify f\u00fcr eine Aufgabe mit einer Schleife verwenden, was wird dann in den Variablen gespeichert? Es kann analytisch verstanden werden, aber das ist nicht immer trivial, besonders wenn die Variablen aus verschiedenen Quellen stammen.<\/p>\n
<\/p>\n
\u2026 Daher sind Handler viel weniger n\u00fctzlich und viel problematischer, als es scheint. Wenn man etwas sch\u00f6n (ohne Ausreden) schreiben kann, sollte man es besser ohne Handler machen. Wenn es nicht sch\u00f6n gelingt, ist es besser, sie zu verwenden.<\/p>\n
<\/p>\n
Ein aufmerksamer Leser weist vollkommen zu Recht darauf hin, dass wir nicht diskutiert haben listen<\/code>, dass ein Handler notify f\u00fcr einen anderen Handler aufrufen kann, dass ein Handler import_tasks enthalten kann (der include_role mit with_items ausf\u00fchren kann), dass das System der Handler in Ansible Turing-vollst\u00e4ndig ist, dass die Handler aus include_role auf merkw\u00fcrdige Weise mit den Handlern aus Play \u00fcberlappen usw. \u2014 all dies sind offensichtlich keine \"Grundlagen\".<\/p>\n<\/p>\n
Obwohl es eine bestimmte \u00dcberraschung gibt, die tats\u00e4chlich eine Funktion ist und die man im Hinterkopf behalten sollte. Wenn Sie eine Aufgabe haben, die mit delegate_to<\/code> ausgef\u00fchrt wird und die einen notify aufweist, wird der entsprechende Handler ohne delegate_to<\/code>ausgef\u00fchrt, d.h. auf dem Host, auf dem das Play zugewiesen ist. (Obwohl der Handler nat\u00fcrlich auch einen delegate_to<\/code> haben kann).<\/p>\n<\/p>\n
Ich m\u00f6chte ein paar Worte zu wiederverwendbaren Rollen sagen. Vor der Einf\u00fchrung von Kollektionen gab es die Idee, universelle Rollen zu schaffen, die man ansible-galaxy install<\/code> , und los geht's. Es funktioniert auf allen Betriebssystemen in allen Varianten und in allen Situationen. Ich denke jedoch, dass es nicht funktioniert. Jede Rolle, die auf unz\u00e4hlige F\u00e4lle abzielt, include_vars<\/code>, mit der Unterst\u00fctzung von 100500 F\u00e4llen ist dazu verurteilt, in den Abgrund von Corner-Case-Bugs zu f\u00fchren. Diese lassen sich zwar mit massivem Testing abdecken, aber wie bei jeder Art von Testing, entweder haben Sie das kartesische Produkt der Eingabewerte und eine totale Funktion, oder Sie \"decken einzelne Szenarien ab\". Meiner Meinung nach ist es viel besser, wenn die Rolle linear ist (cyclomatic complexity 1).<\/p>\n<\/p>\n
Je weniger if\u2019s (explizit oder deklarativ \u2014 in Form von when<\/code> oder in Form von include_vars<\/code> nach einer Variablenliste) vorhanden sind, desto besser ist die Rolle. Manchmal m\u00fcssen Abzweigungen gemacht werden, aber ich wiederhole, je weniger, desto besser. Eine scheinbar gute Rolle von Galaxy (es funktioniert ja!) mit einer F\u00fclle von when<\/code> kann weniger bevorzugt sein als eine \"eigene\" Rolle aus f\u00fcnf Tasks. Der Moment, wenn eine Rolle mit galaxy besser ist \u2014 ist, wenn Sie anfangen, etwas zu schreiben. Der Moment, wenn sie schlechter wird \u2014 ist, wenn etwas kaputtgeht und Sie den Verdacht haben, dass es an der \"Rolle mit galaxy\" liegt. Sie \u00f6ffnen sie und finden f\u00fcnf Includes, acht Task-Listen und einen Stapel when<\/code>\u2018 \u2026 und das muss man herausfinden. Anstelle von 5 Tasks in einer linearen Liste, in der es nichts gibt, woran etwas kaputtgehen kann.<\/p>\n<\/p>\n
In den folgenden Teilen<\/h1>\n <\/p>\n
\nEin wenig \u00fcber Inventare, Gruppenvariablen, das Plugin host_group_vars und Hostvars. Wie man aus Spaghetti einen Gordischen Knoten bindet. Scope und Pr\u00e4ferenz von Variablen, Ansible-Speichermodell. \"Wo zur H\u00f6lle soll der Benutzername f\u00fcr die Datenbank gespeichert werden?\".<\/li>\n jinja: {{ jinja }}<\/code> \u2014 nosql notype nosense weicher Knetgummi. Es ist \u00fcberall, sogar da, wo man es nicht erwartet. Ein bisschen \u00fcber !!unsafe<\/code> und k\u00f6stliches yaml.<\/li>\n<\/ul>\nQuelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u042f \u0434\u0435\u043b\u0430\u044e \u043c\u043d\u043e\u0433\u043e \u0440\u0435\u0432\u044c\u044e \u0434\u043b\u044f \u0447\u0443\u0436\u043e\u0433\u043e \u043a\u043e\u0434\u0430 \u043d\u0430 \u0410\u043d\u0441\u0438\u0431\u043b \u0438 \u043c\u043d\u043e\u0433\u043e \u043f\u0438\u0448\u0443 \u0441\u0430\u043c. \u0412 \u0445\u043e\u0434\u0435 \u0430\u043d\u0430\u043b\u0438\u0437\u0430 \u043e\u0448\u0438\u0431\u043e\u043a (\u043a\u0430\u043a \u0447\u0443\u0436\u0438\u0445, \u0442\u0430\u043a \u0438 \u0441\u0432\u043e\u0438\u0445), \u0430 \u0442\u0430\u043a \u0436\u0435 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0430 \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0439, \u044f \u043f\u043e\u043d\u044f\u043b \u043e\u0441\u043d\u043e\u0432\u043d\u0443\u044e \u043e\u0448\u0438\u0431\u043a\u0443, \u043a\u043e\u0442\u043e\u0440\u0443\u044e \u0434\u043e\u043f\u0443\u0441\u043a\u0430\u044e\u0442 \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0438 \u0410\u043d\u0441\u0438\u0431\u043b\u0430 \u2014 \u043e\u043d\u0438 \u043b\u0435\u0437\u0443\u0442 \u0432 \u0441\u043b\u043e\u0436\u043d\u043e\u0435, \u043d\u0435 \u043e\u0441\u0432\u043e\u0438\u0432 \u0431\u0430\u0437\u043e\u0432\u043e\u0433\u043e. \u0414\u043b\u044f \u0438\u0441\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u044d\u0442\u043e\u0439 \u0432\u0441\u0435\u043b\u0435\u043d\u0441\u043a\u043e\u0439 \u043d\u0435\u0441\u043f\u0440\u0430\u0432\u0435\u0434\u043b\u0438\u0432\u043e\u0441\u0442\u0438 \u044f \u0440\u0435\u0448\u0438\u043b \u043d\u0430\u043f\u0438\u0441\u0430\u0442\u044c \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0410\u043d\u0441\u0438\u0431\u043b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-87084","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t