Ako vaša IT infrastruktura raste prebrzo, prije ili kasnije ćete se suočiti s izborom: linearno povećati ljudske resurse koji će je podržati ili pokrenuti automatizaciju. Do nekog smo trenutka živjeli u prvoj paradigmi, a onda je započeo dugi put do Infrastructure-as-Code.
Naravno, NSPK nije startup, ali takva je atmosfera vladala u tvrtki prvih godina postojanja, a bile su to vrlo zanimljive godine. Moje ime je , podržavam Linux infrastrukturu sa zahtjevima visoke dostupnosti više od 10 godina. Timu NSPK pridružio se u siječnju 2016. godine i nažalost nije doživio sam početak postojanja tvrtke, već je došao u fazi velikih promjena.
Općenito, možemo reći da naš tim isporučuje 2 proizvoda za tvrtku. Prvi je infrastruktura. Mail bi trebao raditi, DNS bi trebao raditi, a kontroleri domene trebali bi vas pustiti na poslužitelje koji se ne bi trebali srušiti. IT krajolik tvrtke je ogroman! Ovo su sustavi kritični za poslovanje i misiju, zahtjevi dostupnosti za neke su 99,999. Drugi proizvod su sami poslužitelji, fizički i virtualni. Postojeće treba nadzirati, a nove redovito isporučivati kupcima iz mnogih odjela. U ovom članku želim se usredotočiti na to kako smo razvili infrastrukturu koja je odgovorna za životni ciklus poslužitelja.
Početak putovanje
Na početku našeg putovanja naš tehnološki skup izgledao je ovako:
OS CentOS 7
FreeIPA kontroleri domene
Automatizacija - Ansible(+Tower), Cobbler
Sve je to bilo smješteno u 3 domene, raspoređene u nekoliko podatkovnih centara. U jednom podatkovnom centru nalaze se uredski sustavi i testna mjesta, u ostalim PROD.
Izrada servera u jednom je trenutku izgledala ovako:
U VM predlošku, CentOS je minimalan, a potrebni minimum je poput ispravnog /etc/resolv.conf, ostalo dolazi kroz Ansible.
CMDB - Excel.
Ako je poslužitelj fizički, umjesto kopiranja virtualnog stroja, OS je instaliran na njega pomoću Cobbler-a - MAC adrese ciljanog poslužitelja dodane su konfiguraciji Cobbler-a, poslužitelj prima IP adresu putem DHCP-a, a zatim OS dodaje se.
Isprva smo čak pokušali napraviti neku vrstu upravljanja konfiguracijom u Cobbleru. No, s vremenom je to počelo donositi probleme s prenosivošću konfiguracija i na druge podatkovne centre i na Ansible kod za pripremu VM-ova.
U to su vrijeme mnogi od nas Ansible doživljavali kao zgodno proširenje Basha i nisu štedjeli na dizajnu koji koristi shell i sed. Sveukupno Bashsible. To je u konačnici dovelo do činjenice da ako playbook iz nekog razloga ne radi na poslužitelju, bilo je lakše izbrisati poslužitelj, popraviti playbook i ponovno ga pokrenuti. U biti nije bilo verzije skripti, niti prenosivosti konfiguracija.
Na primjer, htjeli smo promijeniti neke konfiguracije na svim poslužiteljima:
- Mijenjamo konfiguraciju na postojećim poslužiteljima u logičkom segmentu/podatkovnom centru. Ponekad ne u jednom danu - zahtjevi pristupačnosti i zakon velikih brojeva ne dopuštaju primjenu svih promjena odjednom. A neke su promjene potencijalno destruktivne i zahtijevaju ponovno pokretanje nečega – od usluga do samog OS-a.
- Popravljanje u Ansibleu
- Popravljamo to u Cobbleru
- Ponovite N puta za svaki logički segment/podatkovni centar
Kako bi sve promjene tekle glatko, bilo je potrebno uzeti u obzir mnogo faktora, a promjene se događaju konstantno.
- Refactoring ansible koda, konfiguracijske datoteke
- Promjena internih najboljih praksi
- Promjene na temelju rezultata analize incidenata/nesreća
- Mijenjanje sigurnosnih standarda, kako unutarnjih tako i vanjskih. Na primjer, PCI DSS se svake godine ažurira novim zahtjevima
Rast infrastrukture i početak putovanja
Rastao je broj poslužitelja/logičkih domena/podatkovnih centara, a s njima i broj grešaka u konfiguracijama. U nekom smo trenutku došli do tri smjera u kojima je potrebno razvijati upravljanje konfiguracijom:
- Automatizacija. Ljudsku pogrešku u operacijama koje se ponavljaju treba izbjegavati što je više moguće.
- Ponovljivost. Mnogo je lakše upravljati infrastrukturom kada je predvidljiva. Konfiguracija poslužitelja i alata za njihovu pripremu trebaju biti svugdje isti. Ovo je također važno za proizvodne timove - nakon testiranja mora biti zajamčeno da će aplikacija završiti u produkcijskom okruženju konfiguriranom slično testnom okruženju.
- Jednostavnost i transparentnost unošenja promjena u upravljanje konfiguracijom.
Ostaje dodati par alata.
Izabrali smo GitLab CE kao naš repozitorij koda, ne samo zbog njegovih ugrađenih CI/CD modula.
Trezor tajni - Hashicorp trezor, uklj. za odličan API.
Konfiguracije testiranja i anzibilne uloge – Molecule+Testinfra. Testovi idu puno brže ako se spojite na ansible mitogen. Istovremeno smo počeli pisati vlastiti CMDB i orkestrator za automatsku implementaciju (na slici iznad Cobblera), ali to je sasvim druga priča koju će moj kolega i glavni programer ovih sustava ispričati u budućnosti.
Naš izbor:
Molekula + Testinfra
Ansible + toranj + AWX
World of Servers + DITNET (vlastiti razvoj)
Obućar
Gitlab + GitLab pokretač
Hashicorp trezor
Usput, o anziblnim ulogama. Isprva je bio samo jedan, ali nakon nekoliko refaktoriranja bilo ih je 17. Toplo preporučujem razbijanje monolita na idempotentne uloge, koje se zatim mogu pokrenuti zasebno, dodatno, možete dodati oznake. Podijelili smo uloge po funkcionalnosti - mreža, logiranje, paketi, hardver, molekula itd. Općenito, slijedili smo strategiju u nastavku. Ne inzistiram da je to jedina istina, ali nama je uspjelo.
- Kopiranje servera sa "zlatne slike" je zlo!Glavni nedostatak je da ne znate točno u kakvom su stanju slike sada i da će sve promjene doći do svih slika u svim virtualizacijskim farmama.
- Koristite zadane konfiguracijske datoteke na minimum i dogovorite se s drugim odjelima da ste odgovorni za glavne sistemske datoteke, na primjer:
- Ostavite /etc/sysctl.conf prazan, postavke bi trebale biti samo u /etc/sysctl.d/. Vaša zadana datoteka u jednoj datoteci, prilagođena aplikaciji u drugoj.
- Koristite datoteke nadjačavanja za uređivanje systemd jedinica.
- Napravite predložak svih konfiguracija i uključite ih u cijelosti; ako je moguće, bez sed-a ili njegovih analoga u igrama
- Refaktoriranje koda sustava upravljanja konfiguracijom:
- Podijelite zadatke u logičke entitete i prepišite monolit u uloge
- Koristite lintere! Ansible-lint, yaml-lint, itd
- Promijenite pristup! Nema bashible. Potrebno je opisati stanje sustava
- Za sve Ansible uloge trebate pisati testove u molekuli i generirati izvješća jednom dnevno.
- U našem slučaju, nakon pripreme testova (kojih ima više od 100), pronađeno je oko 70000 grešaka. Trebalo je nekoliko mjeseci da se to popravi.
Naša implementacija
Dakle, ansibilne uloge su bile spremne, šablonske i provjerene od strane lintera. A čak se i kreteni uzgajaju posvuda. Ali pitanje pouzdane dostave koda u različite segmente ostalo je otvoreno. Odlučili smo se sinkronizirati sa skriptama. izgleda ovako:
Nakon što promjena stigne, CI se pokreće, testni poslužitelj se stvara, uloge se uvode i testira molekula. Ako je sve u redu, kod ide u prod granu. Ali ne primjenjujemo novi kod na postojeće poslužitelje u stroju. Ovo je svojevrsni čep koji je neophodan za visoku dostupnost naših sustava. A kada infrastruktura postane ogromna, na scenu stupa zakon velikih brojeva – čak i ako ste sigurni da je promjena bezopasna, može dovesti do kobnih posljedica.
Također postoji mnogo opcija za kreiranje poslužitelja. Na kraju smo odabrali prilagođene Python skripte. A za CI ansible:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
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.ru
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}}"Do ovoga smo došli, sustav nastavlja živjeti i razvijati se.
- 17 Ansible uloga za postavljanje poslužitelja. Svaka od uloga dizajnirana je za rješavanje zasebnog logičkog zadatka (bilježenje, revizija, autorizacija korisnika, nadzor itd.).
- Testiranje uloga. Molekula + TestInfra.
- Vlastiti razvoj: CMDB + Orchestrator.
- Vrijeme izrade poslužitelja je ~30 minuta, automatizirano i praktički neovisno o redu čekanja zadataka.
- Isto stanje/imenovanje infrastrukture u svim segmentima - playbooks, repozitoriji, elementi virtualizacije.
- Dnevna provjera stanja poslužitelja uz generiranje izvješća o odstupanjima od standarda.
Nadam se da će moja priča biti korisna onima koji su na početku svog puta. Koji niz za automatizaciju koristite?
Izvor: www.habr.com