🥇Паскараем 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? Таму што гладыёлус ён працуе, толькі пакуль цягі рэальна простыя і ўсё добра. Аднак варта згарнуць ледзь налева або направа - усё, прыехалі: у адказ у цябе ляціць жменю невыразных выключэнняў, і для завяршэння карціны не хапае толькі ходкай фразы "ўсім дзякуй, усе вольныя". Увогуле, я проста не жадаю марнаваць час на высвятленне прычын чарговага "падземнага груку".

Частка гэтых налад былі выяўлены ў працэсе чытання зыходнага кода 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