Če vaša IT infrastruktura raste prehitro, boste prej ali slej postavljeni pred izbiro: linearno povečevati človeške vire za njeno podporo ali začeti z avtomatizacijo. Do neke točke smo živeli v prvi paradigmi, nato pa se je začela dolga pot do Infrastructure-as-Code.
NSPK seveda ni startup, a takšno vzdušje je vladalo v podjetju v prvih letih obstoja in to so bila zelo zanimiva leta. Ime mi je , že več kot 10 let podpiram infrastrukturo Linuxa z zahtevami po visoki razpoložljivosti. Ekipi NSPK se je pridružil januarja 2016 in na žalost ni dočakal samega začetka obstoja podjetja, ampak je prišel v fazi velikih sprememb.
Na splošno lahko rečemo, da naša ekipa dobavlja 2 izdelka za podjetje. Prva je infrastruktura. Pošta bi morala delovati, DNS bi moral delovati in krmilniki domen bi vas morali pustiti v strežnike, ki se ne bi smeli zrušiti. IT krajina podjetja je ogromna! To so poslovno kritični sistemi, zahteve glede razpoložljivosti za nekatere so 99,999. Drugi produkt so sami strežniki, fizični in virtualni. Obstoječe je treba spremljati, nove pa redno dostavljati kupcem iz številnih oddelkov. V tem članku se želim osredotočiti na to, kako smo razvili infrastrukturo, ki je odgovorna za življenjski cikel strežnika.
Začetek potovanja
Na začetku naše poti je naš tehnološki sklad izgledal takole:
OS CentOS 7
Krmilniki domen FreeIPA
Avtomatizacija - Ansible(+Tower), Cobbler
Vse to se je nahajalo v 3 domenah, razporejenih po več podatkovnih centrih. V enem podatkovnem centru so pisarniški sistemi in testna mesta, v preostalem PROD.
Ustvarjanje strežnikov je na neki točki izgledalo takole:
V predlogi VM je CentOS minimalen in zahtevani minimum je podoben pravilnemu /etc/resolv.conf, ostalo pride prek Ansible.
CMDB - Excel.
Če je strežnik fizični, je bil namesto kopiranja virtualnega stroja OS nameščen na njem s Cobblerjem - naslovi MAC ciljnega strežnika so dodani v konfiguracijo Cobblerja, strežnik prejme naslov IP prek DHCP in nato OS je dodan.
Sprva smo celo poskušali izvesti nekakšno upravljanje konfiguracije v Cobblerju. Toda sčasoma je to začelo prinašati težave s prenosljivostjo konfiguracij v druge podatkovne centre in kodo Ansible za pripravo virtualnih strojev.
Takrat smo mnogi dojemali Ansible kot priročno razširitev Basha in nismo skoparili z zasnovami z lupino in sed. Na splošno Bashsible. To je na koncu pripeljalo do dejstva, da če playbook iz nekega razloga ni deloval na strežniku, je bilo lažje izbrisati strežnik, popraviti playbook in ga znova zagnati. V bistvu ni bilo različic skriptov, nobene prenosljivosti konfiguracij.
Na primer, želeli smo spremeniti nekatere konfiguracije na vseh strežnikih:
- Spremenimo konfiguracijo na obstoječih strežnikih v logičnem segmentu/podatkovnem centru. Včasih ne v enem dnevu - zahteve glede dostopnosti in zakon velikih števil ne dovoljujejo, da bi se vse spremembe uporabile naenkrat. In nekatere spremembe so potencialno uničujoče in zahtevajo ponovni zagon nečesa - od storitev do samega OS.
- Popravljanje v Ansibleu
- Popravimo ga v Cobblerju
- Ponovite N-krat za vsak logični segment/podatkovni center
Da so vse spremembe potekale gladko, je bilo treba upoštevati številne dejavnike, spremembe pa se dogajajo nenehno.
- Refactoring ansible kode, konfiguracijske datoteke
- Spreminjanje najboljših notranjih praks
- Spremembe na podlagi rezultatov analize incidentov/nesreč
- Spreminjanje varnostnih standardov, tako notranjih kot zunanjih. Na primer, PCI DSS se vsako leto posodobi z novimi zahtevami
Rast infrastrukture in začetek poti
Povečalo se je število strežnikov/logičnih domen/podatkovnih centrov, s tem pa tudi število napak v konfiguracijah. Na neki točki smo prišli do treh smeri, v katerih je treba razvijati upravljanje konfiguracije:
- Avtomatizacija. Človeški napaki pri ponavljajočih se operacijah se je treba čim bolj izogibati.
- Ponovljivost. Infrastrukturo je veliko lažje upravljati, če je predvidljiva. Konfiguracija strežnikov in orodij za njihovo pripravo naj bo povsod enaka. To je pomembno tudi za produktne ekipe – po testiranju je treba zagotoviti, da aplikacija konča v produkcijskem okolju, konfiguriranem podobno kot testno okolje.
- Preprostost in preglednost spreminjanja upravljanja konfiguracije.
Ostaja še dodati nekaj orodij.
Za naše skladišče kode smo izbrali GitLab CE, nenazadnje zaradi njegovih vgrajenih modulov CI/CD.
Trezor skrivnosti - Hashicorp Vault, vklj. za odličen API.
Konfiguracije testiranja in anzibilne vloge – Molecule+Testinfra. Testi potekajo veliko hitreje, če se povežete z ansible mitogen. Hkrati smo začeli pisati svoj CMDB in orkestrator za avtomatsko uvajanje (na sliki zgoraj Cobbler), vendar je to povsem druga zgodba, ki jo bo moj kolega in glavni razvijalec teh sistemov povedal v prihodnosti.
Naša izbira:
Molekula + Testinfra
Ansible + stolp + AWX
Svet strežnikov + DITNET (Lasten razvoj)
Čevljar
Gitlab + GitLab runner
Hashicorp trezor
Mimogrede, o anzibilnih vlogah. Sprva je bil samo eden, po več refaktoringih pa jih je bilo 17. Močno priporočam, da monolit razdelite na idempotentne vloge, ki jih lahko nato zaženete ločeno, poleg tega pa lahko dodate oznake. Vloge smo razdelili po funkcionalnosti - omrežje, beleženje, paketi, strojna oprema, molekula itd. Na splošno smo sledili spodnji strategiji. Ne vztrajam, da je to edina resnica, vendar nam je uspelo.
- Kopiranje strežnikov iz "zlate podobe" je zlo!Glavna pomanjkljivost je, da ne veste natančno, v kakšnem stanju so trenutno slike, in da bodo vse spremembe prišle na vse slike v vseh virtualizacijskih farmah.
- Uporabljajte čim manj privzetih konfiguracijskih datotek in se dogovorite z drugimi oddelki, da ste odgovorni za glavne sistemske datoteke, na primer:
- Pustite /etc/sysctl.conf prazno, nastavitve naj bodo samo v /etc/sysctl.d/. Vaš privzeti v eni datoteki, po meri za aplikacijo v drugi.
- Uporabite preglasitvene datoteke za urejanje sistemskih enot.
- Oblikujte vse konfiguracije in jih v celoti vključite; če je mogoče, brez seda ali njegovih analogov v knjigah iger
- Preoblikovanje sistemske kode za upravljanje konfiguracije:
- Razčlenite naloge na logične entitete in prepišite monolit v vloge
- Uporabite linterje! Ansible-lint, yaml-lint itd
- Spremenite svoj pristop! Brez udarca. Potrebno je opisati stanje sistema
- Za vse vloge Ansible morate pisati teste v molekuli in ustvarjati poročila enkrat na dan.
- V našem primeru je bilo po pripravi testov (teh je več kot 100) ugotovljenih približno 70000 napak. Popravilo je trajalo več mesecev.
Naša izvedba
Tako so bile anzibilne vloge pripravljene, oblikovane in preverjene s strani linterjev. In celo gits se gojijo povsod. Odprto pa je ostalo vprašanje zanesljive dostave kode v različne segmente. Odločili smo se za sinhronizacijo s skripti. Izgleda takole:
Ko sprememba prispe, se zažene CI, ustvari testni strežnik, uvedejo se vloge in testira molekula. Če je vse v redu, gre koda v vejo prod. Toda nove kode ne uporabljamo za obstoječe strežnike v napravi. To je neke vrste zamašek, ki je nujen za visoko razpoložljivost naših sistemov. In ko infrastruktura postane ogromna, pride v poštev zakon velikih števil – tudi če ste prepričani, da je sprememba neškodljiva, lahko povzroči hude posledice.
Obstaja tudi veliko možnosti za ustvarjanje strežnikov. Na koncu smo izbrali skripte Python po meri. In 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 tega smo prišli, sistem še naprej živi in se razvija.
- 17 Antabilnih vlog za nastavitev strežnika. Vsaka od vlog je zasnovana za reševanje ločene logične naloge (beleženje, revizija, avtorizacija uporabnikov, spremljanje itd.).
- Preizkušanje vlog. Molecule + TestInfra.
- Lasten razvoj: CMDB + Orchestrator.
- Čas ustvarjanja strežnika je približno 30 minut, avtomatiziran in praktično neodvisen od čakalne vrste opravil.
- Enako stanje/poimenovanje infrastrukture v vseh segmentih - playbooks, repozitoriji, elementi virtualizacije.
- Dnevno preverjanje statusa strežnika z generiranjem poročil o neskladju s standardom.
Upam, da bo moja zgodba koristna za tiste, ki so na začetku svoje poti. Kateri sklad za avtomatizacijo uporabljate?
Vir: www.habr.com