Ansible, potencia y simplicidad.

Simple, bien documentado, sencillo de instalar y de usar. Fácil para escribir automatizaciones, ágil para extender funcionalidades y orientado a la gestión de la configuración son algunas de las características que han impulsado el crecimiento de Ansible en los últimos años.

Desde el advenimiento de la civilización, hemos intentado reemplazar el esfuerzo humano por máquinas con el fin de vencer al tiempo, al espacio y a la fuerza física. Algunas de las primeras automatizaciones que conocemos fueron las trampas para cazar animales que aparecieron en la Edad de piedra, momento en el cual, el cazador-recolector podía dejar que sus “automatizaciones” trabajaran cazando a sus presas mientras se dedicaba a otras tareas de interés como recolectar frutos. Después llegó la clepsidra, el arado, la Wright Flyer y otras muchas “automatizaciones” que permitieron tareas imposibles hasta la fecha, convirtiendo en un hecho la estrecha relación entre automatización y progreso.

Automatizar no sólo tiene que ver con desacoplar el trabajo del tiempo o de la mano de obra humana, también tiene que ver con conseguir sistemas o procesos más robustos y escalables reduciendo su exposición al error humano. En nuestros días, la automatización en IT está estrechamente relacionada con la infraestructura cómo código (IaC) de la que hemos hablado en nuestro post sobre IaC, donde exploramos más a fondo las motivaciones para aumentar nuestro foco en estrategias de automatización para el futuro.

Hoy hablaremos sobre Ansible que ya hace unos años incluimos en nuestro stack tecnológico, pasando por sus orígenes, un breve resumen de su funcionamiento, el gran impacto que tiene tras años de adopción, certificaciones oficiales y algunos hitos del proyecto que han destacado en los últimos tiempos.

¿Preparad@? Empecemos…

Orígenes

Ansible es un proyecto opensource programado en python, que nace en 2012 de la mano de Michael DeHaan (@laserllama) con el propósito de unificar la funcionalidad de varias herramientas de automatización en una sola, que resolviese de forma eficiente la gestión de la configuración, la implementación y la ejecución ad-hoc. Muy pronto atrajo las miradas en el mundo opensource, gracias a su arquitectura basada en módulos, que permite extender funcionalidad fácilmente y su enfoque sin agentes, lo que posibilita lanzar operaciones sobre hosts sin instalar “demonios de control” en ellos, eliminando los consecuentes desafíos asociados, como la gestión del ciclo de vida del software de esos agentes.

Más tarde en 2015, el gigante Red Hat compra Ansible agregándolo a su portfolio de tecnologías Opensource y lejos de considerarlo un proyecto más, lo pone en el centro de su estrategia para los próximos años. No sólo con la creación de Ansible Engine, ofertando Ansible Tower (interfaz gráfico para orquestar automatizaciones) a sus clientes, sino también con la incorporación de roles (forma de organizar y empaquetar automatizaciones en Ansible) para administrar sistemas RHEL (su buque insignia), como parte de la paquetería del sistema operativo desde la versión RHEL 8. Todo ello pone de manifiesto, que Ansible forma parte de la visión para el futuro que tiene Red Hat sobre automatización y tecnología.

Breve resumen de su funcionamiento

El funcionamiento lo podemos resumir con la siguiente infografía.

Desde un nodo de control donde instalaremos Ansible se establece comunicación con los nodos administrados hacia los que enviaremos pequeños programas (llamados módulos), con las operaciones que queremos ejecutar. Las operaciones se ejecutan, los programas se borran de forma automática y el resultado de la ejecución se devuelve al nodo de control. Si lo que administramos son elementos de red (por ejemplo, routers CISCO) existen algunos matices respecto a este comportamiento en los cuales no vamos a entrar en este artículo.

Los módulos son programas que ya están desarrollados (no tenemos que preocuparnos por ese desarrollo por el momento) y que realizan una determinada operación, por ejemplo, copiar un archivo. Mediante la escritura de un archivo YAML declaramos los detalles asociados a esa operación, por ejemplo, nombre de archivo y ruta de destino. Este comportamiento hace que para iniciar tu estrategia de automatización, no necesites conocer las tripas del código, sino que utilizas una abstracción para hacerlo más simple. Los módulos son utilizados globalmente millones de veces al día y al ser un proyecto opensource, cualquiera puede realizar propuestas de mejora o corregir fallos. Es precisamente esta ejecución masiva y esta exposición global lo que les confiere un alto grado de confiabilidad y genera software de alta calidad que sólo mejora con el paso del tiempo, con las propuestas más brillantes en forma de Pull Request.

Una vez tenemos un conjunto de operaciones definidas, podemos empaquetarlas en un rol, que básicamente trabaja en cómo organizar los diferentes recursos que necesitaremos para nuestro objetivo, imaginemos, por ejemplo, instalar docker. La organización en roles, es la forma adecuada para reutilizar código, al igual que para hacer testing con frameworks como molecule, del que ya hemos hablado años atrás.

Gran impacto que tiene tras años de adopción

Uno de los mayores desafíos que enfrenta cualquier equipo TI es encontrar formas de mantenerse al día y reducir la demanda de procesos u operaciones manuales que ocupan gran parte del tiempo. Convertir estas tareas en automatizaciones ayuda a cultivar la innovación, pues los recursos de la empresa se liberan para enfocarse en nuevos productos y crecimiento. En este contexto se hace indispensable el uso de tecnologías que permitan escalar.

Escalar es algo más que tener 10.000 servidores en vez de 100. Escalar también significa aumentar el número de operaciones, resolver problemas más rápido y con mayores garantías mediante el uso de sistemas más probados y seguros. Significa absorber las demandas internas o externas iterando el proceso de automatización en lugar de ejecutar las tareas solicitadas. Significa eliminar cualquier operación repetible por una automatización y crear o utilizar abstracciones.

Podemos referirnos a una abstracción como una forma de reducir el tiempo que empleamos en algo, sin perder control sobre lo que realizamos, eliminando todo lo que no necesita estrictamente intervención humana, haciéndolo simple para poder ampliar nuestra capacidad de ejecutar operaciones. Un script en python es una abstracción. Si es sólido, podemos ejecutarlo confiando en que delegamos el trabajo en el código. El botón de “Compra con 1-click” de amazon también es una abstracción.

La repercusión que tiene el uso de Ansible es algo que podemos intuir de forma clara desde el primer contacto con la tecnología, cuando empezamos a ejecutar nuestras primeras playbooks y a utilizar nuestros primeros roles. Si buscamos algo más detallado, también podemos echar un vistazo a algunos informes como este de Forrester Research, (empresa independiente que ofrece asesoramiento sobre el impacto y el potencial de tecnologías).

También observamos el impacto de Ansible, en los numerosos casos de éxito que el equipo de marketing de Red Hat expone en eventos como #AnsibleFest. Al margen de la función promocional que tienen estos eventos, también nos dejan ver cómo se establecen flujos de trabajo, incluso con empresas que parecen estar en las antípodas tecnológicas del ecosistema linux/opensource. Es el caso de Microsoft, el cual pudimos conocer en uno de los últimos eventos anuales de la mano de Bart Dworak (Gerente de ingeniería software en Microsoft) y para el que Ansible ha desarrollado todo un ecosistema de automatización hacia el que muchas empresas están migrando.

Otro gran hito donde medir el impacto es observando el respaldo de la comunidad. Actualmente el proyecto Ansible es uno de los más populares contando con más de 50k de estrellas y más de 20k forks en github, plataforma que aloja el proyecto y donde también vemos iniciativas como dev-sec, que no tienen tanto que ver con la tecnología Ansible, sino con una aplicación práctica de la misma. El proyecto Dev-sec gira en torno a la seguridad IT, proveyendo una serie de roles Ansible (y también de otras tecnologías) para realizar hardening de sistemas operativos o de tecnologías como nginx o ssh. Encontrar proyectos de esta naturaleza, donde cientos de colaboradores co-crean código con un objetivo común, también pone de manifiesto cómo se extiende hacia nuevos casos de uso que están siendo apoyados por desarrolladores e ingenieros de todo el mundo.

Si queremos analizar datos sobre el impacto de Ansible en nuestro proyecto, podemos recopilar información sobre nuestro caso de uso en particular. Ansible pone a nuestra disposición herramientas como Ansible analytics mediante la cual, una vez implementada una estrategia de automatización, podemos explorar datos y medir el resultado de las ejecuciones en nuestro parque de automatizaciones.

Certificaciones oficiales

Históricamente, Red Hat ha puesto un gran foco en las certificaciones, como parte de su estrategia para cualificar profesionales que operen sus tecnologías y las ha convertido en el estándar de calidad más alto para el sector, en el que muchas otras empresas se han inspirado con el paso de los años. Las certificaciones de Red Hat se obtienen mediante la realización de pruebas prácticas, que no sólo exigen conocer los fundamentos teóricos, sino también ponerlos en práctica en un tiempo limitado, en un sistema que simula un entorno empresarial.

Hablemos más en detalle de las certificaciones de Ansible. El examen EX294 sustituye al antiguo EX300, obteniendo con este la certificación más popular del fabricante, Red Hat Certified Engineer, la cual es considerada la hermana mayor de la certificación RHCSA (también muy popular). Como veíamos al inicio, Red Hat otorga gran importancia a Ansible y que lo incluya como core en su certificación más popular es otra prueba de ello. También tenemos la ya deprecada EX407 Red Hat Certified Specialist in Ansible Automation, que fue la primera certificación que abordaba íntegramente la tecnología y la EX447 Red Hat Certified Specialist in Advanced Automation, que aborda automatización avanzada, buenas prácticas y Ansible tower. Recientemente se han agregado los exámenes EX457, Red Hat Certified Specialist in Ansible Network Automation, donde se aborda un enfoque de automatización para redes y EX374 Red Hat Certified Specialist in Developing Automation with Ansible Automation Platform, la cual pretende dar cobertura a Ansible Automation Platform 2.0.

Los objetivos para superarlas se pueden consultar en los enlaces de cada una de ellas más arriba y son las únicas pistas que ofrece el fabricante. Como guinda del pastel, la obtención de cualquiera de las certificaciones de especialista en Ansible cuenta para la Red Hat Certified Architect, que recordemos consta de RHCSA + RHCE + 5 certificaciones adicionales vigentes, sin duda un desafío que trae consigo horas de práctica y estudio.

Hitos de los últimos tiempos

A medida que Ansible ganó reconocimiento y popularidad en la comunidad, atrajo más y más usuarios y esto conformó nuevos retos. Cuantos más contribuidores enviando código para incluir en el proyecto, más aumentaba el cuello de botella para el equipo core de Ansible, que no tiene capacidad para profundizar tanto como quien desarrolla el código, teniendo lugar incluso casos en los que existen módulos que realizan operaciones sobre hardware o tecnología a la que ni siquiera tiene acceso el equipo core de Ansible. Esto ralentizaba el ciclo de lanzamiento de versiones y es sólo la punta del iceberg de un conjunto de desafíos para el equipo core que mantiene el proyecto.

Como parte de las soluciones y desde una perspectiva de desarrollo, sin profundizar en los detalles de cada uno de ellos, desde entonces, el proyecto Ansible se dividirá en diferentes componentes, existiendo un motor central (mantenido por el equipo Core de Ansible), módulos y complementos principales (los más utilizados), módulos y complementos de la comunidad, módulos y complementos de socios empresariales.

Esto, básicamente, permitirá que todo el contenido de Ansible no tendrá que ser parte del lanzamiento incluído en el core de Ansible, aunque obviamente el proyecto mantendrá los módulos más usados incluidos de forma “auto-mágica” en una instalación simple de Ansible. Para todo lo que sale de estos módulos principales y en base a la nueva estructura del proyecto, el nuevo marco común de implementación son las colecciones, a las que podemos referirnos como la evolución de los roles. Si un rol en Ansible se centra en la organización de nuestras automatizaciones para convertirlas en código reutilizable, una colección va más allá incluyendo plugins, el código python del módulo y también roles que utilizarán ese código.

En el contexto de las colecciones aparece el término namespaces que hace referencia a cómo nombrar las llamadas a ese código desde nuestras playbooks. Veamos un ejemplo en el que utilizamos una colección de AWS de la forma recomendada FQCN para el módulo ec2_instance (amazon.aws.ec2_instance):

- name: Manage EC2 instance
  amazon.aws.ec2_instance:
     name: "public-compute-instance"
     key_name: "{{ ssh_key }}"
     vpc_subnet_id: "{{ subnet_id }}"
     instance_type: c5.xlarge
     security_group: default
     network:
        assign_public_ip: true
     image_id: "{{ ec2_ami_image }}"
     tags:
        Environment: dev

Aprovechando el ejemplo, diremos que Ansible tiene módulos para aprovisionar infraestructura (como el citado arriba), aunque que tengamos capacidad de hacerlo, no quiere decir que sea la mejor solución. En este caso y a pesar de ser fiel defensor de Ansible, para no faltar a la verdad, diremos que terraform es una tecnología que maneja el estado de la infraestructura con grandes ventajas respecto a Ansible, gracias a su enfoque declarativo, pero no nos metamos en este jardín ahora (quizás en el futuro :D).

Cómo ir más a fondo

Para ampliar nuestro conocimiento en Ansible podemos seguir el trabajo de personas que están impulsando el ecosistema. Hoy le toca salir a la palestra a @geerlinguy, desarrollador muy activo y del que podemos encontrar numerosos roles, colaboraciones, vídeos, divulgaciones e incluso un libro “Ansible for DevOps” sobre el tema.

También podemos conectarnos con algunas fuentes primarias, donde encontramos información del proyecto de gran relevancia. Es el caso de Ansible Galaxy donde se aloja el código de roles y colecciones, el blog de Red Hat para Ansible, la documentación oficial, la lista de correo (en google), Bullhorn la newsletter para la comunidad de desarrolladores y por supuesto el código del proyecto en github que ya habíamos mencionado.

Conclusión

Como ha ocurrido a lo largo de la historia, los sistemas se han visto mejorados con la llegada de nuevas ideas y nuevas formas de hacer. Ansible participa activamente en evolucionar el ecosistema de la automatización y no está solo. Los nuevos tiempos exigen la creación de un clima de aprendizaje en el que seguir desarrollando tecnologías mientras avanzamos hacia el futuro.

Y tú, ¿qué opinas sobre Ansible? Te leemos en los comentarios.