Ak vaša IT infraštruktúra rastie príliš rýchlo, skôr či neskôr budete stáť pred voľbou: lineárne zvýšiť ľudské zdroje na jej podporu alebo spustiť automatizáciu. Do určitého bodu sme žili v prvej paradigme a potom sa začala dlhá cesta k Infraštruktúre ako kódu.
Samozrejme, NSPK nie je startup, ale takáto atmosféra vládla vo firme v prvých rokoch jej existencie a boli to veľmi zaujímavé roky. Moje meno je , Už viac ako 10 rokov podporujem infraštruktúru Linuxu s požiadavkami na vysokú dostupnosť. Do tímu NSPK nastúpil v januári 2016 a, žiaľ, nezaznamenal úplný začiatok existencie spoločnosti, ale prišiel v štádiu veľkých zmien.
Vo všeobecnosti sa dá povedať, že náš tím dodáva pre spoločnosť 2 produkty. Prvým je infraštruktúra. Pošta by mala fungovať, DNS by mala fungovať a radiče domény by vás mali pustiť na servery, ktoré by nemali zlyhať. IT prostredie spoločnosti je obrovské! Ide o kritické systémy pre podnikanie a poslanie, pričom požiadavky na dostupnosť niektorých sú 99,999 XNUMX. Druhým produktom sú samotné servery, fyzické a virtuálne. Existujúce je potrebné sledovať a nové je potrebné pravidelne dodávať zákazníkom z mnohých oddelení. V tomto článku sa chcem zamerať na to, ako sme vyvinuli infraštruktúru, ktorá je zodpovedná za životný cyklus servera.
Začiatok cesty
Na začiatku našej cesty vyzeral náš technologický zásobník takto:
OS CentOS 7
FreeIPA radiče domény
Automatizácia - Ansible(+Tower), Cobbler
To všetko sa nachádzalo v 3 doménach, rozmiestnených v niekoľkých dátových centrách. V jednom dátovom centre sú kancelárske systémy a testovacie miesta, vo zvyšku je PROD.
Vytvorenie serverov v jednom bode vyzeralo takto:
V šablóne VM je CentOS minimálny a požadované minimum je ako správny /etc/resolv.conf, zvyšok prichádza cez Ansible.
CMDB - Excel.
Ak je server fyzický, potom sa namiesto kopírovania virtuálneho počítača naň nainštaloval operačný systém pomocou Cobblera - MAC adresy cieľového servera sa pridajú do konfigurácie Cobbler, server dostane IP adresu cez DHCP a potom OS. sa pridáva.
Najprv sme sa dokonca pokúšali urobiť nejaký druh správy konfigurácie v Cobbleri. Postupom času to však začalo prinášať problémy s prenosnosťou konfigurácií ako do iných dátových centier, tak aj do kódu Ansible na prípravu VM.
V tom čase mnohí z nás vnímali Ansible ako pohodlné rozšírenie Bash a nešetrili na dizajnoch využívajúcich shell a sed. Celkovo Bashsible. To nakoniec viedlo k tomu, že ak playbook z nejakého dôvodu na serveri nefungoval, bolo jednoduchšie server vymazať, opraviť playbook a spustiť ho znova. V podstate neexistovalo žiadne verzovanie skriptov, žiadna prenosnosť konfigurácií.
Napríklad sme chceli zmeniť niektoré konfigurácie na všetkých serveroch:
- Zmeníme konfiguráciu na existujúcich serveroch v logickom segmente/dátovom centre. Niekedy nie za jeden deň – požiadavky na prístupnosť a zákon veľkého počtu neumožňujú aplikovať všetky zmeny naraz. A niektoré zmeny sú potenciálne deštruktívne a vyžadujú reštart niečoho – od služieb až po samotný OS.
- Oprava v Ansible
- Opravujeme to v Cobbleri
- Opakujte N-krát pre každý logický segment/dátové centrum
Aby všetky zmeny prebehli hladko, bolo potrebné brať do úvahy veľa faktorov a zmeny nastávajú neustále.
- Refaktorovanie ansible kódu, konfiguračné súbory
- Zmena interných osvedčených postupov
- Zmeny na základe výsledkov analýzy incidentov/nehôd
- Meniace sa bezpečnostné štandardy, interné aj externé. Napríklad PCI DSS sa každý rok aktualizuje o nové požiadavky
Rast infraštruktúry a začiatok cesty
Počet serverov/logických domén/dátových centier rástol a s nimi aj počet chýb v konfiguráciách. V určitom bode sme dospeli k trom smerom, v ktorých je potrebné vyvinúť správu konfigurácie:
- automatizácia. Pri opakujúcich sa operáciách by sa malo v maximálnej možnej miere predchádzať ľudským chybám.
- Opakovateľnosť. Je oveľa jednoduchšie spravovať infraštruktúru, keď je predvídateľná. Konfigurácia serverov a nástrojov na ich prípravu by mala byť všade rovnaká. To je dôležité aj pre produktové tímy – po testovaní musí byť zaručené, že aplikácia skončí v produkčnom prostredí nakonfigurovanom podobne ako testovacie prostredie.
- Jednoduchosť a transparentnosť vykonávania zmien v správe konfigurácií.
Zostáva pridať pár nástrojov.
Ako úložisko kódov sme si vybrali GitLab CE, v neposlednom rade pre jeho vstavané moduly CI/CD.
Trezor tajomstiev - Hashicorp Vault, vrát. pre skvelé API.
Testovanie konfigurácií a dostupných rolí – Molecule+Testinfra. Testy idú oveľa rýchlejšie, ak sa pripojíte k ansible mitogénu. Zároveň sme začali písať vlastný CMDB a orchestrátor pre automatické nasadenie (na obrázku nad Cobblerom), ale to je úplne iný príbeh, ktorý mi v budúcnosti rozpovie môj kolega a hlavný vývojár týchto systémov.
Naša voľba:
Molekula + Testinfra
Ansible + Tower + AWX
Svet serverov + DITNET (vlastný vývoj)
koktail
Gitlab + GitLab runner
Hashicorp Vault
Mimochodom, o ansible rolách. Najprv bol len jeden, ale po niekoľkých refaktoringoch ich bolo 17. Dôrazne odporúčam rozbiť monolit na idempotentné roly, ktoré je možné následne spúšťať samostatne, navyše môžete pridávať značky. Roly sme rozdelili podľa funkčnosti – sieť, protokolovanie, balíky, hardvér, molekula atď. Vo všeobecnosti sme postupovali podľa nižšie uvedenej stratégie. Netvrdím, že toto je jediná pravda, ale u nás to fungovalo.
- Kopírovanie serverov zo „zlatého obrazu“ je zlo!Hlavnou nevýhodou je, že neviete presne, v akom stave sú obrázky teraz, a že všetky zmeny sa prejavia na všetkých obrázkoch vo všetkých virtualizačných farmách.
- Používajte predvolené konfiguračné súbory na minimum a dohodnite sa s ostatnými oddeleniami, že ste zodpovední za hlavné systémové súbory, napríklad:
- /etc/sysctl.conf nechajte prázdne, nastavenia by mali byť iba v /etc/sysctl.d/. Vaše predvolené v jednom súbore, prispôsobené pre aplikáciu v inom.
- Na úpravu jednotiek systemd použite prepisovacie súbory.
- Vytvorte šablónu všetkých konfigurácií a zahrňte ich úplne; ak je to možné, v príručkách nie sú žiadne sed ani jeho analógy
- Refaktorovanie kódu systému riadenia konfigurácie:
- Rozdeľte úlohy na logické celky a prepíšte monolit na roly
- Použite lintre! Ansible-lint, yaml-lint atď
- Zmeňte svoj prístup! Žiadne hanebné. Je potrebné popísať stav systému
- Pre všetky roly Ansible musíte písať testy v molekule a generovať správy raz denne.
- V našom prípade sa po príprave testov (ktorých je viac ako 100) našlo okolo 70000 XNUMX chýb. Trvalo niekoľko mesiacov, kým sa to opravilo.
Naša realizácia
Takže ansible role boli pripravené, šablónované a skontrolované linters. A dokonca aj gitary sa pestujú všade. Otázka spoľahlivého doručovania kódu do rôznych segmentov však zostala otvorená. Rozhodli sme sa pre synchronizáciu so skriptami. Vyzerá to takto:
Po príchode zmeny sa spustí CI, vytvorí sa testovací server, roly sa zavedú a testuje sa molekulou. Ak je všetko v poriadku, kód prejde do pobočky prod. Nový kód však neaplikujeme na existujúce servery v počítači. Ide o akúsi zátku, ktorá je nevyhnutná pre vysokú dostupnosť našich systémov. A keď sa infraštruktúra stane obrovskou, do hry vstupuje zákon veľkých čísel – aj keď ste si istí, že zmena je neškodná, môže viesť k strašným následkom.
Existuje tiež veľa možností na vytváranie serverov. Nakoniec sme si vybrali vlastné Python skripty. A pre CI prípustné:
- 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}}"K tomu sme dospeli, systém ďalej žije a vyvíja sa.
- 17 Možné roly pre nastavenie servera. Každá z rolí je navrhnutá tak, aby riešila samostatnú logickú úlohu (logovanie, auditovanie, autorizácia používateľov, monitorovanie atď.).
- Testovanie rolí. Molekula + TestInfra.
- Vlastný vývoj: CMDB + Orchestrator.
- Čas vytvorenia servera je ~ 30 minút, je automatizovaný a prakticky nezávislý od fronty úloh.
- Rovnaký stav/pomenovanie infraštruktúry vo všetkých segmentoch – playbooky, repozitáre, virtualizačné prvky.
- Denná kontrola stavu servera s generovaním hlásení o nezrovnalostiach s normou.
Dúfam, že môj príbeh bude užitočný pre tých, ktorí sú na začiatku svojej cesty. Aký automatizačný zásobník používate?
Zdroj: hab.com