TuvojÄs Jaunais gads. BÄrni visÄ valstÄ« jau bija sÅ«tÄ«juÅ”i vÄstules ZiemassvÄtku vecÄ«tim vai sarÅ«pÄjuÅ”i sev dÄvanas, un viÅu galvenais izpildÄ«tÄjs, viens no lielÄkajiem mazumtirgotÄjiem, gatavojÄs izpÄrdoÅ”anas apoteozei. DecembrÄ« tÄ datu centra slodze palielinÄs vairÄkas reizes. TÄpÄc uzÅÄmums nolÄma modernizÄt datu centru un ekspluatÄcijÄ nodot vairÄkus desmitus jaunu serveru, nevis iekÄrtas, kurÄm tuvojÄs kalpoÅ”anas laika beigas. Ar to pasaka beidzas uz virpuļojoÅ”u sniegpÄrslu fona, un sÄkas trilleris.
IekÄrtas objektÄ ieradÄs vairÄkus mÄneÅ”us pirms pÄrdoÅ”anas maksimuma. OperÄciju dienests, protams, zina, kÄ un ko konfigurÄt serveros, lai tos ievestu ražoÅ”anas vidÄ. Bet mums vajadzÄja to automatizÄt un novÄrst cilvÄcisko faktoru. TurklÄt serveri tika nomainÄ«ti pirms uzÅÄmumam kritisko SAP sistÄmu kopas migrÄcijas.
Jaunu serveru nodoÅ”ana ekspluatÄcijÄ bija stingri saistÄ«ta ar termiÅu. Un tÄ pÄrvietoÅ”ana nozÄ«mÄja apdraudÄt gan miljardu dÄvanu nosÅ«tÄ«Å”anu, gan sistÄmu migrÄciju. Pat komanda, kuras sastÄvÄ bija TÄvs Frosts un ZiemassvÄtku vecÄ«tis, nevarÄja mainÄ«t datumu - SAP sistÄmu noliktavas pÄrvaldÄ«Å”anai varat nodot tikai reizi gadÄ. No 31. decembra lÄ«dz 1. janvÄrim uz 20 stundÄm darbu pÄrtrauc mazumtirgotÄja milzÄ«gÄs noliktavas, kopumÄ 15 futbola laukumu lielumÄ. Un tas ir vienÄ«gais laika periods sistÄmas pÄrvietoÅ”anai. IevieÅ”ot serverus, mums nebija vietas kļūdÄm.
TeikÅ”u skaidri: mans stÄsts atspoguļo rÄ«kus un konfigurÄcijas pÄrvaldÄ«bas procesu, ko izmanto mÅ«su komanda.
KonfigurÄcijas pÄrvaldÄ«bas komplekss sastÄv no vairÄkiem lÄ«meÅiem. GalvenÄ sastÄvdaļa ir CMS sistÄma. RÅ«pnieciskajÄ darbÄ«bÄ viena lÄ«meÅa neesamÄ«ba neizbÄgami novestu pie nepatÄ«kamiem brÄ«numiem.
OS instalÄcijas pÄrvaldÄ«ba
Pirmais lÄ«menis ir sistÄma operÄtÄjsistÄmu instalÄÅ”anas pÄrvaldÄ«bai fiziskajos un virtuÄlajos serveros. Tas rada pamata OS konfigurÄcijas, novÄrÅ”ot cilvÄcisko faktoru.
Izmantojot Å”o sistÄmu, mÄs saÅÄmÄm standarta servera gadÄ«jumus ar OS, kas piemÄrota turpmÄkai automatizÄcijai. āIeleÅ”anasā laikÄ viÅi saÅÄma minimÄlo vietÄjo lietotÄju un publisko SSH atslÄgu komplektu, kÄ arÄ« konsekventu OS konfigurÄciju. MÄs varÄjÄm bÅ«t pÄrliecinÄti, ka pÄrvaldÄ«sim serverus, izmantojot SPS, un bijÄm pÄrliecinÄti, ka OS lÄ«menÄ« nav nekÄdu pÄrsteigumu.
InstalÄcijas pÄrvaldÄ«bas sistÄmas "maksimÄlais" uzdevums ir automÄtiski konfigurÄt serverus no BIOS/programmaparatÅ«ras lÄ«meÅa uz OS. Å eit daudz kas ir atkarÄ«gs no aprÄ«kojuma un iestatÄ«Å”anas uzdevumiem. AttiecÄ«bÄ uz neviendabÄ«gu aprÄ«kojumu varat apsvÄrt . Ja visa aparatÅ«ra ir no viena ražotÄja, tad bieži vien ÄrtÄk ir izmantot gatavus pÄrvaldÄ«bas rÄ«kus (piemÄram, HP ILO Amplifier, DELL OpenManage u.c.).
Lai instalÄtu OS uz fiziskajiem serveriem, mÄs izmantojÄm labi zinÄmo Cobbler, kas definÄ instalÄcijas profilu kopu, kas saskaÅota ar darbÄ«bas dienestu. Pievienojot infrastruktÅ«rai jaunu serveri, inženieris sasaistÄ«ja servera MAC adresi ar nepiecieÅ”amo profilu programmÄ Cobbler. Pirmoreiz startÄjot tÄ«klÄ, serveris saÅÄma pagaidu adresi un jaunu OS. PÄc tam tas tika pÄrsÅ«tÄ«ts uz mÄrÄ·a VLAN/IP adresÄÅ”anu un turpinÄja darbu tur. JÄ, VLAN maiÅa prasa laiku un prasa saskaÅoÅ”anu, taÄu tÄ nodroÅ”ina papildu aizsardzÄ«bu pret nejauÅ”u servera instalÄÅ”anu ražoÅ”anas vidÄ.
MÄs izveidojÄm virtuÄlos serverus, pamatojoties uz veidnÄm, kas sagatavotas, izmantojot HashiŠ”orp Packer. Iemesls bija tas pats: lai novÄrstu iespÄjamÄs cilvÄka kļūdas, instalÄjot OS. Bet, atŔķirÄ«bÄ no fiziskajiem serveriem, Packer novÄrÅ” vajadzÄ«bu pÄc PXE, tÄ«kla sÄknÄÅ”anas un VLAN izmaiÅÄm. Tas ir padarÄ«jis vienkÄrÅ”Äku un vienkÄrÅ”Äku virtuÄlo serveru izveidi.
RÄ«si. 1. OperÄtÄjsistÄmu instalÄÅ”anas vadÄ«Å”ana.
NoslÄpumu pÄrvaldÄ«Å”ana
Jebkura konfigurÄcijas pÄrvaldÄ«bas sistÄma satur datus, kas ir jÄslÄpj no parastajiem lietotÄjiem, bet ir nepiecieÅ”ami sistÄmu sagatavoÅ”anai. TÄs ir vietÄjo lietotÄju un pakalpojumu kontu paroles, sertifikÄtu atslÄgas, dažÄdi API marÄ·ieri utt. Tos parasti sauc par ānoslÄpumiemā.
Ja jau paÅ”Ä sÄkumÄ nenosakÄt, kur un kÄ uzglabÄt Å”os noslÄpumus, tad atkarÄ«bÄ no informÄcijas droŔības prasÄ«bu nopietnÄ«bas ir iespÄjamas Å”Ädas glabÄÅ”anas metodes:
- tieÅ”i konfigurÄcijas kontroles kodÄ vai failos repozitorijÄ;
- specializÄtos konfigurÄcijas pÄrvaldÄ«bas rÄ«kos (piemÄram, Ansible Vault);
- CI/CD sistÄmÄs (Jenkins/TeamCity/GitLab/u.c.) vai konfigurÄcijas pÄrvaldÄ«bas sistÄmÄs (Ansible Tower/Ansible AWX);
- noslÄpumus var pÄrsÅ«tÄ«t arÄ« āmanuÄliā. PiemÄram, tie ir izvietoti noteiktÄ vietÄ, un pÄc tam tos izmanto konfigurÄcijas pÄrvaldÄ«bas sistÄmas;
- dažÄdas iepriekÅ” minÄto kombinÄcijas.
Katrai metodei ir savi trÅ«kumi. Galvenais no tiem ir pieejas noslÄpumiem politikas trÅ«kums: nav iespÄjams vai grÅ«ti noteikt, kas var izmantot noteiktus noslÄpumus. VÄl viens trÅ«kums ir piekļuves audita un pilna dzÄ«ves cikla trÅ«kums. KÄ Ätri nomainÄ«t, piemÄram, publisko atslÄgu, kas ierakstÄ«ta kodÄ un vairÄkÄs saistÄ«tÄs sistÄmÄs?
MÄs izmantojÄm centralizÄto slepeno krÄtuvi HashiCorp Vault. Tas mums ļÄva:
- glabÄ noslÄpumus droŔībÄ. Tie ir Å”ifrÄti, un pat ja kÄds iegÅ«s piekļuvi Vault datu bÄzei (piemÄram, atjaunojot to no dublÄjuma), viÅÅ” nevarÄs nolasÄ«t tur glabÄtos noslÄpumus;
- organizÄt politikas par piekļuvi noslÄpumiem. LietotÄjiem un lietojumprogrammÄm ir pieejami tikai tiem āpieŔķirtieā noslÄpumi;
- audita piekļuvi noslÄpumiem. Visas darbÄ«bas ar noslÄpumiem tiek ierakstÄ«tas Vault audita žurnÄlÄ;
- organizÄt pilnvÄrtÄ«gu ādzÄ«ves cikluā darbam ar noslÄpumiem. Tos var izveidot, atsaukt, noteikt derÄ«guma termiÅu utt.
- viegli integrÄjams ar citÄm sistÄmÄm, kurÄm nepiecieÅ”ama piekļuve noslÄpumiem;
- kÄ arÄ« izmantot pilnÄ«gu Å”ifrÄÅ”anu, vienreizÄjas OS un datu bÄzes paroles, pilnvaroto centru sertifikÄtus utt.
Tagad pÄriesim pie centrÄlÄs autentifikÄcijas un autorizÄcijas sistÄmas. Bez tÄ varÄja iztikt, taÄu lietotÄju administrÄÅ”ana daudzÄs saistÄ«tÄs sistÄmÄs ir pÄrÄk nenozÄ«mÄ«ga. MÄs esam konfigurÄjuÅ”i autentifikÄciju un autorizÄciju, izmantojot LDAP pakalpojumu. PretÄjÄ gadÄ«jumÄ Vault bÅ«tu nepÄrtraukti jÄizsniedz un jÄseko lÄ«dzi lietotÄju autentifikÄcijas marÄ·ieriem. Un lietotÄju dzÄÅ”ana un pievienoÅ”ana pÄrvÄrstos par meklÄjumu āvai es visur izveidoju/izdzÄsu Å”o lietotÄja kontu?ā
MÄs pievienojam mÅ«su sistÄmai vÄl vienu lÄ«meni: noslÄpumu pÄrvaldÄ«ba un centrÄlÄ autentifikÄcija/autorizÄcija:
RÄ«si. 2. NoslÄpumu pÄrvaldÄ«ba.
KonfigurÄcijas pÄrvaldÄ«ba
MÄs nonÄcÄm pie kodola ā CMS sistÄmas. MÅ«su gadÄ«jumÄ Å”Ä« ir Ansible un Red Hat Ansible AWX kombinÄcija.
Ansible vietÄ var izmantot Chef, Puppet, SaltStack. MÄs izvÄlÄjÄmies Ansible, pamatojoties uz vairÄkiem kritÄrijiem.
- PirmkÄrt, tÄ ir daudzpusÄ«ba. Gatavu moduļu komplekts vadÄ«bai . Un, ja jums ar to nepietiek, varat meklÄt GitHub un Galaxy.
- OtrkÄrt, pÄrvaldÄ«tajÄs iekÄrtÄs nav jÄinstalÄ un jÄatbalsta aÄ£enti, jÄpierÄda, ka tie netraucÄ slodzei, un jÄapstiprina āgrÄmatzÄ«mjuā neesamÄ«ba.
- TreÅ”kÄrt, Ansible ir zema barjera ienÄkÅ”anai. Kompetents inženieris burtiski uzrakstÄ«s darba rokasgrÄmatu pirmajÄ darba dienÄ ar produktu.
TaÄu ar Ansible vien ražoÅ”anas vidÄ mums nepietika. PretÄjÄ gadÄ«jumÄ rastos daudzas problÄmas ar piekļuves ierobežoÅ”anu un administratoru darbÄ«bas auditÄÅ”anu. KÄ ierobežot piekļuvi? Galu galÄ katrai nodaļai vajadzÄja pÄrvaldÄ«t (lasi: palaist Ansible playbook) āsavuā serveru komplektu. KÄ Ä¼aut tikai noteiktiem darbiniekiem vadÄ«t noteiktas Ansible rokasgrÄmatas? Vai arÄ« kÄ izsekot, kurÅ” palaidis rokasgrÄmatu, neiestatot daudz vietÄjo zinÄÅ”anu par serveriem un aprÄ«kojumu, kurÄ darbojas Ansible?
Lauvas tiesu no Å”Ädiem jautÄjumiem atrisina Red Hat , vai viÅa atvÄrtÄ pirmkoda augÅ”upÄjais projekts . TÄpÄc mÄs to izvÄlÄjÄmies klientam.
Un vÄl viens pieskÄriens mÅ«su CMS sistÄmas portretam. IespÄjamÄ rokasgrÄmata ir jÄglabÄ kodu krÄtuvju pÄrvaldÄ«bas sistÄmÄs. Mums tas ir .
TÄtad paÅ”as konfigurÄcijas pÄrvalda Ansible/Ansible AWX/GitLab kombinÄcija (skat. 3. att.). Protams, AWX/GitLab ir integrÄts ar vienu autentifikÄcijas sistÄmu, un Ansible playbook ir integrÄts ar HashiCorp Vault. KonfigurÄcijas nonÄk ražoÅ”anas vidÄ tikai caur Ansible AWX, kurÄ ir norÄdÄ«ti visi āspÄles noteikumiā: kurÅ” ko var konfigurÄt, kur iegÅ«t CMS konfigurÄcijas pÄrvaldÄ«bas kodu utt.
RÄ«si. 3. KonfigurÄcijas pÄrvaldÄ«ba.
Testu vadība
MÅ«su konfigurÄcija ir parÄdÄ«ta koda formÄ. TÄpÄc mÄs esam spiesti spÄlÄt pÄc tÄdiem paÅ”iem noteikumiem kÄ programmatÅ«ras izstrÄdÄtÄji. Mums vajadzÄja organizÄt izstrÄdes, nepÄrtrauktas testÄÅ”anas, piegÄdes un konfigurÄcijas koda pielietoÅ”anas procesus ražoÅ”anas serveriem.
Ja tas netiek izdarÄ«ts nekavÄjoties, konfigurÄcijai rakstÄ«tÄs lomas vai nu vairs netiks atbalstÄ«tas un modificÄtas, vai arÄ« vairs netiktu palaists ražoÅ”anÄ. Å o sÄpju zÄles ir zinÄmas, un tas ir sevi pierÄdÄ«jis Å”ajÄ projektÄ:
- uz katru lomu attiecas vienības testi;
- testi tiek palaisti automÄtiski ikreiz, kad tiek veiktas izmaiÅas kodÄ, kas pÄrvalda konfigurÄcijas;
- izmaiÅas konfigurÄcijas pÄrvaldÄ«bas kodÄ tiek izlaistas ražoÅ”anas vidÄ tikai pÄc sekmÄ«gas visu testu nokÄrtoÅ”anas un koda pÄrskatÄ«Å”anas.
Kodu izstrÄde un konfigurÄcijas pÄrvaldÄ«ba ir kļuvusi mierÄ«gÄka un paredzamÄka. Lai organizÄtu nepÄrtrauktu testÄÅ”anu, mÄs izmantojÄm GitLab CI/CD rÄ«ku komplektu un paÅÄmÄm .
Ikreiz, kad notiek izmaiÅas konfigurÄcijas pÄrvaldÄ«bas kodÄ, GitLab CI/CD izsauc Molecule:
- tÄ pÄrbauda koda sintaksi,
- paceļ Docker konteineru,
- piemÄro modificÄto kodu izveidotajam konteineram,
- pÄrbauda lomu idempotencei un veic Ŕī koda testus (detalitÄte Å”eit ir iespÄjamÄ loma lÄ«menÄ«, skatiet 4. attÄlu).
MÄs piegÄdÄjÄm konfigurÄcijas ražoÅ”anas vidÄ, izmantojot Ansible AWX. OperÄciju inženieri piemÄroja konfigurÄcijas izmaiÅas, izmantojot iepriekÅ” noteiktas veidnes. AWX neatkarÄ«gi āpieprasÄ«jaā jaunÄko koda versiju no GitLab galvenÄs filiÄles katru reizi, kad tÄ tika izmantota. TÄdÄ veidÄ mÄs izslÄdzÄm nepÄrbaudÄ«ta vai novecojuÅ”a koda izmantoÅ”anu ražoÅ”anas vidÄ. Protams, kods iekļuva galvenajÄ zarÄ tikai pÄc testÄÅ”anas, pÄrskatÄ«Å”anas un apstiprinÄÅ”anas.
RÄ«si. 4. AutomÄtiska lomu pÄrbaude GitLab CI/CD.
Ir arÄ« problÄma, kas saistÄ«ta ar ražoÅ”anas sistÄmu darbÄ«bu. ReÄlajÄ dzÄ«vÄ ir ļoti grÅ«ti veikt konfigurÄcijas izmaiÅas, izmantojot tikai CMS kodu. AvÄrijas situÄcijas rodas, kad inženierim jÄmaina konfigurÄcija āÅ”eit un tagadā, negaidot koda rediÄ£ÄÅ”anu, testÄÅ”anu, apstiprinÄÅ”anu utt.
RezultÄtÄ manuÄlu izmaiÅu dÄļ viena veida aprÄ«kojuma konfigurÄcijÄ parÄdÄs neatbilstÄ«bas (piemÄram, sysctl iestatÄ«jumi HA klastera mezglos tiek konfigurÄti atŔķirÄ«gi). Vai arÄ« faktiskÄ aprÄ«kojuma konfigurÄcija atŔķiras no CMS kodÄ norÄdÄ«tÄs.
TÄpÄc papildus nepÄrtrauktai testÄÅ”anai mÄs pÄrbaudÄm ražoÅ”anas vidÄs konfigurÄcijas neatbilstÄ«bas. MÄs izvÄlÄjÄmies vienkÄrÅ”Äko variantu: CMS konfigurÄcijas koda palaiÅ”anu āsausÄs darbÄ«basā režīmÄ, tas ir, neveicot izmaiÅas, bet paziÅojot par visÄm neatbilstÄ«bÄm starp plÄnoto un faktisko konfigurÄciju. MÄs to ieviesÄm, periodiski palaižot visas Ansible rokasgrÄmatas ar opciju āā checkā ražoÅ”anas serveros. KÄ vienmÄr, Ansible AWX ir atbildÄ«gs par rokasgrÄmatas palaiÅ”anu un atjauninÄÅ”anu (skatiet 5. attÄlu):
RÄ«si. 5. PÄrbauda Ansible AWX konfigurÄcijas neatbilstÄ«bas.
PÄc pÄrbaudÄm AWX nosÅ«ta administratoriem neatbilstÄ«bas ziÅojumu. ViÅi izpÄta problemÄtisko konfigurÄciju un pÄc tam labo to, izmantojot pielÄgotas rokasgrÄmatas. TÄdÄ veidÄ mÄs uzturam konfigurÄciju ražoÅ”anas vidÄ, un CMS vienmÄr ir atjauninÄta un sinhronizÄta. Tas novÄrÅ” nepatÄ«kamus ābrÄ«numusā, kad CMS kods tiek izmantots āražoÅ”anasā serveros.
Tagad mums ir svarÄ«gs testÄÅ”anas slÄnis, kas sastÄv no Ansible AWX/GitLab/Molecule (6. attÄls).
Rīsi. 6. Testu vadība.
GrÅ«ti? Es nestrÄ«dos. Bet Å”Äds konfigurÄcijas pÄrvaldÄ«bas komplekss ir kļuvis par visaptveroÅ”u atbildi uz daudziem jautÄjumiem, kas saistÄ«ti ar servera konfigurÄcijas automatizÄciju. Tagad mazumtirgotÄja standarta serveriem vienmÄr ir stingri noteikta konfigurÄcija. CMS, atŔķirÄ«bÄ no inženiera, neaizmirsÄ«s pievienot nepiecieÅ”amos iestatÄ«jumus, izveidot lietotÄjus un veikt desmitiem vai simtiem nepiecieÅ”amo iestatÄ«jumu.
MÅ«sdienÄs serveru un vides iestatÄ«jumos nav āslepeno zinÄÅ”anuā. Visas nepiecieÅ”amÄs funkcijas ir atspoguļotas rokasgrÄmatÄ. Vairs nav radoÅ”uma un neskaidru norÄdÄ«jumu: āInstalÄjiet to kÄ parasto Oracle, taÄu jums ir jÄnorÄda pÄris sysctl iestatÄ«jumi un jÄpievieno lietotÄji ar nepiecieÅ”amo UID. PajautÄjiet puiÅ”iem, kas strÄdÄ, viÅi zina'.
IespÄja atklÄt konfigurÄcijas neatbilstÄ«bas un proaktÄ«vi tÄs labot nodroÅ”ina sirdsmieru. Bez konfigurÄcijas pÄrvaldÄ«bas sistÄmas tas parasti izskatÄs savÄdÄk. ProblÄmas krÄjas, lÄ«dz kÄdu dienu tÄs āizÅ”aujā ražoÅ”anÄ. PÄc tam tiek veikta apskate, konfigurÄcijas tiek pÄrbaudÄ«tas un labotas. Un cikls atkÄrtojas vÄlreiz
Un, protams, mÄs paÄtrinÄjÄm serveru palaiÅ”anu no vairÄkÄm dienÄm lÄ«dz stundÄm.
PaÅ”Ä Vecgada vakarÄ, kad bÄrni priecÄ«gi izsaiÅoja dÄvanas un pieauguÅ”ie izteica vÄlmes, zvanot, mÅ«su inženieri migrÄja SAP sistÄmu uz jauniem serveriem. Pat ZiemassvÄtku vecÄ«tis teiks, ka vislabÄkie brÄ«numi ir tie, kas ir labi sagatavoti.
PS MÅ«su komanda bieži saskaras ar faktu, ka klienti vÄlas pÄc iespÄjas vienkÄrÅ”Äk atrisinÄt konfigurÄcijas pÄrvaldÄ«bas problÄmas. IdeÄlÄ gadÄ«jumÄ kÄ uz burvju mÄjienu ā ar vienu instrumentu. Bet dzÄ«vÄ viss ir sarežģītÄk (jÄ, sudraba lodes atkal netika piegÄdÄtas): jums ir jÄizveido viss process, izmantojot klienta komandai Ärtus rÄ«kus.
Autors: Sergejs Artemovs, nodaļas arhitekts "ReaktÄ«vÄs informÄcijas sistÄmas"
Avots: www.habr.com