Ansibl 3. deo

Autor: Stefan Nožinić

U prethodnom delu ste mogli pročitati kako se podešava inventar i tu ste videli kako možemo održavati više servera te njima proslediti određene parametre i klasifikovati ih u grupe na osnovu njihove namene. Sada je vreme da pređemo na pravu stvar i da pokažemo šta još Ansibl može da radi. U ovom tekstu dajemo realne primere koje ćemo objasniti i koji se često koriste. Na kraju dajemo i neke opšte korisne savete iz prakse kojih se treba pridržavati kako bi vam kod bio uredan i kako biste mogli lako održavati svoju konfiguraciju.

Ako pratite naš serijal o Vagrantu, onda sigurno znate da Ansibl možete primeniti i kroz Vagrant prilikom kreiranja svoje virtuelne mašine.

Najpre počinjemo od osnovnih pojmova, a potom prelazimo na kompleksnije stvari i savete.

Moglo bi se reći da tek ovde počinje magija i čarolija ovog alata. Sve do sada se moglo izvesti i bez Ansibla uz malo više kuckanja, ali na ovom delu se vidi koliko Ansibl olakšava proces (prim. aut.). Isto tako, u početku je možda svakome čudan ovaj koncept, ali to je normalno ako se prvi put susrećete sa sistemima orkestracije servera. Zamislimo da morate da održavate više prodavnica. Sada zamislimo da imate robote (module) od kojih su neki zaduženi za čišćenje, neki za pakovanje robe, a neki za otvaranje i zatvaranje prodavnice.

U tom slučaju biste vi morali da napišete pravila po kojima će se roboti ponašati. Recimo, želite da se sve prodavnice prvo zatvore i potom počiste, da se spakuje roba, a posle pakovanja da se prodavnice ponovo očiste. Sve dok prodavnica nije čista, ona ne sme da se otvori.

Sada ovo možemo prevesti na naš glavni problem – nama su prodavnice računari koji mogu biti udaljeni serveri, virtuelne mašine, ili vaš lokalni sistem. Roboti su nam moduli Ansibla, a naš plan koji kucamo je zapravo plejbuk (eng. playbook).

Dakle, mi pišemo plan u obliku tekstualnog fajla, a potom to prosledimo Ansiblu. On treba da na osnovu te naše specifikacije željenog stanja konfiguriše sistem. Kasnije ćete videti kako se ovi planovi razdvajaju u posebne fajlove radi lakše organizacije i održavanja.

Ovaj pristup je mnogo pogodan za velike sisteme jer vam omogućava da držite vaše specifikacije u sistemu kontrole verzija kao što su to git ili svn.

Specifikacije Ansibla, plejbukovi, pišu se u YAML sintaksi. Ovaj format je intuitivan i nije ga potrebno učiti posebno. Lako se čita i iz koda se jasno vidi šta se želi postići. Ove specifikacije su upravo to – dakle, nisu skripte sa raznim petljama i slično. Kod pisanja specifikacija se teži velikoj preciznosti. Organizovane su tako da ih je lako razumeti. Razume ih čak i onaj ko nema iskustva sa Ansiblom.

Počinjemo sada od trivijalnog primera. Imamo definisane veb-servere i želimo podesiti Apači na njima. U tom slučaju bi naša specifikacija izgledala ovako:

--- - hosts: webservers vars: http_port: 80 max_clients: 200 remote_user: root tasks: - name: ensure apache is at the latest version yum: pkg: httpd state: latest - name: write the apache config file template: src: /srv/httpd.j2 dest: /etc/httpd.conf notify: - restart apache - name: ensure apache is running service: name: httpd state: started handlers: - name: restart apache service: name: httpd state: restarted

Kao što vidite, specifikacija je veoma intuitivna i lako se čita. Na početku definišemo na koje servere se odnosi specifikacija kao i promenljive koje prosleđujemo (ovo će se koristiti u obrascima – eng. templates). Definišemo i korisnika preko kog će se Ansibl logovati i na kojem će se izvršavati komande. U grupi sa zadacima se definišu sledeći zadaci: prvo proveravamo da li je Apači instaliran, a kada to uradimo, podešavamo konfiguracionu datoteku iz obrasca koji se nalazi na lokaciji /srv/httpd.j2 – zatim na kraju pokrećemo servis. Imamo i jedan upravljač (eng. handler), koji se pokreće posle konfiguracije i koji je zadužen za restartovanje servisa.

Jako je važno da udvajate kod kao u primeru jer se u suprotnom specifikacija neće ponašati očekivano. Pored toga, udvajanje je jedan od načina dobre prakse i dobre organizacije koda. Na ovaj način ćete vaš kod moći da razumete i posle nekoliko meseci bez razvoja i rada na istom.

Specifikacija je tako sastavljena i Ansibl tako funkcioniše da će izvršiti promene na sistemu samo ako su one potrebne. Ovo znači da specifikaciju možete izvršiti više puta, a ona će promene napraviti samo kad mora da bi sistem dovela u željeno stanje.

Za više primera preporučujemo da pogledate zvaničnu stranicu dokumentacije, gde možete pronaći riznicu sa dosta primera za različite metode i koncepte. Ako budete imali teškoća i nejasnoća, preporučujemo da kontaktirate s nama na našu adresu elektronske pošte.

Pokretanje odnosno izvršavanje specifikacije postiže se upotrebom komande ansible-playbook na sledeći način:

ansible-playbook specifikacija.yml -f 10

Potrebno je primetiti da smo zadali i nivo paralelizma odnosno broj forkovanih procesa (10 u našem slučaju).

Dokumentacija kaže da koristite role. Mi to isto kažemo. U nastavku se to jasnije vidi.

Direktorijum treba imati ovakvu strukturu:

production - inventar za produkciju site.yml - glavna specifikacija group_vars/ grupa1 grupa2 host_vars/ server1 server2 roles/ common/ tasks/ main.yml handlers/ main.yml templates/ ntp.conf.j2 httpd.conf.j2 files/ bar.txt foo.txt vars/ main.yml defaults/ main.yml meta/ main.yml web/ ... isto kao i za common python/ ... ...

Evo kako bi izgledao site.yml:

  - hosts: webservers roles: - common - web

Sada možemo pokrenuti

ansible-playbook site.yml -i production

koji će izvršiti celu konfiguraciju.

U našem primeru imamo samo jedan inventar, ali ih možemo imati više ukoliko, recimo, želimo razdvojiti servere za produkciju i za test.Za više detalja i više primera preporučujemo da pročitate dokumentaciju Ansibla. Tamo možete naći reference za sve module koje možete koristiti.

Ovim tekstom završavamo serijal. Ako mislite da smo nešto važno propustili, ili mislite da smo nešto loše objasnili, pišite nam na adresu naše elektronske pošte.