Ансибл 3. део
Аутор: Стефан Ножинић
У претходном делу сте могли прочитати како се подешава инвентар и ту сте видели како можемо одржавати више сервера те њима проследити одређене параметре и класификовати их у групе на основу њихове намене. Сада је време да пређемо на праву ствар и да покажемо шта још Ансибл може да ради. У овом тексту дајемо реалне примере које ћемо објаснити и који се често користе. На крају дајемо и неке опште корисне савете из праксе којих се треба придржавати како би вам код био уредан и како бисте могли лако одржавати своју конфигурацију.
Ако пратите наш серијал о Вагранту, онда сигурно знате да Ансибл можете применити и кроз Вагрант приликом креирања своје виртуелне машине.
Најпре почињемо од основних појмова, а потом прелазимо на комплексније ствари и савете.
Плејбукови
Могло би се рећи да тек овде почиње магија и чаролија овог алата. Све до сада се могло извести и без Ансибла уз мало више куцкања, али на овом делу се види колико Ансибл олакшава процес (прим. аут.). Исто тако, у почетку је можда свакоме чудан овај концепт, али то је нормално ако се први пут сусрећете са системима оркестрације сервера. Замислимо да морате да одржавате више продавница. Сада замислимо да имате роботе (модуле) од којих су неки задужени за чишћење, неки за паковање робе, а неки за отварање и затварање продавнице.
У том случају бисте ви морали да напишете правила по којима ће се роботи понашати. Рецимо, желите да се све продавнице прво затворе и потом почисте, да се спакује роба, а после паковања да се продавнице поново очисте. Све док продавница није чиста, она не сме да се отвори.
Сада ово можемо превести на наш главни проблем – нама су продавнице рачунари који могу бити удаљени сервери, виртуелне машине, или ваш локални систем. Роботи су нам модули Ансибла, а наш план који куцамо је заправо плејбук (енг. playbook).
Дакле, ми пишемо план у облику текстуалног фајла, а потом то проследимо Ансиблу. Он треба да на основу те наше спецификације жељеног стања конфигурише систем. Касније ћете видети како се ови планови раздвајају у посебне фајлове ради лакше организације и одржавања.
Овај приступ је много погодан за велике системе јер вам омогућава да држите ваше спецификације у систему контроле верзија као што су то git или svn.
Спецификације Ансибла, плејбукови, пишу се у YAML синтакси. Овај формат је интуитиван и није га потребно учити посебно. Лако се чита и из кода се јасно види шта се жели постићи. Ове спецификације су управо то – дакле, нису скрипте са разним петљама и слично. Код писања спецификација се тежи великој прецизности. Организоване су тако да их је лако разумети. Разуме их чак и онај ко нема искуства са Ансиблом.
Почињемо сада од тривијалног примера. Имамо дефинисане веб-сервере и желимо подесити Апачи на њима. У том случају би наша спецификација изгледала овако:
---
- 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
Као што видите, спецификација је веома интуитивна и лако се чита. На почетку дефинишемо на које сервере се односи спецификација као и променљиве које прослеђујемо (ово ће се користити у обрасцима – енг. templates). Дефинишемо и корисника преко ког ће се Ансибл логовати и на којем ће се извршавати команде. У групи са задацима се дефинишу следећи задаци: прво проверавамо да ли је Апачи инсталиран, а када то урадимо, подешавамо конфигурациону датотеку из обрасца који се налази на локацији /srv/httpd.j2 – затим на крају покрећемо сервис. Имамо и један управљач (енг. handler), који се покреће после конфигурације и који је задужен за рестартовање сервиса.
Јако је важно да удвајате код као у примеру јер се у супротном спецификација неће понашати очекивано. Поред тога, удвајање је један од начина добре праксе и добре организације кода. На овај начин ћете ваш код моћи да разумете и после неколико месеци без развоја и рада на истом.
Спецификација је тако састављена и Ансибл тако функционише да ће извршити промене на систему само ако су оне потребне. Ово значи да спецификацију можете извршити више пута, а она ће промене направити само кад мора да би систем довела у жељено стање.
За више примера препоручујемо да погледате званичну страницу документације, где можете пронаћи ризницу са доста примера за различите методе и концепте. Ако будете имали тешкоћа и нејасноћа, препоручујемо да контактирате с нама на нашу адресу електронске поште.
Покретање односно извршавање спецификације постиже се употребом команде ansible-playbook на следећи начин:
ansible-playbook specifikacija.yml -f 10
Потребно је приметити да смо задали и ниво паралелизма односно број форкованих процеса (10 у нашем случају).
Добра пракса и организација кода
Документација каже да користите роле. Ми то исто кажемо. У наставку се то јасније види.
Директоријум треба имати овакву структуру:
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/ ... ...
Ево како би изгледао site.yml:
- hosts: webservers roles: - common - web
Сада можемо покренути
ansible-playbook site.yml -i production
који ће извршити целу конфигурацију.
У нашем примеру имамо само један инвентар, али их можемо имати више уколико, рецимо, желимо раздвојити сервере за продукцију и за тест.За више детаља и више примера препоручујемо да прочитате документацију Ансибла. Тамо можете наћи референце за све модуле које можете користити.
Овим текстом завршавамо серијал. Ако мислите да смо нешто важно пропустили, или мислите да смо нешто лоше објаснили, пишите нам на адресу наше електронске поште.