Aventuras con Ansible: desafíos, soluciones y... ¿Subversion?

En el entorno de TI actual, las aplicaciones empresariales son complejas y escalables, están distribuidas, se basan en elementos y suelen ser de misión crítica. Pueden implementarse en varias plataformas en la nube privada, púbica o híbrida. Es posible que accedan a datos confidenciales y estén sujetas a normativas y políticas de seguridad estrictas, pero deben ser tan fáciles de utilizar como sea posible. En pocas palabras, estas aplicaciones son sumamente complejas. En esta publicación, analizaremos cómo se relacionan esos aspectos importantes con el uso de las herramientas de automatización como Ansible.

En la publicación anterior, Aventuras con Ansible: lecciones aprendidas gracias a las implementaciones en la práctica, expliqué los aspectos prácticos que debe considerar para utilizar Ansible correctamente en su entorno. En la publicación de hoy, profundizaré en lo que considero las prácticas recomendadas que adquirí en la experiencia de campo con implementaciones reales.

Diseñar y desarrollar aplicaciones empresariales implica satisfacer una gran cantidad de requisitos diferentes. Es más, las decisiones de desarrollo que tome para cumplir uno de los requisitos pueden afectar al resto de ellos de formas que suelen ser difíciles de comprender o predecir. El incumplimiento de estos requisitos podría conducir al fracaso del proyecto.Estas son algunas de las aplicaciones empresariales que puede encontrar en la actualidad:

• Sistemas de facturación automatizados (ABS)

• Procesamiento de pagos

• Sistemas de marketing por correo electrónico

• Sistemas de gestión de contenido (CMS)

• Centro de llamadas y soporte al cliente

• Gestión de relaciones con el cliente (CRM)

• Planificación de recursos empresariales (ERP)

• Inteligencia comercial

• Planificación de continuidad del negocio (BCP)

• Gestión de recursos humanos

• Integración de aplicaciones empresariales (EAI)

• Sistemas de mensajería y colaboración

Como resultado de la complejidad de estas aplicaciones en la práctica, las empresas explican que no han automatizado sus aplicaciones empresariales debido a las siguientes razones, entre otras:

• No se pueden automatizar.

• Originalmente, no se diseñaron para automatizarse.

• Automatizarlas es demasiado complejo y costoso.

• Ya están automatizadas con scripts de shell y otros trucos y herramientas diferentes.

• Por el momento, no tenemos problemas con nuestras operaciones actuales.

• El encargado de la TI soluciona cualquier problema con los productos de la empresa.

Es posible que también piensen en el hecho de que esto es más que un desafío técnico. Honestamente, la automatización no se trata solo de la tecnología, sino también de una forma de pensar distinta, lo cual requiere un cambio cultural.

Cuando estuve en Alemania por un compromiso laboral con un cliente, tuve la oportunidad de estar a cargo de un equipo de automatización cuyo objetivo era automatizar las implementaciones de las pilas de software en diez entornos diferentes con Ansible, Jenkins y Vagrant. Realizaban implementaciones en la producción cada tres meses y experimentaban tiempos de inactividad prolongados y problemas inesperados durante la implementación, entre otras complicaciones. La presión y la dificultad de lanzar una versión a medianoche con diez expertos que residieran en el lugar ya no tenía sentido en el mundo moderno de la TI.

Querían una solución automatizada para reducir los costos, aumentar la confiabilidad, estandarizar sus entornos, eliminar las tareas manuales y repetitivas y permitir que sus equipos se enfocasen en mejorar los sistemas, en lugar de gestionarlos.

En general, el proyecto fue un éxito, pero no fue un proceso sencillo. Esto es lo que ocurrió:

Los problemas

Comencemos con algunos de los problemas que enfrentaban.

Implementaciones manuales

Todas las implementaciones eran manuales, lo cual generó algunos de los siguientes desafíos:

• Las implementaciones de producción se llevaban a cabo cada tres meses y podían demorar hasta ocho horas. Además, se realizaban durante la noche y se necesitaba la ayuda de cinco a diez especialistas diferentes.

• Cada uno de ellos tenía su propio script personalizado para efectuar las distintas tareas necesarias para lograr que cada versión funcionara en todos los entornos.

• Era un gran desafío de organización, y cada implementación tenía sus propios problemas específicos.

Implementaciones complejas

• Confiabilidad: a veces, las aplicaciones no se iniciaban debido a secuencias de detención incorrectas. Todos tenían sus propios trucos para volver a iniciarlas. Además, algunas aplicaciones no estaban configuradas de la misma manera en todos los entornos, lo cual comprometía aún más la confiabilidad.

• Interacción humana: para efectuar las implementaciones de forma adecuada, a menudo era necesario que una persona ejecutara una acción en el sitio web.

Falta de uniformidad en los entornos (también conocido como "Factor humano")

En ese momento, nuestros entornos no eran uniformes. Las implementaciones se realizaban de forma manual, y de alguna manera siempre lográbamos que funcionaran.Algunos colegas tenían scripts especiales, carpetas específicas en los servidores de destino, etc.Generalmente, esto provocaba errores en la producción que no ocurrían en los entornos anteriores. Y cuando el entorno de producción está inactivo durante un período más largo de lo esperado, se genera un problema complicado y costoso.

Básicamente, de eso se trataba el "factor humano".

Cultura de modelo en cascada

Antes de la automatización, la cultura básicamente consistía en las técnicas de desarrollo en cascada. Casi nunca realizábamos implementaciones en el entorno de producción.

Todo comenzó con las metodologías ágiles, y así se desarrollaron los equipos de Scrum. Luego, creamos un equipo de automatización en el departamento de operaciones para impulsar la automatización de las implementaciones y reducir las inconsistencias y las complejidades manuales. En general, este proceso de transformación del modelo en cascada al ágil tomó alrededor de dos años y aún puede mejorarse. El proceso no deja de evolucionar y cambiar, y ese es el objetivo del desarrollo ágil.

La solución

Implementamos una técnica mejor.

Para poder ofrecer una solución sofisticada y reducir en gran medida la complejidad de las implementaciones, se necesitaron un software de automatización, las metodologías ágiles, los equipos de Scrum del departamento de desarrollo y operaciones, un equipo de automatización que se dedicara a distribuir herramientas automatizadas y un proceso diario para transformar nuestra cultura empresarial en una nueva perspectiva.

Todas las personas involucradas invirtieron mucho tiempo e hicieron un gran trabajo.

Esta es la descripción general de algunas de las herramientas que utilizamos para automatizar todos los elementos en nuestro entorno:

Nexus

En primer lugar, es necesario contar con un repositorio central para los artefactos. Es muy probable que el equipo de desarrollo ya utilice uno para almacenar los artefactos binarios que diseñan.

Jenkins

Jenkins es la herramienta de automatización del canal de CI/CD. Es muy probable que el equipo de desarrollo ya utilice Jenkins o alguna herramienta similar para los diseños automatizados. Sin embargo, decidimos crear una instancia de Jenkins distinta para la automatización de las implementaciones, ya que queríamos gestionar los firewalls de forma diferente.

Creamos canales para organizar las etapas del proceso de implementación: la preparación, la detención, la implementación y el inicio; y lo hicimos con el código Groovy (funciones, clases orientadas a objetos, etc.). De esta manera, no solo desarrollamos estándares (código reutilizable), sino que si Jenkins falla o todo se desmorona, podemos recuperarnos con gran rapidez utilizando el código.

Recuerde que se deben automatizar incluso las herramientas de automatización. Por esta razón, también automatizamos la instalación de Jenkins e instalamos un servidor Jenkins a menor escala en el nodo de control para probar los canales de manera local antes de cargar el código Groovy o Ansible al repositorio. Se instaló exactamente con las mismas versiones del complemento de Jenkins que se ejecutaban en el clúster de Jenkins para la producción.

Ansible

Todas nuestras tareas se basaban en Ansible.

Trasladábamos toda la configuración al inventario de Ansible usando una estructura de inventario de varias etapas (que se encargaba de Dev1, Dev2, Dev3, Test1, Test2, Test3, etc.), así como variables compartidas y group_vars. Demorábamos mucho tiempo en trasladar la configuración de aplicación que residía originalmente en los artefactos que el equipo de desarrollo diseñaba usando su instancia de Jenkins.Las credenciales se almacenaban con Ansible Vault.

Nuestras implementaciones de software se podían desglosar en las siguientes etapas: la preparación, la detención, la implementación y el inicio.Como resultado, desarrollamos nuestras funciones de Ansible con el punto de entrada tasks/main.yml que gestionaba estas etapas utilizando etiquetas.Consulte el ejemplo a continuación. Esto nos permitió usar un canal de Jenkins para ejecutar todas las funciones de Ansible y solo llevar a cabo la etapa prepare o de preparación, que se encarga de enviar los artefactos nuevos a los servidores de destino sin afectar ningún servicio en ejecución. Gracias a esto, ahorramos mucho tiempo de preparación, que no requiere tiempo de inactividad.

--- - name: Prepare artifact  import_tasks: prepare.yml  tags: prepare - name: Shutdown services  import_tasks: shutdown.yml  tags: shutdown … 

Vagrant

Utilizamos Vagrant y Virtualbox para implementar un nodo de control que tuviera una instalación de menor escala similar al servidor Jenkins desde donde se ejecutan nuestros playbooks de Ansible. Esto era importante porque necesitábamos una forma de evaluar y depurar los problemas de automatización.

Se implementó la caja local de Vagrant con la misma versión de Ansible y de Jenkins y los mismos complementos de Jenkins, paquetes del SO y nombres de volumen que nuestro nodo maestro principal de Jenkins. Naturalmente, se redujo para utilizar una memoria de 1 GB y un vCPU, pero era suficiente para realizar las pruebas. Además, Vagrant estaba configurada con cajas que emulaban nuestra pila de producción, por lo que podíamos ejecutar los playbooks desde el nodo de control para realizar aprovisionamientos e implementaciones en uno o más hosts de destino (servidores web, de aplicaciones, entre otros).

Subversion

Subversion era el sistema de control de versiones (VCS) en la empresa. Al principio, queríamos cambiarlo, pero toda la empresa utilizaba Subversion. Habría sido un cambio grande y problemático. Si solo nuestro equipo hubiera usado Git, habríamos creado un silo nuevo y agregado otra capa a la pila. Considero que lo mejor es no complicarse, y nunca tuvimos ningún problema que justificara cambiar Subversion por Git. A veces, conviene saber cuándo quitar y reemplazar una tecnología y cuándo seguir usándola, incluso si no se trata de una herramienta de última moda.

JIRA

¿Qué son la metodología ágil y los equipos de Scrum sin Jira? El software de seguimiento de Atlassian es muy útil para planificar, rastrear y lanzar sistemas de software.Uno de los mayores desafíos de nuestra transformación a la automatización fue definir las historias de los usuarios en JIRA y comprender el producto viable mínimo (MVP).

Desafíos

Ningún cambio ocurre sin desafíos, y los nuestros abarcaban todas las áreas posibles.

Técnicos

En ese momento, las aplicaciones dependían de Internet Explorer y utilizaban la tecnología de ActiveX. Para evitarlo, utilizamos PhantomJS para su automatización con un explorador sin interfaz gráfica.

Políticos

Tanto al equipo de desarrollo como al de operaciones les interesaba aplicar DevOps, pero era difícil alinear las prioridades que los dos departamentos habían establecido respecto del movimiento DevOps. Ambos tenían líderes diferentes con objetivos generales distintos.

Personales

A algunos colegas del equipo no les interesaba la automatización en absoluto; al menos al comienzo. Consideraban que ya habían automatizado lo suficiente. Es importante que su empresa dedique tiempo a definir la automatización. Tal vez mucha gente aún ve la automatización como otro idioma que debe aprender. Con mucha paciencia, luego de tan solo plantar la idea en sus cabezas y mostrarles pequeñas historias de éxito, pudimos convencerlos de utilizar la automatización de Ansible.

Resultados

¿Qué logramos? En general, fue una historia de éxito sorprendente que debíamos compartir, y de ahí nace la necesidad de escribir este blog. Pasamos de ser un equipo que no automatizaba ningún proceso a uno muy exitoso que, actualmente, realiza implementaciones en la producción cada dos semanas con un solo canal que casi no requiere ningún tipo de experiencia o interacción humana.

Algunos de los logros y resultados que conseguimos incluyen un procedimiento estandarizado para la preparación, el inicio, la implementación y la detención en diez entornos. Hasta ahora, es confiable y siempre inicia sin problemas, y el tiempo de implementación se redujo de dos horas a tan solo 20 minutos.

Con la automatización del canal, ya no necesitamos operaciones manuales para realizar las implementaciones y eliminamos los errores que estas generaban. Incluso con una documentación sólida y un personal de TI experimentado, hay un gran margen de error cuando se depende de las personas para procesar una serie de comandos y operaciones de forma manual. Si se comete un error o se omite un paso, todo puede salir mal muy rápido.

Lecciones aprendidas

Los resultados hablan por sí solos, pero además de los resultados empresariales, también aprendimos mucho durante el proceso.

Tenga en cuenta que no todos desean adoptar la automatización, o al menos al comienzo. Deberá emplear algo que no encontrará en Ansible ni en ninguna herramienta de automatización: la paciencia. La necesitará, y mucho, para embarcarse en un proyecto de automatización de gran envergadura.

Comience de a poco y automatice un elemento que le dé un resultado excelente para poder mostrarlo como una historia de éxito. Si desea solucionar un inconveniente que enfrentan las personas, no intenta abordar el problema principal de inmediato sin tener experiencia en el tema o el respaldo de la automatización. Un error al comienzo podría acabar con las iniciativas de automatización y provocar que las personas se convenzan de que es imposible automatizar su entorno.

Como muchos otros aspectos en la TI, el 80 % de los problemas que enfrentará serán relativamente fáciles de solucionar. El otro 20 % será el que presente un verdadero desafío durante la automatización, debido a los casos extremos, el manejo de las excepciones y otras situaciones inusuales que puedan surgir. Sin embargo, estos problemas suelen ser complejos, pero no imposibles.

Los encargados de las operaciones y los administradores de sistemas experimentados se ven muy tentados a utilizar SSH en los hosts para solucionar los problemas, pero usted debe resistir ese impulso. El objetivo es obtener sistemas uniformes, predecibles, estandarizados y confiables, por lo que debe descubrir cómo cambiar (o crear) los playbooks de Ansible para no tener que usar SSH en la caja. Solucione el origen del problema y no solo los síntomas.

Por último, su trabajo no habrá terminado hasta que automatice la automatización. Debe instalar y actualizar Ansible, Jenkins, los complementos de Jenkins, etc. automáticamente y no de forma manual, ya que generaría el mismo problema que solucionó con Ansible en los hosts de destino. Además, sus entornos nos serían uniformes ni confiables para las herramientas de automatización, y esta no es una buena base.

Conclusión

A lo largo de mi profesión, siempre automaticé todo lo que pude, ya que detestaba realizar la misma tarea manual dos veces. El problema era que utilizaba las herramientas incorrectas.

Finalmente, automatizar el sistema de software que instalé, configuré, implementé y en el que ejecuté parches durante más de diez años fue una experiencia increíble y reveladora en cuanto a todas las funciones de la gestión de configuración, la CI/CD, los canales, la idempotencia, etc.; y todo se basaba en Ansible.

Por eso, ya no tenga miedo y comience a automatizar sus aplicaciones empresariales hoy mismo. Para obtener más información sobre cómo Red Hat Services puede ayudarlo a mejorar su empresa automatizada, eche un vistazo a nuestras ofertas de consultoría.