la escala lo cambia todo #
Instalar y configurar equipos usando ansible 1 es muy cómodo, pero
siempre se puede mejorar y a gran escala, cuando es necesario lidiar con
cientos o miles de servers y workstations es conveniente utilizar
AWX 2 ya que permite organizar, registrar y monitorear el deploy
en paralelo sin perder ningún detalle.
módulos tower vs awx-cli #
Ansible cuenta con módulos tower_* 3 (collections en las
versiones nuevas) que permiten crear y/o modificar los diferentes
recursos de una instancia de AWX (Ansible Tower) e inicialmente creé
un rol ansible_role_tower_cli que tomaba las definiciones de desde
archivos YAML para crear y/o modificar projects, jobtemplates.
A medida que pasaron los días y en el apuro de varios deploys, ejecutar el rol no resultó práctico, porque estaba pensado para actualizar el histórico de recursos completos de AWX.
Luego de probar diferentes alternativas de trabajo con AWX, crear un
jobtemplate manualmente en la instancia de desarrollo (awx-dev) y
exportar la plantilla a un archivo .json usando awx-cli 4 para
luego importarla en la instancia productiva (awx-prd) resultó muy
práctico.
awx.git + ansible-tools #
Versionar los recursos de AWX en un repositorio awx.git 5 surgió
naturalmente para obtener reproducibilidad entre diferentes instancias,
generar releases, verificar diferencias y aplicar correcciones.
El repositorio awx.git impulsó la creación de nuevos scripts de
ansible_tools 6, para interactuar con AWX, obtener dependencias,
validar recursos, otorgar permisos y obtener valores de variables de la
una instancia.
awx-deploy-revision #
Teniendo todos los recursos versionados en un repositorio git, era
inevitable automatizar el deploy de una revisión de AWX, al
principio awx-deploy-revision 7 se ejecutaba manualmente y permitía
reproducir el deploy de un release en diferentes instancias,
asegurando la integridad de cada componente detectando inconsistencias y
asegurando los mismos permisos.
GitLab CI/CD #
Invocando reglas de Makefile 8, fue posible ejecutar
awx-deploy-revision desde .gitlab-ci.yml 9 de modo desatendido y
aprovechando todas las ventajas de las Pipelines ahora es posible
iniciar el desarrollo de un jobtemplate directamente desde el
repositorio awx.git monitoreando la salida de los jobs de GitLab
sin necesidad de ingresar a AWX.
git push = pipeline success #
Sin entrar en detalles, la secuencia de pasos automatizada es la siguiente:
- La persona hoy conicida como DevOps ejecuta
git push - GitLab recibe los cambios y ejecuta
json-lint - Luego se configura el entorno definido en
AWX_ENVmedianteawx-config - Se envían los teams usando
awx-cli send team - Se envían los projects usando
awx-cli send project - Se actualizan los projects enviados usando
awx-cli update project - Se envían los inventories sources usando
awx-cli send inventory_source - Se envían los inventories usando
awx-cli send inventory - Se actualizan los inventories sources usando
awx-cli pdate inventory_source - Se envían los job templates usando
awx-cli send job_template - Se envían los workflows usando
awx-cli send workflow - Se otorgan permisos para todos los recursos usando
awx-cli grant
Si no hubo ningún error, se obtiene Pipeline Success y la revisión en
curso queda disponible para ejecutar en AWX :)
Si hubo algún error, basta con observar la salida del Job fallido y
realizar los cambios necesarios en el repositorio awx.git, efectuar un
commit y al ejecutar nuevamente git push, GitLab se ocupará del
deploy.
Si fue exitoso el deploy en awx-dev, en otro stage se realiza el
mismo deploy en otra instancia de AWX.
Relacionado #
ChangeLog #
2022-10-10 15:54remove Leaked GitLab Token from ChangeLog :S2022-10-10 13:04corregir links de.gitlab-ci.ymlyMakefileen Automatizar la implementación de los recursos de AWX con GitLab CI/CD y Ansible Tools2022-10-08 23:02Agregar Automatizar la implementación de los recursos de AWX con GitLab CI/CD y Ansible Tools