Aasta lõpp lähenes. Kõik laste kirjad Jõuluvanal on juba välja saadetud ning nende peamine tegija – üks suuremaid jaekette – valmistub müügimeistriteoseks. Detsembris kasvab koormus tema andmekeskuses mitmekordseks. Seetõttu otsustas ettevõte andmekeskust moderniseerida ja käivitada mitu tosinat uusi servereid vana seadme asemel, mille eluaeg lõppes. Sellega lõpeb meie jõululoo eelloog ja algab thriller.
Seadmed saabusid platsile mitu kuud enne müügihuippu. Loomulikult teab hooldusteenistus, kuidas ja mida serverites seadistada, et need produktsioonikeskkonda viia. Kuid meil oli vaja see protsess automatiseerida ja välistada inimfaktor. Lisaks asendasid serverid enne migratsiooni SAP-süsteemide kogumit, mis on ettevõtte jaoks kriitilise tähtsusega.
Uute serverite tööle rakendamine oli kindlalt seotud tähtajaga. Selle edasilükkamine tähendaks miljardite kingituste kohaletoimetamise ja süsteemide migratsiooni ohustamist. Kuigi Jõuluvana ja Santa Klause meeskond ei suudaks kuupäeva muuta – SAP-süsteemi, mis haldab laosüsteemi, saadakse ümber võtta vaid kord aastas. 31. detsembril kuni 1. jaanuarini peatub jaeketi tohutu ladu, mille kogu pindala on võrreldav 20 jalgpalliväljaku kogupindalaga, 15 tunniks. Ja see on ainus ajavahemik süsteemi kolimiseks. Meil ei olnud lubatud vigu serverite käivitamisel.
Selgitan kohe: minu jutt kajastab sellist tööriistade ja konfiguratsioonihalduse protsessi, mida kasutab meie meeskond.
Konfiguratsioonihalduse süsteem koosneb mitmest tasemest. Võtmeelement on CMS-süsteem. Tootmisprotsessi käigus tooks ühe taseme puudumine paratamatult kaasa ebameeldivaid olukordi.
Opsüsteemi installimise haldamine
Esimene tase on opsüsteemide installimise haldamise süsteem füüsilistes ja virtuaalsetes serverites. See loob opsüsteemidele põhikonfiguratsioonid, välistades inimfaktori.
Selle süsteemi abil saime genereerida standardseid ja edasiste automatiseerimist võimaldavaid serverite näidiseid koos operatsioonisüsteemiga. "Valamisel" said nad minimaalset kohalikku kasutajate komplekti ja avalikke SSH võtmeid, samuti kooskõlastatud OS konfigureerimise. Me saime usaldusväärselt hallata servereid CMS-i kaudu ja olime kindlad, et "allpool", operatsioonisüsteemi tasandil, ei ole üllatusi.
Süsteemi haldamise suurim eesmärk on automaatselt konfigureerida servereid BIOSi/Vormiriistvara tasemest operatsioonisüsteemini. Palju sõltub siinkohal riistvarast ja konfigureerimise ülesannetest. Heterogeense riistvara puhul võiks kaaluda . Kui kogu "raha" tuleb ühelt tarnijalt, on sageli mugavam kasutada valmis haldustooted (näiteks HP ILO Amplifier, DELL OpenManage jne).
Füüsiliste serverite operatsioonisüsteemi installimiseks kasutasime kõigile tuntud Cobblerit, milles on määratud kooskõlastatud installiprofiilide komplekt. Uue serveri lisamisel infrastruktuuri seostas insener serveri MAC-aadressi nõutud profiiliga Cobbleris. Esmase võrgulaadimise ajal sai server ajutise aadressi ja uuema operatsioonisüsteemi. Seejärel viidi see soovitud VLAN/iP-aadresside juurde ja töö jätkus seal. Jah, VLANi vahetamine võtab aega ja vajab kooskõlastamist, kuid see annab lisakaitse võimaliku serveri juhusliku installatsiooni eest tootmisringkonnas.
Virtuaalsed serverid loodi Mallide põhjal, mis olid ette valmistatud HashiCorp Packeri abil. Põhjuseks oli sama: et vältida võimalikke inimvigu operatsioonisüsteemi installimisel. Kuid erinevalt füüsilistest serveritest võimaldab Packer mitte kasutada PXE-d, võrgu käivitamist ja VLAN-i vahetamist. See lihtsustas ja hõlbustas virtuaalsete serverite loomist.
Joonis 1. Operatsioonisüsteemide installimise haldamine.
Saladuste haldamine
Iga konfigureerimisse süsteem sisaldab andmeid, mis peavad olema tavaliste kasutajate eest peidetud, kuid vajalikud süsteemide ettevalmistamiseks. Need on kohalikud kasutajate paroolid ja teenusekontode kontod, sertifikaatide võtmed, erinevad API Tokenid jne. Neid nimetatakse tavaliselt "saladusteks".
Kui alguses ei määrata, kus ja kuidas neid saladusi hoida, siis sõltuvalt infoturbe nõuete karmusest võivad olla sellised hoidmisviisid:
- otse otse konfiguratsiooni halduse koodis või hoidlatest.
- spetsialiseeritud konfiguratsioonihaldustöö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 'käsitsi'. Näiteks paigutatakse need kokku lepitud kohta ja seejärel kasutatakse neid konfiguratsioonihaldussüsteemide poolt;
- erinevad kombinatsioonid eelöeldust.
Igal meetodil on oma puudused. Peamine neist on juurdepääsupoliitikate puudumine saladustele: on raske või võimatu määrata, kes võib kasutada neid või teisi saladusi. Veel üks miinus on juurdepääsu auditi ning täisväärtusliku elutsükli puudumine. Kui kiiresti asendada näiteks avalik võti, mis on kodeeritud ja mitmes külgpoolses süsteemis?
Kasutasime keskset saladuste hoidlat HashiCorp Vault. See võimaldas meil:
- saladusi ohutult hoida. Need on krüpteeritud ja isegi kui keegi pääseb juurde Vaulti andmebaasile (näiteks taastades selle varukoopiast), ei suuda nad seal hoitavaid saladusi lugeda;
- korraldada juurdepääsupoliitikaid saladustele. Kasutajad ja rakendused saavad ligi ainult neile 'määratud' saladustele;
- teostada saladustele juurdepääsu auditeerimist. Kõik saladustega seonduvad toimingud registreeritakse Vaulti auditi logisse;
- organiseerida täisväärtuslik 'elutsükkel' saladustega. Neid saab luua, tühistada, seadistada kehtivusaega jne.
- lihtsalt integreeruda teiste süsteemidega, kellel on vajadus saladustele juurdepääsu järele;
- ja rakendada lõpp-punktide krüpteerimist, ühekordseid paroole operatsioonisüsteemidele ja andmebaasidele, volitatud keskuste sertifikaate jne.
Nüüd liigume üle kesksele autentimise ja autoriseerimise süsteemile. Saime ilma selleta hakkama, kuid kasutajate haldamine paljuski kaasnevates süsteemides oleks liiga keeruline. Seadisime autentimise ja autoriseerimise LDAP teenuse kaudu. Muul juhul oleks Vaultis pidanud pidevalt laevandama ja jälgima autentimistokenite väljaandmist kasutajatele. Ja kasutajate eemaldamine ja lisamine oleks muutunud missiooniks 'kas ma olen igal pool selle kasutaja loonud/ eemaldanud?'
Lisame süsteemi veel ühe taseme: saladuste haldamine ja keskne autentimine/autoriseerimine:
Joon. 2. Saladuste haldamine.
Konfiguratsioonide haldamine
Me jõudsime tuumani — CMS-süsteemi. Meie puhul on see kombinatsioon Ansible'ist ja Red Hat Ansible AWX-st.
Ansible'i asemel võib kasutada Chef'i, Puppet'it, SaltStack'i. Me valisime Ansible'i mitmete kriteeriumide tõttu.
- Esiteks, see on universaalne. Valmis moodulite komplekt haldamiseks . Ja kui seda on puudu, võib otsida GitHub'ist ja Galaxy'st.
- Teiseks, ei ole vaja installida ja hallata agente haldataval seadmel, tõestada, et nad ei sega koormust, ja kinnitada «tagasiteed» puudumist.
- Kolmandaks, Ansible'il on madal sisenemise piir. Kogenud insener kirjutab töötava playbook'i literally esimesel päeval toote kasutamisel.
Aga ainult Ansible ei piisanud meile tööstuskeskkonnas. Vastasel juhul tekiks palju probleeme juurdepääsupiirangute ja administraatorite tegevuste auditi osas. Kuidas juurdepääsu jagada? Lõppude lõpuks pidi iga osakond haldama (loe — käivitama Ansible playbook'i) oma «serverite» komplekti. Kuidas lubada konkreetsete Ansible playbook'ide käivitamist ainult teatud töötajatele? Või kuidas jälgida, kes käivitas playbook'i, looma palju kohalikke kontosid serverites ja Ansible'i halduses olevates seadmetes?
Suur osa selliseid küsimusi lahendab Red Hat , või selle open-source upstream projekt . Seetõttu eelistasime seda kliendile.
Ja veel üks detail meie CMS-süsteemi portreest. Ansible playbook peab olema salvestatud koodihaldussüsteemidesse. Meie kasutame .
Nii et konfiguratsioonide haldamise eest vastutab kombinatsioon Ansible'/Ansible AWX'/GitLab (vt. Joonis 3). Loomulikult on AWX/GitLab integreeritud ühtse autentimissüsteemiga ning Ansible playbook on seotud HashiCorp Vault'iga. Konfiguratsioonid jõuavad tootmisümbrusesse ainult läbi Ansible AWX, milles on määratud kõik «mängureeglid»: kes ja mida võib konfigureerida, kust võtta konfiguratsioonide haldamise koodi CMS-ile jne.
Joonis 3. Konfiguratsioonide haldamine.
Testimise haldamine
Meie konfiguratsioon on esitatud koodina. Seetõttu peame mängima sama reeglite järgi, mis tarkvaraarendajad. Meil oli vajalik korraldada arendamise, pideva testimise, toimetamise ja konfiguratsioonikoodi rakendamise protsessid tootmisserveritele.
Kui seda kohe ei teha, siis kirjutatud rollid konfiguratsiooni jaoks kas lõpetavad toetamise ja muutmise või lõpetavad tootmises käivitamise. Selle valu ravimeetod on teada ja see on selles projektis õigustanud end:
- iga roll on kaetud moodulitega testidega;
- testid jooksutatakse automaatselt iga koodi muudatuse korral, mis haldab seadistusi;
- koodi muudatused, mis haldavad seadistusi, jõuavad tootmiskeskkonda alles pärast kõikide testide ja koodide ülevaatuse edukat läbimist.
Koodi arendamine ja seadistuste haldamine on saanud rahulikumaks ja prognoositavamaks. Jätkuva testimise korraldamiseks kasutasime GitLab CI/CD tööriistu ning testide korraldamiseks olime valinud .
Iga kord, kui koodis haldustoimingutes on muudatus, kutsub GitLab CI/CD esile Molecule:
- see kontrollib koodi süntaksit,
- käivitab Docker-konteineri,
- rakendab muudetud koodi loodud konteinerisse,
- kontrollib rolli idempotentsust ja jookseb selle koodi jaoks testid (granulaarsus on siin ansible rolli tasemel, vt Joon. 4).
Tootmiskeskkonda edastasime seadistusi Ansible AWX-i kaudu. Kasutusele võtnud insenerid rakendasid seadistuse muudatusi ettenähtud mallide kaudu. AWX küsis iga rakendamise ajal viimast koodiversiooni GitLabi põhiharust. Nii välistasime mittekatsetatud või vananenud koodi kasutamise tootmiskeskkonnas. Loomulikult jõudis kood põhiharusse ainult pärast testimist, vaatamist ja kooskõlastamist.
Joon. 4. Automaatne testimine rollide GitLab CI/CD-s.
On veel üks probleem, mis on seotud tootmisüsteemide kasutamisega. Tegelike olukordade tõttu on väga raske teha muudatusi lihtsalt CMS-i koodi kaudu. Tõuseb erakorralisi olukordi, kus insener peab seadistust muutma "siin ja praegu", oodates koodi muutmist, testimist, kooskõlastamist jne.
Käsi-sekkumise tõttu tekivad konfiguratsioonis erinevused sama tüüpi varustuse vahel (näiteks HA-klastri sõlmedel on erinev sysctl seadistuste konfiguratsioon). Või erineb reaalse seadistuse konfiguratsioon varustuses sellest, mis on määratud CMS-i koodis.
Seetõttu kontrollime koos pideva testimisega tootmiskeskkondi konfiguratsioonide lahknevuste osas. Valisime kõige lihtsama variandi: CMS konfiguratsioonikoodi käivitamine „dry run“ režiimis, st muudatuste rakendamata jätmine, kuid teavitamine kõigist lahknevustest plaanitud ja tegeliku konfiguratsiooni vahel. Realiseerisime selle, käivitades perioodiliselt kõik Ansible playbookid valikuga "—check" tootmisse-serverites. Playbookide käivitamise ja ajakohasuse eest vastutab nagu alati Ansible AWX (vt joonis 5):
Joonis 5. Konfiguratsioonide lahknevuste kontrollimine Ansible AWX-s.
Pärast kontrollimist saadab AWX, et tuvastada lahknevused, haldajatele aruande. Nad uurivad probleemset konfiguratsiooni ja seejärel parandavad selle korrigeeritud playbookide kaudu. Nii hoiame tootmiskeskkonnas konfiguratsiooni ja CMS on alati ajakohane ja sünkroniseeritud. See väldib ebameeldivaid „imet”, kui CMS-i kood rakendatakse „töörõngas” serverites.
Nüüd on meil oluline testimise tasand, mis koosneb Ansible AWX/GitLab/Molecule (vt joonis 6).
Joonis 6. Testimise haldamine.
Kas see on keeruline? Ei vaidle. Kuid selline konfiguratsioonide haldamise kompleks on saanud ammendavaks vastuseks paljudele küsimustele, mis on seotud serverite seadistamise automatiseerimisega. Nüüd on jaemüüjal tüüpiliste serverite konfiguratsioon alati täpselt määratletud. Erinevalt insenerist ei unusta CMS vajalikku seadistuste lisamist, kasutajate loomist ja kümnete või sadade nõutud seadistuste tegemist.
Serverite ja keskkondade seadistustes puuduvad täna „salajased teadmised“. Kõik vajalikud omadused on kajastatud playbookides. Pole enam loovust ja ähmaseid juhiseid: "seadista nagu tavaline Oracle, kuid seal peab mõningaid sysctl seadeid üles kirjutama, ja lisama vajalikud kasutajad vastava UID-ga. Küsige töögrupilt, nad teavad.».
Võime avastada konfiguratsioonide lahknevusi ja ennetada nende parandamist annab rahu. Ilma konfiguratsioonihalduse süsteemita näeb see tavaliselt teistsugune välja. Probleemid kuhjuvad kuniks ühel päeval „plahvatavad“ tootmises. Siis viiakse läbi analüüs, kontrollitakse ja parandatakse konfiguratsioonid. Ja tsükkel kordub jälle.
Ja loomulikult oleme kiirendanud serverite tööle rakendamise aega mitmest päevast tundide peale.
Uue aasta öösel, kui lapsed rõõmsalt kingitusi avasid ja täiskasvanud kellalöökide saatel soove soovisid, migreerisid meie insenerid SAP-süsteemi uusetele serveritele. Isegi Jõuluvana ütleb, et parimad imed on hästi ettevalmistatud.
P.S. Meie meeskond seisab tihti silmitsi olukordadega, kus kliendid soovivad võimalikult lihtsalt lahendada konfiguratsiooni haldamise ülesandeid. Ideaalis nagu võluväel — ühe tööriistaga. Kuid elus on kõik keerulisem (jah, jälle ei toodud hõbedasi kuule): tuleb luua terve protsess, kasutades kliendi meeskonnale mugavaid tööriistu.
Autor: Sergei Artyomov, osakonna arhitekt «Infosisüsteemid Jet»
Allikas: habr.com
