block<\/code> et cetera. Plus vous connaissez Ansible, plus vous pourrez nommer de nuances pour une solution \"rus\u00e9e\". Et la solution simple - utiliser une s\u00e9paration naturelle entre pre\/roles\/post - ne soul\u00e8ve pas de nuances.<\/p>\n<\/p>\n
Et, revenons \u00e0 notre 'foo'. O\u00f9 le placer ? Dans pre, post ou roles ? \u00c9videmment, cela d\u00e9pend de savoir si nous avons besoin des r\u00e9sultats du handler pour foo. Si ce n'est pas le cas, alors foo n'a pas besoin d'\u00eatre mis dans ni pre ni post - ces sections ont un sens particulier - ex\u00e9cuter les t\u00e2ches avant et apr\u00e8s le bloc de code principal.<\/p>\n
<\/p>\n
Maintenant, la r\u00e9ponse \u00e0 la question \"r\u00f4le ou t\u00e2che\" se r\u00e9sume \u00e0 ce qui est d\u00e9j\u00e0 dans le play - s'il y a des tasks, alors il faut ajouter dans tasks. S'il y a des roles - il faut cr\u00e9er un r\u00f4le (m\u00eame s'il n'y a qu'une t\u00e2che). Je rappelle que les tasks et roles ne sont pas utilis\u00e9es simultan\u00e9ment.<\/p>\n
<\/p>\n
Comprendre les bases d'Ansible donne des r\u00e9ponses justifi\u00e9es \u00e0 ce qui semble \u00eatre des questions de go\u00fbt.<\/p>\n
<\/p>\n
T\u00e2ches et r\u00f4les (partie deux)<\/h1>\n <\/p>\n
Discutons maintenant de la situation o\u00f9 vous commencez \u00e0 \u00e9crire un playbook. Vous devez faire foo, bar et baz. S'agit-il de trois t\u00e2ches, d'un r\u00f4le ou de trois r\u00f4les ? En r\u00e9sum\u00e9 : \u00e0 quel moment doit-on commencer \u00e0 \u00e9crire des r\u00f4les ? Quel est l'int\u00e9r\u00eat d'\u00e9crire des r\u00f4les quand on peut \u00e9crire des t\u00e2ches ?\u2026 Qu'est-ce qu'un r\u00f4le ?<\/p>\n
<\/p>\n
Une des erreurs les plus graves (j'en ai d\u00e9j\u00e0 parl\u00e9) est de consid\u00e9rer qu'un r\u00f4le est comme une fonction dans la biblioth\u00e8que d'un programme. \u00c0 quoi ressemble une description g\u00e9n\u00e9ralis\u00e9e d'une fonction ? Elle prend des arguments en entr\u00e9e, interagit avec des effets secondaires, produit des effets collat\u00e9raux et retourne une valeur.<\/p>\n
<\/p>\n
Maintenant, attention. Que peut-on faire dans un r\u00f4le ? Appeler des effets secondaires - pas de probl\u00e8me, c'est l'essence m\u00eame d'Ansible - cr\u00e9er des effets secondaires. Avoir des causes secondaires ? \u00c9videmment. Mais pour \"passer une valeur et la retourner\" - ici, c'est non. Tout d'abord, vous ne pouvez pas passer de valeur \u00e0 un r\u00f4le. Vous pouvez d\u00e9finir une variable globale dont la dur\u00e9e de vie est \u00e9quivalente au play dans la section vars pour le r\u00f4le. Vous pouvez d\u00e9finir une variable globale dont la dur\u00e9e de vie est dans le play \u00e0 l'int\u00e9rieur du r\u00f4le. Ou m\u00eame dont la dur\u00e9e de vie est celle des playbooks (set_fact<\/code>\/register<\/code>). Mais vous ne pouvez pas avoir de \"variables locales\". Vous ne pouvez pas \"recevoir une valeur\" et \"la retourner\".<\/p>\n<\/p>\n
Ce qui en d\u00e9coule est essentiel : il est impossible d'\u00e9crire quelque chose sur Ansible sans provoquer d'effets secondaires. La modification de variables globales est toujours un effet secondaire pour une fonction. Dans Rust, par exemple, la modification d'une variable globale \u2014 c'est unsafe<\/code>. Dans Ansible, la seule m\u00e9thode d'influencer les valeurs d'un r\u00f4le. Faites attention aux mots utilis\u00e9s : ne pas dire \"passer une valeur au r\u00f4le\", mais \"modifier les valeurs que le r\u00f4le utilise\". Il n'y a pas d'isolement entre les r\u00f4les. Il n'y a pas d'isolement entre les t\u00e2ches et les r\u00f4les.<\/p>\n<\/p>\n
Total : un r\u00f4le n'est pas une fonction<\/strong>.<\/p>\n<\/p>\n
Quels sont les avantages des r\u00f4les ? Tout d'abord, les r\u00f4les ont des valeurs par d\u00e9faut (\/default\/main.yaml<\/code>), deuxi\u00e8mement, les r\u00f4les ont des r\u00e9pertoires suppl\u00e9mentaires pour stocker des fichiers.<\/p>\n<\/p>\n
Pourquoi les valeurs par d\u00e9faut sont-elles bonnes ? Parce que dans la pyramide de Maslow, qui pr\u00e9sente une hi\u00e9rarchie assez complexe des variables dans Ansible, les valeurs par d\u00e9faut des r\u00f4les sont les moins prioritaires (\u00e0 l'exception des param\u00e8tres de ligne de commande d'Ansible). Cela signifie que si vous devez fournir des valeurs par d\u00e9faut sans vous inqui\u00e9ter qu'elles ne remplacent des valeurs provenant d'inventaires ou de variables de groupe, alors les valeurs par d\u00e9faut des r\u00f4les sont le seul endroit appropri\u00e9 pour vous. (Je mens un peu - il y a aussi |d(your_default_here)<\/code>, mais si nous parlons d'emplacements fixes, alors ce ne sont que les valeurs par d\u00e9faut des r\u00f4les).<\/p>\n<\/p>\n
Qu'est-ce qui est encore bon dans les r\u00f4les ? Ils ont leurs propres r\u00e9pertoires. Ce sont des r\u00e9pertoires pour les variables, tant permanentes (c\u2019est-\u00e0-dire calcul\u00e9es pour le r\u00f4le) que dynamiques (il existe un motif ou un anti-motif appel\u00e9 include_vars<\/code> avec {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>.). Ce sont des r\u00e9pertoires pour files\/<\/code>, templates\/<\/code>. De plus, cela permet d'avoir des modules et des plugins propres aux r\u00f4les (library\/<\/code>). Mais, par rapport aux t\u00e2ches dans le playbook (qui peut aussi avoir tout \u00e7a), l'avantage ici est simplement que les fichiers ne sont pas tous m\u00e9lang\u00e9s en un seul tas, mais en plusieurs tas distincts.<\/p>\n<\/p>\n
Un autre d\u00e9tail : il est possible d'essayer de cr\u00e9er des r\u00f4les qui seront disponibles pour la r\u00e9utilisation (via galaxy). Apr\u00e8s l'apparition des collections, la distribution des r\u00f4les peut \u00eatre consid\u00e9r\u00e9e comme presque oubli\u00e9e.<\/p>\n
<\/p>\n
Ainsi, les r\u00f4les poss\u00e8dent deux caract\u00e9ristiques importantes : ils ont des valeurs par d\u00e9faut (une caract\u00e9ristique unique) et ils permettent de structurer le code.<\/p>\n
<\/p>\n
Pour revenir \u00e0 la question initiale : quand utiliser des t\u00e2ches et quand des r\u00f4les ? Les t\u00e2ches dans le playbook sont le plus souvent utilis\u00e9es soit comme \"colles\" avant\/apr\u00e8s les r\u00f4les, soit comme \u00e9l\u00e9ments distincts (dans ce cas, il ne devrait pas y avoir de r\u00f4les dans le code). Un m\u00e9lange de t\u00e2ches normales avec des r\u00f4les est d\u00e9finitivement d\u00e9sordonn\u00e9. Il faut s'en tenir \u00e0 un style pr\u00e9cis \u2014 soit des t\u00e2ches, soit des r\u00f4les. Les r\u00f4les offrent une s\u00e9paration des entit\u00e9s et des valeurs par d\u00e9faut, tandis que les t\u00e2ches permettent de lire le code plus rapidement. En g\u00e9n\u00e9ral, on place dans les r\u00f4les un code plus \"stationnaire\" (important et complexe), et dans le style des t\u00e2ches, on \u00e9crit des scripts auxiliaires.<\/p>\n
<\/p>\n
Il est possible de faire un import_role comme t\u00e2che, mais si vous \u00e9crivez cela, pr\u00e9parez-vous \u00e0 expliquer pourquoi vous voulez le faire pour votre propre sens esth\u00e9tique.<\/p>\n
<\/p>\n
Un lecteur pointilleux peut dire que les r\u00f4les peuvent importer des r\u00f4les, que les r\u00f4les peuvent avoir des d\u00e9pendances via galaxy.yml, et il y a aussi le terrible et horrible. include_role<\/code> \u2014 je rappelle que nous am\u00e9liorons nos comp\u00e9tences en Ansible de base, et non en gymnastique rythmique.<\/p>\n<\/p>\n
Gestionnaires et t\u00e2ches<\/h1>\n <\/p>\n
Discutons d'une autre chose \u00e9vidente : les gestionnaires. Savoir les utiliser correctement est presque un art. Quelle est la diff\u00e9rence entre un gestionnaire et une t\u00e2che ?<\/p>\n
<\/p>\n
Puisque nous nous rappelons les bases, voici un exemple :<\/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
Les handlers des r\u00f4les se trouvent dans rolename\/handlers\/main.yaml. Les handlers sont partag\u00e9s entre tous les participants du play : les pre\/post_tasks peuvent appeler les handlers du r\u00f4le, et le r\u00f4le peut appeler les handlers du play. Cependant, les appels de handlers \"cross-r\u00f4les\" provoquent beaucoup plus de confusion que la r\u00e9p\u00e9tition d'un handler triviale. (Un autre \u00e9l\u00e9ment des bonnes pratiques \u2014 essayer de ne pas r\u00e9p\u00e9ter les noms des handlers).<\/p>\n
<\/p>\n
La principale diff\u00e9rence est que la t\u00e2che s'ex\u00e9cute (idempotemment) toujours (plus ou moins les balises et when<\/code>), tandis que le gestionnaire s'ex\u00e9cute en fonction du changement d'\u00e9tat (notify ne se d\u00e9clenche que s'il y a eu un changement). Qu'est-ce que cela implique ? Par exemple, lors de l'ex\u00e9cution r\u00e9p\u00e9t\u00e9e, si aucune modification n'a eu lieu, il n'y aura pas de gestionnaire. Et pourquoi pourrait-il \u00eatre n\u00e9cessaire d'ex\u00e9cuter un gestionnaire alors qu'il n'y a pas eu de changement dans la t\u00e2che g\u00e9n\u00e9ratrice ? Par exemple, parce que quelque chose s'est cass\u00e9 et qu'il y a eu un changement, mais l'ex\u00e9cution n'est pas parvenue jusqu'au gestionnaire. Par exemple, parce que le r\u00e9seau \u00e9tait temporairement hors service. La configuration a chang\u00e9, le service n'a pas \u00e9t\u00e9 red\u00e9marr\u00e9. Lors de la prochaine ex\u00e9cution, la configuration ne change plus, et le service reste avec l'ancienne version de la configuration.<\/p>\n<\/p>\n
La situation avec le config est insoluble (en fait, il est possible d'inventer soi-m\u00eame un protocole de red\u00e9marrage sp\u00e9cial avec des drapeaux de fichiers, etc., mais cela ne rel\u00e8ve plus du 'basic ansible' sous aucune forme). En revanche, il existe une autre histoire fr\u00e9quente : nous avons install\u00e9 l'application, l'avons enregistr\u00e9e. .service<\/code>- fichier, et maintenant nous voulons faire son daemon_reload<\/code> et state=started<\/code>. Et un endroit naturel pour cela semble \u00eatre un gestionnaire. Mais si nous en faisons une t\u00e2che au bas de la liste des t\u00e2ches ou un r\u00f4le, elle sera ex\u00e9cut\u00e9e de mani\u00e8re idempotente \u00e0 chaque fois. M\u00eame si le playbook \u00e9choue en cours de route. Cela ne r\u00e9sout absolument pas le probl\u00e8me du red\u00e9marrage (il n'est pas possible de faire une t\u00e2che avec l'attribut restarted, car cela perd l'idempotence), mais il est certainement utile de faire state=started, la stabilit\u00e9 g\u00e9n\u00e9rale des playbooks augmente car le nombre de d\u00e9pendances et d'\u00e9tats dynamiques diminue.<\/p>\n<\/p>\n
Une autre caract\u00e9ristique positive du handler est qu'il ne surcharge pas la sortie. Pas de modifications \u2014 pas de skipped ou ok suppl\u00e9mentaires dans la sortie \u2014 plus facile \u00e0 lire. Cela constitue aussi une caract\u00e9ristique n\u00e9gative : si vous trouvez une faute de frappe dans une t\u00e2che ex\u00e9cut\u00e9e lin\u00e9airement lors du premier passage, les handlers ne seront ex\u00e9cut\u00e9s que lors d'un changement, c'est-\u00e0-dire dans certaines conditions \u2014 tr\u00e8s rarement. Par exemple, la premi\u00e8re fois en cinq ans. Et, bien s\u00fbr, il y aura une faute de frappe dans le nom et tout va casser. La seconde fois, ils ne peuvent pas \u00eatre lanc\u00e9s \u2014 pas de changement.<\/p>\n
<\/p>\n
Il faut parler s\u00e9par\u00e9ment de l'accessibilit\u00e9 des variables. Par exemple, si vous notifiez pour une t\u00e2che avec une boucle, que se passera-t-il dans les variables ? On peut le deviner par voie analytique, mais ce n'est pas toujours trivial, surtout si les variables proviennent de diff\u00e9rents endroits.<\/p>\n
<\/p>\n
Ainsi, les handlers sont beaucoup moins utiles et bien plus probl\u00e9matiques qu'il n'y para\u00eet. Si quelque chose peut \u00eatre \u00e9crit de mani\u00e8re \u00e9l\u00e9gante (sans contorsions) sans handlers, il vaut mieux le faire sans eux. Si cela ne fonctionne pas de mani\u00e8re esth\u00e9tique, il est pr\u00e9f\u00e9rable d'en utiliser.<\/p>\n
<\/p>\n
Un lecteur perspicace remarque \u00e0 juste titre que nous n'avons pas discut\u00e9 \u00e9couter<\/code>, que le handler peut appeler notify pour un autre handler, que le handler peut inclure import_tasks (qui peut faire include_role avec with_items), que le syst\u00e8me de handlers dans Ansible est Turing-complet, que les handlers d'included_role se croisent de mani\u00e8re curieuse avec les handlers de play, etc. \u2014 tout cela ne repr\u00e9sente clairement pas les \"fondamentaux\").<\/p>\n<\/p>\n
Bien qu'il y ait un certain WTF qui est en r\u00e9alit\u00e9 une fonctionnalit\u00e9, et dont il faut se souvenir. Si vous avez une t\u00e2che qui s'ex\u00e9cute avec delegate_to<\/code> et qu'elle a un notify, alors le gestionnaire correspondant s'ex\u00e9cute sans delegate_to<\/code>, c'est-\u00e0-dire sur l'h\u00f4te auquel le play est assign\u00e9. (Bien que le gestionnaire puisse, bien s\u00fbr, avoir delegate_to<\/code> aussi).<\/p>\n<\/p>\n
Je voudrais \u00e9galement dire quelques mots sur les r\u00f4les r\u00e9utilisables. Avant l'apparition des collections, l'id\u00e9e \u00e9tait de cr\u00e9er des r\u00f4les universels qui peuvent \u00eatre ansible-galaxy install<\/code> et je suis parti. Cela fonctionne sur tous les syst\u00e8mes d'exploitation dans toutes les variantes et toutes les situations. Mon avis est le suivant : cela ne fonctionne pas. Tout r\u00f4le tr\u00e8s g\u00e9n\u00e9ral avec un support pour 100500 cas est condamn\u00e9 aux ab\u00eemes des bugs sp\u00e9cifiques. On peut les juguler par des tests massifs, mais comme pour tout test, soit vous avez le produit cart\u00e9sien des valeurs d'entr\u00e9e et une fonction totale, soit vous avez \"des sc\u00e9narios couverts\". \u00c0 mon avis, il est bien mieux d'avoir un r\u00f4le lin\u00e9aire (complexit\u00e9 cyclomatique 1). include_vars<\/code>, avec le support de 100500 cas, est vou\u00e9e aux ab\u00eemes des bugs corner case. On peut les colmater par des tests massifs, mais comme pour tout test, soit vous avez le produit cart\u00e9sien des valeurs d'entr\u00e9e et une fonction totale, soit vous avez \"couverts des sc\u00e9narios particuliers\". Mon avis \u2014 il vaut mieux que le r\u00f4le soit lin\u00e9aire (complexit\u00e9 cyclomatique 1).<\/p>\n<\/p>\n
Moins il y a de if (expr\u00e8s ou d\u00e9claratifs \u2014 sous forme de when<\/code> sur un ensemble de variables), mieux c'est pour le r\u00f4le. Il arrive parfois qu'il faille faire des embranchements, mais, je le r\u00e9p\u00e8te, moins il y en a, mieux c'est. Donc, il semble qu'un bon r\u00f4le avec galaxy (\u00e7a fonctionne, apr\u00e8s tout !) avec une tonne include_vars<\/code> puisse \u00eatre moins pr\u00e9f\u00e9r\u00e9 qu'un r\u00f4le \"propre\" de cinq t\u00e2ches. Le moment o\u00f9 un r\u00f4le avec galaxy est meilleur \u2014 c'est quand vous commencez \u00e0 \u00e9crire quelque chose. Le moment o\u00f9 cela devient pire \u2014 c'est quand quelque chose se casse, et vous soup\u00e7onnez que cela vient du \"r\u00f4le avec galaxy\". Vous l'ouvrez, et l\u00e0, vous avez cinq inclusions, huit listes de t\u00e2ches et une pile when<\/code> ), moins cela peut \u00eatre pr\u00e9f\u00e9rable qu'un r\u00f4le \"propre\" compos\u00e9 de cinq t\u00e2ches. Le moment o\u00f9 un r\u00f4le avec galaxy est meilleur \u2014 c'est quand vous commencez \u00e0 \u00e9crire quelque chose. Le moment o\u00f9 il devient pire \u2014 c'est quand quelque chose casse, et vous soup\u00e7onnez que c'est \u00e0 cause du \"r\u00f4le avec galaxy\". Vous l'ouvrez, et l\u00e0, il y a cinq inclusions, huit listes de t\u00e2ches et une pile when<\/code>\u2026 Et vous devez comprendre cela. Au lieu de 5 t\u00e2ches dans une liste lin\u00e9aire, o\u00f9 il n'y a m\u00eame pas de quoi casser.<\/p>\n<\/p>\n
Un peu sur l'inventaire, les variables de groupe, le plugin host_group_vars, les hostvars. Comment attacher une \u00e9pine de Gordius \u00e0 partir d'une spaghetti. Port\u00e9e et priorit\u00e9 des variables, mod\u00e8le de m\u00e9moire d'Ansible. \"Alors o\u00f9 stocker le nom d'utilisateur pour la base de donn\u00e9es ?\".<\/h1>\n <\/p>\n
\nUn peu sur l'inventaire, les variables de groupe, le plugin host_group_vars, les hostvars. Comment relier les spaghetti en un n\u0153ud gordien. \u00c9tendue et priorit\u00e9 des variables, mod\u00e8le de m\u00e9moire d'Ansible. \"Alors o\u00f9 stocker le nom d'utilisateur pour la base de donn\u00e9es ?\".<\/li>\n \u2014 nosql notype nosense plastique mall\u00e9able. Il est partout, m\u00eame l\u00e0 o\u00f9 vous ne l'attendez pas. Un peu sur<\/code> !!unsafe et un yaml savoureux.<\/code> Je fais beaucoup de revues de code pour d'autres sur Ansible et j'\u00e9cris beaucoup moi-m\u00eame.<\/li>\n<\/ul>\nSource : 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