
Goddag
Vi har flere cloudklynger med et stort antal virtuelle maskiner i hver. Alt dette hostes hos Hetzner. I hver klynge har vi en mastermaskine, fra hvilken der tages et snapshot, som automatisk distribueres til alle virtueller inden for klyngen.
Denne metode tillader os ikke at bruge gitlab-runnerne ordentligt, da der opstår mange problemer, når der optræder mange identiske registrerede runners, hvilket har motiveret os til at finde en omvej og skrive denne artikel/manual.
Det er sandsynligvis ikke best practice, men denne løsning virker ganske praktisk og simpel.
Du kan finde tutorialen under kat.
Nødvendige pakker på mastermaskinen:
- python
- git
- fil med ssh-nøgler
Det generelle princip for at implementere automatisk git pull på alle virtuelle maskiner er, at vi skal have en maskine, hvor Ansible er installeret. Fra denne maskine vil ansible sende git pull-kommandoer og genstarte den opdaterede service. Vi har oprettet en separat virtuel maskine til dette formål uden for klyngerne, og installeret:
- python
- ansible
- gitlab-runner
Fra organisatoriske spørgsmål – det er nødvendigt at registrere gitlab-runner, lave ssh-keygen, og tilføje den offentlige ssh-nøgle fra denne maskine til .ssh/authorized_keys på mastermaskinen, åbne port 22 på mastermaskinen for ansible.
Lad os nu konfigurere ansible
Da vores mål er at automatisere alt, hvad der er muligt. I filen /etc/ansible/ansible.cfg skal vi fjerne kommenteringen af linjen host_key_checking = False, så ansible ikke beder om bekræftelse af nye maskiner.
Dernæst er det nødvendigt automatisk at generere en inventarfil til ansible, hvorfra den vil tage ip-adresserne for maskinerne, hvor git pull skal udføres.
Vi genererer denne fil ved hjælp af Hetzner's API, men du kan tage listen over værter fra din AWS, Azure, database (for du har vel et API til at vise dine kørende maskiner, ikke?).
For Ansible er strukturen af inventarfilen meget vigtig, den skal være som følgende:
[gruppe]
ip-adresse
ip-adresse
[gruppe2]
ip-adresse
ip-adresseFor 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_ipDet er tid til at tjekke, om ansible fungerer og kan kommunikere med ip-adressehentningen:
/etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'hostname' group
I outputtet skal vi få værtsnavne på de maskiner, hvor kommandoen er udført.
Et par ord om syntaksen:
- /etc/ansible/./vm_list — генерируем список машин
- -i — den absolutte sti til inventarfilen
- -m — vi beder ansible om at bruge shell modulet
- -a — argument. Her kan du skrive hvilken som helst kommando
- group — navnet på klyngen din. Hvis du skal gøre det på alle klynger, ændrer vi group til all
Lad os fortsætte — 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 ser already up to date eller en udlæsning fra repository'et i output, så fungerer det hele.
Nu til det, det hele handler om
Lad os lære vores script at køre automatisk ved commit i master-gren i gitlab
Først skal vi gøre vores script pænere og putte det i en eksekverbar fil (lad os kalde den exec_pull) —
#!/bin/bash
/etc/ansible/./get_vms && ansible -i /etc/ansible/cloud_ip -m shell -a "$@" Lad os gå ind i vores gitlab og oprette en fil i projektet .gitlab-ci.yml
Indsæt følgende:
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 —
- lav en commit
- lad os håbe, at alt fungerer
Når .yml overføres til andre projekter, er det nok bare at ændre navnet på servicen for genstart og navnet på klyngen, hvor ansible-kommandoerne skal køres.
Kilde: habr.com
