Ako vaša IT infrastruktura raste prebrzo, prije ili kasnije ćete biti suočeni s izborom: linearno povećati ljudske resurse za podršku ili započeti automatizaciju. Do nekog trenutka smo živjeli u prvoj paradigmi, a onda je počeo dug put do infrastrukture kao koda.
Naravno, NSPK nije startup, ali takva atmosfera je vladala u kompaniji prvih godina postojanja, a to su bile veoma zanimljive godine. Moje ime je , Podržavam Linux infrastrukturu sa zahtjevima visoke dostupnosti više od 10 godina. Timu NSPK-a se pridružio u januaru 2016. godine i, nažalost, nije doživio sam početak postojanja kompanije, ali je došao u fazu velikih promjena.
Generalno, možemo reći da naš tim isporučuje 2 proizvoda za kompaniju. Prvi je infrastruktura. Mail bi trebao funkcionirati, DNS bi trebao raditi, a kontroleri domena bi trebali pustiti u servere koji se ne bi trebali rušiti. IT pejzaž kompanije je ogroman! Ovo su poslovni i kritični sistemi, a zahtjevi dostupnosti za neke su 99,999. Drugi proizvod su sami serveri, fizički i virtuelni. Postojeće treba pratiti, a nove redovno dostavljati kupcima iz mnogih odjela. U ovom članku želim da se fokusiram na to kako smo razvili infrastrukturu koja je odgovorna za životni ciklus servera.
Početak putovanja
Na početku našeg putovanja, naš tehnološki niz izgledao je ovako:
OS CentOS 7
FreeIPA kontroleri domena
Automatizacija - Ansible(+Toranj), Obućar
Sve je to bilo locirano u 3 domene, raspoređene u nekoliko data centara. U jednom data centru se nalaze kancelarijski sistemi i testne lokacije, u ostalim je PROD.
Kreiranje servera je u jednom trenutku izgledalo ovako:
U VM šablonu, CentOS je minimalan i zahtevani minimum je kao ispravan /etc/resolv.conf, ostalo dolazi preko Ansiblea.
CMDB - Excel.
Ako je server fizički, onda je umjesto kopiranja virtuelne mašine na njega instaliran OS pomoću Cobbler-a - MAC adrese ciljnog servera se dodaju u Cobbler konfiguraciju, server dobija IP adresu preko DHCP-a, a zatim OS je dodan.
U početku smo čak pokušali napraviti neku vrstu upravljanja konfiguracijom u Cobbleru. Ali s vremenom je to počelo donositi probleme s prenosivosti konfiguracija i na druge centre podataka i na Ansible kod za pripremu VM-ova.
U to vrijeme, mnogi od nas doživljavali su Ansible kao zgodno proširenje Bash-a i nisu štedjeli na dizajnu koji koristi shell i sed. Overall Bashsible. To je na kraju dovelo do činjenice da ako playbook iz nekog razloga nije radio na serveru, bilo je lakše izbrisati server, popraviti playbook i ponovo ga pokrenuti. U suštini nije bilo verzionisanja skripti, niti prenosivosti konfiguracija.
Na primjer, htjeli smo promijeniti neke konfiguracije na svim serverima:
- Mijenjamo konfiguraciju na postojećim serverima u logičkom segmentu/data centru. Ponekad ne u jednom danu - zahtjevi pristupačnosti i zakon velikih brojeva ne dozvoljavaju primjenu svih promjena odjednom. A neke promjene su potencijalno destruktivne i zahtijevaju ponovno pokretanje nečega - od usluga do samog OS-a.
- Popravljam to u Ansibleu
- Popravljamo to u Cobbleru
- Ponovite N puta za svaki logički segment/centar podataka
Da bi sve promjene tekle glatko, bilo je potrebno uzeti u obzir mnoge faktore, a promjene se dešavaju konstantno.
- Refaktoring ansible koda, konfiguracijski fajlovi
- Promjena interne najbolje prakse
- Promjene na osnovu rezultata analize incidenata/nesreća
- Promjena sigurnosnih standarda, kako internih tako i eksternih. Na primjer, PCI DSS se svake godine ažurira novim zahtjevima
Rast infrastrukture i početak putovanja
Porastao je broj servera/logičkih domena/centra podataka, a sa njima i broj grešaka u konfiguracijama. U nekom trenutku smo došli do tri pravca u kojima je potrebno razviti upravljanje konfiguracijom:
- Automatizacija. Ljudsku grešku u operacijama koje se ponavljaju treba izbjegavati što je više moguće.
- Ponovljivost. Mnogo je lakše upravljati infrastrukturom kada je ona predvidljiva. Konfiguracija servera i alata za njihovu pripremu treba da budu svuda ista. Ovo je takođe važno za timove proizvoda - nakon testiranja, mora se garantovati da će aplikacija završiti u proizvodnom okruženju konfigurisanom slično kao u test okruženju.
- Jednostavnost i transparentnost unošenja promjena u upravljanje konfiguracijom.
Ostaje dodati nekoliko alata.
Odabrali smo GitLab CE kao naše spremište koda, ne samo zbog svojih ugrađenih CI/CD modula.
Trezor tajni - Hashicorp Trezor, uklj. za odličan API.
Testiranje konfiguracija i ansible uloga – Molecule+Testinfra. Testovi idu mnogo brže ako se povežete na ansible mitogen. Istovremeno smo počeli da pišemo sopstveni CMDB i orkestrator za automatsku implementaciju (na slici iznad Cobblera), ali ovo je sasvim druga priča koju će moj kolega i glavni programer ovih sistema pričati u budućnosti.
Naš izbor:
Molecule + Testinfra
Ansible + Tower + AWX
Svijet servera + DITNET (vlastiti razvoj)
Pahuljar
Gitlab + GitLab runner
Hashicorp Vault
Usput, o ansible ulogama. U početku je bio samo jedan, ali nakon nekoliko refaktoringa bilo ih je 17. Toplo preporučujem da se monolit razbije na idempotentne uloge, koje se onda mogu zasebno pokrenuti, a dodatno možete dodati oznake. Podijelili smo uloge prema funkcionalnosti - mreža, logiranje, paketi, hardver, molekula itd. Općenito, slijedili smo strategiju u nastavku. Ne insistiram da je to jedina istina, ali nama je uspjelo.
- Kopiranje servera sa “zlatne slike” je zlo!Glavni nedostatak je što ne znate tačno u kakvom su stanju slike sada i što će sve promjene doći na sve slike 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 treba da budu samo u /etc/sysctl.d/. Vaša zadana vrijednost u jednoj datoteci, prilagođena aplikaciji u drugoj.
- Koristite datoteke za poništavanje za uređivanje systemd jedinica.
- Šablonirajte sve konfiguracije i uključite ih u potpunosti; ako je moguće, bez sed-a ili njegovih analoga u playbookovima
- Refaktoriranje koda sistema za upravljanje konfiguracijom:
- Podijelite zadatke na logičke entitete i prepišite monolit u uloge
- Koristite lintere! Ansible-lint, yaml-lint, itd
- Promijenite svoj pristup! No bashsible. Potrebno je opisati stanje sistema
- Za sve Ansible uloge morate pisati testove u molekulu i generirati izvještaje 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, ansible uloge su bile spremne, šablonizirane i provjerene od strane lintera. Čak se i gitovi uzgajaju posvuda. Ali pitanje pouzdane isporuke koda u različite segmente ostalo je otvoreno. Odlučili smo da se sinhronizujemo sa skriptama. izgleda ovako:
Nakon što promjena stigne, pokreće se CI, kreira se test server, uloge se uvode i testiraju od strane molekula. Ako je sve u redu, kod ide u granu prod. Ali ne primjenjujemo novi kod na postojeće servere u mašini. Ovo je vrsta graničnika koja je neophodna za visoku dostupnost naših sistema. A kada infrastruktura postane ogromna, stupa na snagu zakon velikih brojeva – čak i ako ste sigurni da je promjena bezopasna, može dovesti do strašnih posljedica.
Postoji i mnogo opcija za kreiranje servera. 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 toga smo došli, sistem nastavlja da živi i razvija se.
- 17 Dostupne uloge za postavljanje servera. Svaka od uloga je dizajnirana za rješavanje zasebnog logičkog zadatka (logiranje, revizija, autorizacija korisnika, nadzor, itd.).
- Testiranje uloga. Molecule + TestInfra.
- Vlastiti razvoj: CMDB + Orchestrator.
- Vrijeme kreiranja servera je ~30 minuta, automatizirano i praktično nezavisno od reda zadataka.
- Isto stanje/imenovanje infrastrukture u svim segmentima - playbooks, repozitorijumi, elementi virtuelizacije.
- Dnevna provera statusa servera sa generisanjem izveštaja o odstupanjima od standarda.
Nadam se da će moja priča biti korisna onima koji su na početku svog puta. Koji stek za automatizaciju koristite?
izvor: www.habr.com