🥇Przyspieszenie Ansible

Nie jest tajemnicą, że przy domyślnych ustawieniach Ansible nie jest w stanie wykonać swojej pracy bardzo szybko. W artykule wskażę kilka powodów i zaproponuję przydatne minimum ustawień, które prawdopodobnie faktycznie zwiększą prędkość Twojego projektu.

Tutaj i poniżej omawiamy Ansible 2.9.x, który został zainstalowany w świeżo utworzonym środowisku wirtualnym w Twój ulubiony sposób.

Po instalacji utwórz plik „ansible.cfg” obok swojego playbooka - ta lokalizacja pozwoli Ci przenieść te ustawienia wraz z projektem, a dodatkowo załadują się one całkiem automatycznie.

Rurociągi

Niektórzy być może słyszeli już o konieczności stosowania potokowania, czyli nie kopiowania modułów do systemu plików systemu docelowego, a przesyłania archiwum ZIP zapakowanego w Base64 bezpośrednio na standardowe wejście interpretera Pythona, inni niekoniecznie, ale fakt pozostaje faktem: to ustawienie nadal pozostaje niedoceniany. Niestety, niektóre popularne dystrybucje Linuksa używane do domyślnej konfiguracji sudo nie są zbyt dobre - dlatego to polecenie wymagało tty (terminalu), więc Ansible domyślnie pozostawił to bardzo przydatne ustawienie wyłączone.

pipelining = True

Zbieranie faktów

Czy wiesz, że przy ustawieniach domyślnych Ansible przy każdej zabawie inicjuje zbieranie faktów dla wszystkich hostów, którzy w niej uczestniczą? Ogólnie rzecz biorąc, jeśli nie wiedziałeś, teraz już wiesz. Aby temu zapobiec, należy włączyć tryb jawnego żądania w celu gromadzenia faktów (jawny) lub tryb inteligentny. W nim fakty zostaną zebrane tylko od tych gospodarzy, których nie spotkano w poprzednich grach.
UPD. Podczas kopiowania będziesz musiał wybrać jedno z tych ustawień.

gathering = smart|explicit

Ponowne użycie połączeń SSH

Jeśli kiedykolwiek uruchamiałeś Ansible w trybie debugowania (opcja „v”, powtórzona od jednego do dziewięciu razy), być może zauważyłeś, że połączenia ssh są stale nawiązywane i zrywane. Zatem i tutaj jest kilka subtelności.

Możesz uniknąć etapu ponownego ustanawiania połączenia ssh na dwóch poziomach jednocześnie: zarówno bezpośrednio w kliencie ssh, jak i podczas przesyłania plików do zarządzanego hosta od menedżera.
Aby ponownie wykorzystać otwarte połączenie ssh, po prostu przekaż niezbędne klucze klientowi ssh. Następnie zacznie wykonywać następujące czynności: nawiązując po raz pierwszy połączenie ssh dodatkowo utworzy tzw. gniazdo kontrolne, przy kolejnych instalacjach sprawdzi istnienie tego właśnie gniazda i jeśli się powiedzie, ponownie wykorzysta istniejące połączenie ssh. A żeby to wszystko miało sens, ustalmy czas utrzymywania połączenia w stanie nieaktywnym. Więcej możesz przeczytać w dokumentacja ssh, a w kontekście Ansible po prostu używamy „przekazywania” niezbędnych 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 do zarządzanego hosta, po prostu określ inne nieznane ustawienie ssh_tranfer_method. Dokumentacja na ten temat jest niezwykle bogata skąpy i mylące, ponieważ ta opcja działa całkiem nieźle! Ale czytanie kod źródłowy pozwala zrozumieć, co dokładnie się stanie: polecenie dd zostanie uruchomione na zarządzanym hoście, bezpośrednio pracując z żądanym plikiem.

transfer_method = piped

Nawiasem mówiąc, w gałęzi „develop” to ustawienie również istnieje nigdzie nie ide.

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

Kolejnym przydatnym ustawieniem są widelce. Określa liczbę procesów roboczych, które będą jednocześnie łączyć się z hostami i wykonywać zadania. Ze względu na specyfikę Pythona jako języka używane są procesy, a nie wątki, ponieważ Ansible nadal obsługuje Python 2.7 - nie ma dla Ciebie asyncio, nie ma sensu wprowadzać tutaj zachowania asynchronicznego! Domyślnie Ansible działa pięć workers, ale jeśli zostanie poprawnie zapytany, uruchomi więcej:

forks = 20

Od razu ostrzegam, że mogą tu wystąpić pewne trudności związane z ilością dostępnej pamięci na maszynie sterującej. Innymi słowy, możesz oczywiście ustawić forks=100500, ale kto powiedział, że to zadziała?

Kładąc wszystko razem

W rezultacie dla ansible.cfg (format ini) niezbędne ustawienia mogą wyglądać następująco:

[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 normalnym inwentarzu YaML zdrowej osoby, 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 nie będzie to działać z ustawieniami „gathering = smart/explicit” i „forks = 20”: ich odpowiedniki w YaML nie istnieją. Albo ustawiamy je w pliku ansible.cfg, albo przekazujemy je poprzez zmienne środowiskowe ANSIBLE_GATHERING i ANSIBLE_FORKS.

O Mitogenie
- Gdzie jest mowa o Mitogenie? – masz prawo zapytać, drogi czytelniku. Nigdzie w tym artykule. Ale jeśli naprawdę jesteś gotowy, aby przeczytać jego kod i dowiedzieć się, dlaczego Twój podręcznik ulega awarii z Mitogenem, ale działa dobrze z waniliowym Ansible, lub dlaczego ten sam podręcznik działał wcześniej dobrze, ale po aktualizacji zaczął robić dziwne rzeczy - cóż, Mitogen może potencjalnie być Twoim narzędziem. Stosuj, zrozum, pisz artykuły – przeczytam z zainteresowaniem.

Dlaczego osobiście nie używam Mitogenu? Bo mieczyk działa tylko wtedy, gdy zadania są naprawdę proste i wszystko jest w porządku. Jeśli jednak skręcisz trochę w lewo lub w prawo - to wszystko, dotarliśmy: w odpowiedzi leci na ciebie kilka niewyraźnych wyjątków i do uzupełnienia obrazu brakuje tylko powszechnego zwrotu „dziękuję wszystkim” , wszyscy są wolni.” Ogólnie rzecz biorąc, po prostu nie chcę tracić czasu na szukanie przyczyn kolejnego „podziemnego pukania”.

Niektóre z tych ustawień zostały odkryte podczas procesu odczytu kod źródłowy wtyczkę połączeniową pod oczywistą nazwą „ssh.py”. Dzielę się wynikami lektury w nadziei, że zainspiruje to kogoś innego do zajrzenia do źródeł, przeczytania ich, sprawdzenia realizacji, porównania z dokumentacją - przecież to wszystko prędzej czy później przyniesie pozytywne rezultaty. Powodzenia!

W ankiecie mogą brać udział tylko zarejestrowani użytkownicy. Zaloguj się, Proszę.

Których z poniższych ustawień Ansible używasz do przyspieszania swoich projektów?

69,6%potokowanie=true32
34,8%gromadzenie = inteligentne/jawne16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%metoda_transferu = potok8
63,0%widelce = XXX29
6,5%Nic z tego, tylko Mitogen3
8,7%Mitogen + napiszę które z tych ustawień4

Głosowało 46 użytkowników. 21 użytkownik wstrzymał się od głosu.

Chcesz więcej informacji o Ansible?

78,3%tak, oczywiście54
21,7%tak, chcę tylko więcej hardcorowych rzeczy! 15
0,0%nie i nie jest to do niczego potrzebne0
0,0%nie, to skomplikowane!!!0

Głosowało 69 użytkowników. 7 użytkowników wstrzymało się od głosu.

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

Przyspieszenie Ansible