Ускоряваме Ansible

Ускоряваме Ansible
Не е тайна, че с настройки „по подразбиране“ Ansible не винаги работи достатъчно бързо. В статията ще посоча няколко причини за това и ще предложа полезен минимум настройки, който вероятно наистина ще увеличи скоростта на работа на вашия проект.

Обсъждаме тук и по-нататък Ansible 2.9.x, който е инсталиран в новосъздаден virtualenv по вашия любим начин.

След инсталацията създайте файл „ansible.cfg“ до вашия плейбук — такова разположение ще позволи пренасянето на тези настройки заедно с проекта, плюс ще се зареждат напълно автоматично.

Конвейеризация

Знаете ли, че е необходимо да се използва pipelining, т.е. вместо да копирате модули в файловата система на целевата система, да предавате опакован в Base64 zip-архив директно на stdin на интерпретатора Python? Някои вече са чули за това, а други — не, но фактът остава факт: това настройка все още остава недооценена. За съжаление, някои популярни дистрибуции на Linux по подразбиране настроиха sudo не особено добре — така, че тази команда изискваше наличие на tty (терминал), затова в Ansible тази много полезна настройка остана изключена по подразбиране.

pipelining = True

Събиране на факти

Знаете ли, че с настройките по подразбиране Ansible за всеки плей иницира събиране на факти от всички хостове, участващи в него? В общи линии, ако не сте знаели, сега знаете. За да предотвратите това, трябва да активирате или режима на изрично искане за събиране на факти (explicit), или режима smart. В него фактите ще се събират само от тези хостове, които не са се срещали в предишни плейове.
UPD. При копирането ще трябва да изберете една от тези настройки.

gathering = smart|explicit

Пренос на ssh-съединения

Ако някога сте стартирали Ansible в режим на извеждане на отладъчна информация (опция „v“, повторена от едно до девет пъти), вероятно сте забелязали, че ssh-съединенията постоянно се установяват и разкъсват. Е, и тук съществуват няколко тънкости.

Можете да избегнете етапа на повторно установяване на ssh-съединението на два нивота едновременно: както в клиента ssh, така и при предаване на файлове на управлявания хост от управляващия.
За повторно използване на отворена ssh-сесия е достатъчно просто да предадете необходимите ключове на ssh-клиента. Тогава той ще започне да прави следното: при първоначалната настройка на ssh-сесията допълнително ще създаде така наречения control socket, а при последващи опити — ще провери съществуването на този сокет и, при успешен резултат, ще повторно използва съществуващата ssh-сесия. А за да има всичко това смисъл, задайте времето за запазване на сесията при неактивност. Подробности можете да намерите в документацията за ssh, а в контекста на Ansible просто използваме "пробив" на необходимите опции към ssh-клиента.

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

За повторно използване на вече отворена ssh-сесия при прехвърляне на файлове към управлявания хост, е достатъчно да зададете още една неизвестна настройка ssh_tranfer_method. Документацията по този въпрос е изключително оскъдна и може да доведе до объркване, тъй като тази опция е напълно работеща! Четенето на изходния код позволява да разберете какво точно ще се случи: на управлявания хост ще бъде изпълнена команда dd, която работи директно с необходимия файл.

transfer_method = piped

Между другото, в клон "develop" тази настройка също съществува и не е изчезнала.

Не се бой от ножа, бой се от вилицата

Още една полезна настройка е forks. Тя определя броя работни процеси, които ще се свързват едновременно към хостовете и ще изпълняват задачи. Поради особеностите на Python като език за програмиране, се използват именно процеси, а не нишки, тъй като Ansible все още поддържа Python 2.7 — никакви asyncio, няма нужда от асинхронност! По подразбиране Ansible стартира пет работника, но ако поискате правилно, може да стартира повече:

forks = 20

Само веднага предупреждавам, че тук могат да възникнат някои трудности, свързани с наличния обем памет на управляващата машина. С други думи, задаването на forks=100500, разбира се, е възможно, но кой каза, че ще работи?

Събираме всичко заедно

В резултат на това нужните настройки за ansible.cfg (ini-формат) могат да изглеждат така:

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

А ако желаете да скриете всичко в нормален YaML-inventory на здравия човек, то той може да изглежда приблизително така:

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

За съжаление, с настройките «gathering = smart/explicit» и «forks = 20» това няма да проработи: техните YaML-еквиваленти не съществуват. Или ги задаваме в ansible.cfg, или ги предаваме чрез променливите на средата ANSIBLE_GATHERING и ANSIBLE_FORKS.

За Mitogen
— Къде е информация за Mitogen тук? — можете да попитате, уважаеми читателю. В тази статия — никъде. Но ако сте наистина готови да прочетете кода му и да разберете защо вашият плейбук с Mitogen не работи, а с ваниловия Ansible е наред, или защо същият плейбук е работил перфектно, а след обновлението започна да се държи странно — какво да кажа, Mitogen потенциално може да бъде вашият инструмент. Използвайте го, проучвайте, пишете статии — ще ги прочета с интерес.

Защо лично аз не използвам Mitogen? Защото той работи само когато задачите са наистина прости и всичко е наред. В момента, в който се отклоните малко наляво или надясно — всичко, приключихте: в отговор ви лети купчина неразбираеми изключения, а за завършек на картината само се нуждаете от популярната фраза «благодаря на всички, свободни сте». Общо взето, просто не искам да губя време в търсене на причините за следващия „подземен звук“.

Част от тези настройки бяха открити по време на четене на изходния код на плъгина за свързване с говорящото заглавие «ssh.py». Споделям резултатите от четенето в надежда, че това ще вдъхнови още някого да погледне в изходния код, да го прочете, да провери реализацията, да я сравни с документацията — защото всичко това рано или късно ще донесе положителни резултати. Успех!

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.

Кои от изброените настройки на Ansible използвате за ускоряване на проектите си?

  • 69,6%pipelining = true32

  • 34,8%gathering = smart/explicit16

  • 52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=…"24

  • 17,4%transfer_method = piped8

  • 63,0%forks = XXX29

  • 6,5%Нищо от това, само Mitogen3

  • 8,7%Mitogen + отбелязвам, които точно от тези настройки4

Гласували са 46 потребители. Сдържал се 21 потребител.

Искате ли още неща за Ansible?

  • 78,3%да, разбира се54

  • 21,7%да, само искам повече хардкорни неща!15

  • 0,0%не, и безплатно не ми трябва0

  • 0,0%не, трудно е!!!0

Гласували са 69 потребители. Сдържали се 7 потребители.

Източник: habr.com

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster