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
