Ansible konfiguráció

Korábban már szó volt az alapokról és a változók témaköréről, de az eddig bemutatott Ansible 2.8 működését az alapbeállításokra bíztam, habár nem kevés létezik az Ansible viselkedésének módosítására, finomítására. Annyira, hogy a telepítéssel külön programot is kapsz ezek lekérdezésére, ha nem az online dokumentációt szeretnéd böngészni. Nem beszélve arról, hogy alkalmazásuk is többféle módon történhet. A cikkből megtudhatod, milyen módszerek vannak a konfigurációra, és néhány fontosabb beállítást is megismerhetsz. Olvasd tovább a cikket és tégy egy újabb lépést a magabiztos Ansible használat felé.

Tartalomjegyzék

• Konfiguráció általában
• Konfigurációs fájl használata
• Környezeti változókon keresztül
• Parancssori paraméterekkel
• Néhány fontosabb beállítás
• Összefoglalás

Konfiguráció általában

[Tartalom]

A változókról szóló cikkben már volt szó olyan paraméterekről, mint a "become", ami azért felel, hogy a célgépen bejelentkezett felhasználó root jogot kérjen magának. Ezt megmutattam parancssori paraméterként, playbookban és változóként átadva is az --extra-vars segítségével. Ezen kívül viszont az ansible programot futtató gépen is beállíthatók hasonló paraméterek környezeti változóként, valamint külön konfigurációs fájlban is. A become mellett még számos más beállítás létezik például a program kimenete színeinek módosítására, hibakezelésre, logolásra vagy akár az utasítások futtatásának optimalizálására.

A bővebb lista megtalálható az online dokumentációban, vagy a legbiztosabb módon a telepített ansible-config programon keresztül.

Érdemes tájékozódni ezek alapján. A továbbiakban néhány beállításra külön is kitérek, de érthető módon az összes lehetőséget egy cikkben nem lehet lefedni.

Konfigurációs fájl használata

[Tartalom]

Konfigurációs fájl alatt egy ini szintaktikájú fájlt kell érteni, ahol az egyes beállítások külön szekciókba vannak szerverzve. A [defaults] szekció tartalmazza az egyébként playbookban is megadható paraméterek alapértékeit, míg az [ssh_connection] szekcióban az SSH kapcsolathoz tartozó konfigurciók kerülnek. Ennél persze több szekció is létezik. Figyelni kell rá, hogy a megfelelő szekciót válaszd, ami a dokumentációban áll, különben hibaüzenet nem lesz, csak nem a várt módon fog működni az Ansible.

Konfigurációs fájlok betöltése:

• /etc/ansible/ansible.cfg: Ha nincs más konfigurációs fájl, akkor ez a fájl lesz alkalmazva. Ez viszont nem projekt szintű, tehát minden Ansible projektedre érvényes lesz és az összes felhasználó számára. Ha pedig akár csak egy üres lokális konfigurációs fájl is létezik, a globális változat egyáltalán nem lesz betöltve, ezért nem igazán érdemes erre alapozni semmit. Ha viszont úgy véled, egy többek által használt gépen szükséges az alapbeállításokon változtatni, amennyiben nem írják azt felül, nyugodtan használd. Ekkor viszont a playbookjaid kevésbé lesznek hordozhatók, hiszen más környezetben egész másképp működhetnek.

• ~/.ansible.cfg: A felhasználód home könyvtárában is lehet egy konfigurációs fájl. Ilyenkor a globális konfiguráció nem lesz betöltve, projektszintű konfiguráció híján viszont minden saját projektedre érvényesek lesznek a benne definiáltak. Az előzőhöz hasonlóan erre sem javaslom, hogy támaszkodj, ha nincs rá jó okod.

• $PWD/ansible.cfg: Az aktuális mappában, azaz ahol az ansible-playbook parancsot kiadod, lehet egy ansible.cfg nevű fájl is, ami automatikusan alkalmazva lesz. A felhasználói szintű és a globális beállítások viszont nem lesznek betöltve. Fontos még, hogy ha a mappa bárki által írható, az Ansible biztonsági okokból nem fogja betölteni, amiről figyelmeztetést ír ki. Más részről, ha a mappa nem is írható mindenki által, de a fájl igen, ugyanolyan kockázat, de ettől még betöltődik a konfiguráció. Ezt olyan ráutaló magatartásként érzékeli, mint a következő pontban írt környezeti változó használatát. Az aktuális könyvtár tipikusan a projekt könyvtáron belül van, így ezt már bátrabban lehet használni.

• ANSIBLE_CONFIG=custom.cfg: Az ANSIBLE_CONFIG környezeti változóval bármilyen fájl beállítható konfigurációs fájlként. Ebben az esetben még az írásjog korlátozása nélküli könyvtárból is alkalmazva lesz a beállítás. Nyilván ekkor a te dolgod, hogy a jogosultságokról gondoskodj, viszont az így megadott fájl felett teljes kontrollod van, azaz tetszőleges számú változatot készíthetsz és egyértelmű lesz, mi, miért történik. A projekt részeként pedig mindenki azonos beállításokkal dolgozhat.

Környezeti változókon keresztül

[Tartalom]

A konfigurációs fájl megadásához már mutattam egy környezeti változót. Nem muszáj viszont az INI fájlos megoldást választani. A legtöbb beállítás megoldható közvetlenül környezeti változókkal. Változókat is beállíthatsz Bash-ben akár rendszerszinten, felhasználó szinten, vagy akár lokálisan. Ezek ráadásul egyidőben is alkalmazhatók, azaz a projektszinten definiált értékek mellett nyugodtan lehetnek globális, egyedi beállításaid is.

Változók többszinten definiálása:

• Rendszerszintű változók: Ilyen változók beállításának módja rendszertől függhet és nem célja a cikknek részletezni, de a következő mappáknak és fájloknak érdemes utánanézni: /etc/bash.bashrc, /etc/profile /etc/profile.d, /etc/environment, /etc/environment.d. Ehhez olyan esetekben nyúlj, ha valami nem projektfüggő, hanem inkább magát a rendszert érintő paraméterről van szó. Lehet ez például adott esetben egy rendszerszintű Ansible naplófájl, vagy az SSH program lecserélése bármilyen okból az ANSIBLE_SSH_EXECUTABLE változóval.

• Felhasználói szintű változók: Az előző ponthoz hasonlóan alkalmazható, viszont felhasználó például a felhasználó HOME könyvtárában levő .bashrc vagy .profile fájlban adhatók meg. Mivel az output színeit is lehet változtatni konfigurációval, akár a személyes preferenciád is ösztönözhet az alkalmazására.

• Projekt szintű változók: A Bash függvények sudo-val című cikkben volt szó legutóbb a source parancsról, amivel például függvények vagy változók definícióját remekül be lehet tölteni az aktuális shell munkamenetbe. Kiteheted a konfigurációkat így egy shell szkriptbe, amit a munka megkezdése előtt betöltesz. Pl.:

  env.sh

  export ANSIBLE_BECOME=true
  export ANSIBLE_COMMAND_WARNINGS=false

  Terminál

  source env.sh
  ansible-playbook ...

  Ezt el lehet felejteni véletlenül, de elkerüleheted, ha a playbook első taskjaként egy, a betöltendő fájlban definiált változót ellenőrzöl.

  env.sh

  export CURRENT_ENV_FILE="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)/$(basename "${BASH_SOURCE[0]}")"

  export ANSIBLE_BECOME=true
  export ANSIBLE_COMMAND_WARNINGS=false

  Playbook

  - hosts: remotes
    tasks:
      - name: Check sourced variables
        vars:
          expectedEnvFile: "{{ playbook_dir }}/env.sh"
          currentEnvFile: "{{ lookup('env', 'CURRENT_ENV_FILE') }}"
        fail:
          msg: Run "source {{ expectedEnvFile }}" before ansible-playbook
        when: currentEnvFile != expectedEnvFile
      # more tasks

  Ha ehhez még hozzátesszük, hogy az ansible telepíthető pip-pel egy lokális python környezetbe, amit szintén hasonlóan lehet betölteni, megmutatkozik a megoldás igazi ereje:

  env.sh

  # export ...
  source venv/bin/activate

  Lásd például az Ansible alapok című cikkben.

• Szkript szintű változók: Van, hogy egy adott esethez készítesz egy wrapper szkriptet az alapértelmezettől eltérő paraméterezéssel. Ilyenkor a szkriptben a playbook futtatása előtt is felsorolhatod a szükséges beállításokat:

  export ANSIBLE_BECOME=true
  export ANSIBLE_COMMAND_WARNINGS=false

  ansible-playbook ...

• Inline változók: Ha csak gyorsan kipróbálnál egy beállítást, azért aligha írsz külön szkriptet, de átadhatod kivételesen az "ansible-playbook" program előtt:

  ANSIBLE_COMMAND_WARNINGS=false ansible-playbook ...

Parancssori paraméterekkel

[Tartalom]

Van néhány olyan beállítás, amit az ansible vagy ansible-playbook programoknak is át lehet adni. Ilyen például többek között a --forks, ami a párhuzamosan futtatható processzek számát határozza meg, és a --timeout ami másodpercekben adja meg a célszerverekhez a csatlakozási kísérletre fordítható maximális időt.

Ha nincs más beállításra szükséged, valószínűleg nem is fogsz konfigurációs fájlokat létrehozni, sem pedig környezeti változókat definiálni. De még ha van is más beállítás, ha az egyes ansible-playbook parancsaid csak ezekben a paraméterekben térnek el, megint csak jó választás lehet így átadni őket.

Néhány fontosabb beállítás

[Tartalom]

Az alábbiakban az említésre méltó konfigurációs lehetőségekből szemezgetek, ám valójában mind említésre méltó, így ha komolyan gondolod az Ansible használatát, alaposabban tanulmányozd át a dokumentációt, mik lesznek számodra relevánsak.

A listában az egyes beállítások dokumentációban szereplő nevére hivatkozom, ami olykor megegyezik a környeezeti változó nevével, de nem mindig. A konfigurációs fájlban pedig teljesen mást kell megadni ezért a részletekért mindig a dokumentációt keresd fel!

• ANSIBLE_PIPELINING: Ez egy nagyon fontos beállítás, mivel nagyban befolyásolja a playbook lefutásának sebességét. Alapesetben a futtatandó task-ok mind külön SSH kapcsolat létesítését jelentik, ráadásul egy task futtatásához nem is elég egy SSH kapcsolat. A szükséges python kód fel lesz töltve a célszerverekre egy ideiglenes mappába, majd külön kapcsolatban lefutnak az utasítások, a végén pedig törlődnek az ideiglenes mappák is, ha másképp nem döntesz. A pipelining segítségével viszont egyszerre több task is futtatható egyetlen kapcsolaton. Első lépésben elindul a python értelmező a célszerveren, majd ezen a kapcsolaton lesznek átadva a python utasítások az értelmezőnek. Ekkor viszont meg kell bizonyosodni róla, hogy a célszervereken az /etc/sudoers fájlban nincs engedélyezve "Defaults" sorban a "requiretty" opció, ami a "require TTY"-t jelenti és nem egy újkeletű angol szó. :). Megjegyzem, ez az opció jó eséllyel nem is lesz engedélyezve.

• DEFAULT_KEEP_REMOTE_FILES: Ez az opció változóként valójában az ANSIBLE_KEEP_REMOTE_FILES névre hallgat és éppen ez felel azért, hogy a távoli fájlok a taskok lefutása után ne legyenek törölve. Debugoláskor érdekes lehet. Ha viszont ezt engedélyezed, a pipelining ki lesz kapcsolva, mivel akkor nem is másolna fel semmit amúgy sem. Ez tipikusan olyan, amit mondjuk inline változóként adsz meg alkalmanként.

• DEFAULT_LOG_PATH: Avagy változóként ANSIBLE_LOG_PATH egy fájl útvonalat vár, ahova az egyébként a terminál outputba is bekerülő tartalom lesz naplózva. Ha gyakran futtatod a playbookodat sok taskkal, érdemes valamilyen feltétel alapján mindig más útvonalat megadni. Például a változó értékének egy időbélyeget tartalmazo suffixet adni vagy legalább időnként üríteni a naplófájlt.

• DEFAULT_PRIVATE_ROLE_VARS: Az Ansible változók és precedenciájuk című cikkben említettem azokat a role változókat is, amiket hiába definiálsz a role listában egy adott role alatt, a többi is látni fogja. Ez a beállítás éppen ezt a viselkedést változtatja meg, azaz csak az adott role-nál lesznek a változók elérhetők. Változóként az ANSIBLE_PRIVATE_ROLE_VARS néven éred el.

• DEFAULT_UNDEFINED_VAR_BEHAVIOR: A ANSIBLE_ERROR_ON_UNDEFINED_VARS változóval azon a viselkedésen változtathatnál, hogy egy definiálatlan változó megállítsa-e a playbook futását vagy sem. Alapértelmezetten ez az opció engedélyezve van és az esetek többségében ez így is van jól, de azért jó tudni a létezéséről.

Összefoglalás

[Tartalom]

Ismét sok ismerettel gazdagodhattál immár az Ansible konfigurációja terén, amire nem egy megoldás létezik. Általában viszont egy projektszintű konfiguráció fájlt javaslok, hiszen abban minden beállítást megadhatsz. Ha viszont valamit dinamikusan szeretnél megadni, a változók használata jobb választás lehet. A változók betöltésének elmulasztása érdekében a playbookokba is beilleszthető egy, a betöltést ellenőrző task. Így komolyann logikát is bevihetsz a konfigurációba, de érdemes amennyire lehet, átláthatóvá tenni a beállíásokat. Ha a cikkben tárgyalt összes megoldást egyszerre alkalmaznád, abból hamar káosz lenne.

A beállítások közül csak néhányat tudtam említeni a cikkben. Te milyen beállításokat tartasz fontosnak? Mik azok, amiknek az értelmére még nem jöttél rá? Írd meg kommentben. Ha tanultál valami újat, like-old a cikket facebookon. Ha úgy gondolod, van ismerősöd, aki tanulhat belőle, ne habozz megosztani vele a linket.