🥇Shpejtojmë Ansible

Nuk është sekret për askënd se me konfigurimet "default", Ansible mund ta bëjë punën e tij jo shumë shpejt. Në këtë artikull do të theksoj disa arsye për këtë dhe do të ofroj një minimum të dobishëm konfigurimesh, të cilat, është shumë e mundur, do të rrisin realisht shpejtësinë e punës së projektit tuaj.

Diskutojmë këtu dhe më pas mbi Ansible 2.9.x, i cili u instalua në një virtualenv të krijuar rishtazi me mënyrën tuaj të preferuar.

Pas instalimit krijoni afër playbook-ut tuaj skedarin "ansible.cfg" — kjo vendosje do të lejojë transferimin e këtyre konfigurimeve së bashku me projektin, për më tepër do të ngarkohen automatikisht.

Konteinerizimi

Dikush mund të ketë dëgjuar për nevojën për të përdorur pipelining, domethënë jo kopjimin e moduleve në sistemin e targetuar, por dërgimin e një arkivi zip të mbështjellë me Base64 drejtpërdrejt në stdin të interpretorit Python, ndonëse fakti mbetet fakt: kjo konfigurim këto konfigurations kanë mbetur të nënvlerësuara. Fatkeqësisht, një nga distribucionet e njohura të Linux gjithashtu ndihmoi që sudo të nuk është konfiguruar shumë mirë nga planifikimi, duke bërë që kjo komandë të kërkonte një tty (terminal), kështu që në Ansible kjo konfigurim shumë e dobishme mbetet e çaktivizuar nën default.

pipelining = True

Mblidhen fakte

A e dini se me konfigurimet e defaultit, Ansible për çdo play iniciaton mbledhjen e fakteve për të gjitha hostet që përfshihen? Nëse nuk e dinit, tani e know. Për të parandaluar këtë, duhet të aktivizoni ose modin e kërkesës eksplicite për mbledhjen e fakteve (explicit), ose modin e zgjuar (smart). Në këtë mod, faktet do të mblidhen vetëm nga ato hoste që nuk janë hasur në play-përpara.
UPD. Kur kopjoni, do t'ju duhet të zgjidhni një nga këto konfigurime.

gathering = smart|explicit

Rivendosja e lidhjeve ssh

Nëse keni ndonjëherë ekzekutuar Ansible në modalitetin e informacionit të depërtimit (opsioni 'v', i përsëritur nga një deri në nëntë herë), mund të keni vënë re se lidhjet ssh vazhdimisht krijohen dhe ndërpriten. Këtu gjithashtu ka disa nuanca.

Mund të shmangni fazën e riinstalimit të lidhjes ssh në dy nivele: si në klientin ssh, ashtu edhe gjatë transferimit të skedarëve në hostin e menaxhuar nga menaxhuesi.
Për të ripërdorur lidhjen e hapur ssh, mjafton t'i kaloni çelësat e nevojshëm klientit ssh. Atëherë ai do të fillojë të bëjë këtë: gjatë instalimit të parë të lidhjes ssh, do të krijojë një "control socket" dhe gjatë lidhjeve të ardhshme do të kontrollojë ekzistencën e këtij soketi dhe, nëse është e suksesshme, do të ripërdorë lidhjen ekzistuese ssh. Për të pasur kuptim, le të caktojmë kohën e ruajtjes së lidhjes gjatë inaktivitetit. Mund të lexoni më shumë në dokumentacionin për ssh, ndërsa në kontekstin e Ansible thjesht përdorim "kalimin" e opsioneve të nevojshme për klientin ssh.

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

Për të ripërdorur tashmë lidhjen ssh të hapur gjatë transferimit të skedarëve në hostin e menaxhuar, mjafton të tregoni një cilësim të panjohur ssh_transfer_method. Dokumentacioni për këtë është jashtëzakonisht i shkurtër dhe gjithashtu në jep konfuzion, sepse kjo mundësi është plotësisht funksionale! Por lexim i kodit burimor tregon se çfarë do të ndodhë: në hostin e menaxhuar do të ekzekutohet komanda dd, e cila punon drejtpërdrejt me skedarin e nevojshëm.

transfer_method = piped

Nga ana tjetër, në degën «develop» ky parametr ekziston gjithashtu dhe nuk ka shkruar askund..

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

Një tjetër parametr i dobishëm është forks. Ai përcakton numrin e proceseve punuese që do të lidhen njëkohësisht me hostet dhe do të kryejnë detyra. Për shkak të veçorive të Python si një gjuhë programimi, përdoren pikërisht proceset dhe jo thread-at, sepse Ansible ende mbështet Python 2.7 — asnjë asyncio, nuk ka çfarë të bëjmë me asinkroninë këtu! Me defakt, Ansible nis pesë punëtorë, por nëse kërkoni siç duhet, do të nisë më shumë:

forks = 20

Por menjëherë paralajmëroj se këtu mund të ketë disa vështirësi të lidhura me volumet ekzistuese të memories në makinën menaxhuese. Në të tjera fjalë, është e mundur të vendosësh forks=100500, por kush e tha se do të funksionojë?

Të gjitha së bashku

Pra, për ansible.cfg (format ini) parametrat e nevojshëm mund të duken kështu:

[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ëndetshëm, ai mund të duket gjithashtu 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ë: ekvivalentët e tyre YaML nuk ekzistojnë. Ose i caktojmë në ansible.cfg, ose i kalojmë përmes variablave të mjedisit ANSIBLE_GATHERING dhe ANSIBLE_FORKS.

Për Mitogen
— Ku është këtu për Mitogen? — mund të pyesësh, lexues i nderuar. Në këtë artikull — askund. Por nëse je vërtet gati të lexosh kodin e tij dhe të kuptosh pse playbook-u yt bie me Mitogen, ndërsa me Ansible-n e zakonshëm punon normalisht, ose pse ky playbook deri tani ka punuar mirë, dhe pas azhurnimit filloi të bëjë gjëra të çuditshme — atëherë, Mitogen potencialisht mund të jetë instrumenti yt. Përdor, kupto, shkruaj artikuj — do t’i lexoj me interes.

Pse unë personalisht nuk e përdor Mitogen? Sepse ai funksionon vetëm për detyrat mjaft të thjeshta dhe kur gjithçka shkon mirë. Megjithatë, sa herë që are duhet të devijoni pak majtas ose djathtas — mbaroi: këtu bien një mori përjashtimesh të paqartë, dhe për të përfunduar tablonë, vetëm fraza e zakonshme «faleminderit të gjithëve, jeni të lirë» mungon. Përgjithësisht, nuk dua të humbas kohë duke zbuluar arsyet e një `të rënë të nënshkruar` të fundit.

Disa nga këto cilësime u gjetën gjatë leximin kodit burimor plugin-it me emrin e përfolur «ssh.py». Po ndaj rezultatet e leximet shpresoj që kjo të frymëzojë edhe ndokënd tjetër të shikojë në kodin burimor, ta lexojë, ta verifikojë implementimin, ta krahasojë me dokumentacionin — sepse të gjitha këto përfundimisht do t'ju sjellin rezultate pozitive. Suksese!

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