Ansible + auto git pull w klastrze maszyn wirtualnych w chmurze

Ansible + auto git pull w klastrze maszyn wirtualnych w chmurze

Dzień dobry

Mamy kilka klastrów chmurowych z dużą liczbą maszyn wirtualnych w każdym. Całą tę działalność prowadzimy w firmie Hetzner. W każdym klastrze mamy jedną maszynę master, z której pobierany jest snapshot i automatycznie dystrybuowany do wszystkich maszyn wirtualnych w obrębie klastra.

Ten schemat nie pozwala nam na normalne korzystanie z gitlab-runnerów, ponieważ pojawia się wiele problemów, gdy pojawia się wielu identycznych zarejestrowanych biegaczy, co skłoniło nas do znalezienia obejścia i napisania tego artykułu/podręcznika.

Prawdopodobnie nie jest to najlepsza praktyka, ale to rozwiązanie wydawało się tak wygodne i proste, jak to tylko możliwe.

Aby zapoznać się z samouczkiem, zobacz cat.

Wymagane pakiety na maszynie głównej:

  • pyton
  • odrzutowiec
  • plik z kluczami ssh

Ogólna zasada wdrażania automatycznego ściągania na wszystkich maszynach wirtualnych jest taka, że ​​potrzebujesz maszyny, na której zostanie zainstalowany Ansible. Z tego komputera ansible wyśle ​​polecenia git pull i ponownie uruchomi zaktualizowaną usługę. W tym celu utworzyliśmy osobną maszynę wirtualną poza klastrami i zainstalowaliśmy na niej:

  • pyton
  • ansible
  • gitlab-runner

Z kwestii organizacyjnych - musisz zarejestrować gitlab-runner, zrobić ssh-keygen, wgrać publiczny klucz ssh tej maszyny do .ssh/authorized_keys na maszynie głównej otwórz port 22 dla ansible na maszynie głównej.

Teraz skonfigurujmy ansible

Ponieważ naszym celem jest automatyzacja wszystkiego, co jest możliwe. W pliku /etc/ansible/ansible.cfg odkomentujemy tę linię host_key_checking = Falseaby anible nie pytał o potwierdzenie nowych maszyn.

Następnie musisz automatycznie wygenerować plik inwentarza dla Ansible, skąd pobierze adres IP maszyn, na których musisz wykonać git pull.

Generujemy ten plik przy użyciu API Hetznera, możesz pobrać listę hostów ze swojej bazy danych AWS, Asure (masz gdzieś API do wyświetlania uruchomionych maszyn, prawda?).

Struktura pliku inwentarza jest dla Ansible bardzo ważna, powinna wyglądać tak:

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

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

Aby wygenerować taki plik, zrobimy prosty skrypt (nazwijmy go 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

Czas sprawdzić, czy Ansible działa i jest przyjazny w odbieraniu adresów IP:

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

Dane wyjściowe powinny zawierać nazwy hostów komputerów, na których wykonano polecenie.
Kilka słów o składni:

  • /etc/ansible/./vm_list – wygeneruj listę maszyn
  • -i - bezwzględna ścieżka do pliku inwentarza
  • -m - powiedz ansible, aby używał modułu powłoki
  • -a jest argumentem. Można tu wpisać dowolne polecenie
  • group — nazwa klastra. Jeśli chcesz to zrobić we wszystkich klastrach, zmień grupę na wszystkie

Pójdźmy dalej - spróbujmy wykonać git pull na naszych maszynach wirtualnych:

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

Jeśli na wyjściu widzimy już aktualne lub wyładowanie z repozytorium, to wszystko działa.

Teraz właśnie temu to wszystko miało służyć

Nauczmy nasz skrypt, aby działał automatycznie podczas zatwierdzania do gałęzi master w gitlabie

Najpierw upiększmy nasz skrypt i umieśćmy go w pliku wykonywalnym (nazwijmy go exec_pull) -

#!/bin/bash

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

Przejdźmy do naszego gitlaba i utwórzmy plik w projekcie .gitlab-ci.yml
Wewnątrz umieszczamy:

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 

Wszystko jest gotowe. Teraz -

  • dokonać zobowiązania
  • Cieszę się, że wszystko działa

Podczas przesyłania .yml do innych projektów wystarczy zmienić nazwę usługi, która ma zostać zrestartowana, oraz nazwę klastra, na którym będą wykonywane polecenia ansible.

Źródło: www.habr.com

Dodaj komentarz