Többször írtam már a Dockerről, aminek sok előnyét lehet említeni, de ez nem jelenti azt, hogy ne maradna olyan feladat, amit ettől függetlenül meg kellene oldani. Elég csak arra gondolni, hogy már a Dockert is telepíteni kell. Nem beszélve az egyéb nem, vagy nehezen konténerizálható szolgáltatásokról és azok függőségeiről, illetve az éppen a Docker miatt felmerülő további feladatokról.
Természetesen ez a két szoftver egymástól függetlenül használható, de ha a Docker szóba kerül, nagyon gyakran felmerül az Ansible is, mint eszköz. A segítségével azok a műveletek is leírhatók és verziózhatók, amik nem spórolhatók meg Docker image-ek létrehozásával.
Ez persze még nem minden, ráadásul alternatívák is vannak az Ansible-re, én viszont ebben a cikkben az Ansible 2.8 alapjairól fogok írni.
Tartalomjegyzék
- Mire jó az Ansible
- Telepítés
- Ansible és Ansible Playbook
- Példafeladatok
- Utasítások hierarchiája a taskoktól felfelé
- Összefoglalás
- Források
Mire jó az Ansible
[Tartalom]
Ahogy említettem, az Ansible nem az egyetlen a maga kategóriájában, ahogy általában mindenre van alternatíva. Ezek nem feltétlenül egyaránt alkalmasak bizonyos feladatokra, de hasonló a céljuk. Itt érdemes megemlíteni a Chefet, a Puppetet és a Terraformot a HashiCorptól, akik egyébként a Vagrantért is felelősek, amiről már korábban írtam. Koncentráljunk most mégis az Ansible-re. Néhány pontban megpróbálom összefoglalni, mire is jó.
-
Utasítások lefuttatására egyszerre több szerveren. Add meg az utasítást, definiáld a célszervereket és legyen például SSH hozzáférésed ezekhez a szerverekhez.
-
Konfiguráció menedzsmentre. Az előző pontból adódik, hogy természetesen megint csak egyszerre több szerveren. Definiáld a kívánt konfigurációt és az ennek alkalmazására szükséges utasítást
- Deploymentre, szolgáltatások telepítésére. Még akkor is, ha ez Dockerrel történik, lesznek olyan feladatok, amit a hoszt rendszeren kell elvégezni, vagy csak kezelni a Docker Compose projektek közös paramétereit, mint az aktuális proxy hálózat.
- Komplett virtuális környezetek felépítése, tesztkörnyezetek egy mozdulattal történő telepítése
Tehát egy teljes infrastruktúrát le lehet írni (Infrastructure as Code / IaC), majd ezt például egy Git repoban tárolni. Ettől függetlenül maradhatnak még manuálisan elvégzendő feladatok, de mindent, amit lehet, beépítünk a futtatható kódba.
Ha arra gondolsz, hogy ezt lehetne egyszerű Bash szkriptekkel is, akkor igazad is van, meg nem is. Az Ansible és a hasonló eszközök legnagyobb előnye sem az, amit meg lehet velük oldani, hanem az, ahogy. Az egyes utasítások sikerességét sok esetben nem kell külön ellenőrizned, csak meghatározni a kívánt állapotot, a többit pedig az Ansible intézi. Például szükséged van egy programcsomagra. Csak definiálod az igényt, és ha nincs még telepítve, megpróbálja feltenni. Ha nem sikerült, mert például hibás a csomag neve, az Ansible alapértelmezetten leállítja a folyamatot és név szerint látni fogod, melyik feladatnál történt a hiba. Az utasítások jórészt deklaratívan vannak leírva YAML formátumban, de nincs akadálya összetettebb programok, szkriptek futtatásának sem. Mindezek mellett használható a Jinja template rendszer, ami a Python programozóknak ismerős lehet, de a PHP programozók is találkozhatttak egy változatával a Symfony keretrendszerben. Ez pedig a Twig.
Az Ansible alapértelmezett viselkedését változók segítségével vagy konfigurációs fájlokkal módosítani lehet. Ezeket fontos ismerni, mert szükség is van rájuk. Ha pedig nem szeretnél mindent magad megoldani, létezik egy "csomagkezelő", az Ansible Galaxy, ahol különböző role-ok között lehet böngészni. A role-okról hamarosan szó lesz bővebben is.
Szereted a grafikus adminisztrációs felületeket? Akkor az Ansible Towerrel is ismerkedhetsz, ami ugyan nem ingyenes, de létezik egy ingyenes verziója is a GitHub-on, az AWX.
Telepítés
[Tartalom]
Telepíthető Linux csomagkezelőkkel, mint apt, yum, dnf, pacman többek között. Az alábbit írja például a dokumentáció Ubuntuhoz.
sudo apt install software-properties-common
sudo apt-add-repository --yes --update ppa:ansible/ansible
sudo apt install ansible
Bár a hivatalos dokumentáció ezt a fajta telepítést javasolja, azon kivételek egyike ez, amikor nem értek vele egyet. Ebben az esetben ugyanis egy verziót tudsz csak használni, márpedig a projekt érzékeny lehet az Ansible verziójára. Egyes modulok esetleg másképp működhetnek, és ugye nem szeretnéd az összes projektet egyszerre átírni. Vannak persze modulok, amiknél garantálják a visszafelé kompatibilitást, de ha nem szeretnél meglepetéseket, mindenképpen projektszinten javaslom a telepítést Pythonnal például virtualenv-vel vagy Pipenv-vel.
A pontosság kedvéért megjegyzem, hogy a Python telepítés és virtuális környezet létrehozása valamivel komplikáltabb a hivatalosan javasolt telepítésnél, valamint eltérő rendszereknél más lehet a módja, ezért ha csak ismerkedsz az Ansible-lel, nyugodtan válaszd a hivatalosan javasolt módszert. Az alábbi megoldás Ubuntu 19.04-en lett tesztelve:
# FIGYELEM: Az alábbi parancs megváltoztatja az alapértelmezett pip-et
# az aktuális felhasználónál pip3 -ra, ha előtte régebbi verzió volt telepítve.
# Ha a $HOME/.local/bin még nem volt a PATH-ban, a legközelebbi belépéskor
# lesz elérhető az új pip
pip3 install --user --upgrade pip
pip3 install --user virtualenv
mkdir myproject
cd myproject
python3 -m virtualenv myproject-env
source myproject-env/bin/activate
pip3 install ansible
A fenti utolsó sor az Ansible legújabb verzióját telepíti a lokális python környezetbe, ami egy új projekt esetén jó választás. Érdemes viszont lefixálni a telepített verziót, hogy később, adott esetben egy másik gépen vagy más fejlesztő számára a git-ből letöltött verziónál se települjön újabb ansible.
Legközelebb pedig a "pip3 install ansible" helyett az alábbi parancsot kell futtatni, hogy garantáltan az első telepítéskor használt csomagok legyenek ismét telepítve:
Verziókezelőbe feltöltve a létrejött myproject-env mappát mindenképp vedd fel a fel nem töltendő kivételek közé. Git esetén a ".gitignore" fájlban.
További információkért ajánlom a fent linkelt git projekt leírásáát is.
Telepítés Windowson
Bár a Python Windowsra is elérhető, az Ansible csomag telepítése már nem annyira triviális. Lehetőség van akár docker konténerben telepíteni az Ansible-t, ami még szintén nem a pofon egyszerű kategória Windows hoszton, vagy A WSL is használható, esetleg virtuális gép.
Ansible és Ansible Playbook
[Tartalom]
Az "ansible" és az "ansible-playbook" program amivel a legtöbbet fogsz találkozni. Ha a Dockert már ismered, akkor talán azt mondhatnám, hogy az "ansible-playbook" olyan az "ansible"-nek, mint a "docker-compose" a "docker"-nek. Főként YAML fájlokkal dolgozik és míg az ansible arra való, hogy egy egyszerűbb utasítást lefuttass több szerveren, például mindegyiken elindíts manuálisan egy mentést, az ansible-playbookkal utasítások egész halmazát fogod lefuttatni. Ezek a futtatandó utasítások viszont egy megadott hierarchiába vannak szervezve, csoportosítva és akár feltételes elágazásokkal megvalósítva.
Példafeladatok
[Tartalom]
Most lépésről lépésre bemutatom, hogyan dolgozhatsz az Ansible-lel a világ legegyszerűbb példájától kezdve az összetettebb, de még mindig egyszerű példákig. Ehhez készítettem egy Git repository-t, ami elérhető a GitHub-on: itsziget/ansible-examples. Első lépésben töltsd le a projektet, amire a példák hivatkozni fognak. A linken a cikkben használt verziót éred el közvetlenül, de elképzelhető, hogy a cikk megírása után további példák kerülnek fel, így a legfrissebb verzióra is érdemes vetni időnként egy pillantást.
A példautasításokat mindig az adott példa mappájába beléépve kell futtatni a "run.sh" segítségével, de a cikkben idézem az egyszerűség kedvéért a szkript tartalmát is.
TIPP: A letöltött projektben a mappákba egyenként belépés helyett az alábbi módon is futtathatod a parancsokat:
Például:
Teszt virtuális gép indítása (Opcionális)
[Tartalom]
Ez a lépés opcionális, mivel, ha már van saját teszt virtuális géped, vagy bármilyen szervered, amin tesztelni tudsz, az is használható. Hasznos, ha nem tudsz vagy nem akarsz VirtualBoxot telepíteni. Ekkor viszont módosítanod kell a mellékelt szkripteket és konfigurációs fájlokat, így ajánlott ezzel a lépéssel kezdeni.
Korábban már írtam röviden a Vagrant telepítéséről és használatáról. Ennek a cikknek most nem célja mélyebben belemenni a témába, de ha problémába ütközöl, írj bátran kommentben.
A Vagrant telepítése után a projekt gyökérkönyvtárából futtathatod az alábbi utasítást, hogy elinduljon a virtuális gép.
Alapértelmezettként a 127.0.0.1-es IP címen, a 2222-es porton lesz elérhető az SSH vagrant felhasználóval. A jelszó is "vagrant", de ezzel nem lehet bejelentkezni, csak SSH kulccsal, amit a Vagrant automatikusan létrehoz a következő útvonalon a projekt gyökeréhez képest:
Tesztelheted is a bejelentkezést az alábbi módon:
ssh vagrant@127.0.0.1 -p 2222 -i .vagrant/machines/default/virtualbox/private_key
Erre kizárólag az Ansible miatt van szükség. A Vagrant virtuális gépbe a vagrant paranccsal is beléphetsz az alábbi módon sokkal egyszerűbben:
Ha pedig nem működne a bejelentkezés, mert például másik porton vagy más IP címmel jött létre a virtuális gépedhez a kapcsolat, a vagrant azt is meg tudja mutatni, milyen adatokkal kell kapcsolódnod:
Ad-Hoc Ansible utasítás
[Tartalom]
Példa: 01-ad-hoc
Oké, most, hogy települt az Ansible, nézzük is rögtön a legegyszerűbb utasítást, amit az eddigi ismeretekkel már el tudsz indítani. Később majd utasítások egész sorának indítása lesz a cél, de az elemi utasítások elküldését "Ad-Hoc" utasításoknak hívjuk. A példa legyen egyszerűen csak egy SSH kulcssal elérhető szervergépen a gyökérkönyvtárban levő tartalom kilistázása.
all \
--inventory 127.0.0.1:2222, \
--module-name raw \
--args 'ls -la /' \
--user vagrant \
--private-key '../../.vagrant/machines/default/virtualbox/private_key'
A projekt gyökérből az alábbi utasítást kiadva is futtathatod:
Van pár furcsaság benne így elsőre, tudom. Elemezzük hát:
-
all: Amikor csak egy "Ad-Hoc" parancsot futtatsz le és nincs sehol definiálva a szervereidnek egy csoportja egy megadott csoportnéven, akkor az "all" csoportot kell megadni.
-
--inventory: Ebben az esetben az "--inventory" után lehet megadni a szervered ip címét vagy domain nevét egy opcionális portszámmal. Az utána következő vessző karakter viszont kötelező jelezve, hogy itt szerverek listáját adod meg, nem egy konfigurációs fájlt (inventory fájl).
-
--module-name: A "--module-name" egy ansible modul, ami felelős lesz a célszerveren az utasítás futtatásáért. Rengeteg modul létezik és ezek legtöbbjének függősége a Python interpreter, a raw-nak viszont nem. Így ezt akár egy olyan gép vagy router felé is lehet alkalmazni, amin nincs Python telepítve.
-
--args A moduloknak lesznek argumentumai, amit az '--args' után lehet megadni. A legegyszerűbb esetben csak egy argumentum van, de összetetttebb esetekben kulcs-érték párokat kell felsorolni.
-
--user: Mivel a szerver címénél nem adható meg kukac karakterrel a felhasználónév, ezt külön a "--user" után kell írni.
-
--private-key: Az SSH privát kulcs útvonala feltételezve, hogy a publikus kulcs már telepítve van a szerveren. Ha a Vagranttal telepített virtuális géppel tesztelsz, akkor már telepítette a virtuális gépbe.
-
--ask-pass: Ha az autentikáció jelszavas SSH-val történik, akkor az "--ask-pass" érték nélküli ansible argumentumot kell átadni a privát kulcs helyett. Erre a példában nem volt szükség.
Példa: 02-ad-hoc-with-inventory
Mivel a lényeg éppen az volna, hogy egyszerre több szerver felé küldhess utasításokat anélkül, hogy minden alkalommal felsorolnád a tulajdonságaikat, ezt a módszert nem sok esetben tudom gyakorlatban elképzelni. Általában legalább egy inventory fájl van. Ez lehet egy egyszerű "INI" fájl is, de én sokkal átláthatóbbnak gondolom a YAML-t, ezért erre mutatok példát
inventory.yml
hosts:
127.0.0.1:
ansible_user: vagrant
ansible_port: 2222
ansible_ssh_private_key_file: ../../.vagrant/machines/default/virtualbox/private_key
Ilyenkor az alábbira módosul az előző utasítás:
remotes \
--inventory inventory.yml \
--module-name raw \
--args 'ls -la /'
A már az inventory fájlban megadott kapcsolódási adatokon kívül az "all" csoportot is megváltoztattam "remotes"-ra. Így akár több csoport is lehet, de nem kell mindig mindegyiken futtatni a parancsokat.
A projekt gyökérből az alábbi utasítást kiadva is futtathatod:
A legegyszerűbb Ansible playbook
[Tartalom]
Példa: 03-playbook
Az Ansible playbookkal a fenti elemi utasításokból állíthatsz össze egy listát, amik minden szerveren egymás után lefutnak. Azt hiszem, ez az a pont, ahol már nagyobb eséllyel el lehet veszteni a fonalat, ugyanis ez a lista általában több fájlban, speciális mappastruktúrában helyezkedik el. A legegyszerűbb esetben viszont egy újabb yml fájlba már a futtatandó parancs is bekerül, valamint a szervercsoport neve. Ez a fájl a playbook. Nevezzük ezt most playbook.yml-nek.
tasks:
- name: List the content of system root
raw: ls -la /
Az újdonság, hogy itt a parancsnak egy nevet is adtam, ami futtatáskor megjelenik a konzolban. Fontos a megfelelő indentálás, mivel a YAML zárójelek helyett ez alapján azonosítja, melyik kulcs-érték pár vagy lista mi alá tartozik. Ebben a playbookban jelenleg egy darab play van. Ha több szervercsoporton kellene egymás után dolgozni, például a gazda rendszeren telepíteni, legenerálni egy fájlt, amit majd a szerverre fel kell tölteni (pl GPG kulcs), akkor több play is írható egy fájlba:
tasks:
- name: Some command before installing remotes
raw: whoami
- hosts: remotes
tasks:
- name: List the content of system root
raw: ls -la /
Az ansible parancs most így már jóval rövidebb lehet:
A projekt gyökérből az alábbi utasítást kiadva is futtathatod:
Parancs kimenetének megjelenítése playbookkal
[Tartalom]
Példa: 04-playbook-debug
Feltűnhetett, hogy a playbookos megoldással a konzolban nem jelent meg az egyébként kilistázott mappa tartalma. Mivel a playbookoknál nagyon sok parancs futhat egymás után, a kimenet automatikusan el van rejtve, amit egy külön task-ban a "debug" modullal tudsz megjeleníteni. Ehhez csak a playbookoot kell módosítani az alábbira:
tasks:
- name: List the content of system root
raw: ls -la /
register: systemRoot
- name: Debug the previous command's output
debug:
var: systemRoot
- name: Display only the previous command's standard output
debug:
var: systemRoot.stdout_lines
- name: Display only the previous command's standard output using jinja templates
debug:
msg: '{{ systemRoot.stdout_lines }}'
Megfigyelheted, hogy használtam a "register" paramétert, aminek egy változónevet kellett megadnom. Erre a változóra később hivatkozhatok bármilyen azt követő tasknál. A hivatkozásra két módszer van:
-
Egyes esetekben csak a változó nevét kell megadni egy újabb paraméternek, mint a "debug" modul "var" paramétere. Ez a változó tartalmát jeleníti meg. Hasznos, ha nem tudod mit tartalmaz pontosan egy változó.
-
Jinja template-tel szinte bárhol hivatkozhatsz egy változóra. Ilyenkor általában a változó nevét dupla kapcsos zárójelek közé kell tenni, mivel statikus értékeket is megadhatnál és ez jelzi, hogy egy változóról van szó. A "debug" modul "msg" paraméterében tetszőleges szöveget írhatnál, de általában egy vagy több változó értékének kiírásakor hasznos. Fontos, hogy bár nem kötelező idézőjelbe tenni a YAML-ben az értékeket, amikor csak egy változóhivatkozást írsz kapcsos zárójelek között, az a YAML értelmező szerint egy helytelen JSON szintaktika. Ha körülötte más tartalom is van, már egyszerűbben tudja szövegként értelmezni.
A projekt gyökérből az alábbi utasítást kiadva is futtathatod:
Blokkok használata playbookban
[Tartalom]
Példa: 05-playbook-block
Oké, ez eddig gyerekjáték volt, ugye? A helyzet viszont az, hogy általában sokkal bonyolultabb egy playbook és az elvégzendő feladatok, azaz taskok további csoportokra vannak osztva. Egy mód a csoportosításra a blokkok használata. Ezek is taskok bizonyos korlátozásokkal, amiken belül viszont további taskok sorolhatók fel. Ez akkor hasznos, ha taskok egy csoportját nagyon hasonlóan szeretnéd kezelni, például mindegyik, vagy több közülük ugyanarra az általad deklarált változóra hivatkozna. Például egy megadott mappán belül szeretnél műveleteket végezni, de a mappát előtte létre kell hozni (file modul), majd pedig abban egy fájlt hoznál létre (copy modul), majd megjelenítenéd a mappa tartalmát. Az alábbira módosul a playbook:
tasks:
- name: Test file handling in a custom directory
vars :
path: '{{ ansible_env.HOME }}/custom/path'
block:
- name: Create custom directory
file:
state: directory
path: '{{ path }}'
- name: Create custom file
copy:
dest: '{{ path }}/hello.txt'
content: 'Welcome'
- name: List the content of {{ path }}
raw: ls -la {{ path }}
register: systemRoot
- name: Display only the previous command's standard output using jinja templates
debug:
msg: '{{ systemRoot.stdout_lines }}'
A copy modul, ahogy a neve is mutatja, fájlok másolására használható az ansible kontrollerről a célszerverekre, de egyszerűbb esetben akár a playbookban is megadható a fájl tartalma, ahogy azt most én is tettem. Látható még, hogy több helyen is használtam a Jinja template-et, ahol a block kulcsszó felett a "vars" paraméterrel adtam meg a változómat kulcs-érték párként. A változókról egy későbbi cikkben írok bővebben, de most elég annyit tudni, a blokkszinten definiált változó értéke csak a blokkon belül lesz elérhető, ott viszont mindenhol.
A projekt gyökérből az alábbi utasítást kiadva is futtathatod:
Taskok csoportosítása role-okkal
[Tartalom]
Példa: 06-playbook-role
Általános elv az informatikában, hogy készítsünk újrafelhasználható kódokat. A role egy olyan egység, amit ha kellően általánosan meg tudsz írni, másokkal is megoszthatsz a már korábban említett Ansible Galaxy oldalon, illetve tetszőleges sorrendben hivatkozhatsz rájuk a playbookokban. Ezzel több playbookot is készíthetsz, amikben vannak közös feladatok, de csak egyszer kellett leírnod. A role-okat egy külön roles mappa alá szervezzük, amiben minden almappa egy újabb role. Egy role pedig tartalmazhat felmásolandó fájlokat, template-eket, metaadatokat és tetszőleges számú tasklista fájlt is. Ezek a tasklista fájlok az eddig a playbookba írt "tasks" kulcsszó alatti taskokat tartalmazzák.
Az előzőleg elkészített üdvözlő szöveg mentése role használatával az következőképen módosul.
roles/save-hello/tasks/main.yml
vars:
path: '{{ ansible_env.HOME }}/custom/path'
block:
- name: Create custom directory
file:
state: directory
path: '{{ path }}'
- name: Create custom file
copy:
dest: '{{ path }}/hello.txt'
content: 'Welcome'
- name: List the content of {{ path }}
raw: ls -la {{ path }}
register: systemRoot
- name: Display only the previous command's standard output using jinja templates
debug:
msg: '{{ systemRoot.stdout_lines }}'
playbook.yml
roles:
- save-hello
A projekt gyökérből az alábbi utasítást kiadva is futtathatod:
Több tasklista fájl include-ok használatával
[Tartalom]
Példa: 07-playbook-role-with-include
Ahogy egyre nagyobbra nő a projekt és egyre több taskod van, már a blokkok használatával is átláthatatlan lehet a kód. Ilyenkor lehet az "include" modult használni. Az eddigi main.yml tartalmát szétszedheted több fájlba.
roles/save-hello/tasks/create-file.yml
file:
state: directory
path: '{{ path }}'
- name: Create custom file
copy:
dest: '{{ path }}/hello.txt'
content: 'Welcome'
roles/save-hello/tasks/debug.yml
raw: ls -la {{ path }}
register: systemRoot
- name: Display only the previous command's standard output using jinja templates
debug:
msg: '{{ systemRoot.stdout_lines }}'
roels/save-hello/tasks/main.yml
vars:
path: '{{ ansible_env.HOME }}/custom/path'
block:
- name: Include create-file.yml
include: create-file.yml
- name: Include debug.yml
include: debug.yml
Bár az include task-nak is adtam nevet, ez a futtatáskor még nem fog megjelenni, de nincs is sok jelentősége, mivel az előző két fájlban betöltöttt taskok is el vannak nevezve. Sok esetben viszont hasznos egy beszédes nevet adni neki ezzel is érthetővé téve a kódot. Lesz viszont olyan eset, amikor meg is jelenik a név.
A projekt gyökérből az alábbi utasítást kiadva is futtathatod:
Ciklusok használata listák segítségével
[Tartalom]
Példa: 08-playbook-role-with-loop
Van lehetőség taskokat ciklusban is futtatni például a "loop" kulcsszó használatával. A "loop" nem modul, így szinte bármilyen modullal együtt használható, kivéve a blokkokat. Szerencsére bármi kiszervezhető külön fájlba, ami eredetileg blokkban volt. Az előző példában írt blokk tartalmát tehát most ki kell tenni egy küllön fájlba:
roles/save-hello/tasks/loop-content.yml
vars:
path: '{{ ansible_env.HOME }}/custom/{{ item }}'
include: loop-content.yml
loop:
- path-1
- path-2
A loop automatikusan beregisztrálja az "item" változót. Ez nem csak egyszerű szöveges tartalom lehet, hanem tetszőleges struktúra, akár újabb kulcsérték pár is. Természetesen akkor a változóra hivatkozás változik a kulcsok megadásával.
Utasítások hierarchiája a taskoktól felfelé
[Tartalom]
-
task: A legkisebb egység, amit akár a playbookba is írharsz, de role-okba is kiszervezhető.
-
block: Speciális task, ami további taskok listáját tartalmazza, ciklusként viszont nem használható.
-
task fájl: Blokk helyett is használható, majd "include" kulcsszóval betölthető. Ezzel már használható a "loop" kulcsszó, azaz ciklusként is működhet.
-
role: Újra felhasználható egység, ami tartalmazhat a taskok leírásán túl további fájlokat is és megosztható az Ansible Galaxy oldalon.
-
play: Taskokat vagy role-okat rendeli egy szervercsoporthoz vagy szervercsoportokhoz. Ez esetben a taskokhoz vagy role-okhoz hasonlóan listaként kell megadni a csoportok nevét vagy szóközzel elválasztva egymás után.
-
playbook: play-eket tartalmazó fájl, amire az "ansible-playbook" paranccsal hivatkozni kell.
-
inventory fájl: A playbookokban megadott szervercsoportokat tartalmazza kapcsolódási adatokkal és további változókkal.
Összefoglalás
[Tartalom]
Ebben a cikkben az Ansible képességeinek csak egy részéről volt szó. Valójában a "raw'" modult nagyon ritkán használjuk. Helyette a shell vagy a command is bevethető. Komolyabb konfigurációról sem volt szó, ez viszont várható újabb cikkben a későbbiekben. Remélem, sikerült egy képet adnom az alapokról és az Ansible felépítéséről, amivel akár már magad is továbbléphetsz. Ne felejts el viszont visszanézni időnként, mert készülök több újabb cikkel is a témában.
Ha tetszett a cikk, kattints a "tetszik" gombra és oszd meg másokkkal is. Ha szeretnél értesülni az új cikkekről, kövesd az oldalt facebookon, illetve várom a javaslatokat új cikktémákra.
Források
[Tartalom]
