Ansible + auto git pull i en klynge af virtuelle maskiner i skyen

Ansible + auto git pull i en klynge af virtuelle maskiner i skyen

God dag

Vi har flere cloud-klynger med et stort antal virtuelle maskiner i hver. Vi er vært for hele denne forretning hos Hetzner. I hver klynge har vi en mastermaskine, et snapshot tages fra den og distribueres automatisk til alle virtuelle maskiner i klyngen.

Dette skema tillader os ikke at bruge gitlab-runners normalt, da der opstår mange problemer, når mange identiske registrerede løbere dukker op, hvilket fik os til at finde en løsning og skrive denne artikel/manual.

Dette er nok ikke bedste praksis, men denne løsning virkede så praktisk og enkel som muligt.

For selvstudiet, se venligst kat.

Nødvendige pakker på mastermaskinen:

  • python
  • git
  • fil med ssh-nøgler

Det generelle princip for at implementere automatisk gut pull på alle virtuelle maskiner er, at du har brug for en maskine, som Ansible vil blive installeret på. Fra denne maskine vil ansible sende git pull-kommandoer og genstarte den service, der er blevet opdateret. Til disse formål oprettede vi en separat virtuel maskine uden for klyngerne og installerede på den:

  • python
  • ansible
  • gitlab-runner

Fra organisatoriske spørgsmål - du skal registrere gitlab-runner, lave ssh-keygen, uploade den offentlige ssh-nøgle på denne maskine til .ssh/authorized_keys på mastermaskinen, åbn port 22 for ansible på mastermaskinen.

Lad os nu konfigurere ansible

Da vores mål er at automatisere alt, hvad der er muligt. I fil /etc/ansible/ansible.cfg vi afkommenterer linjen host_key_checking = Falseså ansible ikke beder om bekræftelse af nye maskiner.

Dernæst skal du automatisk generere en inventory-fil til ansible, hvorfra den vil tage ip'en af ​​de maskiner, som du skal lave git pull på.

Vi genererer denne fil ved hjælp af Hetzners API, du kan tage listen over værter fra din AWS, Asure, database (du har en API et sted til at vise dine kørende maskiner, ikke?).

Strukturen af ​​inventarfilen er meget vigtig for Ansible; den skulle se sådan ud:

[группа]
ip-адрес
ip-адрес

[группа2]
ip-адрес
ip-адрес

For at generere en sådan fil laver vi et simpelt script (lad os kalde det 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

Det er tid til at kontrollere, at Ansible fungerer og er venlig med at modtage IP-adresser:

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

Outputtet skal indeholde værtsnavnene på de maskiner, hvorpå kommandoen blev udført.
Et par ord om syntaks:

  • /etc/ansible/./vm_list - generer en liste over maskiner
  • -i - absolut sti til inventarfilen
  • -m - fortæl ansible at bruge shell-modulet
  • -a er argumentet. Enhver kommando kan indtastes her
  • gruppe — navnet på din klynge. Hvis du har brug for at gøre dette på alle klynger, skal du ændre gruppe til alle

Lad os gå videre - lad os prøve at lave git pull på vores virtuelle maskiner:

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

Hvis vi i outputtet allerede ser opdateret eller aflæsning fra depotet, så fungerer alt.

Det er nu det, det hele var beregnet til

Lad os lære vores script at køre automatisk, når vi forpligter os til mastergrenen i gitlab

Lad os først gøre vores script smukkere og lægge det i en eksekverbar fil (lad os kalde det exec_pull) -

#!/bin/bash

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

Lad os gå til vores gitlab og oprette en fil i projektet .gitlab-ci.yml
Vi lægger følgende indeni:

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 

Alt er klar. Nu -

  • forpligte sig
  • Jeg er glad for, at alt fungerer

Når du overfører .yml til andre projekter, skal du blot ændre navnet på den service, der skal genstartes, og navnet på den klynge, hvorpå de mulige kommandoer vil blive udført.

Kilde: www.habr.com

Tilføj en kommentar