🥇Përshpejtojmë Ansible

Nuk është sekret për askënd se me cilësimet 'me default', Ansible nuk e bën punën e tij shumë shpejt. Në këtë artikull do të theksoj disa arsye për këtë dhe do të propozoj një minimum të dobishëm të cilësimeve, të cilat ndoshta do të rrisin shpejtësinë e funksionimit të projektit tuaj.

Këtu dhe më tej diskutojmë Ansible 2.9.x, i cili është instaluar në një virtualenv të sapo krijuar në mënyrën tuaj të preferuar.

Pas instalimit krijoni pranë playbook-ut tuaj skedarin 'ansible.cfg' — kjo pozicion do të mundësojë transferimin e cilësimeve të dhënave së bashku me projektin, përveç që ato do të ngarkohen automatikisht.

Pipelining

Dikush ka dëgjuar që duhet të përdoret pipelining, domethënë jo kopjimi i moduleve në sistemin e skedarëve të sistemit të targetuar, por transferimi i një arkivi zip të mbështjellë në Base64 drejtpërdrejt në stdin të interpretuesit Python, por kjo është një fakt: kjo cilësim ende mbetet e nënvlerësuar. Fatkeqësisht, disa nga shpërndarjet e njohura të Linux herët më parë e përshtatën sudo-në jo shumë mirë — kështu që kjo komandë kërkonte një tty (terminal), prandaj në Ansible kjo cilësim shumë e dobishme u la e çaktivizuar nga default.

pipelining = True

Grumbullimi i fakteve

A e dini se me cilësimet me default Ansible për çdo play iniciaton grumbullimin e fakteve nga të gjithë hostet që marrin pjesë në të? Në përgjithësi, nëse nuk e dinit, tani e dini. Për t'u siguruar që kjo të mos ndodhi, duhet të aktivizoni ose mënyrën e kërkesës eksplicite për grumbullim faktesh (explicit), ose mënyrën smart. Në të, faktet do të grumbullohen vetëm nga ato hoste që nuk janë takuar në play të mëparshëm.
UPD. Gjatë kopjimit ju do të duhet të zgjidhni ndonjë nga këto cilësime.

gathering = smart|explicit

Rikëthimi i lidhjeve ssh

Nëse ndonjëherë keni ekzekutuar Ansible në mënyrën e daljes së informacionit të shkallës (opsioni 'v', i përsëritur nga një deri në nëntë herë), ndoshta keni vënë re se lidhjet ssh vazhdimisht krijohen dhe prishen. Pra, këtu gjithashtu ekziston një çift nuancash.

Të shmangni etapën e riinstalimit të lidhjes ssh mund të bëhet në dy nivele menjëherë: si direkt në klientin ssh, ashtu edhe gjatë transferimit të skedareve në hostin e menaxhuar nga ai që menaxhon.
Për të ripërdorur një lidhje ssh të hapur, mjafton të kaloni çelësat e nevojshëm te klienti ssh. Atëherë ai do të fillojë të bëjë sa vijon: gjatë instalimit të parë të lidhjes ssh, do të krijojë një socket kontrolli, dhe gjatë lidhjeve të mëpasshme do të kontrollojë ekzistencën e këtij socket-i, dhe nëse është e suksesshme, do të ripërdorë lidhjen ssh ekzistuese. Dhe për ta bërë këtë të kuptueshëm, le të caktuar një kohë ruajtjeje të lidhjes kur nuk është aktive. Më shumë detaje mund të lexoni në dokumentacionin për ssh, ndërsa në kontekstin e Ansible ne thjesht përdorim "kalimin" e opsioneve të nevojshme te klienti ssh.

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

Për të ripërdorur një lidhje ssh tashmë të hapur kur të kaloni skedarë në hostin e menaxhuar, mjafton të specifikoni një konfigurim të panjohur ssh_transfer_method. Dokumentacioni lidhur me këtë është jashtëzakonisht i varfër dhe jep informacione të gabuara, sepse ky opsion funksionon pa probleme! Megjithatë, leximin e kodit burimor na lejon të kuptojmë se çfarë do të ndodhë: në hostin e menaxhuar do të ekzekutohet komanda dd, që punon direkt me skedarin e nevojshëm.

transfer_method = piped

Në fakt, në degën "develop" kjo konfigurim gjithashtu ekziston dhe nuk është zhdukur.

Mos ki frikë nga thika, ki frikë nga piruni

Një tjetër konfigurim të dobishëm është forks. Kjo përcakton numrin e proceseve punuese që do të lidhen njëkohësisht me hostet dhe do të ekzekutojnë detyrat. Për shkak të veçorive të Python si gjuhë programimi, përdoren pikërisht proceset, jo thread-et, sepse Ansible ende mbështet Python 2.7 — asnjë asyncio këtu, nuk duhet të zhvillojmë ashpërsira asinkrone! Me përjashtim të rasteve, Ansible nismon pesë punëtorë, por nëse kërkoni saktë, mund të nisim më shumë:

forks = 20

Por menjëherë të paralajmëroj se këtu mund të kenë disa vështirësi, lidhur me sasinë e memorie që ekziston në makinën menaxhuese. Me fjalë të tjera, vendosja e forks=100500, padyshim që është e mundur, por kush tha se do të funksionojë?

Të gjitha së bashku

Si rezultat, për ansible.cfg (format ini) konfigurimet e nevojshme mund të duken si më poshtë:

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

Dhe nëse dëshiron të fshehësh gjithçka në një YaML-inventory të shëndoshë, atëherë ai mund të duket kështu:

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

Fatkeqësisht, me konfigurimet «gathering = smart/explicit» dhe «forks = 20» kjo nuk do të kalojë: nuk ekzistojnë ekivalente YaML për to. Ose t’i vendosim ato në ansible.cfg, ose t’i kalojmë përmes variablave mjedisorë ANSIBLE_GATHERING dhe ANSIBLE_FORKS.

Për Mitogen
— Ku është këtu për Mitogen? — mund të pyesësh ti, lexues i nderuar. Në këtë artikull — askund. Por nëse je vërtet i gatshëm të lexosh kodin e tij dhe të kuptosh pse playbook-u yt dështon me Mitogen, ndërsa me Ansible-in e zakonshëm funksionon normal, ose pse ky playbook deri tani ka punuar mirë, por pas përditësimit ka filluar të sillet çuditshëm — çfarë të thuhet, Mitogen potencialisht mund të jetë instrumenti yt. Apliko, hulumto, shkruaj artikuj — do t’i lexoj me interes.

Pse unë personalisht nuk e përdor Mitogen? Sepse ai funksionon vetëm kur detyrat janë vërtet të thjeshta dhe gjithçka shkon mirë. Megjithatë, sapo e kthen pak majtas ose djathtas — gjithçka, mbaroi: në përgjigje të kësaj, një grusht përjashtimesh të paqartësish vjen drejt teje, dhe për të përfunduar pamjen nuk i mungon vetëm fraza e zakonshme «faleminderit të gjithëve, jeni të lirë». Në përgjithësi, nuk dëshiroj të humbas kohë me zbardhjen e arsyes së një «thirrjeje nëntokësore» të re.

Disa nga këto konfigurime janë zbuluar në procesin e leximit e kodit burimor plugin-it të lidhjes me emrin domethënës «ssh.py». Po ndaj rezultatet e leximit me shpresën se kjo do të frymëzojë edhe dikë tjetër të shikojë në burimin, të lexojë, të kontrollojë implementimin, të krahasojë me dokumentacionin — sepse gjithçka kjo vonë apo herët do t'ju sjellë rezultate pozitive. Fat të mbarë!

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.