Todo el poder de GitLab CI en la demostración de libros de jugadas Ansible con la infraestructura como enfoque de código.
GitLab CI es una herramienta eficaz para una amplia variedad de escenarios, incluida la infraestructura como código. GitLab se puede usar con diferentes herramientas, pero en esta demostración tomaremos Ansible, porque es precisamente eso lo que los desarrolladores usan con mayor frecuencia al abordar la "infraestructura como código". Aquí hay una demostración con dos enrutadores del curso en redes Ansible .
La belleza de GitLab CI es que el código del libro de jugadas de Ansible se puede modificar y entregar sin instalar localmente ninguna dependencia. Un proyecto de demostración que hace que las cadenas SNMP se actualicen en todos los dispositivos cada mes de acuerdo con nuestra política de seguridad se puede completar por completo en GitLab.com , nuestro servicio de alojamiento de códigos.
Para comenzar, abra el libro de jugadas de Ansible, donde hay 4 tareas:
- Recopilar datos sobre enrutadores: recopilar datos sobre enrutadores.
- Versión de pantalla - versión de pantalla
- Mostrar número de serie
- Configurar SNMP: configure SNMP.
En esta demostración, nos centraremos en la configuración de cadenas SNMP, para lo cual deberá seguir algunos pasos simples.
Comenzando desde el tablero de tareas
Cualquier plan en GitLab comienza de la misma manera: con una tarea . Entonces, el primer paso del flujo de trabajo de GitLab es verificar el tablero de tareas en el proyecto ansible-demo . En el tablero de tareas de ansible-demo, ya vemos la tarea: cambiar las líneas SNMP en todos los enrutadores . La tarea tiene un enlace a la página wiki de la política de seguridad de GitLab, donde dice que las líneas SNMP deben actualizarse todos los meses, y para las operaciones de solo lectura y lectura y escritura, debe haber diferentes líneas.
La política de seguridad de GitLab prescribe la actualización de cadenas SNMP cada mes.
Luego, debe verificar que los comandos para configurar cadenas SNMP en la demostración con dos enrutadores no violen la política de seguridad de GitLab descrita en la tarea.
Los comandos para configurar cadenas SNMP están disponibles en el libro de jugadas de Ansible.
Luego regrese a la tarea, asígnela a usted mismo y cambie el acceso directo de to-do a doing en el panel derecho o simplemente arrastre la tarea en el tablero de una columna a otra.
Crear una solicitud de fusión
Ahora necesita crear una solicitud de fusión a partir de la tarea. Asegúrese de que la solicitud de fusión tenga un indicador de Trabajo en curso (WIP) para que no ingrese al asistente prematuramente. En lugar de conectarnos localmente, usamos el IDE web de GitLab porque los cambios en las líneas SNMP son menores.
- Abra la sección de demostración de CI / CD.
- Ve al libro de jugadas de Ansible.
- Cambie la sección SNMP de la siguiente manera:
- Tenga en cuenta que se configuran diferentes líneas para RO y RW de acuerdo con la política de seguridad de GitLab descrita en la tarea .
Comprometer comprometer
Actualizó la línea SNMP de acuerdo con las instrucciones, y ahora necesita confirmar los cambios. Abra una comparación de cambios paralelos para asegurarse de que la solicitud de fusión contenga la última confirmación.
La herramienta de comparación paralela muestra visualmente los cambios.
Resultados
La confirmación de los cambios iniciará automáticamente la canalización de GitLab CI. Realizará las siguientes tareas:
- Verificación de sintaxis
- La prueba corre.
- Pruebas de cambios en un laboratorio / ambiente artificial.
Vemos el progreso y la salida de cada trabajo en la tubería de GitLab CI que actualiza SNMP.
El resultado de su tarea muestra que las actualizaciones de SNMP en el entorno artificial tuvieron éxito.
Todas estas tareas se iniciarán y documentarán en la solicitud de fusión.
Las marcas de verificación indican que la tarea en la canalización de GitLab CI se ha completado.
Luego inicie sesión en los enrutadores para una demostración y vea los cambios.
Los cambios en las cadenas SNMP RO y RW se reflejan en los enrutadores.
Revisión de solicitud de fusión
Puede realizar un paso adicional: la aprobación de la solicitud de fusión . Si configura la aprobación, varios usuarios podrán verificar los cambios antes de que entren en producción.
La solicitud de fusión se puede configurar para que otro usuario verifique sus trabajos antes de que aparezcan en el asistente.
Transferencia al maestro
Los cambios se pueden enviar al asistente inmediatamente después de la prueba. Un asistente es la rama principal que contiene el código del espacio de trabajo.
Cuando esté listo, haga clic en el botón Resolve Work In Progress . Luego haga clic en Merge .
Cuando habilita el estado de WIP, la solicitud de fusión se puede enviar al asistente y la tarea se puede cerrar.
La nueva tubería ejecutará todas las pruebas que realizó en el paso adicional de lanzar el libro de jugadas en producción.
Mantenga un registro del progreso y los registros en la pantalla de la tubería. Cuando finalice el proceso, inicie sesión en los enrutadores en funcionamiento y verifique que las líneas SNMP hayan cambiado.
Magic GitLab CI
Todo esto es posible gracias a la magia de GitLab CI. Las canalizaciones de GitLab CI son una serie de tareas secuenciales que realizan todo lo necesario para probar e implementar el código Ansible.
La configuración completa de GitLab CI cabe en un archivo YAML simple, que se almacena en el .gitlab-ci.yml .
En esta demostración, el .gitlab-ci.yml contiene 3 pasos.
- Implementar (Implementación): crea una red simulada con dos enrutadores en AWS con Ansible.
- Demostración: realiza un libro de jugadas que cambiará las líneas SNMP.
- Destruir: destruye una red simulada con dos enrutadores.
GitLab CI comienza con una imagen básica. En este caso, utilizamos la imagen Docker, que contiene todo el código necesario y las dependencias Ansible. Indique los comandos que se ejecutarán en cada etapa y las dependencias.
Un archivo YAML simple contiene tres etapas de GitLab CI.
La fase de demostración de GitLab CI, que ejecuta el libro de jugadas Ansible.
Analizamos el interior de la tubería y vimos cómo puede usar GitLab CI para crear una infraestructura como código sin siquiera instalar dependencias Ansible en su computadora. Este es solo un ejemplo de cómo GitLab CI se puede utilizar para implementar infraestructura como código. Vea el video para una guía completa: