🥇Прискорюємо 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 XNUMX, звичайно, можна, але хто сказав, що працюватиме?

Зводимо все разом

У результаті для 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? Тому що гладіолус він працює, тільки поки що таски реально прості і все добре. Однак варто згорнути трохи вліво або вправо — все, приїхали: у відповідь у тебе летить жменя невиразних винятків, і для завершення картини не вистачає лише розхожої фрази: «Дякуємо всім, всі вільні». Загалом я просто не бажаю витрачати час на з'ясування причин чергового «підземного стуку».

Частина цих налаштувань було виявлено у процесі читання вихідного коду connection plugin'а під назвою «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%так, тільки хочу більше хардкорних штук!
0,0%ні, і задарма не треба0
0,0%ні, складнаааааа!!!0

Проголосували 69 користувачів. Утрималися 7 користувачів.

Джерело: habr.com

Прискорюємо Ansible