Michael DeHaan es el hombre que creó Ansible. Muchas de las cosas que los administradores de sistemas, la versión y los ingenieros de DevOps hacen regularmente son, por decirlo suavemente, poco interesantes. DeHaan quiere que estas personas liberen su tiempo para cosas más interesantes (en el trabajo o fuera de la puerta de la oficina) y escriban un código de producto que libere el tiempo del administrador.
Más tiempo, menos adrenalina durante el horario comercial, menos guiones y menos errores.
Por cierto, puede terminar de leer este párrafo conectándose a livestream el 6 de junio
aquí .
Si aún seguías leyendo ...
Ansible: Integración continua y entrega
Ansible es un poderoso lenguaje de automatización de código abierto. Sí, es excelente no solo para la administración, sino también para la implementación y la orquestación de los sistemas de TI. Ansible se creó originalmente para resolver eficazmente una amplia gama de tareas de automatización y como una base universal simple para reemplazar los controles tradicionales, pero al final resultó ser muy útil en muchas áreas. Por ejemplo, al tiempo que garantiza un tiempo de inactividad cero durante la integración continua y la entrega de aplicaciones (CI / CD). Por lo general, este problema se resuelve debido al refinamiento extenso del software, el uso de varios paquetes de software y muchos trucos únicos para cada configuración específica. Ansible fue originalmente diseñado específicamente para tales escenarios de orquestación y ofrece una solución llave en mano "todo en uno".
Integración continua y entrega de aplicaciones (CI / CD)
Algunas verdades comunes. La práctica de desarrollar sistemas de software en los últimos 10 años muestra que el largo ciclo de vida de las versiones de software (modelo de desarrollo en cascada) tiene una sobrecarga mucho mayor en comparación con un ciclo corto (el llamado desarrollo "iterativo" o ágil). Se trata de una arritmia: cuando los programadores recién comienzan a trabajar en una nueva versión, el personal de TI responsable de las pruebas y la implementación simplemente no tiene nada que hacer. Pero cuanto más se acerca la versión al lanzamiento, más ocupados están los profesionales de TI y más a menudo los programadores tienen que cambiar los contextos, alternando entre trabajar en errores y planificar la próxima versión.
Además, un ciclo largo aumenta el intervalo entre la identificación y la eliminación de errores de software y deficiencias, lo cual es especialmente crítico para grandes sistemas web con una audiencia de usuarios multimillonaria. Por lo tanto, la industria del software está adoptando rápidamente metodologías ágiles bajo el lema "lanzar más rápido y con más frecuencia" para que los participantes en el proceso de desarrollo puedan cambiar su contexto de trabajo con menos frecuencia y crear, depurar e implementar mejoras e innovaciones mucho más rápido.
La automatización del control de calidad, el desarrollo de TDD a través de pruebas y otras técnicas relacionadas aumentan aún más la efectividad de los nuevos métodos de trabajo. ¿Dónde está la automatización? ¿Dónde están las tecnologías que hacen que los engranajes giren más rápido y reducen la participación humana al mínimo estrictamente necesario?
Y aquí, por ejemplo, la torre Ansible y Ansible Tower de Red Hat para orquestar sistemas de TI como parte de los procesos modernos de desarrollo de software.
Tiempo de inactividad cero
Un poco más obvio. El tiempo de inactividad significa ganancias perdidas y clientes insatisfechos. Por lo tanto, en los sistemas de colas web, cuyos usuarios se distribuyen en todas las zonas horarias, el apagado programado solo se permite en casos realmente graves, cuya lista no incluye explícitamente la actualización de las versiones de la aplicación. La situación es similar en entornos corporativos donde la inaccesibilidad de una intranet o un sistema de contabilidad reduce drásticamente la productividad de los empleados. Por lo tanto, cualquier automatización de procesos debe proporcionar actualizaciones sin interrumpir las operaciones, en otras palabras, con un tiempo de inactividad cero.
Es muy posible lograr un tiempo de inactividad cero, pero para esto necesitamos herramientas apropiadas, como proporcionar una orquestación avanzada, de múltiples niveles y etapas, como, por ejemplo, el sistema Ansible.
Sistemas de construcción de aplicaciones
La entrega continua (CD) comienza con la integración continua (CI). Un sistema que supervisa los repositorios de código fuente en busca de cambios, ejecuta independientemente las pruebas correspondientes y crea automáticamente (e idealmente prueba) una nueva versión de la aplicación con cada actualización de código, por ejemplo, el proyecto Jenkins (jenkins.io).
Para transmitir el testigo al sistema de CD después de ensamblar con éxito la nueva versión de la aplicación, el subsistema de compilación del sistema CI puede llamar a Ansible para proporcionar de inmediato esta nueva versión a aquellos que realizan pruebas de unidad o integración. En particular, Jenkins puede usar Tower para desplegar ensamblajes en diversos entornos, y el entorno de prueba o intermedio se puede modelar en función del entorno de producción, lo que mejora en gran medida la previsibilidad durante todo el ciclo de vida del software. Los datos devueltos por Ansible de los resultados de la ejecución de scripts de automatización pueden estar directamente involucrados en los trabajos de Build Systems del sistema Tower. De hecho, Tower incluso le permite probar escenarios de implementación en un entorno intermedio antes de ejecutarlos en servidores de "combate".
Actualización de aplicaciones multinivel una por una
El sistema de CD debe poder organizar los procesos de actualización continua de las aplicaciones multinivel. Gracias a la arquitectura de inserción y las capacidades de la orquestación de múltiples niveles y múltiples etapas, Ansible puede hacer frente a esta tarea actualizando cualquier aplicación nivel por nivel, mientras intercambia datos entre ellos.
Para implementar actualizaciones una por una, Ansible utiliza scripts de Play que le permiten especificar con precisión el grupo de hosts de destino y asignar tareas (Rol) que deben realizarse en ellos. Por lo general, las tareas son anuncios de que un recurso de TI específico debe estar en un estado determinado, por ejemplo, para una versión de un software se debe instalar un paquete determinado y para otro es necesario verificar el repositorio de código. Las topologías de aplicaciones web, por regla general, requieren actualizarlas en un orden estricto, y aún no puede actualizar las aplicaciones y las configuraciones del sistema en todas las máquinas al mismo tiempo.
Cuando se reinicia el servicio, no está disponible por algún tiempo, y el reemplazo de la versión de la aplicación tampoco ocurre instantáneamente. Por lo tanto, antes de actualizar el sistema, lo retiramos del grupo de equilibrio. Como resultado, necesita la capacidad de automatizar las operaciones de conectar y desconectar máquinas del grupo. Consistentemente es la palabra clave. Ansible puede controlar con mucha precisión el tamaño de la ventana de una actualización sucesiva. Bueno, el desarrollo de tales actualizaciones se lleva a cabo con mucho cuidado, y si en algún momento ocurre una falla, la actualización se suspende para no deshabilitar el resto de la infraestructura de TI.
Implementación continua para scripts de automatización
Además de la funcionalidad de CD para servicios que operan en modo de operación comercial, también puede organizar la implementación continua de los propios scripts de automatización (conjuntos de instrucciones Ansible Playbook. No deje de leer, en la segunda parte habrá ejemplos de libros de jugadas). Esto permite a los administradores y desarrolladores del sistema administrar los scripts utilizando el repositorio de código fuente, probar estos scripts en un entorno intermedio y transferirlos automáticamente al entorno de producción en caso de un robo exitoso. En otras palabras, cuando trabaja con scripts, obtiene todas las ventajas metodológicas y de otro tipo del repositorio de código central al que está acostumbrado cuando desarrolla software.
Realizar cambios en el software y las configuraciones del sistema es una de las principales razones de las interrupciones no planificadas. Por lo tanto, además de las pruebas automatizadas, existe un control humano. Se puede organizar mediante la integración con un sistema de inspección de código como
Gerrit , y aplicar los cambios solo después de que sean aprobados por los camaradas responsables.
Actualizaciones alternativas y sistemas de equilibrio de carga.
Ansible funciona de manera muy independiente con los sistemas de equilibrio de carga cuando realiza actualizaciones sucesivas. Por lo tanto, simplemente puede escribir en un script de Playbook, en cualquier ciclo para un grupo de hosts, algo así como "realizar esta acción en el sistema X en nombre del host Y", y Ansible se encargará del resto.
Ansible interactúa bien con los equilibradores de carga de todo tipo y puede establecer un indicador para desconectar temporalmente un host para desactivar la supervisión de disponibilidad durante el período de actualización. El esquema simple "apagar el monitoreo - eliminar del grupo - actualizar el nivel de software deseado - regresar al grupo - activar el monitoreo" implementa fácilmente una actualización secuencial con tiempo de inactividad cero y sin falsas alarmas. Y todo esto en un modo totalmente automatizado, sin intervención del operador.
Pruebas intermedias integradas
Tower puede trabajar con varios archivos de inventario de recursos (Inventory), lo que facilita probar escenarios de actualización sucesivos en un entorno intermedio antes de ejecutarlos en servidores de "batalla". Para hacer esto, es suficiente simular el entorno de producción en el entorno de prueba, ejecutar Ansible con el parámetro "-i" e indicar qué archivo de inventario debe usarse al ejecutar el script, para el entorno de prueba o para el entorno de producción. El script en sí no necesita ser modificado.
Implementación de control de versiones
A algunas personas les gusta empacar aplicaciones junto con paquetes del sistema operativo (RPM, debs, etc.) más calientes, pero a menudo, especialmente para aplicaciones web, dicho empaque no es necesario. Por lo tanto, Ansible incluye varios módulos para implementar aplicaciones directamente desde los sistemas de control de versiones. En la secuencia de comandos de Playbook, puede escribir una reconciliación con el repositorio de código para la etiqueta o el número de versión especificados, después de lo cual Ansible verificará esta condición en todos los servidores de destino y activará los siguientes pasos solo si la versión necesita ser reemplazada, eliminando así reinicios de servicio innecesarios.
Integración con herramientas de monitoreo
Como un sistema de orquestación completo, Ansible admite la integración con sistemas de gestión de rendimiento de aplicaciones basados en APM a nivel de monitoreo. Por ejemplo, durante la fase de prueba de implementación o integración, debe instalar o actualizar el agente de software APM con la aplicación. Ansible tiene un papel especial para esto, y después de instalar y activar el agente, Ansible puede configurarlo en la pila de monitoreo APM (si aún no está configurado) para que los administradores de aplicaciones puedan verificar de inmediato que la nueva versión se ha instalado y funciona sin problemas .
Si algo salió mal después de actualizar la aplicación en el entorno de producción, las herramientas de monitoreo pueden llamar a Ansible para volver a la versión anterior. Por supuesto, solo si se permite dicha reversión.
Notificación de evento
En el paradigma de CI / CD, todos quieren recibir notificaciones de eventos lo más rápido posible. Ansible ofrece funciones integradas, incluido un módulo de correo electrónico, así como la integración con herramientas de notificación externas, como mensajería instantánea, redes sociales o sistemas de registro de eventos.
Implementación utilizando un modelo de estado de recursos
Una de las características clave de Ansible, que lo convierte en una herramienta muy útil para implementar aplicaciones, es el uso regular del modelo de estado de recursos en los procesos de actualización de software, que ha ganado popularidad en la gestión de las configuraciones del sistema. A diferencia de los controles tradicionales de código abierto, Ansible no necesita estar equipado con ningún software adicional o scripts especiales para organizar la entrega de la aplicación.
En Ansible, puede registrar y controlar con mucha precisión el orden de los eventos en diferentes niveles arquitectónicos, lo que le permite delegar acciones a otros sistemas, así como combinar directivas del modelo de recursos (como “el paquete X debe estar en estado Y”) y los comandos de script tradicionales (como “ejecutar script .sh ") dentro de un proceso.
Ansible también facilita la ejecución de verificaciones de diversas condiciones y la toma de decisiones en función de sus resultados. La combinación de los procesos de configuración del sistema y el despliegue de aplicaciones dentro de una sola cadena de herramientas es mucho más eficiente que un esquema con varias herramientas especializadas y, además, aumenta la coherencia de las políticas y aplicaciones del sistema operativo.
Prueba de implementación
Cuantas más oportunidades, mayor es la responsabilidad. La automatización de los procesos de entrega continua aumenta drásticamente el riesgo de implementar una configuración fallida en todos los nodos del sistema. Para reducir los riesgos, Ansible sugiere insertar pruebas de control en el script, lo que interrumpirá la actualización secuencial si algo sale mal. Para probar varias condiciones, incluido el estado del funcionamiento de los servicios, puede implementar pruebas arbitrarias utilizando los módulos Command o Script, e incluso crear tales pruebas como módulos Ansible separados.
El módulo Fail puede interrumpir la ejecución del script en el host en cualquier momento, lo que le permite detectar fallas en una etapa temprana de la actualización secuencial. Por ejemplo, debido a la diferencia entre el entorno intermedio y el entorno de producción, este último genera un error de configuración, que desactiva los servidores de "combate". En este caso, se puede registrar una salida de emergencia en el script de Playbooks en la primera etapa de la actualización secuencial. Y si tiene 100 servidores, y el tamaño de la ventana de actualización sucesiva es 10, una parada de emergencia de este tipo le dará tiempo para resolverlo con calma, corregir el script y continuar actualizando.
En caso de falla, Ansible no continúa trabajando, dejando los sistemas en un estado semiconfigurado, y genera un error para atraer la atención del operador y decirle qué host se produjo el ciclo de actualización con errores y cuántos cambios se realizaron en cada plataforma. Ansible tiene un modo de ejecución de simulación, cuando el sistema genera un informe sobre los cambios que se habrían realizado si el script se hubiera ejecutado sin su ejecución real.
Verificación de cumplimiento
Hay entornos donde las configuraciones cambian solo cuando no hay forma de hacerlo sin él. Cualquier cambio en dichos entornos se analiza previamente. Utiliza sistemas de entrega continua "con reservas".
Ansible tiene un modo de ejecución de simulación (activado por el indicador "--check"), cuando el sistema genera un informe sobre los cambios que se realizarían cuando se ejecutara el script. En este caso, la ejecución real del script no ocurre, la ejecución de la simulación no permite detectar errores, pero ayuda a comprender y analizar mejor los detalles y resultados de los cambios propuestos.
Por otro lado, incluso con el despliegue continuo de nuevos ensamblajes, Ansible le permite ejecutar verificaciones de conformidad con mucha más frecuencia para detectar el momento en que algunas cosas en el entorno de producción cambian como resultado de la intervención humana y deben corregirse ejecutando el script correspondiente de Ansible, por ejemplo, para cambiar versión de software, ajustar permisos, etc.
Despliegue de piloto automático
Si vives en un mundo de orquestación de múltiples niveles y múltiples etapas de procesos de actualización de software secuenciales con tiempo de inactividad cero, lo más probable es que CI / CD sea realizado exclusivamente por operadores (tanto manualmente como con automatización parcial) y requiera, como en un baile redondo, acciones coordinadas de todos los participantes del proceso. Ansible, junto con su arquitectura única y la ausencia de agentes de software en los hosts de destino (lo que aumenta la seguridad y elimina la necesidad de administrar el sistema de gestión en sí), puede describir y automatizar fácilmente procesos de implementación complejos, es decir, Ansible implementa el modo de piloto automático completo aquí.
Se pueden encontrar ejemplos de scripts de automatización Ansible en
GitHub , y ahora daremos una base y un ejemplo de cómo escribir un script de Playbook que se puede ejecutar en Ansible o Ansible Tower. Junto con una
lista de módulos y
otros documentos, ella lo ayudará a aprender cómo crear sus propios scripts de Playbooks.
¿Qué es un libro de jugadas?
Un script de Playbook es esencialmente un conjunto de jugadas que se envía para ejecutarse en un único host remoto o grupo de hosts. Es como una guía de ensamblaje de muebles de IKEA: siga las instrucciones exactamente y obtenga exactamente lo que vio en la tienda. Así funcionan los guiones.
Módulos
Crearemos un Playbook que instalará el servidor web en el host RHEL / CentOS 7 y crearemos un archivo index.html basado en la plantilla especificada en el script. El script de muestra que se muestra aquí está en pleno funcionamiento y listo para usar. A continuación, veremos un script de Playbook de ejemplo y mostraremos cómo usar los módulos.
Autores (Autores)
Un autor es alguien que crea instrucciones que serán ejecutadas por módulos (a menudo junto con valores adicionales: argumentos, ubicaciones, etc.). Los módulos se ejecutan en el host de destino en el orden en que se siguen en el script de Playbook (incluidos include'y y otros archivos adicionales incluidos en él). El estado del host cambia (o no cambia) según los resultados de la ejecución del módulo, que se muestran en forma de salida Ansible y Tower.
Ejecución de guiones de Playbook
Primero, hay algunas cosas que debe saber sobre la ejecución de scripts de Playbook. Playbook es un tipo de sistema simbólico que informa al módulo sobre la necesidad de realizar alguna tarea. Para iniciar con éxito su Playbook, es importante comprender los siguientes puntos:
1. Sistema de destino (Target)Debido a que los scripts de Playbook proporcionan instrucciones e interactúan con los módulos, Ansible cree que usted comprende lo que está tratando de hacer y simplemente lo automatiza. Es por eso que decimos que los Playbooks son como instrucciones o instrucciones: le dices a los elementos automatizados cómo quieres configurar la tarea. Pero al mismo tiempo, usted mismo debe comprender muy bien cómo funciona el host de destino en el que se ejecuta el script Playbook.
2. TareasSi necesita iniciar un servidor web en alguna parte de Playbook, debe comprender cómo se hace para saber qué módulo de servicio utilizar para esto e iniciar el servidor web por su nombre. Si Playbook instala el paquete de software, debe saber cómo hacerlo en el host de destino. También debe comprender, al menos en un nivel básico, la esencia de las tareas realizadas. ¿Se requiere una configuración de host adicional para el software que desea instalar? ¿Hay alguna rama dependiendo de las condiciones y valores de los argumentos? Si se pasan variables en el proceso, debe comprender exactamente qué y por qué.
Ejemplo de script de PlaybookEl siguiente ejemplo de secuencia de comandos de Playbook lo ayudará a comprender lo que acaba de leer. El host de destino en él es el servidor RHEL / CentOS 7, en el que nuestro script instala el servidor web NGINX, y luego crea el archivo index.html en el directorio raíz predeterminado. , -.
*: Playbook Ansible Tower inventory .Playbooks YAML (---), :
Name : , Playbook.
Hosts : , Ansible.
Become : , , nginx ( ).
1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true
Con la sangría como las tres líneas anteriores, están las
tareas : directiva, después de lo cual, con sangría adicional (de acuerdo con las reglas de anidamiento de YAML), se enumeran las tareas (jugadas). En este ejemplo, tenemos dos tareas, y ambas usan el módulo Yum. La primera tarea agrega un repositorio epel-release para que pueda instalar nginx. Después de que epel aparece en el sistema, la segunda tarea instala el paquete nginx.
La directiva
state : significa que Ansible debe verificar el estado del host de destino antes de realizar cualquier otra acción. En nuestro ejemplo, si ya hay un repositorio o nginx en el host, Ansible comprende que no es necesario realizar estas dos tareas y pasa a lo siguiente.
1 tasks: 2 - name: Add epel-release repo 3 yum: 4 name: epel-release 5 state: present 6 7 - name: Install nginx 8 yum: 9 name: nginx 10 state: present
La página de descarga, que se usa por defecto en nginx, es excelente para verificar que nginx se haya instalado correctamente, pero probablemente querrá hacer esto con su archivo html de inicio. En este ejemplo, por simplicidad, la plantilla del archivo de índice está en el mismo directorio donde se inicia el Playbook. El destino es solo la ruta predeterminada en nginix sin sitios configurados.
1 - name: Insert Index Page 2 template: 3 src: index.html 4 dest: /usr/share/nginx/html/index.html
La última línea de nuestro Playbook sirve solo para verificar que el servicio nginx se haya iniciado con éxito (o para iniciarlo si no).
1 - name: Start NGiNX 2 service: 3 name: nginx 4 state: started
El guión completo de Playbook tenía aproximadamente la misma longitud que el párrafo inicial de esta publicación:
1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 5 6 tasks: 7 - name: Add epel-release repo 8 yum: 9 name: epel-release 10 state: present 11 12 - name: Install nginx 13 yum: 14 name: nginx 15 state: present 16 17 - name: Insert Index Page 18 template: 19 src: index.html 20 dest: /usr/share/nginx/html/index.html 21 22 - name: Start NGiNX 23 service: 24 name: nginx 25 state: started
Resumen
Los scripts de Playbook son una manera fácil y conveniente de hacer muchas cosas con un pequeño código. En el ejemplo anterior, utilizamos tres módulos: mmm, plantilla y servicio, para instalar el repositorio y el paquete de software en el servidor, crear un archivo desde la plantilla local y luego iniciar el servicio que acaba de instalar. ¡Al mismo tiempo, nuestro guión de Playbook salió un poco más largo que esta oferta! Y aunque lo ejecutamos en un host, también podría hacerlo en docenas y cientos de servidores, para esto solo necesita hacer cambios muy pequeños. Además, Tower le permite colocar un script de Playbook en una plantilla de trabajo para ejecutar en un grupo de servidores en la nube de AWS o en un centro de datos corporativo.
Las características arquitectónicas y la capacidad de integrarse con los sistemas de CI, como Jenkins, automatizan no solo los procesos de gestión de la configuración, sino también una gama mucho más amplia de tareas de TI. Es por eso que llamamos cariñosamente a Ansible un sistema de orquestación integrado, y no solo una herramienta de administración de configuración y despliegue de software.