Ansible + auto git pull dans un cluster de machines virtuelles dans le cloud

Bonjour

Nous avons plusieurs clusters cloud contenant un grand nombre de machines virtuelles dans chacun. Tout cela est hébergé chez Hetzner. Dans chaque cluster, nous avons une machine maître, dont un snapshot est automatiquement diffusé à toutes les machines virtuelles du cluster.

Ce schéma ne nous permet pas d'utiliser correctement les gitlab-runners, car il y a beaucoup de problèmes liés à l'apparition d'un grand nombre de runners enregistrés identiques, ce qui a conduit à la recherche d'une solution alternative et à la rédaction de cet article / manuel.

C'est probablement pas la meilleure pratique, mais cette solution semble être la plus pratique et simple.

Pour le tutoriel, je vous invite à suivre le lien.

Packages nécessaires sur la machine maître :

• python
• git
• fichier avec des clés ssh

Le principe général de la mise en œuvre d'un git pull automatique sur toutes les machines virtuelles est qu'il faut une machine sur laquelle Ansible sera installé. À partir de cette machine, ansible enverra des commandes git pull et redémarrera le service qui a été mis à jour. Nous avons créé pour cela une machine virtuelle séparée en dehors des clusters et y avons installé :

• python
• ansible
• gitlab-runner

Concernant les questions organisationnelles – il est nécessaire d'enregistrer le gitlab-runner, de faire un ssh-keygen, de placer la clé ssh publique de cette machine dans .ssh/authorized_keys sur la machine maître, d'ouvrir le port 22 sur la machine maître pour ansible.

Maintenant, configurons ansible

Étant donné que notre objectif est d'automatiser tout ce qui est possible. Dans le fichier /etc/ansible/ansible.cfg nous décommenterons la ligne host_key_checking = False, afin qu'ansible ne demande pas de confirmation pour les nouvelles machines.

Ensuite, il est nécessaire de générer automatiquement un fichier d'inventaire pour ansible, à partir duquel il récupérera les adresses IP des machines sur lesquelles il doit effectuer le git pull.

Nous générons ce fichier à l'aide de l'API d'Hetzner, vous pouvez prendre la liste des hôtes depuis votre AWS, Azure, base de données (vous avez bien un API quelque part pour afficher vos machines en cours d'exécution, n'est-ce pas ?).

Pour Ansible, la structure du fichier d'inventaire est très importante, elle doit être la suivante :

[groupe]
ip-address
ip-address

[groupe2]
ip-address
ip-address

Pour générer un tel fichier, nous allons faire un petit script (appelons-le 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

Il est temps de vérifier qu'ansible fonctionne et qu'il est compatible avec la récupération des adresses IP :

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

Dans la sortie, nous devons obtenir les noms d'hôte des machines sur lesquelles la commande a été exécutée.
Quelques mots sur la syntaxe :

• /etc/ansible/./vm_list — генерируем список машин
• -i — chemin absolu vers le fichier d'inventaire
• -m — indiquer à Ansible d'utiliser le module shell
• -a — argument. Ici, vous pouvez entrer n'importe quelle commande
• groupe — le nom de votre cluster. Si vous devez le faire sur tous les clusters, remplacez groupe par all

Continuons — essayons de faire un git pull sur nos des machines virtuelles:

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

Si dans la sortie nous voyons already up to date ou un tirage du dépôt, cela signifie que tout fonctionne.

Maintenant, passons à ce pourquoi tout cela a été conçu

Nous allons rendre notre script automatiquement exécutable lors d'un commit sur la branche master dans gitlab

Tout d'abord, nous allons embellir notre script et l'enfermer dans un fichier exécutable (appelons-le exec_pull) —

#!/bin/bash

/etc/ansible/./get_vms && ansible -i /etc/ansible/cloud_ip -m shell -a "$@"

Allons dans notre gitlab et dans le projet, créons un fichier .gitlab-ci.yml
Mettez-y ce qui suit :

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 

Tout est prêt. Maintenant —

• faisons un commit
• espérons que tout fonctionne

Lors de la migration du .yml vers d'autres projets, il suffit de changer le nom du service pour le redémarrage et le nom du cluster sur lequel les commandes ansible seront exécutées.

Source : habr.com