Ako vaša IT infrastruktura raste prebrzo, рано ili kasno ćete se suočiti s odabirom – linearno povećavati ljudske resurse za njezinu podršku ili započeti automatizaciju. Do nekog trenutka živjeli smo u prvoj paradigmi, a zatim je počeo dug put ka Infrastructure-as-Code.
Naravno, NSPK nije startup, ali atmosfera u tvrtki bila je takva u prvim godinama postojanja, a to su bila vrlo zanimljiva vremena. Zovem se , više od 10 godina podržavam Linux infrastrukturu s visokim zahtjevima dostupnosti. Timu NSPK pridružio sam se u siječnju 2016. godine i, nažalost, nisam doživio sam početak postojanja tvrtke, ali sam došao u fazi velikih promjena.
Sve u svemu, može se reći da naša ekipa pruža dva proizvoda za tvrtku. Prvi – to je infrastruktura. Pošta mora raditi, DNS treba funkcionirati, a domeni kontroleri – omogućiti vam pristup serverima koji ne bi smjeli padati. IT krajolik tvrtke je ogroman! To su business&mission critical sustavi, a zahtjevi dostupnosti nekih – 99,999. Drugi proizvod – sami serveri, fizički i virtualni. O postojećima treba brinuti, a nove redovito isporučivati klijentima iz mnogih odjela. U ovom članku želim istaknuti kako smo razvijali infrastrukturu koja je odgovorna za životni ciklus poslužitelja.
Početak puta
Na početku našeg puta naš tehnologijski paket izgledao je ovako:
OS CentOS 7
Kontroleri domena FreeIPA
Automatizacija — Ansible(+Tower), Cobbler
Sve je to bilo raspoređeno u 3 domene, raspoređene na nekoliko podatkovnih centara. U jednom podatkovnom centru – uredski sustavi i testne platforme, u ostalima PRODUCTION.
Kreiranje servera u nekom trenutku izgledalo je ovako:
U predlošku VM CentOS minimalan i nužni minimum poput ispravnog /etc/resolv.conf, ostatak dolazi putem Ansible.
CMDB – Excel.
Ako je server fizički, umjesto kopiranja virtualne mašine na njega, OS se instalira uz pomoć Cobbler – u Cobbler konfiguraciju dodaju se MAC adrese ciljanog servera, server putem DHCP-a dobiva IP adresu, a zatim se instalira OS.
U početku smo čak pokušavali raditi neku vrstu upravljanja konfiguracijom u Cobbleru. No s vremenom su se počeli pojavljivati problemi s prenosivošću konfiguracija, kako u druge podatkovne centre, tako i u Ansible kod za pripremu VM.
Mnogi od nas su u to vrijeme Ansible doživljavali kao korisno proširenje Bash-a, a nisu štedjeli na konstrukcijama koristeći shell i sed. U suštini, to je bio Bashsible. To je na kraju rezultiralo time da, ako playbook iz bilo kojeg razloga nije radio na serveru, bilo je lakše obrisati server, ispraviti playbook i ponovo ga primijeniti. U suštini nije bilo verzioniranja skripti niti prenosivosti konfiguracija.
Na primjer, željeli smo promijeniti neku konfiguraciju na svim serverima:
- Mijenjamo konfiguraciju na postojećim serverima u logičkom segmentu/ data centra. Ponekad ne za jedan dan – zahtjevi za dostupnost i zakon velikih brojeva ne dopuštaju primjenu svih promjena odjednom. A neke promjene su potencijalno destruktivne i zahtijevaju ponovni pokretanje nečega – od servisa do samog operativnog sustava.
- Ispravljamo u Ansible-u
- Ispravljamo u Cobbler-u
- Ponovimo N puta za svaki logički segment/ data centar
Kako bi sve promjene prošle glatko, bilo je potrebno uzeti u obzir mnoge faktore, a promjene se konstantno događaju.
- Refaktoriranje Ansible koda, konfiguracijskih datoteka
- Promjena unutarnjih najboljih praksi
- Izmjene na temelju analize incidenata/nesreća
- Promjena sigurnosnih standarda, kako unutarnjih, tako i vanjskih. Na primjer, PCI DSS se svake godine dopunjava novim zahtjevima
Rast infrastrukture i početak puta
Broj servera/logičkih domena/ data centara je rastao, a s njima i broj grešaka u konfiguracijama. U nekom trenutku došli smo do tri smjera u kojima treba razvijati upravljanje konfiguracijama:
- Automatizacija. Koliko je moguće, treba izbjegavati ljudski faktor u ponavljajućim operacijama.
- Ponavljanost. Upraviti infrastrukturom je puno lakše kada je predvidljiva. Konfiguracija servera i alata za njihovu pripremu trebala bi biti svugdje jednaka. To je također važno za razvojne timove – aplikacija bi nakon testiranja trebala jamčiti da će biti urađena u proizvodnom okruženju, podešenom na način sličan testnom.
- Jednostavnost i transparentnost u uvođenju promjena u upravljanje konfiguracijama.
Preostaje dodati još nekoliko alata.
Kao spremište koda odabrali smo GitLab CE, ne u posljednjem redu zbog prisutnosti ugrađenih CI/CD modula.
Skladište tajni – Hashicorp Vault, između ostalog zbog izvrsnog API-ja.
Testiranje konfiguracija i ansible uloga – Molecule+Testinfra. Testovi idu znatno brže kada se koristi mitogen s ansible-om. Paralelno smo počeli pisati vlastitu CMDB i orkestrator za automatsko raspoređivanje (na slici iznad Cobblera), ali to je već sasvim druga priča, o kojoj će u budućnosti pričati moj kolega i glavni programer ovih sustava.
Naš izbor:
Molecule + Testinfra
Ansible + Tower + AWX
Svijet Servera + DITNET (Vlastiti razvoj)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault
Usput o ansible ulogama. Prvo je bila jedna, nakon nekoliko refaktorizacija ih je postalo 17. Kategorijski preporučujem razbijanje monolita na idempotentne uloge koje se zatim mogu pokretati odvojeno, uz mogućnost dodavanja oznaka. Razbili smo uloge prema funkcionalnosti – mreža, logiranje, paketi, hardver, molekuli itd. U svakom slučaju, držali smo se strategije ispod. Ne tvrdim da je to jedina istina, ali nama je funkcioniralo.
- Kopiranje servera iz "zlatnog obrasca" – zlo!Od glavnih nedostataka – nikada ne znate u kakvom su stanju trenutačno slike, i da će sve promjene doći u sve slike u svim farmama virtualizacije.
- Koristite zadane datoteke konfiguracije minimalno i dogovorite se s drugim odjelima da ste vi odgovorni za osnovne sistemske datoteke., na primjer:
- Ostavite /etc/sysctl.conf praznim, postavke trebaju ležati samo u /etc/sysctl.d/. Vaš zadani u jedan datoteku, prilagođen za aplikaciju u drugu.
- Koristite override datoteke za uređivanje systemd jedinica.
- Šablonirajte sve konfiguracije i dodajte ih u cijelosti, po mogućstvu bez sed-a i njegovih analoga u playbookovima.
- Refaktorizirajući kod sustava za upravljanje konfiguracijama:
- Razdvojite zadatke na logičke entitete i prepišite monolit u uloge.
- Koristite linters! Ansible-lint, yaml-lint itd.
- Promijenite pristup! Nema bashsible-a. Potrebno je opisivati stanje sustava.
- Za sve Ansible uloge potrebno je napisati testove u molekuli i svakodnevno generirati izvješća.
- U našem slučaju, nakon pripreme testova (njih više od 100) pronađeno je oko 70000 grešaka. Ispravljali smo nekoliko mjeseci.
Naša implementacija
Dakle, ansible uloge su bile spremne, šablonizirane i provjerene linters. I svi gitovi su podignuti posvuda. Ali pitanje pouzdane isporuke koda u različite segmente ostalo je otvoreno. Odlučili smo sinkronizirati skriptama. Izgleda ovako:
Nakon što dođe promjena, pokreće se CI, stvara se testni poslužitelj, izvršavaju se uloge, testiraju se molekulom. Ako je sve u redu, kod ide u produkcijsku granu. No, ne primjenjujemo novi kod automatski na postojeće poslužitelje. To je svojevrsna kočnica, potrebna za visoku dostupnost naših sustava. A kad infrastruktura postane ogromna, u igru ulazi i zakon velikih brojeva – čak i ako ste sigurni da je promjena bezopasna, može dovesti do tužnih posljedica.
Opcija za stvaranje poslužitelja također je mnogo. Na kraju smo odabrali prilagođene skripte u Pythonu. A za CI Ansible:
- ime: create1.yml - Kreiraj VM iz predloška
vmware_guest:
hostname: "{{datacenter}}".domain.hr
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "\/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.hr
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Evo do čega smo došli, sustav nastavlja živjeti i razvijati se.
- 17 ansible uloga za postavljanje poslužitelja. Svaka od uloga namijenjena je rješavanju posebnog logičkog zadatka (logiranje, revizija, autorizacija korisnika, praćenje i sl.).
- Testiranje uloga. Molecule + TestInfra.
- Vlastiti razvoj: CMDB + Orkestrator.
- Vrijeme izrade poslužitelja ~30 minuta, automatizirano i gotovo neovisno o redu zadataka.
- Jednako stanje/imena infrastrukture u svim segmentima – playbookovi, repozitoriji, elementi virtualizacije.
- Sv daily provjera stanja poslužitelja uz generiranje izvještaja o razlikama u odnosu na standard.
Nadam se da će moja priča biti korisna onima koji su na početku svog puta. A koji skup alata za automatizaciju koristite vi?
Izvor: habr.com
