Bližalo se je novo leto. Otroci po vsej državi so že poslali pisma Božičku ali si izdelali darila, njihov glavni izvajalec, eden večjih trgovcev, pa se je pripravljal na apoteozo razprodaj. Decembra se obremenitev njegovega podatkovnega centra večkrat poveča. Zato so se v podjetju odločili posodobiti podatkovni center in namesto opreme, ki se ji je iztekala življenjska doba, zagnati več deset novih strežnikov. S tem se konča pravljica v ozadju vrtinčenja snežink in začne se triler.
Oprema je prispela na lokacijo nekaj mesecev pred vrhuncem prodaje. Operativna služba seveda ve, kako in kaj konfigurirati na strežnikih, da jih spravimo v produkcijsko okolje. Toda to smo morali avtomatizirati in odpraviti človeški dejavnik. Poleg tega so bili strežniki zamenjani pred migracijo nabora sistemov SAP, ki so bili kritični za podjetje.
Zagon novih strežnikov je bil strogo vezan na rok. Premik pa je pomenil ogrožanje tako pošiljke milijarde daril kot selitve sistemov. Tudi ekipa, sestavljena iz dedka Mraza in Božička, ni mogla spremeniti datuma - sistem SAP za upravljanje skladišča lahko prenesete le enkrat letno. Od 31. decembra do 1. januarja ogromna skladišča trgovca, skupaj velika kot 20 nogometnih igrišč, ustavijo svoje delo za 15 ur. In to je edino časovno obdobje za premik sistema. Pri uvajanju strežnikov nismo imeli prostora za napake.
Naj bom jasen: moja zgodba odraža orodja in postopek upravljanja konfiguracije, ki ga uporablja naša ekipa.
Kompleks upravljanja konfiguracije je sestavljen iz več nivojev. Ključna komponenta je sistem CMS. V industrijskem obratovanju bi odsotnost ene od stopenj neizogibno povzročila neprijetne čudeže.
Upravljanje namestitve OS
Prvi nivo je sistem za upravljanje namestitve operacijskih sistemov na fizičnih in virtualnih strežnikih. Ustvarja osnovne konfiguracije OS in odpravlja človeški dejavnik.
S tem sistemom smo dobili standardne strežniške instance z OS, ki je primeren za nadaljnjo avtomatizacijo. Med "prelivanjem" so prejeli minimalni nabor lokalnih uporabnikov in javnih ključev SSH ter konsistentno konfiguracijo OS. Lahko smo zagotovili, da bomo upravljali strežnike prek CMS-ja in smo bili prepričani, da ni nobenih presenečenj »spodaj« na ravni OS.
"Največja" naloga sistema za upravljanje namestitve je samodejno konfiguriranje strežnikov od ravni BIOS-a/strojne programske opreme do OS. Tu je veliko odvisno od opreme in nastavitev. Za heterogeno opremo lahko razmislite . Če je vsa strojna oprema enega proizvajalca, je pogosto bolj priročno uporabiti že pripravljena orodja za upravljanje (na primer HP ILO Amplifier, DELL OpenManage itd.).
Za namestitev OS na fizične strežnike smo uporabili znani Cobbler, ki definira nabor namestitvenih profilov, dogovorjenih s servisom za obratovanje. Pri dodajanju novega strežnika v infrastrukturo je inženir povezal naslov MAC strežnika z zahtevanim profilom v Cobblerju. Ob prvem zagonu preko omrežja je strežnik prejel začasni naslov in svež OS. Nato je bil prenesen na ciljno naslavljanje VLAN/IP in tam nadaljeval delo. Da, spreminjanje VLAN-a zahteva čas in koordinacijo, vendar zagotavlja dodatno zaščito pred nenamerno namestitvijo strežnika v produkcijskem okolju.
Virtualne strežnike smo izdelali na podlagi predlog, pripravljenih s HashiСorp Packerjem. Razlog je bil enak: preprečiti morebitne človeške napake pri namestitvi OS. Toda za razliko od fizičnih strežnikov Packer odpravlja potrebo po PXE, omrežnem zagonu in spremembah VLAN. To je olajšalo in poenostavilo ustvarjanje virtualnih strežnikov.
riž. 1. Upravljanje namestitve operacijskih sistemov.
Upravljanje skrivnosti
Vsak sistem za upravljanje konfiguracije vsebuje podatke, ki bi morali biti skriti pred običajnimi uporabniki, vendar so potrebni za pripravo sistemov. To so gesla za lokalne uporabnike in storitvene račune, ključi potrdil, različni žetoni API itd. Običajno se imenujejo »skrivnosti«.
Če od samega začetka ne določite, kje in kako shranite te skrivnosti, potem so glede na resnost zahtev glede varnosti informacij verjetno naslednji načini shranjevanja:
- neposredno v konfiguracijski nadzorni kodi ali v datotekah v repozitoriju;
- v specializiranih orodjih za upravljanje konfiguracije (na primer Ansible Vault);
- v sistemih CI/CD (Jenkins/TeamCity/GitLab/itd.) ali v sistemih za upravljanje konfiguracije (Ansible Tower/Ansible AWX);
- skrivnosti je mogoče prenesti tudi »ročno«. Na primer, postavljeni so na določeno lokacijo, nato pa jih uporabljajo sistemi za upravljanje konfiguracije;
- različne kombinacije naštetega.
Vsaka metoda ima svoje slabosti. Glavna je pomanjkanje politik za dostop do skrivnosti: nemogoče ali težko je določiti, kdo lahko uporablja določene skrivnosti. Druga pomanjkljivost je pomanjkanje revizije dostopa in polnega življenjskega cikla. Kako hitro zamenjati na primer javni ključ, ki je zapisan v kodi in v številnih sorodnih sistemih?
Uporabili smo centralizirano tajno shrambo HashiCorp Vault. To nam je omogočilo:
- varuj skrivnosti. Šifrirani so in tudi če nekdo pridobi dostop do baze podatkov Vault (na primer tako, da jo obnovi iz varnostne kopije), ne bo mogel prebrati tam shranjenih skrivnosti;
- organizirati politike za dostop do skrivnosti. Uporabnikom in aplikacijam so na voljo le skrivnosti, ki so jim »dodeljene«;
- revizijski dostop do skrivnosti. Vsa dejanja s skrivnostmi se zabeležijo v revizijski dnevnik trezorja;
- organizirati poln "življenjski cikel" dela s skrivnostmi. Lahko jih ustvarite, prekličete, določite datum poteka itd.
- enostavna integracija z drugimi sistemi, ki potrebujejo dostop do skrivnosti;
- uporabljajte tudi šifriranje od konca do konca, enkratna gesla za OS in bazo podatkov, potrdila pooblaščenih centrov itd.
Zdaj pa preidimo na centralni sistem za preverjanje pristnosti in avtorizacijo. Brez tega je bilo mogoče storiti, vendar je upravljanje uporabnikov v številnih sorodnih sistemih preveč netrivialno. Konfigurirali smo avtentikacijo in avtorizacijo prek storitve LDAP. V nasprotnem primeru bi moral Vault nenehno izdajati in spremljati žetone za preverjanje pristnosti za uporabnike. In brisanje in dodajanje uporabnikov bi se spremenilo v iskanje "ali sem ustvaril/izbrisal ta uporabniški račun povsod?"
Našemu sistemu dodamo še eno raven: upravljanje skrivnosti in centralna avtentikacija/avtorizacija:
riž. 2. Upravljanje skrivnosti.
Upravljanje konfiguracije
Prišli smo do jedra - sistema CMS. V našem primeru je to kombinacija Ansible in Red Hat Ansible AWX.
Namesto Ansible lahko uporabite Chef, Puppet, SaltStack. Ansible smo izbrali na podlagi več kriterijev.
- Prvič, to je vsestranskost. Komplet že pripravljenih modulov za nadzor . In če ga nimate dovolj, lahko iščete na GitHub in Galaxy.
- Drugič, ni treba namestiti in podpirati agentov na upravljani opremi, dokazati, da ne motijo obremenitve, in potrditi odsotnost "zaznamkov".
- Tretjič, Ansible ima nizko vstopno oviro. Pristojni inženir bo napisal delovno knjigo dobesedno prvi dan dela z izdelkom.
Toda sam Ansible v produkcijskem okolju nam ni bil dovolj. V nasprotnem primeru bi se pojavile številne težave z omejevanjem dostopa in nadzorom delovanja skrbnikov. Kako omejiti dostop? Navsezadnje je moral vsak oddelek upravljati (beri: zagnati Ansible Playbook) »svoj« nabor strežnikov. Kako dovoliti samo določenim zaposlenim, da izvajajo posebne knjige Ansible? Ali kako izslediti, kdo je izdal priročnik, ne da bi na strežnikih in opremi, ki poganja Ansible, vzpostavili veliko lokalnega znanja?
Levji delež takih težav rešuje Red Hat , ali njegov odprtokodni projekt navzgor . Zato smo ga dali prednost stranki.
In še en dotik k portretu našega CMS sistema. Ansible playbook bi moral biti shranjen v sistemih za upravljanje repozitorija kode. Imamo ga .
Same konfiguracije torej upravlja kombinacija Ansible/Ansible AWX/GitLab (glej sliko 3). Seveda je AWX/GitLab integriran z enim sistemom za preverjanje pristnosti, Ansible playbook pa je integriran s HashiCorp Vault. Konfiguracije vstopijo v produkcijsko okolje samo prek Ansible AWX, v katerem so določena vsa "pravila igre": kdo lahko kaj konfigurira, kje dobiti kodo za upravljanje konfiguracije za CMS itd.
riž. 3. Upravljanje konfiguracije.
Upravljanje testov
Naša konfiguracija je predstavljena v obliki kode. Zato smo prisiljeni igrati po enakih pravilih kot razvijalci programske opreme. Organizirati smo morali procese razvoja, nenehnega testiranja, dostave in aplikacije konfiguracijske kode na produkcijske strežnike.
Če tega ne storite takoj, potem vloge, zapisane za konfiguracijo, ne bodo več podprte in spremenjene ali pa se ne bodo več lansirale v produkcijo. Zdravilo za to bolečino je znano in se je izkazalo v tem projektu:
- vsaka vloga je pokrita z enotnimi testi;
- testi se izvajajo samodejno vsakič, ko se spremeni koda, ki upravlja konfiguracije;
- spremembe kode za upravljanje konfiguracije se sprostijo v produkcijsko okolje šele po uspešno opravljenih vseh testih in pregledu kode.
Razvoj kode in upravljanje konfiguracije sta postala mirnejša in bolj predvidljiva. Za organizacijo neprekinjenega testiranja smo uporabili komplet orodij GitLab CI/CD in vzeli .
Kadarkoli pride do spremembe kode za upravljanje konfiguracije, GitLab CI/CD pokliče Molecule:
- preveri sintakso kode,
- dvigne vsebnik Docker,
- uporabi spremenjeno kodo v ustvarjenem vsebniku,
- preveri vlogo za idempotenco in zažene teste za to kodo (razdrobljenost je tukaj na ravni anzibilne vloge, glejte sliko 4).
Konfiguracije smo dostavili v produkcijsko okolje z uporabo Ansible AWX. Operacijski inženirji so spremembe konfiguracije uporabili prek vnaprej določenih predlog. AWX je neodvisno "zahteval" najnovejšo različico kode iz glavne veje GitLab vsakič, ko je bila uporabljena. Na ta način smo izključili uporabo nepreverjene ali zastarele kode v produkcijskem okolju. Seveda je koda vstopila v glavno vejo šele po testiranju, pregledu in odobritvi.
riž. 4. Samodejno testiranje vlog v GitLab CI/CD.
Problem je povezan tudi z delovanjem proizvodnih sistemov. V resničnem življenju je zelo težko spremeniti konfiguracijo samo s kodo CMS. Izredne razmere se pojavijo, ko mora inženir spremeniti konfiguracijo "tukaj in zdaj", ne da bi čakal na urejanje kode, testiranje, odobritev itd.
Posledično se zaradi ročnih sprememb pojavijo odstopanja v konfiguraciji na isti vrsti opreme (na primer, nastavitve sysctl so na vozliščih gruče HA konfigurirane drugače). Ali pa se dejanska konfiguracija opreme razlikuje od tiste, navedene v kodi CMS.
Zato poleg nenehnega testiranja preverjamo produkcijska okolja glede odstopanj v konfiguraciji. Izbrali smo najpreprostejšo možnost: zagon konfiguracijske kode CMS v načinu »suhega delovanja«, to je brez uveljavljanja sprememb, vendar z obvestilom o vseh neskladjih med načrtovano in dejansko konfiguracijo. To smo implementirali tako, da smo občasno izvajali vse Ansible playbooks z možnostjo »—check« na produkcijskih strežnikih. Kot vedno je Ansible AWX odgovoren za zagon in posodabljanje priročnika (glej sliko 5):
riž. 5. Preveri odstopanja v konfiguraciji v Ansible AWX.
Po pregledih AWX pošlje skrbnikom poročilo o neskladju. Preučijo problematično konfiguracijo in jo nato popravijo s prilagojenimi priročniki. Tako vzdržujemo konfiguracijo v produkcijskem okolju in CMS je vedno posodobljen in sinhroniziran. To odpravlja neprijetne "čudeže", ko se koda CMS uporablja na "produkcijskih" strežnikih.
Zdaj imamo pomembno testno plast, ki jo sestavljajo Ansible AWX/GitLab/Molecule (slika 6).
riž. 6. Vodenje testov.
Težko? Ne trdim. Toda tak kompleks upravljanja konfiguracije je postal celovit odgovor na številna vprašanja, povezana z avtomatizacijo konfiguracije strežnika. Zdaj imajo standardni strežniki prodajalca vedno strogo določeno konfiguracijo. CMS za razliko od inženirja ne bo pozabil dodati potrebnih nastavitev, ustvariti uporabnikov in izvesti na desetine ali stotine zahtevanih nastavitev.
Danes v nastavitvah strežnikov in okolij ni "skrivnega znanja". Vse potrebne funkcije so prikazane v priročniku. Nič več ustvarjalnosti in nejasnih navodil: “Namestite ga kot običajni Oracle, vendar morate določiti nekaj nastavitev sysctl in dodati uporabnike z zahtevanim UID. Vprašaj fante v operaciji, oni vedo".
Sposobnost zaznavanja odstopanj v konfiguraciji in njihovega proaktivnega popravljanja zagotavlja brezskrbnost. Brez sistema za upravljanje konfiguracije je to običajno videti drugače. Težave se kopičijo, dokler se nekega dne ne »izstrelijo« v proizvodnjo. Nato se izvede poročilo, konfiguracije se preverijo in popravijo. In cikel se spet ponovi
In seveda smo pospešili zagon strežnikov v delovanje iz nekaj dni na ure.
No, na samo silvestrovo, ko so otroci veselo odvijali darila, odrasli pa ob zvonjenju kleli želje, so naši inženirji sistem SAP preselili na nove strežnike. Tudi Božiček bo rekel, da so najboljši čudeži tisti, ki so dobro pripravljeni.
PS Naša ekipa se pogosto srečuje z dejstvom, da želijo stranke čim bolj preprosto rešiti probleme upravljanja konfiguracije. V idealnem primeru, kot po čarovniji - z enim orodjem. Toda v življenju je vse bolj zapleteno (da, srebrne krogle niso bile ponovno dostavljene): ustvariti morate celoten proces z orodji, ki so primerna za ekipo stranke.
Avtor: Sergej Artemov, arhitekt oddelka "Jet Infosystems"
Vir: www.habr.com