Cree una canalización de implementación automática con Jenkins y Ansible

Todo comenzó cuando nuestro equipo de ingeniería de calidad (QE) se dio cuenta de que estábamos implementando nuestras máquinas con demasiada frecuencia. No pudimos seguir el ritmo de las pruebas de nuevas versiones para nuestro proyecto.

Para facilitar las cosas, decidimos trabajar con nuestro equipo de QE de virtualización para ayudarnos a comprender cómo automatizan sus implementaciones. resulta que usan Ansible roles escritos para realizar tareas específicas. Después de hablar con ellos, pasé mucho tiempo comprendiendo y automatizando la virtualización de Red Hat para nuestro equipo.

Este artículo explica cómo sucedió. Deberías saber que no había trabajado con Oleoducto Jenkins antes, por lo que es posible que mi trabajo no refleje las mejores prácticas. Todavía estoy aprendiendo.

Índice

instalación de archivos

Además de mis archivos internos, recurrí a oVirt Ansible de GitHub sección. Los roles de Ansible particularmente útiles aquí fueron:

En mi jenkins_files, comencé mirando el repositorio de Git. Luego instalé los paquetes necesarios en el nodo de Jenkins. Tenga en cuenta que se requieren algunos paquetes DNF y PIP.

Al final, tomó mucho ensayo y error descubrir los paquetes y versiones correctos para usar. Una vez que todo estuvo funcionando en mi entorno local (en mi ordenador), comencé a traducir todo en Jenkins Pipeline.

Depuración de nuestro libro de jugadas de configuración

Una vez completada esta tarea, nos taza-reaprovisionó los hosts con una instalación nueva de nuestra distribución, la configuró para exportar el almacenamiento NFS, instaló los repositorios necesarios y, finalmente, ejecutó nuestro libro de jugadas de implementación. Una vez que se implementó el motor alojado en oVirt, ejecutamos nuestro manual de configuración para configurar nuestra virtualización Red Hat y las máquinas con redes, almacenamiento, hosts y archivos ISO según fuera necesario.

Un problema con el que me encontré durante esta fase fue que había una tarea en uno de los libros de jugadas que usaba whoami para saber qué usuario usar ssh del hipervisor al motor alojado, y esta tarea eligió mal mi inicio de sesión de usuario personal en lugar de root. I planteó este problema con el ovirt-ansible-hosted-engine contribuyentes y ellos arreglado.

Una vez que se resolvió este problema, me encontré con otro. Estaba superando el paso de falla anterior e implementando el motor alojado correctamente, pero cuando se ejecutaba desde Jenkins seguía fallando con un mensaje de error críptico que apenas me decía qué estaba mal. Investigando un poco, descubrí que la autenticación entre el host del hipervisor y el motor alojado estaba rota. luego agregué he_root_ssh_pubkey attribute a mi implementación y me aseguré de que el hipervisor tuviera la clave privada correcta implementada a través de Beaker. Hacer esto resolvió otro problema, y ​​mi libro de jugadas finalmente terminó de funcionar engine-setup y completó el despliegue.

Añadidas otras mejoras

También queríamos establecer contraseñas predecibles en la base de datos de nuestras herramientas de virtualización. ovirt_engine y almacén de datos ovirt_engine_history Base de datos, pero ovirt-hosted-engine-setup el papel no se lo permitía. Alcé una solicitud de extracción para resolver este problema, y ​​espero tenerlo fusionado pronto.

Otras dos cosas que agregué son la capacidad de copiar claves SSH personalizadas a known_hosts en los hipervisores y omitir la implementación si ya estamos en la versión correcta. Para la parte de SSH, usé el known_hosts módulo para realizar esta tarea. Esta modificación de la comunidad fue un poco confusa, así que escribí mi primera solicitud de extracción contra Ansible Repo, ampliando la documentación y los ejemplos a known_hosts module. También espero que esta adición se fusione pronto.

Para limitar las redistribuciones en caso de que ya estemos en la misma compilación, decidí usar el repodiff para pasar la URL de compilación actual (tomada de los paquetes/repositorios instalados) y la nueva URL de compilación solicitada por el usuario de canalización. el repodiff El comando podría buscar en ambos repositorios y comparar los paquetes, y si no hubiera paquetes agregados/eliminados/modificados, la versión instalada y la versión que intentábamos instalar serían las mismas.

Si es así, usamos nuestro script bash y playbooks para omitir la instalación e ir directamente a la última fase de la canalización: ejecutar pruebas de humo para nuestros productos.

Envoltura

En última instancia, este proceso ha sido doloroso y difícil, pero también una experiencia gratificante para ver cómo todo llega a buen término. Eche un vistazo a una de estas tuberías. Se espera una falla de Etapa 3 en algunas situaciones y se ignora.

Gracias por leer, si quieres saber más sobre cómo llegué allí y cómo planeamos usarlo, o cualquiera de los códigos, no dudes en contactarme, porque este artículo no cubre todos los detalles, pero es solo una descripción general.

Artículos de interés

Subir