Cómo ahorramos días de trabajo con la automatización de TI: un estudio de caso

En 2020, trabajaba en un equipo que automatizaba el proceso de creación de nuevas imágenes de máquinas virtuales (VM) para las últimas versiones de Red Hat Satellite. Nuestro objetivo era automatizar las implementaciones, las instantáneas, la limpieza y la creación de plantillas de máquinas virtuales. Suena fácil, pero fue mucho trabajo. Obviamente, la automatización era necesaria para ahorrarle tiempo a nuestro equipo, y elegimos Red Hat Ansible Automation Platform como nuestra interfaz de automatización. Aquí es donde comienza esta historia.

Si has trabajado con Plataforma de automatización Red Hat Ansible, sabes que hay muchas cosas que necesitas configurar para que sea útil. Por ejemplo, debe configurar el inicio de sesión y la autenticación, luego los proyectos, las credenciales, los inventarios, las fuentes de inventario, las plantillas de trabajo y flujo de trabajo, las notificaciones, los calendarios, etc. Todo este arduo trabajo es la razón por la que ayudé a construir la plataforma de automatización Red Hat Ansible. Configuración como código.

Este proyecto de automatización convierte todo lo que necesita hacer en la interfaz de usuario de Ansible Automation Platform en el lenguaje de serialización YAML. Luego, la configuración se ejecuta con un solo comando de libro de jugadas que lleva toda su plataforma de automatización Ansible desde una nueva instalación a un servicio completamente funcional.

Es una gran victoria. ¿Por qué? Una vez escrita la configuración, el tiempo necesario para configurar una nueva instancia mediante el método de configuración como código es inferior a 30 minutos. Antes de usar este enfoque, se necesitaba un día o más (según a quién le pidiera que lo hiciera y su nivel de experiencia) para implementar, instalar y configurar una nueva instancia y prepararla para el lanzamiento en producción.

Antes de desarrollar el método Config-as-Code, una implementación manual podía llevar de una a tres horas y la configuración podía llevar el resto del día. Probablemente sería un esfuerzo de dos personas para acelerar el proceso. Por ejemplo, si hubiera un proyecto con cinco credenciales, dos inventarios, dos fuentes de inventario, de 20 a 40 plantillas de trabajo y de cinco a 10 flujos de trabajo, podría llevar horas crearlos a través de una interfaz de usuario controlada por mouse. Digamos que lo hiciste una vez, dolorosamente. ¿Qué pasa si pierdes tu instancia? Si no ha escrito ninguna configuración, la reproducción se basa únicamente en su memoria o en la documentación de su equipo.

Es por eso que hemos encontrado esencial escribir la configuración primero. Escribir correctamente la configuración se convirtió en una oportunidad de aprendizaje para mi equipo. ¿Por qué? La configuración no tenía un lenguaje de programación estándar, por lo que el equipo tuvo que aprender el esquema de las construcciones YAML. Una vez que superamos esta curva de aprendizaje, nos volvimos más eficientes.

Ahora que contábamos con el tiempo de instalación automatizado, estábamos seguros de que volveríamos a estar listos y funcionando de inmediato con los archivos de configuración correctos en caso de un desastre. Pero, ¿qué pasa con las configuraciones YAML completamente completadas y probadas?

Para poner este desafío en perspectiva, si está escribiendo un nuevo libro de jugadas que se ejecuta en Ansible Automation Platform como una plantilla de tareas, debe agregar los proyectos apropiados al archivo YAML del proyecto y luego agregar las credenciales, los inventarios y las plantillas de tareas apropiadas en los registros correctos. Esto es un mínimo de unas 50 líneas de código. Comprender este código y escribirlo puede tomar desde 30 minutos (si sabe lo que está haciendo) hasta tres o cuatro horas (si es nuevo).

El proceso de escribir código solo se vuelve más rápido a medida que practica. Vale la pena dedicar tiempo a esto porque obtienes repetibilidad y consistencia. Puede aplicar todas las ventajas y desventajas de Infraestructura como código.

Entonces desea que se pruebe su configuración (código). Aquí es donde mi equipo dedicó algunas horas adicionales a crear una instancia de prueba que se parecía a la instancia de producción y contenía todos los cambios propuestos. A continuación, determinaríamos las tareas necesarias para probar completamente la solicitud de fusión. Finalmente, lo fusionaríamos. Esta carga representaba una carga de trabajo total de uno o dos días.

Para abordar las pruebas con automatización, diseñamos un enfoque automatizado utilizando la integración continua (CI) de GitLab. Con nuestra automatización, cada vez que se abría una nueva solicitud de extracción (PR), GitLab CI creaba una nueva instancia de prueba para esa PR. La automatización ahorró entre dos y cuatro horas, según quién implementó la instancia. Ahora que GitLab lo estaba implementando, se ahorró más tiempo.

El siguiente desafío fue descubrir cómo se debe probar el PR. Con algunos PR más pequeños, fue bastante fácil determinar rápidamente qué probar. Los PR complejos afectan a más de una docena de archivos, y era difícil anticipar lo que podría fallar si el PR no se probaba correctamente antes de fusionarse con la rama principal. Tenga en cuenta que la instancia de producción se ejecutaba con el código de la rama maestra.

Para superar este desafío y ahorrar horas dedicadas a analizar y luego probar los RP, hemos diseñado un nuevo proyecto llamado Ansible Genealogist (en un repositorio privado al momento de la publicación), que examina los RP en minutos y documenta lo que se debe hacer. .

[ A free guide from Red Hat: 5 steps to automate your business. ]

ManchaTiempo empleado manualmenteTiempo dedicado al uso de la automatización
Implementación de una nueva instancia de Ansible Automation Platform: producción lista~ 1-2 días<30-45 minutos
Implemente y configure una instancia de prueba para probar una nueva configuración antes de enviarla a producción~ 4-6 horas<30-45 minutos
Determinar qué debe probarse para cada nuevo PR~ 1-2 horas<5-10 minutos
Ejecutar pruebas~ 2-6 horas (o más para relaciones públicas complejas)<5 minutos (simplemente ejecute el script de prueba de automatización y vuelva más tarde para verificar los resultados)
Vuelva a implementar una instancia de producción porque acaba de perder la que estaba ejecutando debido a una interrupciónSin estimación, es un desastre, todo listo (tal vez ~ 1-2 días si los miembros de su equipo saben qué hacer y pueden hacerlo todo)<30-45 minutos
Realice cambios de producción, como agregar una nueva plantilla de trabajo o actualizar las credencialesTerrible tarea: si haces algo mal, está mal. Si decide probar los cambios antes de actualizar la producción, entonces está planeando alrededor de 1 día hábil<30 minutos, porque sus cambios ya se probarían como parte del proceso de relaciones públicas, empujar a producción es básicamente CI CD / CD

Como puedes ver, gracias a la automatización, hemos reducido las tareas de unos días a unos minutos. Y no, no automatizamos fuera de un trabajo porque seguimos automatizando más tareas. El objetivo de nuestro grupo era automatizar tareas administrativas estándar para máquinas virtuales: implementaciones, plantillas, instantáneas, etc. El ahorro de tiempo fue un elemento esencial de este proyecto. También queríamos crear eventos de desastre repetibles. La automatización y los modelos nos han permitido ser mucho más eficientes en situaciones de recuperación ante desastres.

[ Download now: A system administrator's guide to IT automation.]

Artículos de interés

Subir