Kas yra Ansible ir kodėl jis tapo tokiu populiarus
Jei kada nors teko administruoti daugiau nei vieną serverį, tikriausiai žinote, kokia tai gali būti kančia. Įsivaizduokite: turite atnaujinti konfigūraciją 50 serverių. Prisijungti prie kiekvieno per SSH, rankiniu būdu keisti failus, tikrinti ar viskas veikia… Skamba kaip košmaras, tiesa? Būtent tokioms problemoms spręsti ir atsirado Ansible.
Ansible – tai atviro kodo automatizavimo įrankis, kurį Red Hat įsigijo 2015 metais. Jis leidžia aprašyti norimą sistemos būseną paprastu YAML formatu, o pats pasirūpina, kad ši būsena būtų pasiekta visuose nurodytuose serveriuose. Skirtingai nuo kitų panašių įrankių (Chef, Puppet), Ansible neturi agentų – jam užtenka SSH prieigos ir Python interpretavimo nuotoliniame serveryje.
Pagrindinė Ansible filosofija – idempotentiškumas. Tai reiškia, kad tą patį konfigūracijos scenarijų galite paleisti kelis kartus, ir rezultatas bus tas pats. Sistema nesugrius, nebus dubliuotų įrašų ar kitų problemų. Jei failas jau egzistuoja su reikiamu turiniu, Ansible tiesiog praneš, kad pakeitimų nereikia.
Kaip pradėti: pirmieji žingsniai su Ansible
Ansible įdiegimas yra paprastas kaip du kart du. Debian/Ubuntu sistemose pakanka paleisti sudo apt install ansible, o Red Hat šeimos distributyviuose – sudo yum install ansible. Taip pat galite naudoti Python pip: pip install ansible.
Po įdiegimo pirmiausia reikia sukurti inventoriaus failą. Tai paprastas tekstinis failas, kuriame išvardijate serverius, kuriuos norite valdyti. Paprasčiausias variantas atrodo taip:
[webservers]
web1.example.com
web2.example.com
[databases]
db1.example.com
db2.example.com
Grupės (webservers, databases) leidžia logiškai organizuoti serverius ir vėliau taikyti konfigūracijas konkrečioms grupėms. Galite turėti ir sudėtingesnius inventorius su kintamaisiais, portais, SSH raktais – bet pradžiai pakanka paprastos struktūros.
Norėdami patikrinti ar Ansible gali pasiekti jūsų serverius, paleiskite: ansible all -m ping. Jei viskas sukonfigūruota teisingai, pamatysite žalią „pong” atsakymą iš kiekvieno serverio.
Playbook’ai – Ansible širdis
Playbook’ai yra pagrindinė Ansible sąvoka. Tai YAML failai, kuriuose aprašote, ką norite padaryti su savo serveriais. Štai paprastas pavyzdys, kuris įdiegia Nginx ir užtikrina, kad jis veiktų:
---
- name: Įdiegti ir konfigūruoti Nginx
hosts: webservers
become: yes
tasks:
- name: Įdiegti Nginx paketą
apt:
name: nginx
state: present
- name: Užtikrinti kad Nginx veikia
service:
name: nginx
state: started
enabled: yes
Kiekviena užduotis (task) naudoja modulį – iš anksto parašytą kodą, kuris atlieka konkrečią funkciją. Ansible turi šimtus įvairių modulių: failų valdymui, paketų diegimui, Docker konteineriams, debesų infrastruktūrai ir t.t.
Svarbu suprasti, kad playbook’ai vykdomi iš viršaus į apačią, o kiekviena užduotis vykdoma visuose nurodytuose serveriuose prieš pereinant prie kitos. Tai reiškia, kad Nginx bus įdiegtas visuose web serveriuose, tik tada bus tikrinama ar servisas veikia.
Kintamieji ir šablonai: dinamiškumo pridėjimas
Realybėje retai kada visuose serveriuose norėsite visiškai identišką konfigūraciją. Čia ir praverčia kintamieji. Juos galite apibrėžti keliose vietose: inventoriaus faile, atskiruose kintamųjų failuose, ar net tiesiog playbook’e.
Pavyzdžiui, galite turėti skirtingas Nginx konfigūracijas skirtingiems serveriams:
[webservers]
web1.example.com nginx_worker_processes=4
web2.example.com nginx_worker_processes=8
O tada naudoti Jinja2 šablonus konfigūracijos failams generuoti:
worker_processes {{ nginx_worker_processes }};
events {
worker_connections 1024;
}
http {
# Kita konfigūracija
}
Ansible automatiškai įstatys reikiamą reikšmę kiekvienam serveriui. Šablonai yra neįtikėtinai galingas įrankis – galite naudoti ciklus, sąlygas, filtrus ir kitas Jinja2 galimybes.
Praktinis patarimas: laikykite kintamuosius atskiruose failuose pagal aplinkas (development, staging, production). Tai padės išvengti painiavos ir atsitiktinių klaidų, kai produkcinėje aplinkoje atsiduria testuojamos reikšmės.
Roles – kodo organizavimas ir perpanaudojimas
Kai jūsų playbook’ai pradeda augti, jie tampa sunkiai skaitomi ir prižiūrimi. Roles (rolės) yra Ansible būdas organizuoti kodą į perpanaudojamus komponentus. Rolė – tai standartizuota direktorijų struktūra, kuri gali turėti užduotis, kintamuosius, šablonus, failus ir kitus resursus.
Tipinė rolės struktūra atrodo taip:
roles/
nginx/
tasks/
main.yml
templates/
nginx.conf.j2
handlers/
main.yml
defaults/
main.yml
vars/
main.yml
files/
Vietoj vieno didelio playbook’o, dabar galite tiesiog nurodyti: „šiems serveriams pritaikyk nginx rolę”. Ansible automatiškai žinos, kur ieškoti visų reikiamų failų ir konfigūracijų.
Dar geriau – galite naudoti jau paruoštas roles iš Ansible Galaxy, bendruomenės palaikomos rolių saugyklos. Norite įdiegti ir sukonfigūruoti PostgreSQL? Tikriausiai jau yra gerai ištestuota rolė, kurią galite naudoti kaip pagrindą. Komanda ansible-galaxy install geerlingguy.postgresql atsisiųs vieną iš populiariausių PostgreSQL rolių.
Handlers ir pranešimai: efektyvus pakeitimų valdymas
Viena iš subtiliausių, bet galingiausių Ansible funkcijų yra handlers (apdorojimo programos). Tai specialios užduotys, kurios vykdomos tik tada, kai kažkas pasikeičia ir jas „pranešama” (notify).
Klasikinis pavyzdys: pakeitėte Nginx konfigūraciją. Dabar reikia perkrauti servisą, bet tik jei konfigūracija tikrai pasikeitė. Štai kaip tai atrodo:
tasks:
- name: Kopijuoti Nginx konfigūraciją
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
notify: perkrauti nginx
handlers:
- name: perkrauti nginx
service:
name: nginx
state: reloaded
Jei konfigūracijos failas jau yra identiškas, Ansible nieko nekeičia ir handler’is nepaleidžiamas. Tai sutaupo laiko ir sumažina nereikalingų servisų perkrovimų skaičių.
Dar vienas svarbus dalykas: visi handler’iai vykdomi playbook’o pabaigoje, po visų užduočių. Net jei kelios užduotys „praneša” tam pačiam handler’iui, jis bus paleistas tik vieną kartą. Tai užtikrina efektyvumą ir išvengia situacijų, kai servisas perkraunamas kelis kartus iš eilės.
Ansible Vault: slaptažodžių ir jautrių duomenų apsauga
Viena iš didžiausių problemų automatizuojant infrastruktūrą yra jautrių duomenų saugojimas. Slaptažodžiai, API raktai, sertifikatai – visa tai negali būti saugoma paprastame tekste Git repozitorijoje.
Ansible Vault sprendžia šią problemą leisdamas užšifruoti atskirus failus ar net atskiras reikšmes. Užšifruoti failą galite komanda:
ansible-vault encrypt secrets.yml
Sistema paprašys slaptažodžio, ir failas bus užšifruotas AES256 algoritmu. Vėliau, norėdami paleisti playbook’ą su užšifruotais kintamaisiais, naudokite:
ansible-playbook site.yml --ask-vault-pass
Praktikoje dažnai naudojamas vault slaptažodžio failas, kad nereikėtų kaskart įvedinėti slaptažodžio rankiniu būdu: ansible-playbook site.yml --vault-password-file ~/.vault_pass
Dar patogesnė funkcija – galite užšifruoti ne visą failą, o tik konkrečias reikšmes su ansible-vault encrypt_string. Tai leidžia matyti kintamųjų pavadinimus, bet ne jų reikšmes, kas labai palengvina kodo skaitymą ir prižiūrimą.
Realaus pasaulio patarimai ir geroji praktika
Dirbant su Ansible kasdien, išmoksti kai kurių dalykų, kurių nerasite oficialioje dokumentacijoje. Pirma, visada naudokite --check režimą (dar vadinamą „dry run”) prieš vykdydami pakeitimus produkcinėje aplinkoje. Tai leidžia pamatyti, kas pasikeis, nedarant realių pakeitimų.
Antra, naudokite tags (žymes) didelėse rolėse ir playbook’uose. Jos leidžia vykdyti tik tam tikras užduotis:
- name: Įdiegti paketą
apt:
name: nginx
tags: packages
- name: Konfigūruoti servisą
template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
tags: config
Tada galite paleisti tik konfigūracijos užduotis: ansible-playbook site.yml --tags config
Trečia, visada testuokite savo playbook’us su Molecule – Ansible testavimo įrankiu. Jis leidžia automatiškai sukurti Docker konteinerius ar virtualias mašinas, pritaikyti jūsų rolę ir patikrinti ar viskas veikia kaip tikėtasi.
Ketvirta, naudokite ansible-lint – tai lyg ESLint, bet Ansible kodui. Jis pagauna dažniausias klaidas, neoptimalius sprendimus ir padeda laikytis gerųjų praktikų.
Penkta, dokumentuokite savo roles ir playbook’us. Ansible palaiko README.md failus rolėse, o užduotyse visada naudokite name parametrą su aiškiu aprašymu. Po trijų mėnesių būsite dėkingi sau pačiam.
Ansible ekosistema ir ateities perspektyvos
Ansible nėra tik CLI įrankis. Red Hat sukūrė visą ekosistemą aplink jį. AWX (Ansible Tower atviro kodo versija) suteikia web sąsają, vaidmenų valdymą, job’ų planavimą ir vizualizaciją. Tai ypač naudinga komandose, kur ne visi nori ar gali naudoti komandinę eilutę.
Ansible Collections – tai naujausias būdas platinti Ansible turinį. Vietoj atskirų rolių ar modulių, dabar galite įdiegti visą kolekciją, kuri gali turėti modulius, roles, plugin’us ir dokumentaciją. Pavyzdžiui, ansible-galaxy collection install community.postgresql įdiegs visus PostgreSQL susijusius komponentus.
Ansible taip pat puikiai integruojasi su CI/CD pipeline’ais. GitLab CI, Jenkins, GitHub Actions – visi šie įrankiai gali paleisti Ansible playbook’us kaip deployment žingsnį. Tai leidžia automatizuoti ne tik konfigūraciją, bet ir visą programinės įrangos pristatymo procesą.
Kalbant apie ateitį, Ansible evoliucionuoja link deklaratyvesnio požiūrio su Event-Driven Ansible. Tai leidžia reaguoti į įvykius realiu laiku – pavyzdžiui, automatiškai masteliuoti infrastruktūrą, kai padidėja apkrova, ar izoliuoti serverį, kai aptinkama saugumo problema.
Kodėl Ansible vis dar aktuali 2024 metais
Galite paklausti: ar Ansible vis dar aktuali Kubernetes ir serverless eroje? Atsakymas – absoliučiai taip. Net jei naudojate konteinerius, kažkas turi sukonfigūruoti tuos Kubernetes node’us. Net jei naudojate AWS Lambda, kažkas turi sukurti IAM roles, VPC, ir kitus resursus.
Ansible paprastumas yra jos didžiausia stiprybė. Nereikia mokytis sudėtingos DSL (kaip Puppet), nereikia diegti agentų visuose serveriuose (kaip Chef), nereikia rašyti kodo imperatyviai (kaip su bash skriptais). YAML failas, kurį gali perskaityti ir suprasti net ne-programuotojas, yra neįkainojamas komandiniame darbe.
Be to, Ansible bendruomenė yra milžiniška ir aktyvi. Beveik bet kokiai užduočiai rasite pavyzdinį kodą, rolę ar modulį. Dokumentacija yra išsami, o Stack Overflow pilnas atsakymų į dažniausias problemas.
Taigi, jei dar nenaudojate jokio konfigūracijos valdymo įrankio, Ansible yra puikus pasirinkimas pradėti. Jei naudojate senesnius įrankius, galbūt verta apsvarstyti migraciją. O jei jau naudojate Ansible – tęskite mokymąsi, nes šis įrankis turi daug daugiau galimybių nei atrodo iš pirmo žvilgsnio. Automatizavimas nėra prabanga, tai būtinybė šiuolaikinėje IT infrastruktūroje, ir Ansible padaro jį prieinamą visiems.
