{"id":35513,"date":"2019-10-31T22:04:46","date_gmt":"2019-10-31T19:04:46","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira\/"},"modified":"2019-10-31T22:04:46","modified_gmt":"2019-10-31T19:04:46","slug":"ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ansible-obnovleniya-v-klyuchevyh-resheniyah-dlya-avtomatizatsii-vashego-mira","title":{"rendered":"Ansible: actualizaciones en soluciones clave para automatizar tu mundo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La comunidad de Ansible siempre sorprende con nuevo contenido: complementos y m\u00f3dulos, creando adem\u00e1s mucho nuevo trabajo para quienes est\u00e1n ocupados con el mantenimiento de Ansible, ya que el nuevo c\u00f3digo debe integrarse r\u00e1pidamente en los repositorios. A veces, no se logra cumplir con los plazos y el lanzamiento de algunos productos listos para ser lanzados se pospone hasta la pr\u00f3xima versi\u00f3n oficial de Ansible Engine. Hasta hace poco, el \u00fanico modo para el usuario final de obtener nuevo contenido de Ansible era junto con una nueva versi\u00f3n de Ansible Engine.<\/p>\n

\"Ansible:
\n
\nPara eliminar este inconveniente, la comunidad de Ansible comenz\u00f3 a trabajar en opciones m\u00e1s flexibles para crear y obtener contenido.
\n<\/a><\/noindex><\/p>\n

Red Hat Ansible Engine 2.8: hacia nuevos m\u00e9todos de procesamiento de contenido de Ansible<\/h3>\n

\nEn respuesta a las solicitudes de los usuarios, en Ansible Engine 2.8 se introdujeron cambios relacionados con el procesamiento del contenido, que no forma parte del lanzamiento oficial<\/b>. Estos cambios permitir\u00e1n implementar un nuevo modo de entrega de contenido a los usuarios, que no depender\u00e1 de quienes administran Ansible al gestionar tanto el contenido de Ansible como el c\u00f3digo de la propia plataforma.<\/p>\n

Se espera que en futuras versiones, los Creadores de contenido puedan proporcionar su trabajo en forma de paquetes especiales, llamadas Colecciones, que se podr\u00e1n instalar en el lugar correspondiente para su ejecuci\u00f3n en el nodo principal de Ansible (control node) o en el nodo gestionado (managed node). El creador de la colecci\u00f3n puede especificar directamente en el paquete los detalles de la ejecuci\u00f3n mediante roles y playbooks. Gracias a los mencionados cambios en Ansible Engine, las colecciones se convertir\u00e1n en una de las herramientas que permitir\u00e1n desacoplar el lanzamiento de contenido del lanzamiento de versiones oficiales de Ansible Engine.<\/b>.<\/p>\n

Nueva construcci\u00f3n Become<\/h4>\n

\nLa construcci\u00f3n Become existe desde hace tiempo, pero desde la versi\u00f3n 2.8, la palabra BECOME se utiliza por defecto en Ansible Engine para solicitar la contrase\u00f1a al elevar privilegios (privilegios sudo en sistemas *nix o modo enable en dispositivos de red). En otras palabras, ahora BECOME es la herramienta est\u00e1ndar para la elevaci\u00f3n de privilegios, que ya se encarga de gestionar el sistema objetivo.<\/p>\n

As\u00ed es como se ve un ejemplo de su uso:<\/p>\n

ansible-playbook --become --ask-become-pass site.yml\nBECOME password:\n<\/code><\/pre>\n
\nAdem\u00e1s, en Ansible Engine 2.8 se introdujo el plugin BECOME, que funciona como doas en Linux y como runas en Windows, y permite realizar acciones en nombre de un usuario determinado. Para elevar privilegios en dispositivos de red se utiliza el plugin become enable.<\/p>\n
Buscar el int\u00e9rprete de Python<\/h4>\n
\nEs posible que se haya encontrado con el siguiente error:<\/p>\n
\/usr\/bin\/python: bad interpreter: No such file or directory\n<\/code><\/pre>\n
\nEl hecho es que en versiones anteriores de Ansible Engine se asum\u00eda por defecto que el int\u00e9rprete principal de Python (el que se utiliza por defecto) se encuentra en la carpeta \/usr\/bin\/python. A partir de la versi\u00f3n 2.8, Ansible busca el int\u00e9rprete en cada sistema objetivo, primero verificando la tabla de rutas y nombres de archivos ejecutables del int\u00e9rprete principal de Python en diversas distribuciones, y luego utilizando listas ordenadas de int\u00e9rpretes de respaldo (fallback list), consulte m\u00e1s detalles en Gu\u00eda de migraci\u00f3n a Ansible 2.8<\/a><\/noindex>.<\/p>\n
Los archivos de retry ya no se crean por defecto<\/h4>\n
\n\u00bfHa estado buscando archivos .retry en su disco? Si ha estado utilizando Ansible durante mucho tiempo, es probable que haya muchos, y solo ocupan espacio \u00fatil. A partir de la versi\u00f3n 2.8, Ansible Engine ya no crea estos archivos por defecto (lo que se puede revertir editando el archivo ansible.cfg utilizado por defecto).<\/p>\n
Resumen de Play actualizado<\/h4>\n
\nExtracto de Gu\u00eda de migraci\u00f3n a Ansible 2.8<\/a><\/noindex>:<\/p>\n
El resumen de Play ahora cuenta las tareas (tasks) con estado ignored y rescued, as\u00ed como ok, changed, unreachable, failed y skipped, gracias a dos nuevos contadores estad\u00edsticos en el plugin callback default. Las tareas fallidas que tienen la bandera ignore_errors: yes se cuentan como ignored. Las tareas fallidas que luego fueron manejadas en la secci\u00f3n rescue se cuentan como rescued. Tenga en cuenta que, a diferencia de versiones anteriores de Ansible, las tareas rescued ya no se cuentan como failed.<\/p><\/blockquote>\n
\nY en la tabla de Resumen de Play al final de la ejecuci\u00f3n del playbook, los hosts ahora tienen columnas adicionales skipped, rescued e ignored:<\/p>\n
\"Ansible:<\/p>\n
Nubes y contenedores<\/h4>\n
\nEn la versi\u00f3n 2.8 se han implementado mejoras y adiciones en los m\u00f3dulos de nube y contenedor para trabajar con Amazon Web Services, Microsoft Azure, Google Cloud, Digital Ocean, podman<\/a><\/noindex> y kubevirt<\/a><\/noindex>. Tambi\u00e9n es importante destacar que los archivos TOML ahora se pueden utilizar como fuente de inventario.<\/p>\n
Paramiko<\/h4>\n
\n\u00bfUtiliza Red Hat Ansible Network Automation? Ansible Engine 2.8 ya no incluye paramiko ni depende de \u00e9l. Por defecto, Ansible Engine utiliza ssh. Si necesita paramiko, se puede instalar con el comando pip install paramiko.<\/p>\n
Si necesita soporte para el uso de paramiko en el marco de la suscripci\u00f3n de Red Hat, consulte el art\u00edculo de la base de conocimientos. Paquete de Paramiko faltante despu\u00e9s de nuevas instalaciones de Ansible Engine.<\/a><\/noindex>.<\/p>\n
As\u00ed, la nueva versi\u00f3n de Red Hat Ansible Engine se ha enriquecido con una impresionante lista de mejoras y cambios, que puede consultar con m\u00e1s detalle. aqu\u00ed<\/a><\/noindex>.<\/b><\/p>\n
Red Hat Ansible Tower 3.5: m\u00e1s automatizaci\u00f3n.<\/h3>\n
\nDesde finales de mayo, est\u00e1 disponible la nueva versi\u00f3n de Red Hat Ansible Tower 3.5, que ofrece varias mejoras importantes para la automatizaci\u00f3n, de las cuales hablaremos si a\u00fan no ha tenido la oportunidad de probarlas.<\/p>\n
As\u00ed que, primero lo clave:<\/p>\n