Ansible + auto git pull en el clúster de máquinas virtuales en la nube

Buen dia

Tenemos varios clústeres en la nube con una gran cantidad de máquinas virtuales en cada uno. Todo este negocio está alojado en Hetzner'e. En cada clúster, tenemos una máquina maestra, se toma una instantánea y se distribuye automáticamente a todas las máquinas virtuales dentro del clúster.

Este esquema no nos permite usar gitlab-runners normalmente, ya que surgen muchos problemas cuando aparecen muchos corredores registrados idénticos, lo que nos llevó a encontrar una solución alternativa y escribir este artículo / manual.

Probablemente esta no sea la mejor práctica, pero esta solución parecía lo más conveniente y simple posible.

Para el tutorial, pido un gato.

Paquetes requeridos en la máquina maestra:

• pitón
• git
• archivo con claves ssh

El principio general de implementar la extracción automática del intestino en todas las máquinas virtuales es que necesita una máquina en la que se instalará Ansible. Desde esta máquina, ansible enviará comandos git pull y reiniciará el servicio que se ha actualizado. Creamos una máquina virtual separada fuera de los clústeres para estos fines, y la instalamos en ella:

• pitón
• ansible
• gitlab-runner

Por cuestiones de organización: debe registrar gitlab-runner, hacer ssh-keygen, colocar la clave ssh pública de esta máquina en .ssh/authorized_keys en la máquina maestra, abrir el puerto 22 para ansible en la máquina maestra.

Ahora configure ansible

Dado que nuestro objetivo es automatizar todo lo que sea posible. En el archivo /etc/ansible/ansible.cfg descomentamos la línea host_key_checking = False para que ansible no solicite confirmación de nuevas máquinas.

A continuación, debe generar automáticamente un archivo de inventario para ansible, desde donde recogerá la ip de las máquinas en las que necesita hacer git pull.

Generamos este archivo utilizando la API de Hetzner, pero puede tomar la lista de hosts de su base de datos AWS, Asure (tiene una API en algún lugar para mostrar sus máquinas en ejecución, ¿verdad?).

La estructura del archivo de inventario es muy importante para Ansible, su apariencia debe ser la siguiente:

 [] ip- ip- [2] ip- ip- 

Para generar dicho archivo, hagamos un script simple (llamémoslo vm_list ):

 #!/bin/bash echo [group] > /etc/ansible/cloud_ip && " CLI    IP    " >> /etc/ansible/cloud_ip echo " " >> /etc/ansible/cloud_ip echo [group2] > /etc/ansible/cloud_ip && " CLI    IP     " >> /etc/ansible/cloud_ip 

Es hora de verificar que ansible funcione y sea amigo del destinatario de las direcciones IP:

 /etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'hostname' group 

La salida debe recibir los nombres de host de las máquinas en las que se ejecutó el comando.
Algunas palabras sobre la sintaxis:

• /etc/ansible/./vm_list - genera una lista de máquinas
• -i: ruta absoluta al archivo de inventario
• -m: dile al ansible que use el módulo de shell
• -a es un argumento. Cualquier equipo puede ser ingresado aquí.
• grupo es el nombre de su clúster. Si necesita hacerlo en todos los clústeres, cambie el grupo a todos

Adelante, intenta hacer git pull en nuestras máquinas virtuales:

 /etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'cd /path/to/project && git pull' group 

Si vemos ya actualizado o descargando desde el repositorio en la salida, entonces todo funciona.

Ahora para qué estaba destinado todo

Enseñamos que nuestro script se ejecute automáticamente cuando se confirma en la rama maestra en gitlab

Primero, haremos que nuestro script sea más hermoso y lo colocaremos en un archivo ejecutable (llamémoslo exec_pull):

 #!/bin/bash /etc/ansible/./get_vms && ansible -i /etc/ansible/cloud_ip -m shell -a "$@" 

Vamos a nuestro gitlab y en el proyecto creamos el archivo .gitlab-ci.yml
Dentro ponemos lo siguiente:

 variables: GIT_STRATEGY: none VM_GROUP: group stages: - pull - restart run_exec_pull: stage: pull script: - /etc/ansible/exec_pull 'cd /path/to/project/'$CI_PROJECT_NAME' && git pull' $VM_GROUP only: - master run_service_restart: stage: restart script: - /etc/ansible/exec_pull 'your_app_stop && your_app_start' $VM_GROUP only: - master 

Todo esta listo. Ahora

• hacer compromiso
• alegrarse de que todo funciona

Al portar .yml a otros proyectos, solo necesita cambiar el nombre del servicio para reiniciar y el nombre del clúster en el que se ejecutarán los comandos ansibles.