🥇Paātrinām Ansible

Navam mums nav noslēpums, ka ar «noklusējuma» iestatījumiem Ansible var strādāt ne pārāk ātri. Šajā rakstā es norādīšu uz vairākām šī fakta prasībām un piedāvāšu noderīgu iestatījumu minimālo komplektu, kas, iespējams, tiešām palielinās jūsu projekta ātrumu.

Šeit un turpmāk apspriežam Ansible 2.9.x, kas tika instalēts jaunizveidotajā virtualenv jūsu iecienītajā veidā.

Pēc instalācijas izveidojiet blakus jūsu playbook failu «ansible.cfg» — šāda izvietojuma dēļ iestatījumus būs ērti pārvietot kopā ar projektu, turklāt tie tiks automātiski ielādēti.

Pipelining

Par to, ka ir jāizmanto pipelining, proti, nevis moduļu kopēšanu uz mērķa sistēmas failu sistēmu, bet gan bāzē 64 kodētā zip arhīva nodošanu tieši uz Python interpretatora stdin, kāds kādreiz jau varēja dzirdēt, bet kādam citam — nē, taču fakts paliek fakts: šo iestatījumu joprojām novērtē zems. Diemžēl kādas populāras Linux distribūcijas noklusējuma iestatījumi iepriekš nevienmērīgi konfigurēja sudo — tā, ka šī komanda prasīja tty (termināla) klātbūtni, tādēļ Ansible šo ļoti noderīgo iestatījumu atstāja izslēgtu noklusējuma režīmā.

pipelining = True

Faktu vākšana

Vai zinājāt, ka ar noklusējuma iestatījumiem Ansible katram spēlē uzsāk faktu vākšanu visiem hostiem, kas tajā piedalās? Ja nēzinājāt, tad tagad zināt. Lai to nepieļautu, ir jāieslēdz vai nu skaidra pieprasījuma režīms faktu vākšanai (explicit), vai arī smart režīms. Tajā fakti tiks vākti tikai no tiem hostiem, kuri iepriekš nav parādījušies citās spēlēs.
UPD. Pārsūtīšanas laikā jums būs jāizvēlas kāds no šiem iestatījumiem.

gathering = smart|explicit

SSH savienojumu atkārtota izmantošana

Ja kaut kad esat palaidis Ansible, izmantojot atkļūdošanas informācijas izvadīšanas režīmu (opcija «v», atkārtota no viena līdz deviņiem reizēm), iespējams, esat pamanījis, ka SSH savienojumi pastāvīgi tiek izveidoti un izjaukti. Tātad, arī šeit pastāv pāris nianses.

Izvairīties no SSH savienojuma atkārtotas izveides posma var divos līmeņos: gan tieši SSH klientā, gan, pārsūtot failus uz pārvaldāmo hostu no kontroliera.
Lai atkārtoti izmantotu atvērtās ssh savienojuma, pietiek tikai nodot nepieciešamās ssh atslēgas ssh klientam. Tad viņš sāks veikt sekojošo: pirmo reizi izveidojot ssh savienojumu, papildus izveidot tā dēvēto kontrolsocket, nākamajā – pārbaudīt, vai šis socket pastāv, un, ja tas ir veiksmīgi, atkārtoti izmantot esošo ssh savienojumu. Un lai šim visam būtu jēga, noteiksim savienojuma saglabāšanas laiku neaktivitātes gadījumā. Sīkāk var lasīt dokumentācijā par ssh, bet Ansible kontekstā mēs vienkārši izmantojam "pārnesi" nepieciešamos ssh klienta iestatījumus.

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

Lai atkārtoti izmantotu jau atvērtu ssh savienojumu, pārraidot failus uz pārvaldāmo hostu, pietiek norādīt vēl vienu nezinu konfigurāciju ssh_transfer_method. Dokumentācija šajā sakarā ir ļoti skopa un ievada maldinoši, jo šī opcija ir pilnīgi funkcionējoša! Taču lasīšana avota koda ļauj saprast, kas tieši notiks: pārvaldāmajā hostā tiks izpildīta komanda dd, kas tieši strādā ar attiecīgo failu.

transfer_method = piped

Starpcitu, "develop" zarā šis iestatījums arī pastāv un nekur nav pazudis.

Neuztraucies par nazi, baidies no dakšas

Vēl viens noderīgs iestatījums ir forks. Tas nosaka, cik daudz darba procesu vienlaikus pieslēgsies hostiem un izpildīs uzdevumus. Ņemot vērā Python īpašības, kā programmēšanas valoda tiek izmantoti tieši procesi, nevis pavedieni, jo Ansible vēl joprojām atbalsta Python 2.7 – nekādu asyncio, nevajag te izplatīt asinkronitāti! Pa noklusējumu Ansible palaiž piecus darbiniekus, bet, ja pareizi lūgt, var palaist vairāk:

forks = 20

Bet es brīdinu, ka šeit var rasties dažas grūtības, saistītas ar esošo atmiņas apjomu vadības mašīnā. Citiem vārdiem sakot, iestatīt forks=100500, protams, var, bet kas teica, ka tas darbosies?

Apvienosim visu kopā

Kopumā ansible.cfg (ini formāts) nepieciešamie iestatījumi var izskatīties šādi:

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

Un, ja vēlies visu paslēpt normālā YaML inventārā vesela cilvēka, tas var izskatīties aptuveni šādi:

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

Diemžēl ar iestatījumiem „gathering = smart/explicit” un „forks = 20” tā nesanāks: to YaML ekvivalentu nav. Vai nu mēs tos norādām ansible.cfg, vai nododam caur vides mainīgajiem ANSIBLE_GATHERING un ANSIBLE_FORKS.

Par Mitogen
— Kur šeit ir par Mitogen? — varētu jautāt tu, cienījamais lasītāj. Šajā rakstā — nekur. Bet, ja tu patiešām esi gatavs lasīt viņa kodu un saprast, kāpēc tavs playbook iekrist ar Mitogen, bet ar vaniļas Ansible strādā normāli, vai kāpēc tas pats playbook iepriekš strādāja kārtīgi, bet pēc atjaunināšanas sāka darīt dīvaini — ko žēl, Mitogen potenciāli var būt tavs rīks. Izmanto, pēti, raksti rakstus — es ar interesi izlasīšu.

Kāpēc es personīgi neizmantoju Mitogen? Jo viņš strādā tikai tad, kad uzdevumi patiešām ir vienkārši un viss ir labi. Tomēr, kad tiek iegūts nedaudz pa kreisi vai pa labi — viss, braukt ir beidzies: atpakaļ uz tevi lido lērums neskaidru izņēmumu, un līdz pilnai bildei trūkst tikai izplatītas frāzes „visiem paldies, visi brīvi”. Kopumā es vienkārši nevēlos tērēt laiku, lai noskaidrotu kārtējo „zemzemes sitienu” cēloņus.

Daļa no šiem iestatījumiem tika atklāta lasīšanas procesā avota koda savienojuma spraudņa zem runājošā nosaukuma „ssh.py”. Dalos ar lasīšanas rezultātiem cerībā, ka tas iedvesmos vēl kādu skatīties avota kodā, lasīt to, pārbaudīt īstenojumu, salīdzināt ar dokumentāciju — jo tas agri vai vēlu nesīs jums savus pozitīvos rezultātus. Veiksmi!

Tikai reģistrētie lietotāji var piedalīties aptaujā. Pieteikties, lūdzu.