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

God dag

Vi har flere skyklynger med et stort antall virtuelle maskiner i hver. Vi er vertskap for hele denne virksomheten hos Hetzner. I hver klynge har vi én hovedmaskin, et øyeblikksbilde tas fra den og distribueres automatisk til alle virtuelle maskiner i klyngen.

Dette opplegget tillater oss ikke å bruke gitlab-runners normalt, siden det oppstår mange problemer når mange identiske registrerte løpere dukker opp, noe som fikk oss til å finne en løsning og skrive denne artikkelen/manualen.

Dette er sannsynligvis ikke beste praksis, men denne løsningen virket så praktisk og enkel som mulig.

For veiledningen, se kat.

Nødvendige pakker på hovedmaskinen:

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

Det generelle prinsippet for å implementere automatisk gut pull på alle virtuelle maskiner er at du trenger en maskin som Ansible skal installeres på. Fra denne maskinen vil ansible sende git pull-kommandoer og starte tjenesten som har blitt oppdatert på nytt. For disse formålene opprettet vi en separat virtuell maskin utenfor klyngene og installerte på den:

• python
• ansible
• gitlab-runner

Fra organisatoriske spørsmål - du må registrere gitlab-runner, lage ssh-keygen, laste opp den offentlige ssh-nøkkelen til denne maskinen til .ssh/authorized_keys på mastermaskinen, åpne port 22 for ansible på mastermaskinen.

La oss nå konfigurere ansible

Siden vårt mål er å automatisere alt som er mulig. I fil /etc/ansible/ansible.cfg vi vil oppheve kommentaren til linjen host_key_checking = Falseslik at ansible ikke ber om bekreftelse på nye maskiner.

Deretter må du automatisk generere en inventarfil for ansible, hvorfra den vil ta ip-en til maskinene du trenger å gjøre git pull på.

Vi genererer denne filen ved å bruke Hetzners API, du kan ta listen over verter fra AWS, Asure, databasen din (du har en API et sted å vise kjørende maskiner, ikke sant?).

Strukturen til inventarfilen er veldig viktig for Ansible; den skal se slik ut:

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

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

For å generere en slik fil, lager vi et enkelt skript (la oss kalle 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 på tide å sjekke at Ansible fungerer og er vennlig med å motta IP-adresser:

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

Utdataene skal inneholde vertsnavnene til maskinene som kommandoen ble utført på.
Noen få ord om syntaks:

• /etc/ansible/./vm_list - generer en liste over maskiner
• -i - absolutt bane til inventarfilen
• -m - fortelle ansible å bruke skallmodulen
• -a er argumentet. Enhver kommando kan legges inn her
• gruppe — navnet på klyngen din. Hvis du trenger å gjøre dette på alle klynger, endre gruppe til alle

La oss gå videre - la oss prøve å gjøre git pull på våre 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 utdataene allerede ser oppdatert eller lossing fra depotet, fungerer alt.

Nå er det dette det hele var ment for

La oss lære skriptet vårt å kjøre automatisk når vi forplikter oss til mastergrenen i gitlab

Først, la oss gjøre skriptet vårt vakrere og legge det i en kjørbar fil (la oss kalle det exec_pull) -

#!/bin/bash

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

La oss gå til gitlaben vår og lage en fil i prosjektet .gitlab-ci.yml
Vi legger følgende inni:

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 klart. Nå -

• forplikte seg
• Jeg er glad for at alt fungerer

Når du overfører .yml til andre prosjekter, trenger du bare å endre navnet på tjenesten som skal startes på nytt og navnet på klyngen som de aktuelle kommandoene skal utføres på.

Kilde: www.habr.com