
Не е тайна, че с настройки „по подразбиране“ 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-сесия. А за да има всичко това смисъл, задайте времето за запазване на сесията при неактивност. Подробности можете да намерите в , а в контекста на 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
