block<\/code> y as\u00ed sucesivamente. Cuanto mejor conozcas Ansible, m\u00e1s matices podr\u00e1s se\u00f1alar para una soluci\u00f3n \"inteligente\". Y una soluci\u00f3n simple \u2014 usar una separaci\u00f3n natural entre pre\/roles\/post \u2014 no genera complicaciones.<\/p>\n<\/p>\n
Y, volviendo a nuestro 'foo'. \u00bfD\u00f3nde debe colocarse? \u00bfEn pre, post o roles? Obviamente, depende de si necesitamos los resultados del trabajo del manejador para foo. Si no los hay, entonces foo no necesita estar ni en pre ni en post \u2014 estas secciones tienen un significado especial: ejecutar tareas antes y despu\u00e9s del bloque de c\u00f3digo principal.<\/p>\n
<\/p>\n
Ahora la respuesta a la pregunta \"\u00bfrol o tarea?\" se reduce a lo que ya hay en el play \u2014 si hay tareas, entonces hay que a\u00f1adirlas a las tareas. Si hay roles, hay que hacer un rol (aunque sea de una sola tarea). Recuerdo que no se utilizan tareas y roles simult\u00e1neamente.<\/p>\n
<\/p>\n
Entender las bases de Ansible proporciona respuestas fundamentadas a lo que podr\u00edan parecer preguntas de gusto personal.<\/p>\n
<\/p>\n
Tareas y roles (parte dos)<\/h1>\n <\/p>\n
Ahora discutamos la situaci\u00f3n en la que apenas est\u00e1s comenzando a escribir un playbook. Necesitas hacer foo, bar y baz. \u00bfSon estas tres tareas, un rol o tres roles? Resumiendo la pregunta: \u00bfen qu\u00e9 momento deber\u00edamos comenzar a escribir roles? \u00bfCu\u00e1l es el sentido de escribir roles cuando podemos escribir tareas?\u2026 \u00bfQu\u00e9 es un rol?<\/p>\n
<\/p>\n
Uno de los errores m\u00e1s groseros (ya he hablado de esto) es pensar que un rol es como una funci\u00f3n en una biblioteca de programaci\u00f3n. \u00bfC\u00f3mo se ve una descripci\u00f3n general de una funci\u00f3n? Toma argumentos de entrada, interact\u00faa con efectos colaterales y devuelve un valor.<\/p>\n
<\/p>\n
Ahora, atenci\u00f3n. \u00bfQu\u00e9 de esto se puede hacer en un rol? Invocar efectos secundarios \u2014 siempre puedes, esa es la esencia de Ansible: provocar efectos secundarios. \u00bfTener causas secundarias? Elemental. Pero con \"transferir un valor y devolverlo\" \u2014 aqu\u00ed es donde no. Primero, no puedes pasar un valor a un rol. Puedes establecer una variable global con una duraci\u00f3n igual al play en la secci\u00f3n vars para el rol. Puedes establecer una variable global con una duraci\u00f3n en el play dentro del rol. O incluso con una duraci\u00f3n en el libro de jugadas (set_fact<\/code>\/register<\/code>). Pero no puedes tener \"variables locales\". No puedes \"recibir un valor\" y \"devolverlo\".<\/p>\n<\/p>\n
De esto se deduce lo principal: no se puede escribir algo en Ansible sin provocar efectos colaterales. Cambiar variables globales es siempre un efecto colateral para una funci\u00f3n. En Rust, por ejemplo, cambiar una variable global es unsafe<\/code>. En Ansible, existe un \u00fanico m\u00e9todo para influir en los valores de un rol. Tenga en cuenta las palabras utilizadas: no se dice \"pasar un valor al rol\", sino \"cambiar los valores que utiliza el rol\". No hay aislamiento entre los roles. No hay aislamiento entre las tareas y los roles.<\/p>\n<\/p>\n
Total: un rol no es una funci\u00f3n<\/strong>.<\/p>\n<\/p>\n
\u00bfQu\u00e9 hay de bueno en los roles? En primer lugar, los roles tienen valores predeterminados (\/default\/main.yaml<\/code>), y en segundo lugar, los roles cuentan con cat\u00e1logos adicionales para almacenar archivos.<\/p>\n<\/p>\n
\u00bfCu\u00e1l es la ventaja de los valores predeterminados? En la tabla de prioridades de variables de la pir\u00e1mide de Maslow bastante retorcida de Ansible, los valores predeterminados de los roles son los menos prioritarios (excepto por los par\u00e1metros de la l\u00ednea de comandos de Ansible). Esto significa que si necesitas proporcionar valores predeterminados sin preocuparte de que interrumpan los valores de inventario o variables grupales, los valores predeterminados del rol son el lugar correcto para ti. (Estoy exagerando un poco, tambi\u00e9n existe |d(your_default_here)<\/code>, pero hablando de lugares estacionarios, solo son los valores predeterminados del rol).<\/p>\n<\/p>\n
\u00bfQu\u00e9 m\u00e1s es bueno en los roles? Que tienen sus propios directorios. Son directorios para variables, tanto permanentes (es decir, calculadas para el rol), como din\u00e1micas (hay un patr\u00f3n o antipatrones en juego \u2014 include_vars<\/code> junto con {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml<\/code>). Son directorios para files\/<\/code>, templates\/. Adem\u00e1s, permiten a los roles tener sus propios m\u00f3dulos y complementos (<\/code>library\/). Sin embargo, en comparaci\u00f3n con las tareas de los playbooks (cuyas caracter\u00edsticas tambi\u00e9n pueden incluir todo esto), la ventaja aqu\u00ed radica en que los archivos no est\u00e1n en un solo lugar, sino en varios grupos separados.<\/code>). Sin embargo, comparado con las tareas en el playbook (que tambi\u00e9n puede tener todo esto), la ventaja aqu\u00ed radica \u00fanicamente en que los archivos no est\u00e1n todos amontonados, sino en varias pilas separadas.<\/p>\n<\/p>\n
As\u00ed, los roles poseen dos caracter\u00edsticas importantes: tienen valores predeterminados (una caracter\u00edstica \u00fanica) y permiten estructurar el c\u00f3digo.<\/p>\n
<\/p>\n
Volviendo a la pregunta inicial: \u00bfcu\u00e1ndo hacer tareas y cu\u00e1ndo roles? Las tareas en el playbook se utilizan con mayor frecuencia como \"pegamento\" antes\/despu\u00e9s de los roles, o como elementos constructivos independientes (en cuyo caso no deber\u00edan haber roles en el c\u00f3digo). Un mont\u00f3n de tareas normales mezcladas con roles es sin duda desordenado. Debe seguirse un estilo concreto: o tareas o roles. Los roles ofrecen separaci\u00f3n de entidades y valores predeterminados, las tareas permiten leer el c\u00f3digo m\u00e1s r\u00e1pidamente. Generalmente, en los roles se lleva el c\u00f3digo m\u00e1s \"estacionario\" (importante y complejo), mientras que en el estilo de tareas se escriben scripts auxiliares.<\/p>\n
<\/p>\n
Volviendo a la pregunta original: \u00bfcu\u00e1ndo usar tareas y cu\u00e1ndo usar roles? Las tareas en el playbook se utilizan m\u00e1s com\u00fanmente como \"pegamento\" antes\/despu\u00e9s de los roles, o como un elemento constructivo independiente (en cuyo caso no deber\u00eda haber roles en el c\u00f3digo). Una mezcla desordenada de tareas normales con roles es una clara falta de orden. Se debe mantener un estilo concreto: ya sea tareas o roles. Los roles proporcionan separaci\u00f3n de entidades y valores predeterminados, mientras que las tareas permiten leer el c\u00f3digo m\u00e1s r\u00e1pidamente. Normalmente, el c\u00f3digo m\u00e1s \"est\u00e1tico\" (importante y complejo) se coloca en roles, mientras que las tareas se utilizan para escribir scripts auxiliares.<\/p>\n
<\/p>\n
Existe la posibilidad de hacer un import_role como tarea, pero si escribes esto, prep\u00e1rate para explicar por qu\u00e9 lo deseas hacer.<\/p>\n
<\/p>\n
Un lector perspicaz podr\u00eda decir que los roles pueden importar roles, que los roles pueden tener dependencias a trav\u00e9s de galaxy.yml, y adem\u00e1s existe algo horrible y aterrador include_role<\/code> \u2014 les recuerdo, estamos mejorando nuestras habilidades en Ansible b\u00e1sico, no en gimnasia art\u00edstica.<\/p>\n<\/p>\n
Manejadores y tareas<\/h1>\n <\/p>\n
Hablemos de otra cosa obvia: los manejadores. Saber usarlos correctamente es casi un arte. \u00bfCu\u00e1l es la diferencia entre un manejador y una tarea?<\/p>\n
<\/p>\n
Dado que estamos recordando lo b\u00e1sico, aqu\u00ed hay un ejemplo:<\/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
En los roles, los handlers se encuentran en rolename\/handlers\/main.yaml. Los handlers se comparten entre todos los participantes en el play: pre\/post_tasks pueden invocar los handlers del rol, y el rol puede invocar handlers desde el play. Sin embargo, las llamadas a los handlers \"cross-role\" generan mucha m\u00e1s confusi\u00f3n que la repetici\u00f3n de un handler trivial. (Otro elemento de las mejores pr\u00e1cticas es tratar de no repetir los nombres de los handlers).<\/p>\n
<\/p>\n
La diferencia principal es que una tarea se ejecuta (idempotente) siempre (m\u00e1s\/menos etiquetas y when<\/code>), mientras que un manejador se ejecuta por cambio de estado (notify se activa solo si hubo un cambio). \u00bfQu\u00e9 implica esto? Por ejemplo, que al volver a ejecutar, si no hubo cambios, entonces no habr\u00e1 manejador. \u00bfY por qu\u00e9 puede ser que necesitemos ejecutar un manejador cuando no hubo cambios en la tarea que lo gener\u00f3? Por ejemplo, porque algo se rompi\u00f3 y hubo un cambio, pero la ejecuci\u00f3n no lleg\u00f3 al manejador. Por ejemplo, porque la red estuvo ca\u00edda temporalmente. La configuraci\u00f3n cambi\u00f3, el servicio no se reinici\u00f3. En la siguiente ejecuci\u00f3n, la configuraci\u00f3n ya no cambia y el servicio sigue con la versi\u00f3n anterior de la configuraci\u00f3n.<\/p>\n<\/p>\n
La situaci\u00f3n con la configuraci\u00f3n no es solucionable (m\u00e1s bien, uno mismo puede inventar un protocolo especial de reinicio con banderas de archivo, etc., pero esto ya no es 'ansible b\u00e1sico' en ninguna forma). Sin embargo, hay otra historia com\u00fan: hemos instalado la aplicaci\u00f3n, la hemos registrado. .service<\/code>-archivo, y ahora queremos daemon_reload<\/code> y state=started<\/code>. Y el lugar natural para esto parece ser un handler. Pero si lo hacemos no un handler, sino una tarea al final de la lista de tareas o de un rol, se ejecutar\u00e1 idempotentemente cada vez. Incluso si el playbook falla a la mitad. Esto no resuelve absolutamente el problema de restarted (no se puede hacer una tarea con el atributo restarted, ya que se pierde la idempotencia), pero definitivamente vale la pena hacerlo state=started, ya que la estabilidad general de los playbooks aumenta, a medida que se reduce la cantidad de conexiones y estado din\u00e1mico.<\/p>\n<\/p>\n
Otra propiedad positiva del handler es que no ensucia la salida. No hubo cambios, no hay 'skipped' o 'ok' innecesarios en la salida, lo que facilita la lectura. Este tambi\u00e9n es un aspecto negativo: si usted encuentra un error tipogr\u00e1fico en una tarea ejecutada linealmente en la primera ejecuci\u00f3n, los handlers solo se ejecutar\u00e1n si hubo cambios, es decir, bajo ciertas condiciones, lo que ocurre con muy poca frecuencia. Por ejemplo, la primera vez en cinco a\u00f1os. Y, por supuesto, habr\u00e1 un error tipogr\u00e1fico en el nombre y todo se romper\u00e1. Y no se podr\u00e1n invocar de nuevo, ya que no hubo cambios.<\/p>\n
<\/p>\n
Es necesario hablar por separado sobre la disponibilidad de las variables. Por ejemplo, si notificas para una tarea con un bucle, \u00bfqu\u00e9 habr\u00e1 en las variables? Se puede deducir de manera anal\u00edtica, pero no siempre es trivial, especialmente si las variables provienen de diferentes lugares.<\/p>\n
<\/p>\n
As\u00ed que los handlers son mucho menos \u00fatiles y mucho m\u00e1s problem\u00e1ticos de lo que parece. Si se puede escribir algo bien (sin trucos) sin handlers, es mejor hacerlo sin ellos. Si no se puede hacer de forma bonita, es mejor hacerlo con ellos.<\/p>\n
<\/p>\n
Un lector perspicaz se\u00f1ala correctamente que no hemos discutido listen<\/code>, que un handler puede llamar a notify para otro handler, que un handler puede incluir import_tasks (que puede hacer include_role con with_items), que el sistema de handlers en Ansible es Turing completo, que los handlers de include_role se cruzan de manera muy curiosa con los handlers del play, etc. \u2013 todo esto claramente no son \"fundamentos\".<\/p>\n<\/p>\n
Aunque hay un cierto WTF que en realidad es una caracter\u00edstica y que debe recordarse. Si una tarea se ejecuta con delegate_to<\/code> y tiene notify, entonces el handler correspondiente se ejecuta sin delegate_to<\/code>, es decir, en el host al que se asign\u00f3 el play. (Aunque el handler, por supuesto, puede tener delegate_to<\/code> tambi\u00e9n).<\/p>\n<\/p>\n
Quiero decir unas palabras sobre roles reutilizables. Antes de la aparici\u00f3n de las colecciones, hab\u00eda la idea de que se pod\u00edan hacer roles universales, que se pod\u00edan ansible-galaxy install<\/code> y se fue. Funciona en todos los sistemas operativos en todas las variantes en todas las situaciones. As\u00ed que, mi opini\u00f3n es: no funciona. Cualquier rol con soporte para 100500 casos est\u00e1 condenado a las profundidades de errores corner case. Se pueden solucionar con pruebas masivas, pero como con cualquier prueba, o tienes el producto cartesiano de las entradas y una funci\u00f3n total, o tienes \"cobiertos escenarios individuales\". Mi opini\u00f3n es que es mucho mejor si el rol es lineal (complejidad ciclom\u00e1tica 1). include_vars<\/code>, el soporte de 100500 casos est\u00e1 condenado a las profundidades de errores corner case. Se pueden tapar con pruebas masivas, pero como con cualquier prueba, o tienes el producto cartesiano de los valores de entrada y una funci\u00f3n total, o tienes \"cobiertos escenarios individuales\". Mi opini\u00f3n es que es mejor cuando el rol es lineal (complejidad ciclom\u00e1tica 1).<\/p>\n<\/p>\n
Cuantos menos ifs (expl\u00edcitos o declarativos \u2013 en forma de when<\/code> por conjunto de variables), mejor es el rol. A veces es necesario hacer bifurcaciones, pero, repito, cuanto menos haya, mejor. As\u00ed que parece que un buen rol con galaxy (\u00a1funciona!) con un mont\u00f3n include_vars<\/code> puede ser menos preferible que \"su\" rol de cinco tareas. El momento en que el rol con galaxy es mejor \u2014 es cuando comienzas a escribir algo. El momento en que se vuelve peor \u2014 es cuando algo se rompe, y sospechas que es por \"el rol con galaxy\". Lo abres, y all\u00ed hay cinco inclusiones, ocho listas de tareas y una pila when<\/code> puede ser menos preferible que \"su\" propio rol de cinco tareas. El momento en que un rol con galaxy es mejor es cuando comienzas a escribir algo. El momento en que se vuelve peor es cuando algo se rompe, y tienes la sospecha de que es por \"el rol con galaxy\". Lo abres y all\u00ed hay cinco inclusiones, ocho listas de tareas y un mont\u00f3n when<\/code>\u2018... Y hay que resolver eso. En lugar de 5 tareas en una lista lineal, donde tampoco hay nada que romper.<\/p>\n<\/p>\n
Un poco sobre inventarios, variables de grupo, plugin host_group_vars, hostvars. C\u00f3mo atar un nudo gordiano de espagueti. Alcance y precedencia de variables, modelo de memoria de Ansible. \"\u00bfD\u00f3nde se debe guardar el nombre de usuario para la base de datos?\".<\/h1>\n <\/p>\n
\nUn poco sobre inventario, variables grupales, plugin host_group_vars, hostvars. C\u00f3mo conectar los espaguetis en un nudo gordiano. Alcance y precedencia de las variables, modelo de memoria de Ansible. \"\u00bfD\u00f3nde deber\u00eda guardar el nombre de usuario para la base de datos?\".<\/li>\n \u2014 nosql notype nosense plastilina blanda. Est\u00e1 en todas partes, incluso donde no lo esperas. Un poco sobre<\/code> !!unsafe y un delicioso yaml.<\/code> \u00bfC\u00f3mo ayudan los gigantes de la tecnolog\u00eda a la educaci\u00f3n? Parte 2: Microsoft<\/li>\n<\/ul>\nFuente: 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