Ansible es un sistema que resuelve varias tareas de automatización, incluyendo proyectos de configuración, respaldo y despliegue. Es agradable usar el sistema para escribir scripts de automatización desde un entorno simple a un proyecto grande. En los guiones, los libros de jugadas juegan un papel importante y los libros de jugadas estructurados juegan papeles.
Ansible no es una píldora mágica , y solo ayuda al principio. Cuando un proyecto crece, se hace difícil mantener un número ampliado de roles. El mecanismo de entrega continua de roles ayuda a resolver el problema.
Sobre esto, la decodificación del informe de
Alexander Kharkevich en
DevOps Conf Russia . En el informe: desarrollo de roles Ansible a través de CI, un mecanismo para desarrollar roles públicos y roles públicos con pruebas de ejecución en una infraestructura privada. Y no hay conclusión en el informe.
Sobre el orador : Alexander Kharkevich (
kharkevich ) ingeniero de sistemas senior en
EPAM Systems .
Comencemos con una descripción general rápida.
Sobre Ansible
Ansible es un sistema de gestión de configuración. Está escrito en Python, creado por Junja, y YAML se usa como DSL. Administrado a través de Ansible Tower - WebUI para administrar y monitorear el rendimiento del sistema.
Ansible apareció en 2012, después de 3 años, Red Hat compró todo el proyecto, y dos años más tarde presentó AWX - Project Open Source versión de Ansible Tower.
Instalación
Para usar Ansible, debes hacer dos cosas simples.
En la primera etapa, compile un archivo de inventario en caso de una infraestructura estática.
El segundo es escribir un Playbook que llevará el sistema al estado esperado.
A menudo tenemos un deseo irresistible de escribir automatización, que puede reutilizarse nuevamente. La automatización es un buen deseo, y a los muchachos de Ansible se les ocurrió un concepto genial: el papel.
Papel
Esta es una entidad estructurada que llevará el sistema a su estado esperado con la capacidad de reutilizar la automatización.
Por ejemplo, podemos escribir un rol para Oracle Java: tomar un libro de jugadas, poner un rol y aplicarlo al sistema de destino. La salida tendrá Java instalado.
Cómo imaginamos trabajar con roles
Dado que Ansible tiene una función tan maravillosa como los roles, pensamos que ahora tomaríamos y escribiríamos muchos, muchos roles para todas las ocasiones, perder el tiempo y reutilizar para reducir la cantidad de trabajo.
Pensamos que escribiríamos papeles hermosos e inteligentes ...
Pero la vida resultó ser más complicada.
Al final resultó que, en realidad
Cuando más de una persona trabaja en escribir un papel o en mejorarlo, todos escriben en un lugar y surgen sorpresas desagradables: el papel se comporta de manera diferente a lo que el autor originalmente pretendía.
Es bueno cuando se aplica hasta el final, pero esto no siempre sucede. A veces, un rol se realiza con éxito, pero en el sistema de destino esto no afecta en absoluto como se quería originalmente.
Como resultado, surgen construcciones terribles, intentos de transferir bash a Ansible y enviar todo esto bajo la salsa de administración de configuración. Nos encontramos con este fenómeno y estábamos tristes.
Pensando, descubrimos que en nuestra gestión de configuración hay algún tipo de código, lo que significa que las prácticas que se aplican a la gestión de código en el Ciclo de vida del desarrollo de sistemas también son aplicables en Ansible.
- Recoge las mejores prácticas.
- Aplicar análisis estático, pelusa.
- A prueba.
- Para overclockear, para entrar en la gestión de versiones.
Decidimos implementar la práctica en casa e inmediatamente fuimos a buscar las herramientas adecuadas.
Las herramientas
Desde el punto de vista de los sistemas de control de versiones y la integración continua, hay docenas de soluciones disponibles y un zoológico de pruebas ramificado.
Desde el punto de vista de la administración de versiones en Ansible, no hay tantas soluciones: etiquetar en Git o etiquetar en Git y cargar en Galaxy.
Hay muchos enfoques para probar herramientas, cada uno usando lo que les gusta. Soluciones populares que utilizan KitchenCI, InSpec, Serverspec.
Nuestra alma no mintió para tomar Ansible escrito en Python y mezclar herramientas del mundo Ruby. Por lo tanto, después de haber desechado todo lo que no es nativo del mundo de Python, obtuvimos la siguiente imagen.
Utilizamos:
- Para la gestión de la configuración: GitHub y GitLab. GitLab está mirando directamente en GitHub. Por qué lo hice, lo diré más tarde.
- Para CI, tomamos Travis para la parte pública y GitLab Runner para la parte privada.
- Prueba de molécula.
- Inicie en GitHub y agregue a Ansible Galaxy.
Nuestro ciclo de desarrollo con estas herramientas se ha vuelto más divertido.
Molécula
Esta herramienta ayuda a probar completamente el papel ansible. Para hacer esto, tiene todo:
- Integración con YAML lint y Ansible lint para verificar los roles para el cumplimiento de nuestros requisitos.
- Infraestructura de prueba para ejecutar pruebas funcionales.
- Los controladores de Molecule es donde Molecule está implementando nuestro banco de pruebas. Todo es compatible: Azure, Delegated, Docker, EC2, GCE, LXC, LXD, Openstack, Vagrant.
- Todavía hay algo útil y simple: la delegación. Esto significa que Molecule no es responsable de implementar el banco de pruebas y el desarrollador debe escribir un Playbook para elevar el banco de pruebas. Si tiene una nube súper privada, delegue la creación y eliminación de máquinas de prueba, y la propia Molécula agregará todo dentro.
Matriz de prueba
Considere la matriz de prueba en pasos. Hay 11 pasos en total, pero seré breve.
No. 1. pelusa
Corren pelusa YAML y pelusa Ansible, y encuentran algo.
En el ejemplo anterior, lint jura que el shell no solo debe llamarse en Ansible, sino que debe repararse y vincularse a algo.
No. 2. Destruye
La molécula se deshace de todo lo que queda después de las pruebas anteriores.
Hay momentos en que ha pasado una carrera, se ha desarrollado un campo de entrenamiento y se han completado las pruebas. El soporte debe limpiarse al final, pero intervino fuerza mayor y no hubo limpieza. Para tales situaciones, la molécula escapa, destruye y limpia el medio ambiente de los residuos.
No. 3. Dependencia
Tomamos el archivo require.yml y agregamos las dependencias de nuestro rol en otros roles. Por ejemplo, una referencia al hecho de que el rol no despegará sin Java instalado en el sistema:
--- - src: lean_delivery.java version: 1.4
Molecule entiende esto y ejecutará el script:
- Va galaxia o git
- Se dará cuenta de que es necesario resolver dependencias;
- Va a Galaxy nuevamente;
- descargas;
- se expandirá
No. 4. Sintaxis
El siguiente paso es la verificación de sintaxis. pero no tu rol, sino el Playbook de prueba que agregas a Molecule. También hay errores de sintaxis en este paso.
La diapositiva muestra que el rol ansible se llama 'kibana', y en el Playbook de prueba, se llama ansible-role-kibana. El sistema dice: "Todo estaría bien y puedes crearlo aquí, ¡pero no lo haré porque los nombres no coinciden!"
No. 5. Crear
En esta etapa, indicamos el controlador con el que se implementa el sitio de prueba. Point Google: elevará las máquinas de prueba en Google Cloud.
Podemos escribir en el archivo molécula.yml lo que queramos. Veamos cómo se ve en un ejemplo para Docker.
- Estoy especificando las imágenes de la ventana acoplable para extraer.
- Indico cómo agruparlos para que se forme un archivo de inventario.
Quiero tener dos imágenes acoplables: una para RHEL-like, la segunda para Debian-like, para asegurarme de que durante la ejecución de la prueba todo estará bien tanto con RHEL como con Debian.
No. 6. Prepárate
Este es un paso de preparación preliminar para el entorno de ejecución de prueba.
Parece que todo ha aumentado, pero a veces es necesario realizar algunas configuraciones adicionales. En el caso de las pruebas dentro de un Docker elevado en Debian o Ubuntu, debe instalar un segundo Python, lo que a menudo sucede.
No. 7. Converge
Se ejecuta la etapa de la primera ejecución grande del rol dentro de la instancia, para asegurarse de que llegue al final, y Ansible confirma que todo está bien.
- Molécula se refiere a Ansible.
- Ansible desplegado en un sitio de prueba.
- Corre
- Todo esta bien!
No. 8. Idempotencia
La prueba de idempotencia es simple y se ve así.
- La primera vez que el rol se ejecuta en el paso anterior.
- Ansible informa cuántos cambios se han realizado.
- Relanza el mismo rol.
- Comprueba que el sistema ha sido llevado al estado esperado, pero no hay cambios en el segundo alquiler.
Como resultado, entendemos que nuestro papel no actúa de manera destructiva.
Esta etapa causó dolor a los chicos con los que trabajo. Intentaron trabajar para vencer la prueba de idempotencia. La molécula puede controlar las etapas que atraviesa, y lo primero que hicieron fue desactivar el control de idempotencia.
Tomamos apagones y nos ganamos, pero los ingenieros son inteligentes y fueron más profundos. Los desarrolladores decidieron decir que este paso en Ansible no cambia nada.
Aunque, de hecho, algún tipo de equipo aparecerá aquí. Ansible tomará directamente y
sobrescribirá el archivo, pero al mismo tiempo todo parece idempotente.
Cuando este truco también fue captado, la imagen comenzó a verse así.
Bien: el script se ejecutó con el nombre predeterminado y es idempotente.
No. 9. Efectos secundarios
En la siguiente etapa, los efectos secundarios se superponen. No es necesario hacer esto, pero es conveniente cuando prueba roles de distribución complejos que dependen unos de otros.
Por ejemplo, levante la pila ELK, luego Elasticsearch en un clúster. En la etapa side_effect, agregue datos de prueba y elimine un par de nodos del clúster. El sitio de prueba está listo para las pruebas funcionales que tienen lugar en el siguiente paso.
Número 10. Verificar
Probar la infraestructura.
Arriba hay un ejemplo de una prueba muy simple. Verificamos que tenemos instalado el paquete Docker Community Edition si Ubuntu está instalado, tiene la versión correcta y el servicio se está ejecutando.
En esta etapa del lanzamiento de las pruebas funcionales, todo puede ser muy complicado.
Probablemente el mejor ejemplo sería, en el caso de la pila ELK, si hacemos una solicitud en alguna solicitud de Elasticsearch para algunos datos de prueba, y dado que conocemos los datos de prueba, nos responderá. No verificaremos que todos los componentes instalados estén ensamblados, pero veremos que Elasticsearch esté en funcionamiento y proporcione exactamente lo que necesita en la búsqueda.
Cuando se ejecutan las pruebas funcionales, parece ser hermoso, se ejecuta de arriba a abajo en todo el inventario y el sistema nos dice que todo está bien para nosotros. Nuevamente, las pruebas se ejecutarán si las escribimos.
No. 11. Destruye
Realizamos pruebas, hay un informe de prueba de alguna forma, y ahora eliminamos toda la basura detrás de nosotros.
Automatización
La molécula es una gran herramienta. Ahora queda lo más simple: conectarle un sistema de integración continua para disfrutar de las pruebas automáticas de nuestros roles, lo cual hicimos.
Como en otros lugares, hay varias características.
Algunos de los roles que escribimos para automatizar algo son buenos, pero no podemos probar el sistema usando Travis, porque los roles implementan productos que no podemos compartir por razones de licencia.
Por ejemplo, tiene una implementación automatizada de una base de datos Oracle. Si coloca la base del instalador en un archivo, los abogados de la compañía acudirán a usted y lo jurarán enormemente. Para que todos vivan en paz y no juren, decidimos hacer lo siguiente.
- GitLab, en uno de sus últimos lanzamientos, aprendió a hacer CI para repositorios de terceros.
- El papel recae en el GitHub público, el mismo GitLab.com público está conectado a él, en el que indicamos: "Estimado GitLab, recójanos el CI para el repositorio externo".
- Los corredores privados están atornillados a GitLab, en un perímetro cerrado, y ya tienen acceso a binarios, que pueden implementar.
De hecho, el papel recae públicamente, los datos también, y no estamos engañando a nadie: ejecutamos pruebas reales con herramientas reales.
Echemos un vistazo a los pasos de cómo se ve en Travis.
Travis
Los pasos:
- En el primer paso, la octava línea, le decimos a Travis que no solo queremos lanzarlo, sino que también usamos el servicio Docker para que Docker esté disponible dentro de Travis.
- Luego, la décima línea, tomamos nuestras reglas de pelusa. No solo utilizamos las reglas de pelusa Ansible predeterminadas, sino que también escribimos las nuestras.
- En la línea 15, primero llamamos a lint para ahorrar tiempo al ejecutar la matriz de prueba. Si algo no está escrito de acuerdo con las reglas, y la pelusa no lo encuentra, entonces va al principio y deja un informe. Un desarrollador que confirma, repara su confirmación o descarta los cambios. Cuando se repare, déjelo venir y continuaremos con la prueba.
CI público
El CI público parece elemental.
Desde GitHub, una flecha hacia Travis, dentro de la cual viven Molecule y Docker.
CI privado
Para la parte privada de GitLab, todo es igual.
En el perímetro privado, corremos un corredor, y la imagen se ve más divertida.
El código pasa de GitHub a GitLab, en algún lugar donde se ejecuta un corredor privado, que puede extraer servicios externos, por ejemplo, ejecutar algo en Amazon.
Un poco de digresión. Iniciar e implementar un entorno de prueba en Amazon no desea ser portado, porque necesita claves. Encontrar mecanismos para ponerlos en público, pero al mismo tiempo no convertirse en la próxima plataforma de inicio para la minería, esta es una tarea no trivial. Por lo tanto, no lo resolvimos, pero tomamos el corredor en privado para no extraer bitcoins de Amazon.
Incluso aquí, éramos un poco flojos e hicimos lo siguiente. En EPAM tenemos nuestra propia nube privada y es híbrida. Esto significa que se puede acceder a muchas nubes públicas desde la nube interna, como las regiones. No puede escribir mil pruebas, pero juegue con las regiones y diga: "Ahora pruebe de acuerdo con este escenario de prueba para la región AWS, EPAM Cloud, Azure".
Galaxia ansible
Llegamos al final, nuestro papel es verde, hermoso, lo publicaremos en Galaxy.
Esta es una operación simple:
- La llamada webhook que está en Travis.
- En este caso, Travis se activará, CI se ejecutará nuevamente.
- Llamar a webhook.
- La nueva versión crecerá con éxito en Galaxy.
Hay una característica: si no marca un rol, no lo etiqueta, no le asigna una versión, entonces en Galaxy siempre estará sin una versión. Tan pronto como otro desarrollador quiera instalarlo él mismo a través de la instalación de Ansible Galaxy, eliminará el rol que se encuentra en la rama maestra, o en otra rama por defecto. Por defecto, la rama no siempre es estable, lo cual es inconveniente.
Si publica algo en Galaxy, no olvide etiquetarlo, de manera que haya versiones, y todo fue genial.
Patrones
Estoy compartiendo un pequeño truco: para no copiar y pegar cada vez que escribimos un nuevo rol, decidimos crear plantillas y un repositorio separado en el que colocamos la plantilla para escribir rápidamente roles desde cero.
La plantilla tiene una configuración predeterminada para Ansible lint y GitHub issue_template. Todo es de dominio público, por lo tanto, issue_template en una forma hermosa también fue hermoso para nosotros emitir solicitudes de extracción o informes de errores. Agregamos plantillas para Gitignore, Gitlab-ci y una licencia al mismo repositorio.
Por defecto, publicamos bajo la licencia Apache 2.0. Si quiere venir a nosotros y reutilizar las plantillas, puede quitar todo, crear un repositorio cerrado y no explicar nada a nadie. Gracias apache
Tenemos varias opciones de prueba para que pueda patear y comenzar todo rápidamente.
Resumen
No habrá conclusiones, en cambio, hay enlaces a
mi GitHub , mi
perfil Galaxy ,
GitHub Lean Delivery y
Ansible Galaxy . Usando los enlaces puedes ver cómo funciona todo. Todos los ejemplos están disponibles gratuitamente.
La próxima conferencia de DevOps se llevará a cabo en mayo.
Mientras esperamos el evento, suscríbase al canal y al boletín de YouTube . El canal se repondrá con los registros de los mejores informes, y en la lista de correo habrá selecciones de materiales útiles, transcripciones y noticias de DevOps.
Suscríbete, será interesante :)