Head päeva
Meil on mitu pilveklastrit, millest igaühes on suur hulk virtuaalmasinaid. Me võõrustame kogu seda ettevõtet Hetzneris. Igas klastris on meil üks peamasin, sellest tehakse hetktõmmis ja jaotatakse automaatselt kõikidele klastri virtuaalsetele masinatele.
See skeem ei võimalda meil gitlab-runnereid tavapäraselt kasutada, kuna paljude identsete registreeritud jooksjate ilmumisel tekib palju probleeme, mis ajendas meid leidma lahenduse ja kirjutama selle artikli/juhendi.
See ei ole ilmselt parim praktika, kuid see lahendus tundus võimalikult mugav ja lihtne.
Õpetust vt kat.
Nõutavad paketid põhimasinas:
- püüton
- git
- ssh-võtmetega fail
Üldine põhimõte automaatse gut pulli rakendamisel kõigis virtuaalsetes masinates on see, et vajate masinat, kuhu Ansible installitakse. Sellest masinast saadab ansible git pull käsud ja taaskäivitab värskendatud teenuse. Nendel eesmärkidel lõime väljaspool klastreid eraldi virtuaalse masina ja installisime sellesse:
- püüton
- ansible
- gitlab-jooksja
Organisatsioonilistest probleemidest – tuleb registreerida gitlab-runner, teha ssh-keygen, laadida selle masina avalik ssh-võti .ssh/authorized_keys
peamasinas avage port 22, et saaksite seda teha põhimasinas.
Nüüd konfigureerime ansible
Kuna meie eesmärk on automatiseerida kõike, mis võimalik. Failis /etc/ansible/ansible.cfg
me tühistame rea kommentaarid host_key_checking = False
et ansible ei küsiks uute masinate kinnitust.
Järgmiseks tuleb ansible jaoks automaatselt genereerida inventarifail, kust see võtab nende masinate ip-d, millel on vaja git pulli teha.
Me genereerime selle faili Hetzneri API abil, hostide loendi saate võtta oma AWS-i, Asure'i andmebaasist (teil on kuskil API, et kuvada oma töötavad masinad, eks?).
Inventarifaili struktuur on Ansible jaoks väga oluline; see peaks välja nägema järgmine:
[группа]
ip-адрес
ip-адрес
[группа2]
ip-адрес
ip-адрес
Sellise faili loomiseks koostame lihtsa skripti (nimetagem seda 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
On aeg kontrollida, kas Ansible töötab ja on sõbralik IP-aadresside vastuvõtmisega:
/etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'hostname' group
Väljund peaks sisaldama nende masinate hostinimesid, millel käsk käivitati.
Paar sõna süntaksi kohta:
- /etc/ansible/./vm_list – genereerib masinate loendi
- -i - laofaili absoluutne tee
- -m - käske kasutada shellmoodulit
- -a on argument. Siia saab sisestada mis tahes käsu
- rühm – teie klastri nimi. Kui peate seda tegema kõigis klastrites, muutke rühmaks kõik
Läheme kaugemale – proovime oma virtuaalmasinatel git pulli teha:
/etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'cd /path/to/project && git pull' group
Kui väljundis näeme juba ajakohasust või hoidlast mahalaadimist, siis kõik töötab.
Nüüd on see kõik mõeldud
Õpetame oma skripti gitlabi põhiharule pühendumisel automaatselt jooksma
Esiteks, teeme oma skripti ilusamaks ja paneme selle käivitatavasse faili (nimetagem seda exec_pull) -
#!/bin/bash
/etc/ansible/./get_vms && ansible -i /etc/ansible/cloud_ip -m shell -a "$@"
Läheme oma gitlabi ja loome projektis faili .gitlab-ci.yml
Sisse panime järgmised asjad:
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
Kõik on valmis. Nüüd -
- pühenduma
- Mul on hea meel, et kõik töötab
Kui teisaldate faili .yml teistele projektidele, peate lihtsalt muutma taaskäivitava teenuse nime ja klastri nime, millel võimalikud käsud täidetakse.
Allikas: www.habr.com