ĂĂ«shtja po i afrohej Vitit tĂ« Ri. FĂ«mijĂ«t e tĂ« gjithĂ« vendit kishin dĂ«rguar tashmĂ« letra tek Babagjyshi i Vitit tĂ« Ri ose kishin dĂ«shiruar dhurata pĂ«r veten, ndĂ«rsa kryefiguranti 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 rritet disa herĂ«. Prandaj, kompania vendosi tĂ« modernizonte qendrĂ«n e tĂ« dhĂ«nave dhe tĂ« aktivizonte disa dhjetĂ«ra serverĂ« tĂ« rinj nĂ« vend tĂ« pajisjeve, tĂ« cilat kishin pĂ«rfunduar ciklin e jetĂ«s. KĂ«shtu, qĂ« nĂ« kĂ«tĂ« skenar tĂ« mbuluar me flakesh dĂ«bore, fillon trilleri.
Pajisjet arritën në terren disa muaj para kulmit të shitjeve. Shërbimi i funksionimit, natyrisht, e dinte se si dhe çfarë duhej të konfigurohej në serverë për t'i futur në mjedisin e prodhimit. Por na nevojitej ta automatizonim këtë dhe të përjashtonim faktorët njerëzorë. Për më tepër, serverët zëvendësuan një grup sistemesh SAP, të rëndësishme për kompaninë, para migrimit.
Ăaktivizimi i serverĂ«ve tĂ« rinj ishte i lidhur ngushtĂ« me afatin. Dhe ndryshimi i tij do tĂ« kĂ«rcĂ«nonte dĂ«rgesat e njĂ« miliard dhuratash, si dhe migrimin e sistemeve. Data nuk mund tĂ« ndryshohej as prej ekipit tĂ« Santa Claus dhe Deda Moroz â transferimi i sistemit SAP pĂ«r menaxhimin e magazinave mund tĂ« bĂ«het vetĂ«m njĂ« herĂ« nĂ« vit. Nga 31 dhjetori nĂ« 1 janar, magazinat e mĂ«dha tĂ« shitĂ«sit, tĂ« cilat pĂ«rfitojnĂ« njĂ« sipĂ«rfaqe sa 20 fusha futbolli, ndalin punĂ«n pĂ«r 15 orĂ«. Dhe ky Ă«shtĂ« intervali i vetĂ«m i kohĂ«s pĂ«r tĂ« transferuar sistemin. Ne nuk kishim asnjĂ« tĂ« drejtĂ« pĂ«r gabim nĂ« aktivizimin e serverĂ«ve.
Le të sqaroj menjëherë: tregimi im pasqyron një mjet dhe proces të menaxhimit të konfigurimeve që ekipi ynë e përdor.
Kompleksi i menaxhimit të konfigurimeve përbëhet nga disa nivele. Komponenti kyç është sistemi CMS. Në eksploatimin industrial, mungesa e njërit nga nivelet patjetër do të kishte sjellë mrekulli të padëshiruara.
Menaxhimi i instalimit të OS
Niveli i parë është sistemi i menaxhimit të instalimit të sistemeve operative në servera fizikë dhe virtualë. Ai krijon konfigurime bazë të OS, duke eliminuar faktorët njerëzorë.
Me këtë sistem ne merrnim shembuj tipikë dhe të përshtatshëm për automatizimin e mëtejshëm të serverëve me OS. Gjatë "shkarkimit", ata merrnin një grup minimal të përdoruesve lokalë dhe çelësave publikë SSH, si dhe konfigurimin e konsoliduar të OS. Ne mund të menaxhonim sigurisht serverët përmes CMS dhe ishim të sigurt se "poshtë", në nivelin e OS, nuk kishte surpriza.
Detyra "maksimale" për sistemin e menaxhimit të instalimit është që të konfigurojë automatikisht serverët nga niveli i BIOS/Firmware deri te OS. Shumë gjëra këtu varen nga pajisjet dhe detyrat e konfigurimit. Për pajisje të larmishme mund të shqyrtohet . Nëse të gjitha "hardueret" janë nga një ofrues, shpeshherë është më e lehtë të përdoren mjetet e gatshme të menaxhimit (për shembull, HP ILO Amplifier, DELL OpenManage etj.).
Për instalimin e OS në serverët fizikë, përdorim të njohurën Cobbler, ku është përcaktuar një grup profilash instalimi të miratuar me shërbimin e operacionit. Kur shtohet një server i ri në infrastrukturë, inxhinieri lidhet me adresën MAC të serverit për profilin e kërkuar në Cobbler. Gjatë ngarkesës së parë përmes rrjetit, serveri merr një adresë të përkohshme dhe një OS të freskët. Pastaj, ai transferohet në VLAN/IP adresimin përfundimtar dhe vazhdon punën aty. Po, ndërrimi i VLAN merr kohë dhe kërkon miratim, por kjo ofron mbrojtje shtesë nga instalimi aksidental i serverit në ambientin prodhues.
Serverët virtualë i krijuam mbi bazën e shablloneve të përgatitura me HashiCorp Packer. Arsyetimi ishte i njëjtë: për të parandaluar gabimet e mundshme njerëzore gjatë instalimit të OS. Por, ndryshe nga serverët fizikë, Packer lejon të mos përdorim PXE, ngarkesën në rrjet dhe ndërrimin e 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 tĂ« konfigurimeve 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, tokenat e ndryshĂ«m API dhe tĂ« tjera. NĂ« pĂ«rgjithĂ«si quhen «sekrete».
Nëse që në fillim nuk përcaktohet se ku dhe si të ruhen këto sekrete, atëherë, varësisht nga shkalla e kërkesave të sigurisë informatikë, mund të ketë këto mënyra ruajtjeje:
- drejt në kodin e menaxhimit të konfigurimeve ose në skedarët në depo;
- në mjete të specializuara për menaxhimin e 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ë transferohen në «menaxhim 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ërshkruar më sipër.
Ădo metodĂ« ka disavantazhet e veta. Kryesori Ă«shtĂ« mungesa e politikave tĂ« aksesit nĂ« sekretet: Ă«shtĂ« e pamundur ose e vĂ«shtirĂ« tĂ« pĂ«rcaktohet kush mund tĂ« pĂ«rdorĂ« sekretet e caktuara. NjĂ« tjetĂ«r disavantazh Ă«shtĂ« mungesa e auditit tĂ« aksesit dhe njĂ« cikli tĂ« plotĂ« jetĂ«sor. Si ta zĂ«vendĂ«sojmĂ« shpejt, pĂ«r shembull, çelĂ«sin publik qĂ« Ă«shtĂ« i shkruar nĂ« kod dhe nĂ« disa sisteme tĂ« tjera?
Ne përdorëm një depo të centralizuar për sekretet HashiCorp Vault. Kjo na lejon të:
- ruajmë sekretet në mënyrë të sigurt. Ato janë të enkriptuara, dhe madje nëse dikush arrin të ketë akses në bazën e të dhënave të magazinës Vault (për shembull, duke e rikuperuar atë nga një kopje rezervë), ai nuk do të jetë në gjendje të lexojë sekretet që janë ruajtur atje;
- organizohet politika e aksesit në sekrete. Përdoruesit dhe aplikacionet kanë qasje vetëm në sekretet e "dedikuara" atyre;
- bĂ«jmĂ« auditimin e aksesit nĂ« sekrete. Ădo veprim me sekretet regjistrohet nĂ« logun e auditit tĂ« Vault;
- organizohet një "cikël të plotë" funksionimi me sekretet. Ato mund të krijohen, të rikthehen, t'u caktohet një afat veprimi etj.
- lehtë të integropohet me sisteme të tjera që kanë nevojë për akses në sekrete;
- ndërsa aplikoni enkriptim end-to-end, fjalëkalime të përkohshme për OS dhe DB, certifikata nga autoritetet e autorizimit, etj.
Tani do të kalojmë në sistemin qendror të identifikimit dhe autorizimit. Mund të kishim shkuar pa të, por administrimi i përdoruesve në shumë sisteme anësore është tepër i ndërlikuar. Ne konfigurua identifikimin dhe autorizimin përmes shërbimit LDAP. Përndryshe, në të njëjtin Vault do të duhej të lëshonim vazhdimisht dhe të menaxhonim tokene autentikimi për përdoruesit. Shtimi dhe fshirja e përdoruesve do të kthehej në një aventurë "a kam krijuar/fshirë këtë identitet kudo?"
Po shtojmë një nivel tjetër në sistemin tonë: menaxhimi i sekreteve dhe identifikimi/autorizimi qendror:
Fig. 2. Menaxhimi i sekreteve.
Menaxhimi i konfigurations
ArritĂ«m nĂ« thelb â nĂ« sistemin CMS. NĂ« rastin tonĂ«, kjo Ă«shtĂ« lidhja midis Ansible dhe Red Hat Ansible AWX.
Në vend të Ansible mund të përdoret Chef, Puppet, SaltStack. Ne zgjodhëm Ansible për disa kritere.
- Së pari, kjo është shumëllojshmëria. Grupi i moduleve të gatshme për menaxhimin . Dhe nëse ndonjëherë mungon, mund të kërkohet në GitHub dhe Galaxy.
- Së dyti, nuk ka nevojë të vendosni dhe mbani agjentë në pajisjet e menaxhuara, të provoni që ata nuk e pengojnë ngarkesën dhe të konfirmoni mungesën e "backdoor-eve".
- Së treti, Ansible ka një prag të ulët hyrjeje. Një inxhinier i aftë do të shkruajë një playbook funksional në ditën e parë të punës me produktin.
Por vetëm Ansible në një mjedis industrial ishte e pamjaftueshme për ne. Në të kundërt, do të kishte shumë probleme me kufizimin e aksesit dhe auditimin e veprimeve të administratorëve. Si të kufizoni aksesin? Sepse duhej që çdo njësi të menaxhonte (lexo - të vinte në funksion playbook-un Ansible) grupin e saj të serverëve. Si të lejohet ekzekutimi i playbook-ut të caktuar Ansible vetëm për disa punonjës të caktuar? Ose si të ndjekim se kush e aktivizoi playbook-un, pa krijuar shumë llogari lokale në serverët dhe pajisjet e menaxhuara nga Ansible?
Pjesa më e madhe e këtyre pyetjeve zgjidhen nga Red Hat , ose projekti i tij open-source upstream . Prandaj ne e preferuam atë për klientin.
Dhe një tjetër detaj për portretin e sistemit tonë CMS. Playbook-u Ansible duhet të ruhet në sistemet e menaxhimit të repositorëve të kodit. Kjo e kemi ne .
Pra ndaj, konfigurimet menaxhohen nga një grup i Ansible/Ansible AWX/GitLab (shih. Figura 3). Sigurisht, AWX/GitLab janë të integruara me një sistem të vetëm të autentifikimit, ndërsa playbook-u i Ansible është i lidhur me HashiCorp Vault. Konfigurimet kalojnë në ambientin production vetëm përmes Ansible AWX, në të cilin janë përcaktuar të gjitha "rregullat e lojës": kush dhe çfarë mund të konfigurojë, nga ku mund të merret kodi për menaxhimin e konfigurimeve për CMS etj.
Figura 3. Menaxhimi i konfigurimeve.
Menaxhimi i testimit
Konfigurimi ynë paraqitet në formën e kodit. Prandaj, ne detyrohemi të luajmë sipas të njëjtave rregulla si zhvilluesit e softuerit. Na nevojitej të organizonim proceset e zhvillimit, testimit të vazhdueshëm, dorëzimit dhe aplikimit të kodit të konfigurimit në serverët production.
Nëse kjo nuk bëhet menjëherë, rolet e shkruara për konfigurimin ose do të ndalonin mbështetje dhe modifikim, ose do të ndalonin ekzekutimin në production. Ilaçi për këtë dhembje është i njohur dhe ka treguar rezultate të mira në këtë projekt:
- çdo rol është mbuluar me teste modulare;
- testet janë ekzekutuar automatikisht me çdo ndryshim në kod të menaxhimit të konfigurimeve;
- ndryshimet në kodin e menaxhimit të konfigurimeve kalojnë në ambientin production vetëm pas kalimit të suksesit në të gjitha testet dhe kontrollin e kodit.
Zhvillimi i kodit dhe menaxhimi i konfigurimeve janë bërë më të qetë dhe të parashikueshëm. Për të organizuar testimin e vazhdueshëm, ne përdorëm mjetin GitLab CI/CD, dhe si kornizë për organizimin e testeve morëm .
Kohë pas kohe, kur ndodhin ndryshime 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 idempotentësinë dhe kalon testet për këtë kod (granulariteti këtu është në nivelin e rolit ansible, shih Fig. 4).
Konfigurimet në ambientin production i dorëzuam me Ansible AWX. Inxhinierët përgjegjës për operimin aplikonin ndryshimet në konfigurim përmes shablloneve të paracaktuar. AWX në mënyrë autonome, me çdo aplikim, "kërkonte" versionin më të fundit të kodit nga dega master në GitLab. Kështu ne përjashtuam përdorimin e kodit të pa verifikuar ose të vjetruar në ambientin production. Natyrisht, kodi hynte në degën master vetëm pas testimit, shqyrtimit dhe miratimit.
Fig. 4. Testimi automatik i roleve në GitLab CI/CD.
Ka edhe një problem, i lidhur me operimin e sistemeve production. Në jetën reale, është shumë e vështirë të bëhen ndryshime në konfigurim vetëm përmes kodit CMS. Lindin situata emergjente, kur inxhinieri duhet të ndryshojë konfigurimin "këtu dhe tani", pa pritur rregullimin e kodit, testimin, miratimin etj.
Si rezultat i ndryshimeve manuale, ndodhin diferenca në konfigurim në pajisje të ngjashme (për shembull, në nyjat e HA-klasterit ka konfigurime të ndryshme të cilësimeve sysctl). Ose konfigurimi real në pajisje ndryshon nga ai, i cila është caktuar në kodin CMS.
Prandaj, pĂ«rveç testimit tĂ« vazhdueshĂ«m, ne kontrollojmĂ« ambientet e prodhimit pĂ«r ndryshime nĂ« konfiguracion. Zgjedhim variantin mĂ« tĂ« thjeshtĂ«: ekzekutimin e kodit tĂ« konfiguracionit tĂ« CMS-sĂ« nĂ« modalitetin "dry run", domethĂ«nĂ« pa zbatuar ndryshimet, por me njoftimin mbi tĂ« gjitha ndryshimet ndĂ«rmjet konfiguracionit tĂ« planifikuar dhe atij aktual. Ne realizuam kĂ«tĂ« me ndihmĂ«n e ekzekutimeve periodike tĂ« tĂ« gjitha playbook-eve tĂ« Ansible me opsionin "âcheck" nĂ« serverat e prodhimit. PĂ«r ekzekutimin dhe saktĂ«sinĂ« e playbook-eve, si gjithmonĂ«, Ă«shtĂ« pĂ«rgjegjĂ«s Ansible AWX (shihni Fig. 5):
Fig. 5. Kontrollimi i ndryshimeve në konfiguracion në Ansible AWX.
Pas kontrolleve, AWX dërgon një raport mbi ndryshimet administratorëve. Ata shqyrtojnë konfiguracionin problematik dhe më pas e korrektojnë atë përmes playbook-eve të rregulluara. Kështu, ne mbajmë konfiguracionin në ambientin e prodhimit dhe CMS është gjithmonë në gjendje aktuale dhe të sinkronizuar. Kjo na shpëton nga "mrekulli" të pakëndshme kur kodi i CMS zbatohet në serverat e "luftës".
Tani kemi ndërtuar një nivel të rëndësishëm testimi, që përfshin Ansible AWX/GitLab/Molecule (Fig. 6).
Fig. 6. Menaxhimi i testimit.
E komplikuar? Nuk e diskutoj. Por, ky kompleks menaxhimi i konfigurimeve është përgjigjja e plotë ndaj shumë pyetjeve që lidhen me automatizimin e konfigurimit të serverëve. Tani, shitësi ka gjithmonë një konfigurim të qartë të përcaktuar për serverët standard. CMS, ndryshe nga inxhinieri, nuk do të harrojë të shtojë cilësimet e nevojshme, të krijojë përdoruesit dhe të plotësojë dhjetëra ose qindra cilësime të kërkuara.
Në cilësimet e serverëve dhe ambienteve sot nuk ka «dije të fshehta». Të gjitha tipar e nevojshme janë të pasqyruara në playbook. Asnjë kreativitet dhe instrukcionesh të paqarta më: «vendos si Oracle normal, por aty nevojiten disa cilësime sysctl të shkruhen, dhe të shtohen përdorues me UID të nevojshëm. Pyet djemtë nga operacioni, ata e dinë».
AftĂ«sia pĂ«r tĂ« zbuluar diferencat nĂ« konfigurime dhe pĂ«r tâi korrigjuar ato paraprakisht jep qetĂ«si. Pa njĂ« sistem menaxhimi tĂ« konfigurimeve, zakonisht duket ndryshe. Problemet grumbullohen deri nĂ« momentin kur njĂ« ditĂ« «shpĂ«rthejnë» nĂ« production. Pastaj bĂ«het njĂ« analizĂ«, kontrollohen dhe rregullohen konfigurimet. Dhe cikli pĂ«rsĂ«ritet pĂ«rsĂ«ri.
Natyrisht, ne e shpejtuam aktivizimin e serverëve nga disa ditë në disa orë.
Në natën e vetme të vitit të ri, 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ë migruan sistemin SAP në servera të rinj. Edhe Baba Frost do të thoshte se mrekullitë më të mira janë ato që janë mirë përgatitur.
P.S. Ekipi ynĂ« shpesh pĂ«rballet me kĂ«rkesa nga klientĂ«t pĂ«r tĂ« zgjidhur sa mĂ« thjeshtĂ« detyrat e menaxhimit tĂ« konfigurimeve. Idealisht, ashtu si pĂ«r magji â me njĂ« mjet tĂ« vetĂ«m. Por nĂ« jetĂ«, gjithçka Ă«shtĂ« mĂ« e komplikuar (po, pĂ«rsĂ«ri nuk u sollĂ«n plumbat e argjendit): duhet tĂ« krijojmĂ« njĂ« proces tĂ«rĂ«sor me mjete tĂ« pĂ«rshtatshme pĂ«r ekipin e klientit.
Autori: Sergey Artemov, arkitekt i departamentit «Infosesystemet Jet»
Burimi: habr.com
