Oli lähenemas uusaasta. Lapsed üle riigi olid juba jõuluvanale kirju saatnud või endale kingitusi teinud ning nende peamine täitja, üks suuremaid jaemüüjaid, valmistus müügi apoteoosiks. Detsembris suureneb selle andmekeskuse koormus mitu korda. Seetõttu otsustas ettevõte andmekeskuse kaasajastada ja oma kasutusiga lõppeva seadmete asemel kasutusele võtta mitukümmend uut serverit. Sellega lõpeb lugu keerlevate lumehelveste taustal ja põnevik algab.

Seadmed jõudsid objektile mitu kuud enne müügi tipphetki. Operatsiooniteenus muidugi teab, kuidas ja mida serverites seadistada, et need tootmiskeskkonda tuua. Kuid me pidime selle automatiseerima ja inimteguri kõrvaldama. Lisaks vahetati serverid välja enne ettevõtte jaoks kriitilise tähtsusega SAP-süsteemide komplekti migratsiooni.

Uute serverite kasutuselevõtt oli rangelt seotud tähtajaga. Ja selle liigutamine tähendas nii miljardi kingituse saatmise kui ka süsteemide migratsiooni ohtu seadmist. Isegi Isa Frostist ja Jõuluvanast koosnev meeskond ei saanud kuupäeva muuta – SAP-süsteemi saab laohalduseks üle anda vaid kord aastas. 31. detsembrist 1. jaanuarini seisavad jaemüüja hiiglaslikud laod, kokku 20 jalgpalliväljaku suurused, oma töö 15 tunniks. Ja see on ainus ajavahemik süsteemi liigutamiseks. Meil ei olnud serverite tutvustamisel eksimiseks ruumi.

Ütlen selgelt: minu lugu peegeldab tööriistu ja konfiguratsioonihaldusprotsessi, mida meie meeskond kasutab.

Konfiguratsioonihalduskompleks koosneb mitmest tasemest. Põhikomponent on CMS-süsteem. Tööstuslikus töös tooks ühe taseme puudumine paratamatult kaasa ebameeldivaid imesid.

OS-i installihaldus

Esimene tase on süsteem operatsioonisüsteemide installimise haldamiseks füüsilistesse ja virtuaalserveritesse. See loob põhilised OS-i konfiguratsioonid, välistades inimteguri.

Seda süsteemi kasutades saime standardsed serveri eksemplarid koos edasiseks automatiseerimiseks sobiva operatsioonisüsteemiga. "Valamise" ajal said nad minimaalse hulga kohalikke kasutajaid ja avalikke SSH-võtmeid ning järjekindla OS-i konfiguratsiooni. Meile garanteeriti, et haldame servereid CMS-i kaudu ja olime kindlad, et OS-i tasemel "allapoole" üllatusi ei esine.

Installihaldussüsteemi "maksimaalne" ülesanne on serverite automaatne konfigureerimine BIOS-i/püsivara tasemelt OS-i. Siin sõltub palju varustusest ja seadistusülesannetest. Heterogeensete seadmete puhul võite kaaluda REDFISH API. Kui kogu riistvara on ühelt müüjalt, siis on sageli mugavam kasutada valmis haldustööriistu (näiteks HP ILO Amplifier, DELL OpenManage jne).

OS-i installimiseks füüsilistesse serveritesse kasutasime tuntud Cobbleri, mis määratleb operatsiooniteenusega kokkulepitud installiprofiilide komplekti. Uue serveri lisamisel infrastruktuuri sidus insener serveri MAC-aadressi Cobbleris vajaliku profiiliga. Esmakordsel võrgu kaudu käivitamisel sai server ajutise aadressi ja värske OS-i. Seejärel viidi see üle siht-VLAN/IP-aadressile ja jätkati seal tööd. Jah, VLAN-i muutmine võtab aega ja nõuab kooskõlastamist, kuid see pakub täiendavat kaitset serveri juhusliku installimise eest tootmiskeskkonda.

Lõime virtuaalserverid HashiСorp Packeri abil valmistatud mallide põhjal. Põhjus oli sama: vältida võimalikke inimlikke vigu OS-i installimisel. Kuid erinevalt füüsilistest serveritest välistab Packer vajaduse PXE, võrgu käivitamise ja VLAN-i muudatuste järele. See on muutnud virtuaalserverite loomise lihtsamaks ja lihtsamaks.

Riis. 1. Operatsioonisüsteemide installi haldamine.

Saladuste haldamine

Iga konfiguratsioonihaldussüsteem sisaldab andmeid, mis peaksid olema tavakasutajate eest varjatud, kuid mida on vaja süsteemide ettevalmistamiseks. Need on kohalike kasutajate ja teenusekontode paroolid, sertifikaadivõtmed, erinevad API märgid jne. Neid nimetatakse tavaliselt "saladusteks".

Kui te ei määra algusest peale, kus ja kuidas neid saladusi hoida, siis olenevalt infoturbenõuete tõsidusest on tõenäolised järgmised salvestusmeetodid:

• otse konfiguratsiooni juhtkoodis või hoidlas olevates failides;
• spetsiaalsetes konfiguratsioonihaldustööriistades (näiteks Ansible Vault);
• CI/CD süsteemides (Jenkins/TeamCity/GitLab/jne) või konfiguratsioonihaldussüsteemides (Ansible Tower/Ansible AWX);
• saladusi saab edastada ka "käsitsi". Näiteks paigutatakse need kindlaksmääratud asukohta ja seejärel kasutavad neid konfiguratsioonihaldussüsteemid;
• eespool nimetatute mitmesugused kombinatsioonid.

Igal meetodil on oma puudused. Peamine neist on saladustele juurdepääsu poliitika puudumine: on võimatu või raske kindlaks teha, kes teatud saladusi kasutada saab. Teine puudus on juurdepääsu auditeerimise ja täieliku elutsükli puudumine. Kuidas kiiresti asendada näiteks avalikku võtit, mis on kirjas koodis ja mitmetes sellega seotud süsteemides?

Kasutasime tsentraliseeritud salajast salvestusruumi HashiCorp Vault. See võimaldas meil:

• hoidke saladusi turvaliselt. Need on krüptitud ja isegi kui keegi saab juurdepääsu Vaulti andmebaasile (näiteks taastades selle varukoopiast), ei saa ta sinna salvestatud saladusi lugeda;
• korraldada saladustele juurdepääsu eeskirju. Ainult neile "eraldatud" saladused on kasutajatele ja rakendustele kättesaadavad;
• kontrollida juurdepääsu saladustele. Kõik saladustega toimingud salvestatakse Vaulti auditi logisse;
• korraldage saladustega töötamise täieõiguslik "elutsükkel". Neid saab luua, tühistada, määrata aegumiskuupäeva jne.
• lihtne integreerida teiste süsteemidega, mis vajavad juurdepääsu saladustele;
• ja kasutada ka otsast lõpuni krüptimist, OS-i ja andmebaasi ühekordseid paroole, volitatud keskuste sertifikaate jne.

Liigume nüüd edasi keskse autentimis- ja autoriseerimissüsteemi juurde. Ilma selleta sai hakkama, kuid kasutajate administreerimine paljudes seotud süsteemides on liiga ebatriviaalne. Oleme konfigureerinud autentimise ja autoriseerimise LDAP-teenuse kaudu. Vastasel juhul peaks Vault pidevalt kasutajate autentimismärke väljastama ja neid jälgima. Ja kasutajate kustutamine ja lisamine muutuks küsimuseks "kas ma lõin/kustutasin selle kasutajakonto kõikjal?"

Lisame oma süsteemi veel ühe taseme: saladuste haldamine ja keskne autentimine/volitamine:

Riis. 2. Saladuste haldamine.

Konfiguratsiooni juhtimine

Jõudsime tuumani – CMS-süsteemini. Meie puhul on see Ansible ja Red Hat Ansible AWX kombinatsioon.

Ansible asemel võib kasutada Chef, Puppet, SaltStack. Ansible valisime mitme kriteeriumi alusel.

• Esiteks on see mitmekülgsus. Valmis moodulite komplekt juhtimiseks see on muljetavaldav. Ja kui teil sellest ei piisa, saate otsida GitHubist ja Galaxyst.
• Teiseks pole vaja hallatavatele seadmetele agente installida ja toetada, tõestada, et need ei sega koormust, ja kinnitada järjehoidjate puudumist.
• Kolmandaks on Ansiblel madal sisenemisbarjäär. Pädev insener kirjutab tööjuhendi sõna otseses mõttes esimesel tootega töötamise päeval.

Kuid ainult Ansiblest tootmiskeskkonnas meile ei piisanud. Vastasel juhul tekiks palju probleeme juurdepääsu piiramise ja administraatorite tegevuse auditeerimisega. Kuidas juurdepääsu piirata? Oli ju vaja, et iga osakond haldaks (loe: jooksutaks Ansible playbooki) “oma” serverikomplekti. Kuidas lubada ainult teatud töötajatel konkreetseid Ansible mänguraamatuid juhtida? Või kuidas jälgida, kes juhendi käivitas, ilma Ansible'i kasutavate serverite ja seadmete kohta palju kohalikke teadmisi seadistamata?

Lõviosa sellistest probleemidest lahendab Red Hat Ansible tornvõi tema avatud lähtekoodiga ülesvoolu projekt Võimalik AWX. Seetõttu eelistasime seda kliendi jaoks.

Ja veel üks puudutus meie CMS-süsteemi portreele. Võimalik mänguraamat tuleks salvestada koodihoidlate haldussüsteemidesse. Meil on see GitLab CE.

Seega haldab konfiguratsioone endid Ansible/Ansible AWX/GitLabi kombinatsioon (vt joonis 3). Loomulikult on AWX / GitLab integreeritud ühe autentimissüsteemiga ja Ansible playbook on integreeritud HashiCorp Vaultiga. Konfiguratsioonid sisenevad tootmiskeskkonda ainult Ansible AWX kaudu, milles on ette nähtud kõik “mängureeglid”: kes mida saab seadistada, kust saab CMS-i konfiguratsioonihalduskoodi jne.

Riis. 3. Konfiguratsioonihaldus.

Testi juhtimine

Meie konfiguratsioon on esitatud koodi kujul. Seetõttu oleme sunnitud mängima samade reeglite järgi nagu tarkvaraarendajad. Meil oli vaja korraldada arendusprotsessid, pidev testimine, konfiguratsioonikoodi tarnimine ja tootmisserveritesse rakendamine.

Kui seda kohe ei tehta, lõpetatakse konfiguratsiooni jaoks kirjutatud rollide toetamine ja muutmine või nende käivitamine tootmises. Selle valu ravi on teada ja see on ennast selles projektis tõestanud:

• iga roll on kaetud üksusetestidega;
• testid käivitatakse automaatselt alati, kui konfiguratsioone haldavas koodis tehakse muudatusi;
• konfiguratsioonihalduskoodi muudatused avaldatakse tootmiskeskkonda alles pärast kõigi testide edukat läbimist ja koodi ülevaatust.

Koodiarendus ja konfiguratsioonihaldus on muutunud rahulikumaks ja etteaimatavamaks. Pideva testimise korraldamiseks kasutasime GitLabi CI/CD tööriistakomplekti ja võtsime Ansible molekul.

Kui konfiguratsioonihalduskoodis tehakse muudatusi, kutsub GitLabi CI/CD Molecule:

• see kontrollib koodi süntaksit,
• tõstab Dockeri konteineri üles,
• rakendab loodud konteinerile muudetud koodi,
• kontrollib rolli idempotentsuse suhtes ja käivitab selle koodi testid (täpsustus on siin võimalikul rollitasemel, vt joonis 4).

Tarnisime Ansible AWX-i abil konfiguratsioonid tootmiskeskkonda. Operatsiooniinsenerid rakendasid konfiguratsioonimuudatusi eelmääratletud mallide kaudu. AWX “päris” iseseisvalt GitLabi põhiharult koodi uusimat versiooni iga kord, kui seda kasutati. Nii välistasime tootmiskeskkonnas testimata või aegunud koodi kasutamise. Loomulikult sisenes kood põhiharusse alles pärast testimist, ülevaatamist ja kinnitamist.

Riis. 4. Rollide automaatne testimine GitLabi CI/CD-s.

Probleem on seotud ka tootmissüsteemide tööga. Reaalses elus on ainult CMS-koodi kaudu konfiguratsioonimuudatusi väga raske teha. Tekivad eriolukorrad, kui insener peab muutma konfiguratsiooni “siin ja praegu”, ootamata koodi redigeerimist, testimist, kinnitamist jne.

Selle tulemusena ilmnevad käsitsi tehtud muudatuste tõttu sama tüüpi seadmete konfiguratsioonis lahknevused (nt sysctl-i sätted on HA-klastri sõlmedes konfigureeritud erinevalt). Või erineb seadme tegelik konfiguratsioon CMS-koodis määratust.

Seetõttu kontrollime lisaks pidevale testimisele tootmiskeskkondi konfiguratsiooni lahknevuste suhtes. Valisime kõige lihtsama võimaluse: CMS-i konfiguratsioonikoodi käivitamine kuivkäivitusrežiimis, st ilma muudatusi rakendamata, kuid teavitades kõiki kavandatud ja tegeliku konfiguratsiooni lahknevusi. Rakendasime seda, käitades tootmisserverites perioodiliselt kõiki Ansible mänguraamatuid valikuga „—check”. Nagu alati, vastutab Ansible AWX mänguraamatu käivitamise ja ajakohasena hoidmise eest (vt joonis 5):

Riis. 5. Kontrollib Ansible AWX konfiguratsiooni lahknevusi.

Pärast kontrollimist saadab AWX administraatoritele lahknevuse aruande. Nad uurivad probleemset konfiguratsiooni ja seejärel parandavad selle kohandatud mänguraamatute kaudu. Nii hoiame tootmiskeskkonnas konfiguratsiooni ning CMS on alati ajakohane ja sünkroonitud. See välistab ebameeldivad "imed", kui CMS-koodi kasutatakse "tootmisserverites".

Meil on nüüd oluline testimiskiht, mis koosneb Ansible AWX/GitLab/Molecule (joonis 6).

Riis. 6. Testide juhtimine.

Raske? ma ei vaidle vastu. Kuid sellisest konfiguratsioonihalduse kompleksist on saanud põhjalik vastus paljudele serveri konfigureerimise automatiseerimisega seotud küsimustele. Nüüd on jaemüüja standardserveritel alati rangelt määratletud konfiguratsioon. CMS, erinevalt insenerist, ei unusta vajalikke seadistusi lisada, kasutajaid luua ja kümneid või sadu nõutavaid seadistusi teha.

Serverite ja keskkondade seadistustes pole tänapäeval "salajast teadmist". Kõik vajalikud funktsioonid kajastuvad mänguraamatus. Pole enam loovust ja ebamääraseid juhiseid: “Installige see nagu tavaline Oracle, kuid peate määrama paar sysctl-i seadet ja lisama kasutajad vajaliku UID-ga. Küsi operaatoritelt, nad teavad'.

Võimalus tuvastada konfiguratsiooni lahknevusi ja neid ennetavalt parandada tagab meelerahu. Ilma konfiguratsioonihaldussüsteemita näeb see tavaliselt välja teistsugune. Probleemid kuhjuvad, kuni ühel päeval "tulistavad" tootmisse. Seejärel viiakse läbi arutelu, konfiguratsioone kontrollitakse ja parandatakse. Ja tsükkel kordub uuesti

Ja loomulikult kiirendasime serverite käivitamist mitmelt päevalt tundideni.

Noh, vana-aastaõhtul, kui lapsed rõõmsalt kingitusi lahti pakkisid ja täiskasvanud kella kõlades soove esitasid, viisid meie insenerid SAP-süsteemi uutesse serveritesse. Isegi jõuluvana ütleb, et parimad imed on need, mis on hästi ette valmistatud.

PS Meie meeskond puutub sageli kokku tõsiasjaga, et kliendid soovivad konfiguratsioonihalduse probleeme võimalikult lihtsalt lahendada. Ideaalis justkui võluväel – ühe tööriistaga. Kuid elus on kõik keerulisem (jah, hõbekuule jälle ei toodud): tuleb luua kogu protsess kliendi meeskonnale sobivate tööriistade abil.

Autor: Sergei Artemov, osakonna arhitekt DevOpsi lahendused "Jet Infosüsteemid"

Allikas: www.habr.com