Kas yra Ansible ir kodėl jis tapo administratorių favoritu
Jei administruojate daugiau nei vieną Linux serverį, tikrai esate susidūrę su situacija, kai reikia atlikti tą pačią operaciją dešimtyse ar net šimtuose mašinų. Rankinis darbas čia tampa ne tik nuobodus, bet ir pavojingas – viena klaida, ir galite praleisti valandas ieškodami, kur suklydote. Būtent čia į sceną įžengia Ansible.
Ansible – tai automatizavimo įrankis, kuris leidžia valdyti infrastruktūrą naudojant paprastus YAML formato failus, vadinamus playbooks. Skirtingai nei kai kurie kiti konfigūracijos valdymo įrankiai, Ansible nereikalauja jokių agentų tikslinėse sistemose – jam pakanka SSH prieigos. Tai reiškia, kad galite pradėti naudoti Ansible praktiškai iš karto, be jokių sudėtingų paruošiamųjų darbų.
Ansible populiarumas augo ne be priežasties. Jis paprastas pradedantiesiems, bet pakankamai galingas profesionalams. YAML sintaksė yra intuityvi ir lengvai skaitoma net tiems, kas nėra programuotojai. Be to, Ansible turi milžinišką modulių biblioteką, kuri leidžia valdyti viską – nuo paprastų failų iki sudėtingų Docker konteinerių ar debesų infrastruktūros.
Pirmieji žingsniai su Ansible playbooks
Prieš pradedant kurti sudėtingus playbooks, reikia suprasti pagrindinę struktūrą. Ansible playbook – tai iš esmės instrukcijų rinkinys, parašytas YAML formatu, kuris nurodo, ką ir kaip reikia padaryti jūsų serveriuose.
Paprasčiausias playbook gali atrodyti taip:
„`yaml
—
– name: Atnaujinti sistemą ir įdiegti būtinus paketus
hosts: webservers
become: yes
tasks:
– name: Atnaujinti apt cache
apt:
update_cache: yes
cache_valid_time: 3600
– name: Įdiegti nginx
apt:
name: nginx
state: present
„`
Šis pavyzdys parodo kelis svarbiausius elementus. Pirmiausia, nurodome, kokiems serveriams (hosts) taikysime šias instrukcijas. Tada `become: yes` nurodo, kad komandos bus vykdomos su root teisėmis. Kiekviena užduotis (task) turi savo pavadinimą ir naudoja konkretų modulį – šiuo atveju `apt` modulį paketų valdymui.
Svarbu suprasti, kad Ansible dirba idempotentiškai. Tai reiškia, kad galite paleisti tą patį playbook kelis kartus, ir jis atliks pakeitimus tik tada, kai reikia. Jei nginx jau įdiegtas, Ansible tiesiog praneš, kad viskas jau yra tinkamoje būsenoje.
Inventory failai ir serverių grupavimas
Prieš pradedant rašyti playbooks, reikia sukurti inventory failą – tai sąrašas visų jūsų valdomų serverių. Paprasčiausias inventory gali būti tekstinis failas su IP adresais ar hostnames:
„`ini
[webservers]
web1.example.com
web2.example.com
192.168.1.10
[databases]
db1.example.com
db2.example.com
[production:children]
webservers
databases
„`
Čia matome serverių grupavimą pagal funkcijas. Galite turėti web serverius, duomenų bazes, cache serverius ir pan. Grupės gali būti hierarchinės – pavyzdžiui, `production` grupė apima ir `webservers`, ir `databases`.
Inventory failuose taip pat galite nurodyti kintamuosius konkretiems serveriams ar grupėms:
„`ini
[webservers]
web1.example.com ansible_user=admin ansible_port=2222
web2.example.com ansible_python_interpreter=/usr/bin/python3
[webservers:vars]
http_port=80
max_clients=200
„`
Tai labai patogu, kai skirtingi serveriai turi skirtingas konfigūracijas ar prieigos parametrus. Nebereikia kiekvienam serveriui rašyti atskiro playbook – tiesiog naudojate kintamuosius.
Rolės – kaip struktūrizuoti sudėtingus projektus
Kai jūsų playbooks pradeda augti, jie tampa sunkiai valdomi. Čia į pagalbą ateina Ansible rolės (roles). Rolė – tai standartizuotas būdas organizuoti playbooks, kintamuosius, failus ir šablonus į loginius vienetus.
Tipinė rolės struktūra atrodo taip:
„`
roles/
webserver/
tasks/
main.yml
handlers/
main.yml
templates/
nginx.conf.j2
files/
index.html
vars/
main.yml
defaults/
main.yml
„`
Kiekvienas katalogas turi savo paskirtį. `tasks` – pagrindinės užduotys, `handlers` – veiksmai, kurie vykdomi tik esant pakeitimams (pvz., serviso perkrovimas), `templates` – Jinja2 šablonai, `files` – statiniai failai, o `vars` ir `defaults` – kintamieji.
Naudojant roles, jūsų pagrindinis playbook tampa labai paprastas:
„`yaml
—
– name: Konfigūruoti web serverius
hosts: webservers
roles:
– common
– webserver
– monitoring
„`
Tokia struktūra leidžia pakartotinai naudoti kodą. Jei turite kelis projektus, galite tą pačią `common` rolę naudoti visuose. Tai sutaupo laiko ir sumažina klaidų tikimybę.
Praktiniai pavyzdžiai kasdieniniam darbui
Pažiūrėkime į kelis realistiškus scenarijus, su kuriais susiduria kiekvienas Linux administratorius.
**Vartotojų valdymas**
Viena dažniausių užduočių – vartotojų kūrimas ir valdymas. Štai kaip tai padaryti su Ansible:
„`yaml
– name: Valdyti sistemos vartotojus
hosts: all
become: yes
tasks:
– name: Sukurti deploy vartotoją
user:
name: deploy
shell: /bin/bash
groups: sudo
append: yes
create_home: yes
– name: Pridėti SSH raktą
authorized_key:
user: deploy
key: „{{ lookup(‘file’, ‘~/.ssh/id_rsa.pub’) }}”
state: present
„`
Šis playbook sukuria vartotoją, prideda jį į sudo grupę ir nukopijuoja jūsų viešąjį SSH raktą. Paleiskite jį 50 serverių – ir per kelias minutes visi turės identišką konfigūraciją.
**Failų ir konfigūracijų valdymas**
Dažnai reikia nukopijuoti konfigūracijos failus į serverius. Ansible siūlo kelis būdus tai padaryti:
„`yaml
– name: Konfigūruoti nginx
hosts: webservers
become: yes
tasks:
– name: Kopijuoti nginx konfigūraciją
template:
src: templates/nginx.conf.j2
dest: /etc/nginx/nginx.conf
owner: root
group: root
mode: ‘0644’
notify: Perkrauti nginx
– name: Užtikrinti, kad nginx veikia
service:
name: nginx
state: started
enabled: yes
handlers:
– name: Perkrauti nginx
service:
name: nginx
state: reloaded
„`
Čia naudojame `template` modulį, kuris leidžia naudoti kintamuosius konfigūracijos failuose. Jinja2 šablonas gali atrodyti taip:
„`nginx
worker_processes {{ ansible_processor_vcpus }};
server {
listen {{ http_port }};
server_name {{ inventory_hostname }};
location / {
proxy_pass http://{{ backend_server }};
}
}
„`
Ansible automatiškai pakeičia visus kintamuosius realiomis reikšmėmis. `ansible_processor_vcpus` yra automatiškai surenkamas faktas apie serverį, o kitus kintamuosius galite nurodyti inventory ar vars failuose.
Saugumo aspektai ir slaptažodžių valdymas
Kai dirbate su serveriais, neišvengiamai susiduriate su slaptažodžiais, API raktais ir kitais jautriais duomenimis. Ansible turi įtaisytą sprendimą – Ansible Vault.
Vault leidžia užšifruoti failus, kuriuose saugomi jautrūs duomenys:
„`bash
ansible-vault create secrets.yml
„`
Šis failas gali turėti tokį turinį:
„`yaml
db_password: „labai_slaptas_slaptazodis”
api_key: „xyz123abc456”
ssl_private_key: |
—–BEGIN PRIVATE KEY—–
…
—–END PRIVATE KEY—–
„`
Playbook’e šiuos kintamuosius naudojate kaip įprastus:
„`yaml
– name: Konfigūruoti duomenų bazę
hosts: databases
vars_files:
– secrets.yml
tasks:
– name: Sukurti DB vartotoją
mysql_user:
name: appuser
password: „{{ db_password }}”
priv: ‘*.*:ALL’
„`
Paleisdami playbook, tiesiog pridėkite `–ask-vault-pass` parametrą, ir Ansible paprašys šifravimo slaptažodžio.
Dar vienas svarbus saugumo aspektas – niekada nekopijuokite jautrių duomenų į Git repozitoriją nešifruotus. Visada naudokite Vault arba išorinį slaptažodžių valdymo įrankį kaip HashiCorp Vault ar AWS Secrets Manager. Ansible turi modulius integracijai su šiais įrankiais.
Testavimas ir derinimas
Prieš paleisdami playbook produkcijoje, būtina jį išbandyti. Ansible siūlo kelis būdus tai padaryti saugiai.
**Check režimas**
Naudokite `–check` parametrą, kad pamatytumėte, ką playbook padarytų, bet iš tikrųjų nieko nevykdytų:
„`bash
ansible-playbook -i inventory.ini site.yml –check
„`
Tai kaip „dry run” – matote, kokie pakeitimai būtų atlikti, bet jie nėra vykdomi. Tačiau atminkite, kad check režimas ne visada gali tiksliai prognozuoti rezultatus, ypač jei vėlesnės užduotys priklauso nuo ankstesnių.
**Diff režimas**
Norėdami matyti tiksliai, kas keičiasi failuose, naudokite `–diff`:
„`bash
ansible-playbook -i inventory.ini site.yml –check –diff
„`
Tai parodys tikslias skirtumus tarp esamos ir norimos konfigūracijos.
**Verbosity lygiai**
Kai kažkas neveikia, padidinkite detalumo lygį:
„`bash
ansible-playbook -i inventory.ini site.yml -vvv
„`
Kuo daugiau „v” raidžių, tuo daugiau informacijos. Keturi „v” (`-vvvv`) parodys net SSH debug informaciją.
**Sintaksės tikrinimas**
Prieš paleisdami playbook, patikrinkite sintaksę:
„`bash
ansible-playbook –syntax-check site.yml
„`
Tai sutaupo laiko – geriau sužinoti apie sintaksės klaidą iš karto, nei po kelių minučių vykdymo.
Optimizavimas ir geriausia praktika
Kai jūsų infrastruktūra auga, Ansible vykdymo greitis tampa svarbus. Štai keletas patarimų, kaip pagreitinti playbooks:
**Naudokite pipelining**
Ansible konfigūracijos faile (`ansible.cfg`) įjunkite pipelining:
„`ini
[defaults]
pipelining = True
„`
Tai sumažina SSH sesijų skaičių ir gali pagreitinti vykdymą iki 50%.
**Fakų rinkimas**
Ansible automatiškai renka faktus apie kiekvieną serverį. Jei jų nereikia, išjunkite:
„`yaml
– name: Greitas playbook
hosts: all
gather_facts: no
tasks:
– name: Paprasta užduotis
command: echo „Hello”
„`
**Paralelizavimas**
Numatytai Ansible vykdo užduotis 5 serveriuose vienu metu. Padidinkite šį skaičių:
„`bash
ansible-playbook -i inventory.ini site.yml –forks=20
„`
Arba nustatykite `ansible.cfg`:
„`ini
[defaults]
forks = 20
„`
**Tags naudojimas**
Pažymėkite užduotis tags, kad galėtumėte vykdyti tik tam tikras dalis:
„`yaml
– name: Įdiegti paketą
apt:
name: nginx
state: present
tags:
– packages
– nginx
– name: Konfigūruoti nginx
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
tags:
– config
– nginx
„`
Tada galite vykdyti tik konfigūravimą:
„`bash
ansible-playbook site.yml –tags=config
„`
Arba praleisti tam tikras užduotis:
„`bash
ansible-playbook site.yml –skip-tags=packages
„`
Ką daryti, kai viskas jau veikia
Ansible nėra vienkartinis įrankis – tai procesas. Kai jau turite veikiančius playbooks, svarbu juos prižiūrėti ir tobulinti.
Pirma, dokumentuokite savo playbooks. Naudokite aiškius pavadinimus užduotims, rašykite komentarus sudėtingesnėse vietose. Po pusmečio net jūs patys neprisiminsite, kodėl kažką padarėte būtent taip.
Antra, laikykite playbooks Git repozitorijoje. Tai leidžia sekti pakeitimus, grįžti prie ankstesnių versijų ir bendradarbiauti su komanda. Naudokite branch’us eksperimentams ir pull requests peržiūrai prieš įtraukiant į master.
Trečia, reguliariai testuokite savo playbooks. Infrastruktūra keičiasi – atnaujinami paketai, keičiasi konfigūracijos. Kas veikė prieš mėnesį, gali neveikti šiandien. Naudokite CI/CD sistemą automatiniam testavimui.
Ketvirta, mokykitės iš Ansible Galaxy. Ten rasite tūkstančius paruoštų rolių, kurias galite naudoti ar pritaikyti savo poreikiams. Nereikia išradinėti dviračio – dažnai kažkas jau išsprendė jūsų problemą.
Ir galiausiai, nepersistenkite. Ansible yra galingas įrankis, bet ne viskas turi būti automatizuota nuo pirmos dienos. Pradėkite nuo paprastų dalykų – paketų diegimo, vartotojų valdymo, failų kopijavimo. Sudėtingesni dalykai ateis su laiku ir patirtimi. Svarbu, kad jūsų playbooks būtų suprantami ir palaikomi, o ne maksimaliai sudėtingi ir „protingi”.
