Það var að nálgast áramótin. Börn um allt land höfðu þegar sent jólasveinunum bréf eða búið til gjafir handa sjálfum sér og aðalframkvæmdastjóri þeirra, einn af stóru söluaðilunum, var að undirbúa apótheosis sölunnar. Í desember eykst álagið á gagnaver þess nokkrum sinnum. Því ákvað fyrirtækið að nútímavæða gagnaverið og taka nokkra tugi nýrra netþjóna í notkun í stað búnaðar sem var að ljúka líftíma sínum. Þetta endar söguna á bakgrunni þyrlandi snjókorna og spennumyndin hefst.

Búnaðurinn kom á staðinn nokkrum mánuðum áður en sala náði hámarki. Rekstrarþjónustan veit auðvitað hvernig og hvað á að stilla á netþjónunum til að koma þeim inn í framleiðsluumhverfið. En við þurftum að gera þetta sjálfvirkt og útrýma mannlega þættinum. Að auki var skipt um netþjóna fyrir flutning á SAP kerfum sem voru mikilvæg fyrir fyrirtækið.

Gangsetning nýrra netþjóna var stranglega bundin við frest. Og að flytja það þýddi að tefla bæði sendingu á milljarði gjafa og flutningi kerfa í hættu. Jafnvel teymi sem samanstóð af föður Frost og jólasveininum gat ekki breytt dagsetningunni - þú getur aðeins flutt SAP kerfið fyrir vöruhúsastjórnun einu sinni á ári. Frá 31. desember til 1. janúar hætta risastór vöruhús verslunarinnar, samtals á stærð við 20 fótboltavelli, vinnu sinni í 15 klukkustundir. Og þetta er eini tíminn til að flytja kerfið. Við höfðum ekkert pláss fyrir villur þegar við kynntum netþjóna.

Leyfðu mér að vera skýr: Sagan mín endurspeglar verkfærin og stillingarstjórnunarferlið sem teymið okkar notar.

Stillingarstjórnunarsamstæðan samanstendur af nokkrum stigum. Lykilþátturinn er CMS kerfið. Í iðnaðarrekstri myndi skortur á einu af stigunum óhjákvæmilega leiða til óþægilegra kraftaverka.

Stýrikerfi uppsetningarstjórnunar

Fyrsta stigið er kerfi til að stjórna uppsetningu stýrikerfa á líkamlegum og sýndarþjónum. Það býr til grunnstillingar stýrikerfisins og útilokar mannlega þáttinn.

Með því að nota þetta kerfi fengum við staðlaða netþjónstilvik með stýrikerfi sem henta til frekari sjálfvirkni. Meðan á „úthellingunni“ stóð fengu þeir lágmarkssett af staðbundnum notendum og opinberum SSH lyklum, auk samkvæmrar stýrikerfisstillingar. Við gætum verið tryggð að stjórna netþjónunum í gegnum CMS og vorum viss um að það væri ekkert óvænt „neðar“ á stýrikerfisstigi.

„Hámarks“ verkefni fyrir uppsetningarstjórnunarkerfið er að stilla netþjóna sjálfkrafa frá BIOS/fastbúnaðarstigi yfir í stýrikerfið. Hér fer mikið eftir búnaði og uppsetningarverkefnum. Fyrir ólíkan búnað geturðu íhugað REDFISH API. Ef allur vélbúnaður er frá einum söluaðila, þá er oft þægilegra að nota tilbúin stjórnunarverkfæri (td HP ILO Amplifier, DELL OpenManage, osfrv.).

Til að setja upp stýrikerfið á líkamlegum netþjónum notuðum við hinn vel þekkta Cobbler, sem skilgreinir sett af uppsetningarsniðum sem samið er um við rekstrarþjónustuna. Þegar nýjum þjóni var bætt við innviðina, batt verkfræðingur MAC vistfang þjónsins við nauðsynlegan prófíl í Cobbler. Þegar ræst var yfir netið í fyrsta skipti fékk þjónninn tímabundið heimilisfang og nýtt stýrikerfi. Síðan var það flutt yfir á VLAN/IP vistfangið og haldið áfram vinnu þar. Já, að breyta VLAN tekur tíma og krefst samhæfingar, en það veitir viðbótarvörn gegn uppsetningu þjónsins fyrir slysni í framleiðsluumhverfi.

Við bjuggum til sýndarþjóna byggða á sniðmátum sem voru útbúin með HashiСorp Packer. Ástæðan var sú sama: til að koma í veg fyrir hugsanleg mannleg mistök við uppsetningu stýrikerfisins. En ólíkt líkamlegum netþjónum útilokar Packer þörfina fyrir PXE, netræsingu og VLAN breytingar. Þetta hefur gert það auðveldara og einfaldara að búa til sýndarþjóna.

Hrísgrjón. 1. Umsjón með uppsetningu stýrikerfa.

Stjórna leyndarmálum

Öll stillingarstjórnunarkerfi innihalda gögn sem ættu að vera falin fyrir venjulegum notendum, en þau eru nauðsynleg til að undirbúa kerfi. Þetta eru lykilorð staðbundinna notenda og þjónustureikninga, vottorðslyklar, ýmis API tákn o.s.frv. Þau eru venjulega kölluð „leyndarmál“.

Ef þú ákveður ekki alveg frá upphafi hvar og hvernig á að geyma þessi leyndarmál, þá eru eftirfarandi geymsluaðferðir líklegar, allt eftir alvarleika upplýsingaöryggiskrafna:

• beint í stillingarstýringarkóða eða í skrám í geymslunni;
• í sérhæfðum stillingarstjórnunarverkfærum (til dæmis Ansible Vault);
• í CI/CD kerfum (Jenkins/TeamCity/GitLab/o.s.frv.) eða í stillingarstjórnunarkerfum (Ansible Tower/Ansible AWX);
• Einnig er hægt að flytja leyndarmál „handvirkt“. Til dæmis eru þau sett út á tilteknum stað og síðan eru þau notuð af stillingarstjórnunarkerfum;
• ýmsar samsetningar af ofangreindu.

Hver aðferð hefur sína ókosti. Aðalatriðið er skortur á stefnu um aðgang að leyndarmálum: það er ómögulegt eða erfitt að ákvarða hver getur notað ákveðin leyndarmál. Annar ókostur er skortur á aðgangsendurskoðun og fullan lífsferil. Hvernig á að skipta fljótt út, til dæmis, opinberum lykli sem er skrifaður í kóðann og í fjölda tengdra kerfa?

Við notuðum miðlægu leynigeymsluna HashiCorp Vault. Þetta gerði okkur kleift:

• halda leyndarmálum öruggum. Þær eru dulkóðaðar og jafnvel þótt einhver fái aðgang að Vault gagnagrunninum (til dæmis með því að endurheimta hann úr öryggisafriti) mun hann ekki geta lesið leyndarmálin sem eru geymd þar;
• skipuleggja stefnu um aðgang að leyndarmálum. Aðeins leyndarmálin „úthlutað“ þeim eru í boði fyrir notendur og forrit;
• endurskoðunaraðgang að leyndarmálum. Allar aðgerðir með leyndarmál eru skráðar í Vault endurskoðunarskránni;
• skipuleggja fullgildan „lífsferil“ vinnu með leyndarmál. Þær er hægt að búa til, afturkalla, setja gildistíma o.s.frv.
• auðvelt að samþætta við önnur kerfi sem þurfa aðgang að leyndarmálum;
• og einnig nota end-to-end dulkóðun, einu sinni lykilorð fyrir stýrikerfið og gagnagrunninn, vottorð viðurkenndra miðstöðvar osfrv.

Nú skulum við halda áfram í miðlæga auðkenningar- og heimildakerfið. Það var hægt að vera án þess, en stjórna notendum í mörgum tengdum kerfum er of lítið mál. Við höfum stillt auðkenningu og heimild í gegnum LDAP þjónustuna. Annars þyrfti Vault stöðugt að gefa út og halda utan um auðkenningartákn fyrir notendur. Og að eyða og bæta við notendum myndi breytast í leit "bjó ég til/eyddi þessum notendareikningi alls staðar?"

Við bætum öðru stigi við kerfið okkar: leyndarmálastjórnun og miðlæg auðkenning/heimild:

Hrísgrjón. 2. Leyndarmál stjórnun.

Stillingarstjórnun

Við komumst að kjarnanum - CMS kerfið. Í okkar tilviki er þetta blanda af Ansible og Red Hat Ansible AWX.

Í stað Ansible er hægt að nota Chef, Puppet, SaltStack. Við völdum Ansible út frá nokkrum forsendum.

• Í fyrsta lagi er það fjölhæfni. Sett af tilbúnum einingum til að stjórna setur svip. Og ef þú átt ekki nóg af því geturðu leitað á GitHub og Galaxy.
• Í öðru lagi er engin þörf á að setja upp og styðja umboðsmenn á stýrðum búnaði, sanna að þeir trufli ekki álagið og staðfesta að „bókamerki“ séu ekki til.
• Í þriðja lagi hefur Ansible litla aðgangshindrun. Hæfilegur verkfræðingur mun skrifa vinnubók bókstaflega á fyrsta degi vinnu með vöruna.

En Ansible einn í framleiðsluumhverfi var okkur ekki nóg. Annars myndu mörg vandamál koma upp við að takmarka aðgang og endurskoða aðgerðir stjórnenda. Hvernig á að takmarka aðgang? Þegar öllu er á botninn hvolft var nauðsynlegt fyrir hverja deild að stjórna (lesið: keyra Ansible leikbókina) „sitt eigið“ sett af netþjónum. Hvernig á að leyfa aðeins ákveðnum starfsmönnum að keyra sérstakar Ansible leikrit? Eða hvernig á að rekja hver setti leikbókina af stað án þess að setja upp mikla staðbundna þekkingu á netþjónum og búnaði sem keyrir Ansible?

Ljónshluti slíkra mála er leystur af Red Hat Ansible turninn, eða opinn uppspretta andstreymisverkefni hans Ansible AWX. Þess vegna vildum við það fyrir viðskiptavininn.

Og enn ein snertingin á myndinni af CMS kerfinu okkar. Ansible leikbók ætti að geyma í stjórnunarkerfum kóðageymslu. Við höfum það GitLab CE.

Þannig að stillingunum sjálfum er stjórnað af blöndu af Ansible/Ansible AWX/GitLab (sjá mynd 3). Auðvitað er AWX/GitLab samþætt með einu auðkenningarkerfi og Ansible leikbók er samþætt HashiCorp Vault. Stillingar fara aðeins inn í framleiðsluumhverfið í gegnum Ansible AWX, þar sem allar „leikreglur“ eru tilgreindar: hver getur stillt hvað, hvar á að fá stillingarstjórnunarkóðann fyrir CMS osfrv.

Hrísgrjón. 3. Stillingarstjórnun.

Prófstjórnun

Stillingar okkar eru settar fram í kóðaformi. Þess vegna neyðumst við til að leika eftir sömu reglum og hugbúnaðarframleiðendur. Við þurftum að skipuleggja þróunarferla, stöðugar prófanir, afhendingu og beitingu stillingakóða á framleiðsluþjóna.

Ef þetta er ekki gert strax, þá myndu hlutverkin sem skrifuð eru fyrir uppsetninguna annað hvort hætta að vera studd og breytt, eða hætta að vera sett í framleiðslu. Lækningin við þessum sársauka er þekkt og hún hefur sannað sig í þessu verkefni:

• hvert hlutverk er fjallað um einingapróf;
• próf eru keyrð sjálfkrafa í hvert skipti sem það er einhver breyting á kóðanum sem stjórnar stillingunum;
• breytingar á stillingarstjórnunarkóða eru gefnar út í framleiðsluumhverfið aðeins eftir að hafa staðist allar prófanir og endurskoðun kóða.

Kóðaþróun og stillingarstjórnun hefur orðið rólegri og fyrirsjáanlegri. Til að skipuleggja stöðugar prófanir notuðum við GitLab CI/CD verkfærakistuna og tókum Ansible sameind.

Alltaf þegar það er breyting á stillingarstjórnunarkóðanum kallar GitLab CI/CD Molecule:

• það athugar setningafræði kóðans,
• lyftir Docker gámnum,
• beitir breytta kóðanum á stofnaða ílátið,
• athugar hlutverkið með tilliti til getuleysis og keyrir próf fyrir þennan kóða (granularity hér er á viðeigandi hlutverkastigi, sjá mynd 4).

Við afhentum stillingar í framleiðsluumhverfið með því að nota Ansible AWX. Rekstrarfræðingar beittu stillingarbreytingum í gegnum fyrirfram skilgreind sniðmát. AWX „biðði“ sjálfstætt um nýjustu útgáfu kóðans frá GitLab aðalútibúinu í hvert skipti sem hann var notaður. Þannig útilokuðum við notkun á óprófuðum eða gamaldags kóða í framleiðsluumhverfinu. Auðvitað fór kóðinn aðeins inn í aðalútibúið eftir prófun, yfirferð og samþykki.

Hrísgrjón. 4. Sjálfvirk prófun á hlutverkum í GitLab CI/CD.

Það er líka vandamál sem tengist rekstri framleiðslukerfa. Í raunveruleikanum er mjög erfitt að gera stillingarbreytingar með CMS kóða einum. Neyðartilvik koma upp þegar verkfræðingur þarf að breyta stillingunum „hér og nú“ án þess að bíða eftir kóðabreytingum, prófun, samþykki osfrv.

Þar af leiðandi, vegna handvirkra breytinga, birtast ósamræmi í stillingum á sömu tegund búnaðar (til dæmis eru sysctl stillingar stilltar á annan hátt á HA klasahnútum). Eða raunveruleg uppsetning á búnaðinum er frábrugðin þeirri sem tilgreind er í CMS kóðanum.

Þess vegna, auk stöðugra prófana, athugum við framleiðsluumhverfi fyrir misræmi í stillingum. Við völdum einfaldasta kostinn: að keyra CMS stillingarkóðann í „þurrkeyrslu“ ham, það er, án þess að beita breytingum, en með tilkynningu um allt misræmi á milli fyrirhugaðrar og raunverulegrar stillingar. Við innleiddum þetta með því að keyra reglulega allar Ansible leikbækur með „—athugaðu“ valkostinum á framleiðsluþjónum. Eins og alltaf er Ansible AWX ábyrgur fyrir því að ræsa og halda leikbókinni uppfærðri (sjá mynd 5):

Hrísgrjón. 5. Athugar hvort misræmi í stillingum sé í Ansible AWX.

Eftir athuganir sendir AWX misræmisskýrslu til stjórnenda. Þeir rannsaka erfiðu uppsetninguna og laga hana síðan í gegnum lagfærðar leikbækur. Þannig höldum við uppsetningunni í framleiðsluumhverfinu og CMS er alltaf uppfært og samstillt. Þetta útilokar óþægileg „kraftaverk“ þegar CMS kóða er notað á „framleiðslu“ netþjónum.

Við höfum nú mikilvægt prófunarlag sem samanstendur af Ansible AWX/GitLab/Molecule (Mynd 6).

Hrísgrjón. 6. Prófstjórnun.

Erfitt? Ég rífast ekki. En slíkt flókið stillingarstjórnunar er orðið yfirgripsmikið svar við mörgum spurningum sem tengjast sjálfvirkni stillingar miðlara. Nú hafa staðlaðir netþjónar smásala alltaf stranglega skilgreinda uppsetningu. CMS, ólíkt verkfræðingi, mun ekki gleyma að bæta við nauðsynlegum stillingum, búa til notendur og framkvæma heilmikið eða hundruð nauðsynlegra stillinga.

Það er engin „leynileg þekking“ í stillingum netþjóna og umhverfi í dag. Allir nauðsynlegir eiginleikar endurspeglast í leikbókinni. Ekki lengur sköpunargleði og óljósar leiðbeiningar: “Settu það upp eins og venjulega Oracle, en þú þarft að tilgreina nokkrar sysctl stillingar og bæta við notendum með nauðsynlegu UID. Spyrðu strákana í rekstri, þeir vita það'.

Hæfni til að greina misræmi í stillingum og leiðrétta þau fyrirbyggjandi veitir hugarró. Án stillingastjórnunarkerfis lítur þetta venjulega öðruvísi út. Vandamál safnast upp þar til einn daginn „skota“ þau í framleiðslu. Síðan er farið í skýrslutöku, stillingar athugaðar og lagfærðar. Og hringrásin endurtekur sig aftur

Og auðvitað flýttum við uppsetningu netþjóna í notkun úr nokkrum dögum í klukkustundir.

Jæja, á sjálfu gamlárskvöldinu, þegar börn voru fögnuð að pakka inn gjöfum og fullorðnir voru að óska ​​sér þegar bjölluhljómurinn kom, fluttu verkfræðingar okkar SAP kerfið yfir á nýja netþjóna. Jafnvel jólasveinninn mun segja að bestu kraftaverkin séu þau sem eru vel undirbúin.

PS Lið okkar lendir oft í þeirri staðreynd að viðskiptavinir vilja leysa stillingarstjórnunarvandamál eins einfaldlega og mögulegt er. Helst, eins og fyrir töfra - með einu verkfæri. En í lífinu er allt flóknara (já, silfurkúlur voru ekki afhentar aftur): þú verður að búa til heilt ferli með því að nota verkfæri sem eru þægileg fyrir teymi viðskiptavinarins.

Höfundur: Sergey Artemov, deildararkitekt DevOps lausnir "Jet Infosystems"

Heimild: www.habr.com