🥇Przyspieszamy Ansible

Nie jest tajemnicą, że przy domyślnych ustawieniach Ansible może działać dość wolno. W artykule wskazuję kilka przyczyn tego stanu rzeczy oraz proponuję minimum ustawień, które mogą naprawdę zwiększyć szybkość działania twojego projektu.

Dyskutujemy tutaj i dalej o Ansible 2.9.x, który został zainstalowany w nowo stworzonym virtualenv w twoim ulubionym stylu.

Po instalacji tworzymy obok twojego playbooka plik „ansible.cfg” — takie umiejscowienie pozwoli przenosić te ustawienia razem z projektem, a dodatkowo będą one ładowane automatycznie.

Pipelining

Ktoś mógł już słyszeć, że należy używać pipeliningu, co oznacza, że zamiast kopiowania modułów na system plików docelowego systemu, przesyłany jest zawinięty w Base64 plik zip bezpośrednio na stdin interpretera Python, ale fakt pozostaje faktem: to ustawienie wciąż pozostaje niedoceniane. Niestety, niektóre z popularnych dystrybucji Linux domyślnie źle konfigurowały sudo — tak, że ta komenda wymagała tty (terminala), przez co w Ansible to bardzo użyteczne ustawienie pozostawiono wyłączone domyślnie.

pipelining = True

Zbieranie faktów

Czy wiesz, że przy domyślnych ustawieniach Ansible dla każdego play'a inicjuje zbieranie faktów ze wszystkich hostów, które w nim uczestniczą? Jeśli nie wiedziałeś, to teraz już wiesz. Aby tego uniknąć, należy włączyć tryb wyraźnego żądania zbierania faktów (explicit) lub tryb smart. W tym trybie fakty będą zbierane tylko z tych hostów, które nie pojawiły się w poprzednich play'ach.
UPD. Przy kopiowaniu będziesz musiał wybrać z tych ustawień jedną.

gathering = smart|explicit

Ponowne użycie połączeń ssh

Jeśli kiedykolwiek uruchamiałeś Ansible w trybie wyświetlania informacji debugowych (opcja „v”, powtórzona od jednego do dziewięciu razy), to być może zauważyłeś, że połączenia ssh ciągle się ustanawiają i przerywają. Otóż istnieje tutaj kilka subtelności.

Można uniknąć etapu ponownego nawiązywania połączenia ssh na dwóch poziomach jednocześnie: zarówno w kliencie ssh, jak i podczas przesyłania plików na zarządzany host z kontrolera.
Aby ponownie wykorzystać otwarte połączenie ssh, wystarczy przekazać odpowiednie klucze do klienta ssh. Wtedy rozpocznie on następujące działania: przy pierwszym nawiązywaniu połączenia ssh dodatkowo utworzy tzw. gniazdo kontrolne, a przy kolejnych będzie sprawdzać istnienie tego gniazda i w przypadku sukcesu ponownie wykorzysta istniejące połączenie ssh. Aby miało to sens, określimy czas zachowania połączenia w przypadku braku aktywności. Szczegóły można znaleźć w dokumentacji dotyczącej ssh, a w kontekście Ansible po prostu używamy „przekazywania” odpowiednich opcji do klienta ssh.

ssh_args = "-o ControlMaster=auto -o ControlPersist=15m"

Aby ponownie wykorzystać już otwarte połączenie ssh podczas przesyłania plików na zarządzany host, wystarczy określić jeszcze jedną nieznaną ustawienie ssh_transfer_method. Dokumentacja w tej sprawie jest bardzo skąpa i wprowadza w błąd, ponieważ ta opcja działa! Warto jednak przeczytać źródłowy kod , co pozwala zrozumieć, co tak naprawdę się wydarzy: na zarządzanym hoście zostanie uruchomione polecenie dd, które bezpośrednio współpracuje z wymaganym plikiem.

transfer_method = piped

Przy okazji, w gałęzi „develop” to ustawienie również istnieje i nie zniknęło nigdzie.

Nie bój się noża, bój się widelca

Kolejna przydatna opcja to forks. Określa liczbę procesów roboczych, które będą jednocześnie łączyć się z hostami i wykonywać zadania. Z powodu specyfiki Pythona jako języka programowania używane są procesy, a nie wątki, ponieważ Ansible nadal wspiera Pythona 2.7 — żadnego asyncio, nie ma co tutaj wprowadzać asynchroniczności! Domyślnie Ansible uruchamia pięć pracowników, ale jeśli odpowiednio poprosisz, uruchomi więcej:

forks = 20

Od razu ostrzegam, że mogą wystąpić pewne trudności związane z dostępną pamięcią na maszynie zarządzającej. Innymi słowy, ustawienie forks=100500, oczywiście, jest możliwe, ale kto powiedział, że to zadziała?

Podsumujmy wszystko

Ostatecznie potrzebne ustawienia dla ansible.cfg (format ini) mogą wyglądać tak:

[defaults]
gathering = smart|explicit
forks = 20
[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m
transfer_method = piped

A jeśli chcesz ukryć wszystko w prawidłowym YaML-inventory osoby zdrowej na umyśle, może to wyglądać mniej więcej tak:

---
all:
  vars:
    ansible_ssh_pipelining: true
    ansible_ssh_transfer_method: piped
    ansible_ssh_args: -o ControlMaster=auto -o ControlPersist=15m

Niestety, z ustawieniami „gathering = smart/explicit” oraz „forks = 20” to się nie uda: ich odpowiedników YaML nie ma. Można je ustawić w ansible.cfg lub przekazać za pomocą zmiennych środowiskowych ANSIBLE_GATHERING i ANSIBLE_FORKS.

O Mitogenie
— A gdzie tutaj jest coś o Mitogenie? — możesz zapytać, szanowny czytelniku. W tym artykule — nigdzie. Ale jeśli jesteś naprawdę gotowy przeczytać jego kod i zrozumieć, dlaczego twój playbook nie działa z Mitogenem, a z „waniliowym” Ansible działa normalnie, lub dlaczego ten sam playbook wcześniej działał, a po aktualizacji zaczął działać dziwnie — cóż, Mitogen potencjalnie może być twoim narzędziem. Stosuj, analizuj, pisz artykuły — przeczytam z zainteresowaniem.

Dlaczego osobiście nie używam Mitogena? Ponieważ działa on tylko wtedy, gdy zadania są naprawdę proste i wszystko jest w porządku. Jednak gdy tylko zrobisz coś w lewo lub w prawo — wszystko, koniec: w odpowiedzi dostajesz garść niejasnych wyjątków, a dla pełni obrazu brakuje tylko popularnej frazy „wszystkim dziękuję, wszyscy wolni”. Generalnie po prostu nie chcę tracić czasu na odkrywanie przyczyn kolejnego „podziemnego stuku”.

Część tych ustawień została odkryta podczas czytania źródłowy kod wtyczki połączeniowej o mówiącej nazwie „ssh.py”. Dzielę się efektami czytania z nadzieją, że zainspiruje to kogoś innego do zaglądania do źródeł, czytania ich, sprawdzania implementacji, porównywania z dokumentacją — bo wszystko to prędzej czy później przyniesie pozytywne rezultaty. Powodzenia!

Tylko zarejestrowani użytkownicy mogą brać udział w ankiecie. Zaloguj się, proszę.