Aeg lähenes uue aasta saabumisele. Laste kirjad Jõuluvanale ja soovitud kingitused olid juba teele pandud, samas kui peamine teostaja — üks suuremaid jaemüüjaid — valmistus müügipüha tipphetkeks. Detsembris suureneb nende andmekeskuse koormus mitu korda. Seetõttu otsustas ettevõte andmekeskust uuendada ja käivitada mitu tosinat uut serverit, asendades seadmed, mille tööiga lõppes. Siinkohal lõpeb veidi lustlik jutt ja algab põnevusfilm.
Seadmed saabusid platvormile mitu kuud enne müügipüügi haripunkti. Tootmise teenistus teab loomulikult, kuidas ja mida serverites seadistada, et need tootmisringkonda tuua. Kuid meil oli vaja seda automatiseerida ja inimfaktori kõrvaldada. Lisaks asendasid serverid süsteemide SAP komplekti, mis on ettevõtte jaoks kriitilise tähtsusega, enne migratsiooni.
Uute serverite käivitamine oli tihedalt seotud tähtaegadega. Selle nihutamine tähendanuks miljardite kingituste tarnete ja süsteemide migreerimise ohustamist. Kuupäeva muuta ei oleks suutnud isegi Jõuluvana ja Santa Claus — SAP-i süsteemi üleviimist laohaldamiseks saab teha vaid kord aastas. 31. detsembrist 1. jaanuarini peatuvad jaostuskeskused, mille pindala kokku on 20 jalgpalliväljakut, oma tööks 15 tunniks. See on ainus ajavahemik, millal süsteemi üleviimine toimub. Meil polnud viga sisse viimiseks.
Selgitan kohe: minu jutustus kajastab tööriistu ja konfiguratsiooni haldamise protsessi, mida rakendab meie meeskond.
Konfiguratsiooni haldamise kompleks koosneb mitmest tasemest. Peamine komponent on CMS-süsteem. Tootmisutilduse käigus tooks ühe taseme puudumine paratamatult kaasa ebameeldivaid üllatusi.
Opsüsteemi installimise haldamine
Esimene tase on opsüsteemide installimise haldamise süsteem füüsilistel ja virtuaalsetel serveritel. See loob opsüsteemide baaskonfiguratsioonid, vabanedes inimfaktorist.
Selle süsteemi abil saime serverite standardiseeritud ja edasiseks automatiseerimiseks sobivaid eksemplare koos opsüsteemiga. "Valamisel" said nad minimaalse hulga kohalikke kasutajaid ja avalikke SSH võtmeid, samuti kooskõlastatud opsüsteemi konfiguratsiooni. Me saime garanteerida serverite haldamise CMS-i kaudu ja olime kindlad, et "allpool", opsüsteemi tasandil, ei ole üllatusi.
Süsteemi halduse "maximaalne" ülesanne on automaatselt seadistada serverid BIOS-i/Firmware tasemest opsüsteemini. Palju sõltub siin riistvarast ja seadistamise ülesannetest. Erineva riistvara korral on võimalik kaaluda . Kui kogu "raua" on ühe tootja oma, siis sageli on mugavam kasutada valmis haldustooted (näiteks HP ILO Amplifier, DELL OpenManage jne).
Füüsilistel serveritel operatsioonisüsteemi installimiseks kasutasime kõigile tuntud Cobblerit, kus on määratletud komplekt kokkulepitud teenindusprofiile. Uue serveri lisamisel infrastruktuuri seostas insener serveri MAC-aadressi vajalikku profiiliga Cobbleris. Esimese võrgu kaudu käivitamise korral sai server ajutise aadressi ja värske operatsioonisüsteemi. Seejärel viidi see siht-VLAN/IP-aadressile ja jätkati tööd seal. Jah, VLAN-i vahetamine võtab aega ja vajab kooskõlastust, kuid see pakub täiendavat kaitset serveri juhusliku installatsiooni eest tootmisümbruses.
Virtuaalseid servereid lõime mallide põhjal, mis olid ette valmistatud HashiCorp Packeri abil. Põhjus oli sama: et vältida võimalikke inimlikke vigu operatsioonisüsteemi installimisel. Kuid erinevalt füüsilistest serveritest võimaldab Packer mitte kasutada PXE-d, võrgu käivitamist ega VLAN-i vahetust. See lihtsustas ja hõlbustas virtuaalsete serverite loomist.
Joon. 1. Operatsioonisüsteemide installimise haldamine.
Saladuste haldamine
Iga konfiguratsioonihaldussüsteem sisaldab andmeid, mis peavad olema tava kasutajate eest peidetud, kuid on vajalikud süsteemide ettevalmistamiseks. Need on kohalike kasutajate ja teenuste konto paroolid, sertifikaatide võtmed, erinevad API tokenid jne. Neid nimetatakse tavaliselt "saladusteks."
Kui alates algusest ei määrata, kus ja kuidas neid saladusi hoida, siis sõltuvalt infosüsteemi nõuete rangusest võivad saladuste hoidmise viisid olla järgmised:
- otse konfiguratsiooni juhtimise koodis või failides, mis on hoidlas;
- spetsialiseeritud konfiguratsioonihalduse tööriistades (näiteks Ansible Vault);
- CI/CD süsteemides (Jenkins/TeamCity/GitLab jne) või konfiguratsioonihaldussüsteemides (Ansible Tower/Ansible AWX);
- samuti võivad saladusi edastada "manuaalselt". Näiteks paigutatakse need kokku lepitud kohta, mille järel neid kasutavad konfiguratsioonihaldussüsteemid;
- erinevad ülaltoodud kombinatsioonid.
Igal meetodil on oma puudused. Peamine neist on juurdepääsupoliitikate puudumine saladustele: ei ole võimalik või on raske määrata, kes võib kasutada teatud saladusi. Veel üks puudus on puuduv juurdepääsu audit ja täielik elutsükkel. Kuidas kiiresti asendada näiteks avalik võti, mis on koodis ja mitmes külg süsteemis?
Kasutasime HashiCorp Vaulti tsentraliseeritud saladuste hoidlat. See võimaldas meil:
- saladusi ohutult hoida. Need on krüpteeritud ja isegi kui keegi pääseb Vaulti andmebaasi juurde (näiteks taastades selle varukoopiast), ei saa ta seal hoitavaid saladusi lugeda;
- korraldada saladuste juurde pääsupuud. Kasutajatele ja rakendustele on juurdepääsetavad vaid neile 'moodustatud' saladused;
- teostada saladuste juurdepääsu auditi. Kõik tegevused saladustega salvestatakse Vaulti auditi päevikusse;
- organiseerida täielik 'elutsükkel' saladustega töötamiseks. Need võivad olla loodud, tühistatud, nende kehtivusaega saab määrata jne.
- lihtsalt integreeruda teiste süsteemidega, mis vajavad saladustele juurdepääsu;
- ja veel rakendada lõpp-to-lõpuga krüpteerimist, ühekordseid paroole operatsioonisüsteemidele ja andmebaasidele, volitatud sertifikaadi keskuste sertifikaate jne.
Nüüd liikumine keskse autentimis- ja autoriseerimisse süsteemi. Ilma selleta oleks olnud võimalik läbi saada, kuid kasutajate haldamine paljudes kaasnevates süsteemides on liiga keeruline. Oleme seadnud sisse autentimise ja autoriseerimise LDAP teenuse kaudu. Vastasel juhul peaks Vaultis pidevalt andma välja ja jälgima autentimisetokeneid kasutajatele. Ja kasutajate eemaldamine ja lisamine oleks muutunud „kas ma olen kõikjal selle kasutaja loonud/eemaldanud?” teekonnaks.
Lisame meie süsteemi veel ühe taseme: saladuste haldamine ja keskne autentimine/autoriseerimine:
Joon. 2. Saladuste haldamine.
Konfiguratsioonide haldamine
Oleme jõudnud südamesse — CMS süsteemi. Meie puhul on see ansamblee Ansible ja Red Hat Ansible AWX.
Ansible'i asemel võivad olla Chef, Puppet, SaltStack. Valisime Ansible'i mitmete kriteeriumide alusel.
- Esiteks, see on universaalsus. Valmis moodulite kogum haldamiseks . Ja kui see ei piisa, saab GitHubist ja Galaxy'st otsida.
- Teiseks, ei pea paigaldama ega hooldama agente hallatavates seadmetes, tõestama, et need ei sega koormust, ja kinnitama "tagaside" puudumist.
- Kolmandaks, Ansible'i õppimiskünnis on madal. Hästi haritud insener kirjutab töötava playbooki juba toote esimesel päeval.
Kuid üksi Ansible oli meie tööstuslikus keskkonnas ebapiisav. Vastasel juhul tekkiks palju probleeme juurdepääsu piirangu ja administraatorite tegevuste auditeerimisega. Kuidas juurdepääsu jagada? Iga osakond pidi haldama (loe: käivitama Ansible playbooki) "oma" serverite komplekti. Kuidas lubada konkreetsete Ansible playbookide käivitamist ainult teatud töötajatele? Kuidas jälgida, kes on playbooki käivitanud, ilma et tuleb luua palju kohalikke kasutajakontosid Ansible'i hallatavatel serveritel ja seadmetel?
Suurem osa sarnastest küsimustest lahendab Red Hat , või selle avatud allika projekti . Seetõttu valisime selle kliendi jaoks.
Veel üks detail meie CMS-süsteemi portree juurde. Ansible playbook peab olema talletatud koodirepositooriumide haldamise süsteemides. Meie puhul on see .
Nii, konfiguratsioonidega tegeleb Ansible/Ansible AWX/GitLaBi sidumine (vt joonis 3). Loomulikult on AWX/GitLab integreeritud ühtse autentimissüsteemiga, samas kui Ansible playbook on ühendatud HashiCorp Vaultiga. Konfiguratsioonid jõuavad tootmis keskkonda ainult läbi Ansible AWX-i, kus on määratletud kõik "mängureeglid": kes ja mida tohib konfigureerida, kust võtta konfigureerimise koodi CMS-i jaoks jne.
Joonis 3. Konfiguratsioonide haldamine.
Testimise haldamine
Meie konfiguratsioon on esitatud koodina. Seetõttu peame mängima samade reeglite järgi nagu tarkvaraarendajad. Meil oli vajalik korraldada arendusprotsessid, pidev testimine, konfigureerimis koodi tarnimine ja rakendamine tootmisserverites.
Kui seda kohe ei tehta, siis kirjutatud rollid konfigureerimiseks kas lakkavad töötamast ja muutmast või lõpetavad tootmises kasutamise. Sellele valule on tuntud ravim ja see on ennast selles projektis tõestanud:
- iga roll on kaetud moodulite testidega;
- testid käitatakse automaatselt iga koodi muudatuse korral, mis haldab konfiguratsioone;
- Konfiguratsioonihalduse koodimuudatused jõuavad tootmisringkonda ainult pärast kõigi testide ja koodivaatamise edukat läbimist.
Koodi arendamine ja konfiguratsioonihaldus on muutunud rahulikumaks ja ettearvatavamaks. Pideva testimise organiseerimiseks kasutasime GitLab CI/CD tööriistu ning testide korraldamiseks valisime raamistikuks .
Iga konfiguratsioonihalduse koodimuudatuse korral kutsub GitLab CI/CD esile Molecule:
- see kontrollib koodi süntaksit,
- käivitab Docker konteineri,
- rakendab muudetud koodi loodud konteineris,
- kontrollib rolli idempotentsust ja käivitab selle koodi testid (granulaarsus on siin ansible rolli tasandil, vt joonis 4).
Production-ümbrisse toimetasime konfiguratsioonid Ansible AWX abil. Eksploitatsiooni eest vastutavad insenerid kasutasid konfiguratsiooni muutmiseks eelnevalt määratletud шаблоone. AWX küsis iga rakenduse puhul automaatselt viimane versioon koodist GitLabi master-harust. Nii välistasime mittekontrollitud või aegunud koodi kasutamise production-ümbrikus. Loomulikult jõudis kood master-harusse vaid pärast testimist, ülevaatamist ja kokkulepet.
Joon. 4. Automaatne testimine rollide GitLab CI/CD-s.
On veel üks probleem, mis on seotud production-süsteemide ekspluateerimisega. Tegelikus elus on väga raske teha konfiguratsiooni muudatusi ainult CMS-i koodi kaudu. Tekkivad erakorralised olukorrad, kui insener peab konfiguratsiooni muutma "siin ja praegu", ootamata koodi redigeerimist, testimist, kooskõlastamist jne.
Käealuste muudatuste tõttu tekivad konfiguratsioonis erinevused ühte tüüpi seadmetes (näiteks HA-klastrite sõlmedes on erinev sysctl-i seadistuste konfiguratsioon). Või erineb seadme tegelik konfiguratsioon sellest, mis on määratletud CMS-i koodis.
Seetõttu kontrollime lisaks pidevale testimisele production-keskkondades konfiguratsioonide erinevusi. Valisime kõige lihtsama variandi: CMS-i konfiguratsiooni koodi käitamine 'dry run' režiimis, st muudatusi mitte rakendades, kuid teavitades kõigist erinevustest planeeritud ja tegeliku konfiguratsiooni vahel. Realiseerime seda kõigi Ansible playbookide perioodiliste käivitamiste kaudu '—check' valikuga production-serveritel. Playbooki käitamise ja ajakohasuse eest vastutab nagu alati Ansible AWX (vt joonis 5):
Joonis 5. Konfiguratsioonide erinevuste kontrollimine Ansible AWX-is.
Pärast AWX-i kontrollimist saadab see aruande erinevustest administraatoritele. Nad uurivad probleemset konfiguratsiooni ja seejärel parandavad seda kohandatud playbookide kaudu. Nii hoiame konfiguratsiooni production-keskkonnas ja CMS on alati aktuaalses ja sünkroonitud seisundis. See vabastab ebameeldivatest 'ime' olukordadest, kus CMS-i kood rakendatakse 'toodangu' serverites.
Nüüd on meil oluline testimise tase, mis koosneb Ansible AWX-ist, GitLab-ist ja Moleculest (vt joonis 6).
Joonis 6. Testimise haldamine.
Kas see on keeruline? Olen nõus. Kuid selline konfigureerimise haldamise kompleks on ammendav vastus paljudele serverite seadistamise automatiseerimisega seotud küsimustele. Nüüd on jaemüüjal tüüpilistel serveritel alati rangelt määratletud konfiguratsioon. CMS ei unusta, erinevalt insenerist, vajalikku seadistust lisada, kasutajaid luua ja teostada kümneid või sadu vajalikke seadeid.
Serverite ja keskkondade seadistustes pole täna enam „salajasi teadmisi“. Kõik vajalikud omadused on kajastatud mänguraamatus. Ei mingit loomingulist lähenemist ega uduseid juhiseid: „seadista nagu tavaline Oracle, kuid seal tuleb mõningad sysctl seaded üles märkida ja lisada kasutajad õige UID-ga. Küsi kasutusmeeskonnalt, nemad teavad.».
Võimalus tuvastada konfiguratsioonide lahknevusi ja neid ette ära parandada toob rahu. Ilma konfigureerimise haldamise süsteemita näeb see tavaliselt hoopis teistsugune välja. Probleemid kuhjuvad, kuni need ühel päeval "laskuvad" tootmisse. Siis korraldatakse tagasiside ülevaade, kontrollitakse ja parandatakse konfiguratsioone. Ja tsükkel kordub jälle.
Ja muidugi kiirusime serverite käivitamist päevi mitme tunni võrra.
Ja uue aasta ööl, kui lapsed rõõmuhõisetega avasid kingitusi ja täiskasvanud soovisid kellalöögiga soovida, migreerisid meie insenerid SAP-süsteemi uutele serveritele. Isegi Jõuluvana ütleb, et parimad imed on hästi ette valmistatud.
P.S. Meie meeskond seisab sageli silmitsi sellega, et kliendid soovivad konfiguratsioonihalduse ülesande võimalikult lihtsalt lahendada. Ideaalis nagu maagia — ühe tööriistaga. Kuid elus on kõik keerulisem (jah, jälle ei saadetud hõbedasi kuulikesi): tuleb luua terve protsess, kasutades kliendi meeskonnale mugavaid tööriistu.
Autor: Sergei Artemov, osakonna arhitekt «Infosüsteemid Jet»
Allikas: habr.com
