Po afrohej Viti i Ri. Fëmijët në të gjithë vendin i kishin dërguar letra Santa Claus-it ose kishin bërë dhurata për veten e tyre, dhe ekzekutuesi i tyre kryesor, një nga shitësit kryesorë, po përgatitej për apoteozën e shitjeve. Në dhjetor, ngarkesa në qendrën e saj të të dhënave rritet disa herë. Prandaj, kompania vendosi të modernizojë qendrën e të dhënave dhe të vërë në funksion disa dhjetëra serverë të rinj në vend të pajisjeve që po arrinin në fund të jetës së saj të shërbimit. Kjo përfundon përrallën në sfondin e flokeve të dëborës që rrotullohen dhe fillon thriller.

Pajisjet mbërritën në vend disa muaj para kulmit të shitjeve. Shërbimi i operacioneve, natyrisht, di se si dhe çfarë të konfigurojë në serverë për t'i sjellë ato në mjedisin e prodhimit. Por ne duhej ta automatizonim këtë dhe të eliminonim faktorin njerëzor. Përveç kësaj, serverët u zëvendësuan përpara migrimit të një grupi sistemesh SAP që ishin kritike për kompaninë.

Vënia në punë e serverëve të rinj ishte e lidhur rreptësisht me një afat. Dhe zhvendosja e tij nënkuptonte rrezikimin e dërgesës së një miliard dhuratave dhe migrimit të sistemeve. Edhe një ekip i përbërë nga Babai Frost dhe Santa Claus nuk mund ta ndryshonte datën - ju mund të transferoni sistemin SAP për menaxhimin e depove vetëm një herë në vit. Nga 31 dhjetori deri më 1 janar, magazinat e mëdha të shitësit me pakicë, gjithsej sa 20 fusha futbolli, ndalojnë punën për 15 orë. Dhe kjo është e vetmja periudhë kohore për lëvizjen e sistemit. Nuk kishim vend për gabime gjatë prezantimit të serverëve.

Më lejoni të jem i qartë: historia ime pasqyron mjetet dhe procesin e menaxhimit të konfigurimit që përdor ekipi ynë.

Kompleksi i menaxhimit të konfigurimit përbëhet nga disa nivele. Komponenti kryesor është sistemi CMS. Në funksionimin industrial, mungesa e njërit prej niveleve do të çonte në mënyrë të pashmangshme në mrekulli të pakëndshme.

Menaxhimi i instalimit të OS

Niveli i parë është një sistem për menaxhimin e instalimit të sistemeve operative në serverë fizikë dhe virtualë. Krijon konfigurime bazë të OS, duke eliminuar faktorin njerëzor.

Duke përdorur këtë sistem, ne morëm shembuj standardë të serverëve me OS të përshtatshëm për automatizim të mëtejshëm. Gjatë "derdhjes" ata morën një grup minimal përdoruesish lokalë dhe çelësa publikë SSH, si dhe një konfigurim të qëndrueshëm të OS. Mund të ishim të garantuar të menaxhonim serverët përmes CMS dhe ishim të sigurt se nuk kishte surpriza "poshtë" në nivelin e OS.

Detyra "maksimale" për sistemin e menaxhimit të instalimit është të konfigurojë automatikisht serverët nga niveli BIOS/Firmware në OS. Shumë këtu varet nga pajisjet dhe detyrat e konfigurimit. Për pajisje heterogjene, mund të merrni parasysh REDFISH API. Nëse i gjithë pajisja është nga një shitës, atëherë shpesh është më i përshtatshëm të përdorni mjete të gatshme të menaxhimit (për shembull, HP ILO Amplifier, DELL OpenManage, etj.).

Për të instaluar OS në serverët fizikë, ne përdorëm Cobbler-in e mirënjohur, i cili përcakton një grup profilesh instalimi të rënë dakord me shërbimin e funksionimit. Kur shtoi një server të ri në infrastrukturë, inxhinieri lidhi adresën MAC të serverit me profilin e kërkuar në Cobbler. Kur nisej përmes rrjetit për herë të parë, serveri mori një adresë të përkohshme dhe një OS të ri. Më pas u transferua në adresimin VLAN/IP të synuar dhe vazhdoi punën atje. Po, ndryshimi i VLAN kërkon kohë dhe kërkon koordinim, por siguron mbrojtje shtesë kundër instalimit aksidental të serverit në një mjedis prodhimi.

Ne krijuam serverë virtualë bazuar në shabllone të përgatitur duke përdorur HashiСorp Packer. Arsyeja ishte e njëjtë: për të parandaluar gabimet e mundshme njerëzore gjatë instalimit të sistemit operativ. Por, ndryshe nga serverët fizikë, Packer eliminon nevojën për PXE, nisjen e rrjetit dhe ndryshimet VLAN. Kjo e ka bërë më të lehtë dhe më të thjeshtë krijimin e serverëve virtualë.

Oriz. 1. Menaxhimi i instalimit të sistemeve operative.

Menaxhimi i sekreteve

Çdo sistem i menaxhimit të konfigurimit përmban të dhëna që duhet të fshihen nga përdoruesit e zakonshëm, por nevojiten për përgatitjen e sistemeve. Këto janë fjalëkalime për përdoruesit lokalë dhe llogaritë e shërbimit, çelësat e certifikatave, shenja të ndryshme API, etj. Zakonisht quhen "sekrete".

Nëse nuk përcaktoni që në fillim se ku dhe si t'i ruani këto sekrete, atëherë, në varësi të ashpërsisë së kërkesave të sigurisë së informacionit, metodat e mëposhtme të ruajtjes ka të ngjarë:

• direkt në kodin e kontrollit të konfigurimit ose në skedarë në depo;
• në mjetet e specializuara të menaxhimit të konfigurimit (për shembull, Ansible Vault);
• në sistemet CI/CD (Jenkins/TeamCity/GitLab/etj.) ose në sistemet e menaxhimit të konfigurimit (Ansible Tower/Ansible AWX);
• sekretet gjithashtu mund të transferohen "me dorë". Për shembull, ato vendosen në një vend të caktuar dhe më pas përdoren nga sistemet e menaxhimit të konfigurimit;
• kombinime të ndryshme të sa më sipër.

Çdo metodë ka disavantazhet e veta. Kryesorja është mungesa e politikave për qasje në sekrete: është e pamundur ose e vështirë të përcaktohet se kush mund të përdorë disa sekrete. Një tjetër disavantazh është mungesa e auditimit të aksesit dhe një cikël i plotë jete. Si të zëvendësoni shpejt, për shembull, një çelës publik që është shkruar në kod dhe në një numër sistemesh të lidhura?

Ne përdorëm ruajtjen sekrete të centralizuar HashiCorp Vault. Kjo na lejoi:

• ruaj sekretet. Ato janë të koduara dhe edhe nëse dikush fiton akses në bazën e të dhënave Vault (për shembull, duke e rikthyer atë nga një kopje rezervë), ata nuk do të jenë në gjendje të lexojnë sekretet e ruajtura atje;
• organizojnë politika për qasje në sekrete. Përdoruesit dhe aplikacionet janë të disponueshme vetëm sekretet e "ndara" për ta;
• qasja e auditimit në sekrete. Çdo veprim me sekrete regjistrohet në regjistrin e auditimit të Vault;
• organizoni një "cikli jetësor" të plotë të punës me sekretet. Ato mund të krijohen, të revokohen, të caktojnë një datë skadimi, etj.
• lehtë për t'u integruar me sisteme të tjera që kanë nevojë për qasje në sekrete;
• dhe gjithashtu përdorni enkriptim nga fundi në fund, fjalëkalime një herë për sistemin operativ dhe bazën e të dhënave, certifikatat e qendrave të autorizuara, etj.

Tani le të kalojmë te sistemi qendror i vërtetimit dhe autorizimit. Ishte e mundur të bëhej pa të, por administrimi i përdoruesve në shumë sisteme të lidhura është shumë jo i parëndësishëm. Ne kemi konfiguruar vërtetimin dhe autorizimin përmes shërbimit LDAP. Përndryshe, Vault do të duhet të lëshojë vazhdimisht dhe të mbajë gjurmët e argumenteve të vërtetimit për përdoruesit. Dhe fshirja dhe shtimi i përdoruesve do të shndërrohej në një kërkim "a e kam krijuar/fshirë këtë llogari përdoruesi kudo?"

Ne i shtojmë një nivel tjetër sistemit tonë: menaxhimin e sekreteve dhe vërtetimin/autorizimin qendror:

Oriz. 2. Menaxhimi i sekreteve.

Menaxhimi i konfigurimit

Ne arritëm në thelbin - sistemin CMS. Në rastin tonë, ky është një kombinim i Ansible dhe Red Hat Ansible AWX.

Në vend të Ansible, mund të përdoret Chef, Puppet, SaltStack. Ne zgjodhëm Ansible bazuar në disa kritere.

• Së pari, është shkathtësi. Një grup modulesh të gatshme për kontroll është mbresëlënëse. Dhe nëse nuk keni mjaftueshëm, mund të kërkoni në GitHub dhe Galaxy.
• Së dyti, nuk ka nevojë të instaloni dhe mbështesni agjentë në pajisjet e menaxhuara, të provoni se ato nuk ndërhyjnë në ngarkesë dhe të konfirmoni mungesën e "shënuesve".
• Së treti, Ansible ka një pengesë të ulët për hyrjen. Një inxhinier kompetent do të shkruajë një libër pune fjalë për fjalë në ditën e parë të punës me produktin.

Por vetëm Ansible në një mjedis prodhimi nuk na mjaftonte. Përndryshe, do të lindnin shumë probleme me kufizimin e aksesit dhe auditimin e veprimeve të administratorëve. Si të kufizoni aksesin? Në fund të fundit, ishte e nevojshme që çdo departament të menaxhonte (lexo: ekzekuto librin e lojërave Ansible) grupin "e vet" të serverëve. Si të lejoni vetëm disa punonjës që të ekzekutojnë libra specifikë të Ansible? Ose si të gjurmoni se kush lançoi librin e lojërave pa vendosur shumë njohuri lokale në serverët dhe pajisjet që funksionojnë Ansible?

Pjesa më e madhe e çështjeve të tilla zgjidhet nga Red Hat Kulla Ansible, ose projekti i tij në rrjedhën e sipërme me burim të hapur Ansible AWX. Kjo është arsyeja pse ne e preferuam atë për klientin.

Dhe një prekje tjetër në portretin e sistemit tonë CMS. Libri i lojës ansible duhet të ruhet në sistemet e menaxhimit të depove të kodit. ne e kemi atë GitLab CE.

Pra, vetë konfigurimet menaxhohen nga një kombinim i Ansible/Ansible AWX/GitLab (shih Fig. 3). Sigurisht, AWX/GitLab është i integruar me një sistem të vetëm vërtetimi dhe Ansible playbook është i integruar me HashiCorp Vault. Konfigurimet hyjnë në mjedisin e prodhimit vetëm përmes Ansible AWX, në të cilin specifikohen të gjitha "rregullat e lojës": kush mund të konfigurojë çfarë, ku të marrë kodin e menaxhimit të konfigurimit për CMS, etj.

Oriz. 3. Menaxhimi i konfigurimit.

Menaxhimi i testit

Konfigurimi ynë është paraqitur në formë kodi. Prandaj, ne jemi të detyruar të luajmë sipas të njëjtave rregulla si zhvilluesit e softuerit. Na duhej të organizonim proceset e zhvillimit, testimit të vazhdueshëm, dërgimit dhe aplikimit të kodit të konfigurimit në serverët e prodhimit.

Nëse kjo nuk bëhet menjëherë, atëherë rolet e shkruara për konfigurimin ose do të pushojnë së mbështeturi dhe modifikuar, ose do të pushojnë së lëshuari në prodhim. Ilaçi për këtë dhimbje është i njohur dhe e ka dëshmuar veten në këtë projekt:

• çdo rol mbulohet nga testet e njësive;
• testet ekzekutohen automatikisht sa herë që ka ndonjë ndryshim në kodin që menaxhon konfigurimet;
• ndryshimet në kodin e menaxhimit të konfigurimit lëshohen në mjedisin e prodhimit vetëm pasi të keni kaluar me sukses të gjitha testet dhe rishikimin e kodit.

Zhvillimi i kodit dhe menaxhimi i konfigurimit janë bërë më të qetë dhe më të parashikueshëm. Për të organizuar testime të vazhdueshme, ne përdorëm paketën e veglave GitLab CI/CD dhe morëm Molekula e paqëndrueshme.

Sa herë që ka një ndryshim në kodin e menaxhimit të konfigurimit, GitLab CI/CD thërret Molecule:

• kontrollon sintaksën e kodit,
• ngre kontejnerin Docker,
• aplikon kodin e modifikuar në kontejnerin e krijuar,
• kontrollon rolin për idempotencë dhe kryen teste për këtë kod (përcaktimi këtu është në nivelin e dukshëm të rolit, shih Fig. 4).

Ne dërguam konfigurime në mjedisin e prodhimit duke përdorur Ansible AWX. Inxhinierët e operacioneve aplikuan ndryshimet e konfigurimit përmes modeleve të paracaktuara. AWX në mënyrë të pavarur "kërkoi" versionin më të fundit të kodit nga dega kryesore e GitLab sa herë që përdorej. Në këtë mënyrë ne përjashtuam përdorimin e kodit të patestuar ose të vjetëruar në mjedisin e prodhimit. Natyrisht, kodi hyri në degën kryesore vetëm pas testimit, rishikimit dhe miratimit.

Oriz. 4. Testimi automatik i roleve në GitLab CI/CD.

Ekziston edhe një problem që lidhet me funksionimin e sistemeve të prodhimit. Në jetën reale, është shumë e vështirë të bësh ndryshime konfigurimi vetëm përmes kodit CMS. Situatat e urgjencës lindin kur një inxhinier duhet të ndryshojë konfigurimin "këtu dhe tani", pa pritur për modifikimin e kodit, testimin, miratimin, etj.

Si rezultat, për shkak të ndryshimeve manuale, shfaqen mospërputhje në konfigurimin në të njëjtin lloj pajisje (për shembull, cilësimet sysctl janë konfiguruar ndryshe në nyjet e grupit HA). Ose konfigurimi aktual në pajisje ndryshon nga ai i specifikuar në kodin CMS.

Prandaj, përveç testimit të vazhdueshëm, ne kontrollojmë mjediset e prodhimit për mospërputhje të konfigurimit. Ne zgjodhëm opsionin më të thjeshtë: ekzekutimin e kodit të konfigurimit CMS në modalitetin "Dry Run", domethënë pa aplikuar ndryshime, por me njoftimin e të gjitha mospërputhjeve midis konfigurimit të planifikuar dhe atij aktual. Ne e zbatuam këtë duke ekzekutuar periodikisht të gjithë librat e lojërave Ansible me opsionin "—kontrollo" në serverët e prodhimit. Si gjithmonë, Ansible AWX është përgjegjës për lëshimin dhe mbajtjen e përditësuar të librit të lojërave (shih Fig. 5):

Oriz. 5. Kontrollon për mospërputhje të konfigurimit në Ansible AWX.

Pas kontrolleve, AWX dërgon një raport mospërputhje te administratorët. Ata studiojnë konfigurimin problematik dhe më pas e rregullojnë atë përmes librave të rregulluar. Kështu e ruajmë konfigurimin në mjedisin e prodhimit dhe CMS është gjithmonë i përditësuar dhe i sinkronizuar. Kjo eliminon "mrekullitë" e pakëndshme kur kodi CMS përdoret në serverët "prodhues".

Tani kemi një shtresë të rëndësishme testimi të përbërë nga Ansible AWX/GitLab/Molecule (Figura 6).

Oriz. 6. Menaxhimi i testit.

E veshtire? Unë nuk debatoj. Por një kompleks i tillë i menaxhimit të konfigurimit është bërë një përgjigje gjithëpërfshirëse për shumë pyetje që lidhen me automatizimin e konfigurimit të serverit. Tani serverët standardë të një shitësi me pakicë kanë gjithmonë një konfigurim të përcaktuar rreptësisht. CMS, ndryshe nga një inxhinier, nuk do të harrojë të shtojë cilësimet e nevojshme, të krijojë përdorues dhe të kryejë dhjetëra ose qindra cilësime të kërkuara.

Sot nuk ka "njohuri sekrete" në cilësimet e serverëve dhe mjediseve. Të gjitha veçoritë e nevojshme pasqyrohen në librin e lojërave. Jo më kreativitet dhe udhëzime të paqarta: "Instaloni atë si Oracle i rregullt, por duhet të specifikoni disa cilësime sysctl dhe të shtoni përdorues me UID-në e kërkuar. Pyetni djemtë në operacion, ata e dinë'.

Aftësia për të zbuluar mospërputhjet e konfigurimit dhe për t'i korrigjuar ato në mënyrë proaktive siguron paqe mendore. Pa një sistem të menaxhimit të konfigurimit, kjo zakonisht duket ndryshe. Problemet akumulohen derisa një ditë "xhijnë" në prodhim. Pastaj kryhet një përmbledhje, kontrollohen dhe korrigjohen konfigurimet. Dhe cikli përsëritet përsëri

Dhe sigurisht, ne përshpejtuam nisjen e serverëve në funksion nga disa ditë në orë.

E pra, në natën e Vitit të Ri, kur fëmijët po i hapnin me gëzim dhuratat dhe të rriturit bënin urime teksa tingëllonin tingujt, inxhinierët tanë migruan sistemin SAP në serverë të rinj. Edhe Santa Claus do të thotë se mrekullitë më të mira janë ato që përgatiten mirë.

PS Ekipi ynë shpesh ndeshet me faktin që klientët duan të zgjidhin sa më thjeshtë problemet e menaxhimit të konfigurimit. Idealisht, si me magji - me një mjet. Por në jetë gjithçka është më e ndërlikuar (po, plumbat e argjendit nuk u dorëzuan përsëri): ju duhet të krijoni një proces të tërë duke përdorur mjete që janë të përshtatshme për ekipin e klientit.

Autor: Sergey Artemov, arkitekt departamenti Zgjidhjet e DevOps "Jet Infosystems"

Burimi: www.habr.com