Ngjarja po afrohej drejt Vitit tĂ« Ri. FĂ«mijĂ«t e tĂ« gjithĂ« vendit kishin dĂ«rguar letra te Babagjyshi i Dimrit ose kishin kĂ«rkuar dhurata pĂ«r veten, ndĂ«rsa ekzekutuesi kryesor i tyre â njĂ« nga shitĂ«sit e mĂ«dhenj â po pĂ«rgatitej pĂ«r kulmin e shitjeve. NĂ« dhjetor, ngarkesa nĂ« qendrĂ«n e tĂ« dhĂ«nave tĂ« tij rritej disa herĂ«. Prandaj, kompania vendosi tĂ« modernizojĂ« qendrĂ«n e tĂ« dhĂ«nave dhe tĂ« vendosĂ« nĂ« punĂ« disa dhjetĂ«ra serverĂ« tĂ« rinj nĂ« vend tĂ« pajisjeve, periudha e shĂ«rbimit tĂ« tĂ« cilave kishte pĂ«rfunduar. KĂ«shtu pĂ«rfundon pĂ«rralla nĂ« sfondin e flakesave tĂ« borĂ«s dhe fillon thrilleri.
Pajisjet arritën në vend disa muaj para kulmit të shitjeve. Shërbimi i operacioneve, natyrisht, di si dhe çfarë të konfigurojë në serverë për t'i futur ato në mjedisin e prodhimit. Por na duhej ta automatizonim këtë dhe të përjashtonim faktorin njeri. Për më tepër, serverët zëvendësonin një grup sistemesh SAP, të cilat ishin kritikë për kompaninë, para migrimit.
Futja nĂ« funksionim e serverĂ«ve tĂ« rinj ishte e lidhur ngushtĂ«sisht me afatin e fundit. Shtyrja e tij do tĂ« thoshte tĂ« rrezikohej dĂ«rgimi i njĂ« miliard dhuratash dhe migrimi i sistemeve. AsnjĂ« ekip, madje as ai i Babagjyshit tĂ« Dimrit, nuk do tĂ« mund tĂ« ndryshonte datĂ«n â migrimi i sistemit SAP pĂ«r menaxhimin e magazinĂ«s mund tĂ« bĂ«het vetĂ«m njĂ« herĂ« nĂ« vit. Nga 31 dhjetori deri mĂ« 1 janar, magazinat e mĂ«dha tĂ« shitĂ«sit, qĂ« pĂ«rfshijnĂ« si 20 fusha futbolli, ndalojnĂ« punĂ«n pĂ«r 15 orĂ«. Dhe ky Ă«shtĂ« vetĂ«m intervali i vetĂ«m i kohĂ«s pĂ«r migrimin e sistemit. Nuk kishim tĂ« drejtĂ« pĂ«r gabime nĂ« futjen e serverĂ«ve.
Të sqaroj menjëherë: tregimi im pasqyron mjete dhe procese menaxhimi të konfigurimeve që ekipi ynë aplikon.
Kombinimi i menaxhimit të konfigurimeve përbëhet nga disa nivele. Komponenti kyç është sistemi CMS. Në eksploitimin industrial, mungesa e njërit prej niveleve do të çonte patjetër në mrekulli të pakëndshme.
Menaxhimi i instalimit të OS
Niveli i parĂ« â Ă«shtĂ« sistemi pĂ«r menaxhimin e instalimit tĂ« sistemeve operative nĂ« serverĂ« fizikĂ« dhe virtualĂ«. Ai krijon konfigurimet themelore tĂ« OS-sĂ«, duke e çliruar nga faktori njeri.
Me këtë sistem, ne fitonim tipe dhe ekzemplarë të përshtatshëm për automatizim të mëtejshëm të serverëve me OS. Gjatë 'derdhjes', ata merrnin një grup minimal të përdoruesve lokalë dhe çelësa publikë SSH, si dhe një konfiguracion të koordinuar të OS. Ne mundeshim të menaxhonim me siguri serverët përmes CMS dhe ishim të sigurt se 'në fund', në nivelin e OS, nuk kishte surpriza.
Detyra 'maksimale' për sistemin e menaxhimit të instalimit është të konfigurojë automatikisht serverët nga niveli BIOS/Firmware deri te OS. Shumë varet këtu nga pajisjet dhe detyrat e konfigurimit. Për pajisje të ndryshme, mund të shqyrtohet . Nëse të gjithë 'hekurat' janë nga një shitës, atëherë shpesh është më e lehtë të përdoren mjetet e menaxhimit të gatshme (p.sh., HP ILO Amplifier, DELL OpenManage etj.).
Për instalimin e OS në serverët fizikë, ne përdorëm Cobbler, që është e njohur për të gjithë, në të cilin është përkufizuar një grup profilash instalimi të koordinuar me shërbimin e operacioneve. Kur një server i ri shtohej në infrastrukturë, inxhinieri lidhte adresën MAC të serverit me profilin e nevojshëm në Cobbler. Në ngarkimin e parë në rrjet, serveri merrte një adresë përkohshme dhe një OS të re. Pastaj e transferonin në VLAN/enë e synuar/IP-adresimin dhe vazhdonin punën aty. Po, ndërrimi i VLAN merr kohë dhe kërkon koordinim, por ofron mbrojtje shtesë nga instalimi aksidental të serverit në ambientin e prodhimit.
Serverët virtualë i krijonim mbi bazën e shablloneve të përgatitura me HashiCorp Packer. Arsyeja ishte e njëjtë: për të parandaluar gabimet e mundshme njerëzore gjatë instalimit të OS. Por, ndryshe nga serverët fizikë, Packer lejon mos përdorimin e PXE, ngarkimit në rrjet dhe ndërrimit të VLAN. Kjo e lehtësoi dhe thjeshtoi krijimin e serverëve virtualë.
Fig. 1. Menaxhimi i instalimit të sistemeve operative.
Menaxhimi i sekreteve
Ădo sistem menaxhimi i konfigĆ«rimeve pĂ«rmban tĂ« dhĂ«na qĂ« duhet tĂ« jenĂ« tĂ« fshehura nga pĂ«rdoruesit e zakonshĂ«m, por janĂ« tĂ« nevojshme pĂ«r pĂ«rgatitjen e sistemeve. KĂ«to janĂ« fjalĂ«kalimet e pĂ«rdoruesve lokalĂ« dhe llogarive shĂ«rbyese, çelĂ«sat e certifikatave, API Tokens tĂ« ndryshĂ«m etj. Zakonisht quhen 'sekrete'.
Nëse nga fillimi nuk përcaktohet se ku dhe si të ruhet këto sekrete, atëherë, në varësi të kërkesave të rrepta të sigurisë së informacionit, mund të ndodhin këto mënyra ruajtjeje:
- direkt në kodin e menaxhimit të konfiguracionit ose në skedarët në repositorin;
- në mjetet e specializuara të menaxhimit të konfigurimeve (p.sh., Ansible Vault);
- në sistemet CI/CD (Jenkins/TeamCity/GitLab/etj.) ose në sistemet e menaxhimit të konfigurimeve (Ansible Tower/Ansible AWX);
- po ashtu sekretet mund të transmetohen përmes "menaxhimit manual". Për shembull, vendosen në një vend të caktuar dhe pastaj përdoren nga sistemet e menaxhimit të konfigurimeve;
- kombinime të ndryshme të përshkruara më sipër.
Ădo metodĂ« ka disavantazhet e saj. Disavantazhi kryesor Ă«shtĂ« mungesa e politikave tĂ« qasjes pĂ«r sekretet: Ă«shtĂ« e pamundur ose e vĂ«shtirĂ« tĂ« pĂ«rcaktohet kush mund tĂ« pĂ«rdorĂ« kĂ«to sekrete. NjĂ« tjetĂ«r minus Ă«shtĂ« mungesa e auditi tĂ« qasjes dhe njĂ« cikli tĂ« plotĂ« tĂ« jetĂ«s. Si mund tĂ« zĂ«vendĂ«sohet shpejt njĂ« çelĂ«s publik qĂ« Ă«shtĂ« shkruar nĂ« kod dhe nĂ« rrethin e sistemit tĂ« lidhur?
Ne përdorëm një depo të centralizuar për sekretet HashiCorp Vault. Kjo na lejoi:
- të ruajmë sekretet në siguri. Ato janë të kriptuara, dhe edhe nëse dikush fiton qasje në bazën e të dhënave të depozitës Vault (p.sh., duke e rikuperuar atë nga një kopje rezervë), nuk do të jetë në gjendje të lexojë sekretet që janë ruajtur aty;
- të organizojmë politikat e qasjes për sekretet. Përdoruesit dhe aplikacionet kanë qasje vetëm në sekretet "e dedikuara" për ta;
- tĂ« kryejmĂ« auditimin e qasjes pĂ«r sekretet. Ădo veprim mbi sekretet regjistrohet nĂ« regjistrin e auditit tĂ« Vault;
- të organizojmë një "cikël të plotë" të punës me sekretet. Ato mund të krijohen, revokohen, t'u caktohet një afat dhe etj.
- të integrohemi lehtë me sistemet e tjera që kanë nevojë për qasje në sekretet;
- dhe gjithashtu të aplikojmë enkriptim end-to-end, fjalëkalime të njëhershme për OS dhe DB, certifikata nga organet e autorizuara etj.
Tani kalojmë te sistemi qendror i autentifikimit dhe autorizimit. Mund të kalohej pa të, por administrimi i përdoruesve në një numër të madh sistemesh shoqërues është shumë i komplikuar. Ne konfigurour autentifikimin dhe autorizimin përmes shërbimit LDAP. Nëse jo, në të njëjtin Vault do të duhej të lëshoheshin vazhdimisht dhe të mbaheshin regjistrat e tokeneve të autentifikimit për përdoruesit. Dhe shtimi dhe heqja e përdoruesve do të bëhej një quest "a e kam krijuar/hequr këtë ID në të gjitha vendet?"
Shtojmë një nivel tjetër në sistemin tonë: menaxhimin e sekretet dhe autentikimin/autoritetin qendror;
Fig. 2. Menaxhimi i sekretet.
Menaxhimi i konfigureve
ArritĂ«m nĂ« zemĂ«r â nĂ« sistemin CMS. NĂ« rastin tonĂ«, kjo Ă«shtĂ« lidhja Ansible dhe Red Hat Ansible AWX.
Mund të përdoren edhe Chef, Puppet, SaltStack në vend të Ansible. Ne zgjodhëm Ansible për disa kritere.
- Së pari, është universaliteti. Grupi i moduleve të gatshme për menaxhim . Nëse ndonjëherë mungon, mund të kërkoni në GitHub dhe Galaxy.
- Së dyti, nuk është e nevojshme të instaloni dhe mbani agjentë në pajisjet e menaxhuara, të provoni që ata nuk pengojnë ngarkesën dhe të konfirmoni mungesën e 'çerdheve'.
- Së treti, Ansible ka një prag të ulët hyrjeje. Një inxhinier i aftë do të shkruajë një playbook funksional pothuajse në ditën e parë të punës me produktin.
Por Ansible vetĂ«m nĂ« njĂ« ambient industrial nuk ishte e mjaftueshme. PĂ«rndryshe do tĂ« kishte shumĂ« probleme me kufizimin e aksesit dhe auditimin e veprimeve tĂ« administratorĂ«ve. Si tĂ« kufizojmĂ« aksesin? Sepse ishte e nevojshme qĂ« secila njĂ«si tĂ« menaxhonte (lexo â tĂ« ekzekutonte Ansible playbook) grupin e saj tĂ« serverĂ«ve. Si mund tĂ« lejohet ekzekutimi i njĂ« Ansible playbook specifik vetĂ«m pĂ«r disa punonjĂ«s? Ose si mund tĂ« kontrollohet kush e ekzekutoi playbook-un, pa krijuar shumĂ« UZ lokale nĂ« serverat dhe pajisjet e menaxhuara nga Ansible?
Shumicën e pyetjeve të ngjashme e zgjidh Red Hat , ose projekti i tij open-source upstream . Prandaj, ne e preferuam atë për klientin.
Dhe një detaj tjetër për portretin e sistemit tonë CMS. Ansible playbook duhet të ruhet në sistemet e menaxhimit të repository-t të kodit. Në rastin tonë, kjo është .
Pra, vetë konfigurat e menaxhuara përbëjnë një lidhje nga Ansible/Ansible AWX/GitLab (shih. Figurën 3). Sigurisht, AWX/GitLab janë të integruar me një sistem të vetëm autentikimi, ndërsa Ansible playbook është i lidhur me HashiCorp Vault. Konfigurat kalojnë në ambientin e prodhimit vetëm përmes Ansible AWX, në të cilin janë të vendosura të gjitha 'rregullat e lojës': kush dhe çfarë mund të konfigurojë, nga ku të merret kodi për menaxhimin e konfigureve për CMS, etj.
Figura 3. Menaxhimi i konfigureve.
Menaxhimi i testimit
Konfigurat tona paraqiten si kod. Prandaj, ne duhet të luajmë sipas të njëjtave rregulla si zhvilluesit e softuerit. Na nevojitej të organizonim proceset e zhvillimit, testimit të vazhdueshëm, shpërndarjes dhe aplikimit të kodit të konfigureve në serverët e prodhimit.
Nëse kjo nuk bëhet menjëherë, atëherë rolet e shkruara për konfigurimin do të ndalojnë të mbështetet dhe të ndryshojnë, ose do të ndalen së ekzekutimi në production. Mjekimi për këtë dhimbje është i njohur dhe ka funksionuar mirë në këtë projekt:
- çdo rol mbulohet me teste modulare;
- testet ekzekutohen automatikisht me çdo ndryshim në kodin që menaxhon konfigurimet;
- ndryshimet në kodin e menaxhimit të konfigurimeve hyjnë në ambientin production vetëm pas kalimit me sukses të të gjitha testeve dhe shqyrtimit të kodit.
Zhvillimi i kodit dhe menaxhimi i konfigurimeve janë bërë më të qetë dhe parashikues. Për të organizuar testimin e vazhdueshëm, ne përdorëm mjetet GitLab CI/CD, dhe si kornizë për organizimin e testeve morëm .
Me çdo ndryshim në kodin e menaxhimit të konfigurimeve, GitLab CI/CD thërret Molecule:
- ajo kontrollon sintaksën e kodit,
- ngre një kontejner Docker,
- aplikon kodin e ndryshuar në kontejnerin e krijuar,
- kontrollon rolin për idempotencë dhe ekzekuton testet për këtë kod (granariteti këtu është në nivelin e robit ansible, shih. Fig. 4).
Konfigurimet nĂ« ambientin production i shpĂ«rndanim me ndihmĂ«n e Ansible AWX. InxhinierĂ«t e pĂ«rgjegjshĂ«m pĂ«r operimin aplikonin ndryshimet nĂ« konfigurim pĂ«rmes ŃĐ°Đ±Đ»ĐŸĐœĂ«ve tĂ« parapĂ«rcaktuar. AWX automatikisht, nĂ« çdo aplikim, 'kĂ«rkonte' versionin mĂ« tĂ« fundit tĂ« kodit nga dega master e GitLab. KĂ«shtu ne pĂ«rjashtuam pĂ«rdorimin e kodit tĂ« pa verifikuar ose tĂ« vjetruar nĂ« ambientin production. Natyrisht, kodi nĂ« degĂ«n master hynte vetĂ«m pas testimit, shqyrtimit dhe miratimit.
Fig. 4. Testimi automatik i roleve në GitLab CI/CD.
Ka ende një problem që lidhet me operimin e sistemeve production. Në jetën reale është shumë e vështirë të bësh ndryshime në konfigurim vetëm përmes kodit CMS. Paraqiten situata emergjente, kur inxhinieri duhet të ndryshojë konfigurimin 'këtu dhe tani', pa pritur rregullimin e kodit, testimin, miratimin etj.
Si rezultat, për shkak të ndryshimeve manuale, krijohen dallime në konfigurim në pajisje të ngjashme (për shembull, në njësitë e HA-clusterit ka konfigurim të ndryshëm të cilësimeve sysctl). Ose konfigurimi real në pajisje ndryshon nga ai që është caktuar në kodin CMS.
Prandaj, nĂ« pĂ«rputhje me testimin e vazhdueshĂ«m, ne kontrollojmĂ« mjediset e prodhimit pĂ«r nuk ndodhin ndryshime nĂ« konfigurim. ZgjodhĂ«m variantin mĂ« tĂ« thjeshtĂ«: ekzekutimi i kodit tĂ« konfigurimit tĂ« CMS nĂ« modalitetin "dry run", domethĂ«nĂ« pa aplikuar ndryshimet, por me njoftimin pĂ«r tĂ« gjitha prishjet midis konfigurimit tĂ« planifikuar dhe atijàžàžŁàžŽàž. E kemi realizuar kĂ«tĂ« pĂ«rmes ekzekutimeve periodike tĂ« tĂ« gjitha Ansible playbook me opsionin "âcheck" nĂ« serverat e prodhimit. PĂ«r ecjen dhe aktualitetin e playbook, si gjithmonĂ«, Ă«shtĂ« pĂ«rgjegjĂ«s Ansible AWX (shihni Fig. 5):
Fig. 5. Kontrolli i prishjeve të konfigurimeve në Ansible AWX.
Pas kontrolleve, AWX dërgon një raport mbi prishjet administratorëve. Ata shqyrtojnë konfigurimin problematik dhe më pas e korrigjojnë atë përmes playbook të korrigjuara. Kështu ne mbajmë konfigurimin në mjedisin e prodhimit dhe CMS gjithmonë ndodhet në një gjendje të përditësuar dhe të sinkronizuar. Kjo na shpëton nga "mrekullitë" e pakëndshme, kur kodi i CMS aplikohet në serverat "live".
Tani kemi një nivel të rëndësishëm testimi, që përbëhet nga Ansible AWX/GitLab/Molecule (Fig. 6).
Fig. 6. Menaxhimi i testimit.
E vështirë? Nuk e kundërshtoj. Por ky kompleks i menaxhimit të konfigurimeve u bë një përgjigje e plotë ndaj shumë pyetjeve që lidhen me automatizimin e shtrimit të serverave. Tani, pikat e shitjes kanë gjithmonë një konfigurim të përcaktuar me saktësi për serverat standard. CMS, ndryshe nga inxhinieri, nuk do të harrojë të shtojë cilësitë e nevojshme, të krijojë përdoruesit dhe të ekzekutojë dhjetëra ose qindra cilësira të kërkuara.
Në konfigurimet e serverëve dhe mjediseve sot nuk ka "njohuri të fshehta". Të gjitha karakteristikat e nevojshme janë pasqyruar në playbook. Asnjë kreativitet dhe instrukcione të paqarta më: "shkruaj si një Oracle të zakonshëm, por atje nevojiten disa configurime sysctl, dhe përdoruesit me UID të nevojshëm duhet të shtohen. Pyesni djemtë nga operacionet, ata e dinë.».
Kapaciteti për të zbuluar prishjet e konfigurimeve dhe për t'i korrigjuar ato paraprakisht ofron qetësi. Pa një sistem menaxhimi të konfigurimeve, kjo zakonisht duket ndryshe. Problemet grumbullohen derisa një ditë të "shkrepin" në prodhim. Pastaj bëhet një analizë, verifikohen dhe rregullohen konfigurimet. Dhe cikli përsëritet sërish.
Dhe sigurisht, ne e shpejtësuam vendosjen e serverëve në funksion nga disa ditë në orë.
E pra festa e natale, kur fëmijët me gëzim hapnin dhuratat dhe të rriturit bënin dëshira nën zhurmën e orës, inxhinierët tanë migronin sistemin SAP në servera të rinj. Edhe Babagjyshi i Krismas do të thoshte se mrekullitë më të bukura janë ato që janë përgatitur mirë.
P.S. Ekipi ynĂ« shpesh pĂ«rballet me faktin qĂ« klientĂ«t duan tĂ« zgjidhin detyrat e menaxhimit tĂ« konfigurimeve sa mĂ« thjesht tĂ« jetĂ« e mundur. Idealisht, ashtu si me magji â me njĂ« mjet tĂ« vetĂ«m. Por nĂ« jetĂ«, gjĂ«rat janĂ« mĂ« tĂ« ndĂ«rlikuara (po, pĂ«rsĂ«ri nuk erdhĂ«n plumbat e argjendit): Ă«shtĂ« e nevojshme tĂ« krijohet njĂ« proces i tĂ«rĂ« me ndihmĂ«n e mjeteve tĂ« pĂ«rshtatshme pĂ«r ekipin e klientit.
Autori: Sergei Artemov, arkitekt i departamentit «Infositteme Jet»
Burimi: habr.com
