🥇 Ansiblen nopeuttaminen

Ei ole mikään salaisuus, että oletusasetuksilla Ansible ei pysty tekemään työtään kovin nopeasti. Tässä artikkelissa osoitan useita syitä tähän ja tarjoan hyödyllisen vähimmäisasetusten määrän, jotka todennäköisesti todella lisäävät projektisi nopeutta.

Tässä ja alla käsitellään Ansible 2.9.x:ää, joka asennettiin juuri luotuun virtualenv:hen suosikkitavallasi.

Luo asennuksen jälkeen pelikirjan viereen "ansible.cfg" -tiedosto - tässä paikassa voit siirtää nämä asetukset projektin mukana, ja ne latautuvat melko automaattisesti.

Putkilinjaus

Jotkut ovat ehkä jo kuulleet tarpeesta käyttää liukuhihnaa, eli ei kopioida moduuleja kohdejärjestelmän tiedostojärjestelmään, vaan siirtää Base64:ään kääritty zip-arkisto suoraan Python-tulkin stdiniin, mutta toiset eivät ehkä, mutta tosiasia jää faktaksi: tämä asetus on edelleen aliarvioitu. Valitettavasti jotkin suositut Linux-jakelut, joita käytettiin sudon määrittämiseen, eivät oletuksena kovin hyvin - joten tämä komento vaati tty:n (päätelaitteen), joten Ansible jätti tämän erittäin hyödyllisen asetuksen oletusarvoisesti pois käytöstä.

pipelining = True

Faktojen kerääminen

Tiesitkö, että oletusasetuksissa Ansible for every play aloittaa faktojen keräämisen kaikilta siihen osallistuvilta isänniltä? Yleisesti ottaen, jos et tiennyt, nyt tiedät. Jotta näin ei tapahdu, sinun on otettava käyttöön joko eksplisiittinen pyyntötila faktojen keräämistä varten (eksplisiittiset) tai älykäs tila. Siinä kerätään faktoja vain niiltä isänniltä, joita ei tavattu aiemmissa näytelmissä.
UPD. Kun kopioit, sinun on valittava jokin näistä asetuksista.

gathering = smart|explicit

ssh-yhteyksien uudelleenkäyttö

Jos olet joskus käyttänyt Ansiblea virheenkorjaustilassa ("v"-vaihtoehto, toistettu yhdestä yhdeksään kertaan), olet ehkä huomannut, että ssh-yhteyksiä luodaan ja katkeaa jatkuvasti. Tässä on siis myös pari hienovaraisuutta.

Voit välttää vaiheen, jossa ssh-yhteys muodostetaan uudelleen kahdella tasolla kerralla: sekä suoraan ssh-asiakkaassa että siirrettäessä tiedostoja hallittuun isäntään hallinnasta.
Jos haluat käyttää avointa ssh-yhteyttä uudelleen, välitä tarvittavat avaimet ssh-asiakkaalle. Sitten se alkaa tehdä seuraavaa: kun muodostat ssh-yhteyden ensimmäistä kertaa, se luo lisäksi ns. ohjauspistorasian, myöhemmissä asennuksissa se tarkistaa juuri tämän pistorasian olemassaolon, ja jos onnistuu, käyttää uudelleen olemassa oleva ssh-yhteys. Ja jotta tämä kaikki olisi järkevää, asetetaan aika yhteyden ylläpitämiselle, kun se ei ole aktiivinen. Voit lukea lisää kohdasta ssh-dokumentaatio, ja Ansiblen yhteydessä käytämme yksinkertaisesti tarvittavien vaihtoehtojen "välittämistä" ssh-asiakkaalle.

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

Jos haluat käyttää uudelleen jo avointa ssh-yhteyttä siirtäessäsi tiedostoja hallittuun isäntään, määritä toinen tuntematon asetus ssh_tranfer_method. Asiakirjat ovat erittäin laadukkaita niukka ja harhaanjohtavaa, koska tämä vaihtoehto toimii varsin hyvin! Mutta lukeminen lähdekoodi antaa sinun ymmärtää, mitä tarkalleen tapahtuu: dd-komento käynnistetään hallittuun isäntään, joka toimii suoraan halutun tiedoston kanssa.

transfer_method = piped

Muuten, "kehitys"-haarassa tämä asetus on myös olemassa ei mene minnekään.

Älä pelkää veistä, pelkää haarukkaa

Toinen hyödyllinen asetus on haarukat. Se määrittää työntekijöiden prosessien määrän, jotka muodostavat samanaikaisesti yhteyden isäntiin ja suorittavat tehtäviä. Pythonin kielen erityispiirteistä johtuen käytetään prosesseja, ei säiettä, koska Ansible tukee edelleen Python 2.7:ää - ei asyncioa sinulle, ei ole mitään järkeä ottaa käyttöön asynkronista käyttäytymistä! Oletuksena Ansible toimii viisi työntekijöitä, mutta jos sitä kysytään oikein, se käynnistää lisää:

forks = 20

Varoitan heti, että tässä saattaa olla vaikeuksia, jotka liittyvät ohjauskoneen käytettävissä olevaan muistiin. Toisin sanoen, voit tietysti asettaa forks=100500, mutta kuka sanoi, että se toimisi?

Laittamalla kaikki yhteen

Tämän seurauksena ansible.cfg:n (ini-muodossa) tarvittavat asetukset voivat näyttää tältä:

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

Ja jos haluat piilottaa kaiken normaaliin terveen ihmisen YaML-inventaarioon, se voi näyttää suunnilleen tältä:

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

Valitettavasti tämä ei toimi asetuksilla "gathering = smart/explicit" ja "forks = 20": niiden YaML-vastineita ei ole olemassa. Joko asetamme ne tiedostoon ansible.cfg tai välitämme ne ympäristömuuttujien ANSIBLE_GATHERING ja ANSIBLE_FORKS kautta.

Tietoja Mitogenista
- Missä tämä Mitogen on? - sinulla on oikeus kysyä, rakas lukija. Ei missään tässä artikkelissa. Mutta jos olet todella valmis lukemaan sen koodin ja selvittämään, miksi pelikirjasi kaatuu Mitogenin kanssa, mutta toimii hyvin vanilla Ansiblen kanssa tai miksi sama pelikirja toimi hyvin ennen, mutta päivityksen jälkeen alkoi tehdä outoja asioita - no, Mitogen saattaa olla työkalusi. Käytä sitä, ymmärrä sitä, kirjoita artikkeleita - luen sen mielenkiinnolla.

Miksi en henkilökohtaisesti käytä Mitogenia? Gladiolusin takia se toimii vain niin kauan kuin tehtävät ovat todella yksinkertaisia ja kaikki on hyvin. Jos kuitenkin käännät hieman vasemmalle tai oikealle - siinä se, olemme perillä: vastauksena kourallinen epäselviä poikkeuksia lentää sinua kohti, ja kuvan täydentämiseksi puuttuu vain yleinen lause "kiitos kaikille , kaikki ovat vapaita." Yleensä en vain halua tuhlata aikaa seuraavan "maanalaisen koputuksen" syiden selvittämiseen.

Jotkut näistä asetuksista löydettiin lukuprosessin aikana lähdekoodi yhteyslaajennus itsestään selvällä nimellä "ssh.py". Jaan lukemisen tulokset siinä toivossa, että se innostaa jotakuta toista katsomaan lähteitä, lukemaan niitä, tarkistamaan toteutus, vertailemaan dokumentaatiota - loppujen lopuksi ennemmin tai myöhemmin kaikki tämä tuo sinulle myönteisiä tuloksia. Onnea!

Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. Kirjaudu sisään, ole kiltti.

Mitä seuraavista Ansible-asetuksista käytät nopeuttaaksesi projektejasi?

69,6%pipelining=true32
34,8%kerääminen = älykäs/selkeä16
52,2%ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24
17,4%siirtomenetelmä = piped8
63,0%haarukat = XXX29
6,5%Ei mikään näistä, vain Mitogen3
8,7%Mitogen + Panen merkille, mitkä näistä asetuksista4

46 käyttäjää äänesti. 21 käyttäjä pidättyi äänestämästä.

Haluatko lisää tietoa Ansiblesta?

78,3%kyllä, tietysti 54
21,7%kyllä, haluan vain lisää hardcore-juttuja!15
0,0%ei, eikä se ole turhaan tarpeellista0
0,0%ei, se on monimutkaista!!!0

69 käyttäjää äänesti. 7 käyttäjää pidättyi äänestämästä.

Lähde: will.com

Ansiblen nopeuttaminen