Dit het die nuwe jaar aangebreek. Kinders regoor die land het reeds briewe aan Kersvader gestuur of geskenke vir hulself gemaak, en hul hoof-eksekuteur, een van die groot kleinhandelaars, was besig om voor te berei vir die apoteose van verkope. In Desember neem die las op sy datasentrum verskeie kere toe. Daarom het die maatskappy besluit om die datasentrum te moderniseer en 'n paar dosyn nuwe bedieners in werking te stel in plaas van toerusting wat die einde van sy dienslewe bereik het. Dit eindig die verhaal teen die agtergrond van kolkende sneeuvlokkies, en die riller begin.

Die toerusting het etlike maande voor die hoogtepunt van verkope by die terrein aangekom. Die bedryfsdiens weet natuurlik hoe en wat om op die bedieners te konfigureer om hulle in die produksie-omgewing te bring. Maar ons moes dit outomatiseer en die menslike faktor uitskakel. Daarbenewens is die bedieners vervang voor die migrasie van 'n stel SAP-stelsels wat van kritieke belang was vir die maatskappy.

Die ingebruikneming van nuwe bedieners was streng gekoppel aan 'n sperdatum. En om dit te verskuif het beteken dat beide die verskeping van 'n miljard geskenke en die migrasie van stelsels in gevaar gestel is. Selfs 'n span bestaande uit Vader Frost en Kersvader kon nie die datum verander nie - jy kan die SAP-stelsel vir pakhuisbestuur net een keer per jaar oordra. Van 31 Desember tot 1 Januarie staak die kleinhandelaar se groot pakhuise, in totaal die grootte van 20 sokkervelde, hul werk vir 15 uur. En dit is die enigste tydperk vir die verskuiwing van die stelsel. Ons het geen ruimte vir foute gehad toe ons bedieners bekendgestel het nie.

Laat my duidelik wees: my storie weerspieël die gereedskap en konfigurasiebestuursproses wat ons span gebruik.

Die konfigurasiebestuurskompleks bestaan ​​uit verskeie vlakke. Die sleutelkomponent is die CMS-stelsel. In industriële bedryf sou die afwesigheid van een van die vlakke onvermydelik tot onaangename wonderwerke lei.

OS installasie bestuur

Die eerste vlak is 'n stelsel vir die bestuur van die installering van bedryfstelsels op fisiese en virtuele bedieners. Dit skep basiese OS-konfigurasies, wat die menslike faktor uitskakel.

Deur hierdie stelsel te gebruik, het ons standaardbedienergevalle ontvang met OS wat geskik is vir verdere outomatisering. Tydens die "skiet" het hulle 'n minimum stel plaaslike gebruikers en publieke SSH-sleutels ontvang, sowel as 'n konsekwente OS-konfigurasie. Ons kan gewaarborg word om die bedieners deur die CMS te bestuur en was seker dat daar geen verrassings “onder” op die OS-vlak was nie.

Die "maksimum" taak vir die installasiebestuurstelsel is om bedieners outomaties vanaf die BIOS/Firmware-vlak na die OS te konfigureer. Baie hier hang af van die toerusting en opsteltake. Vir heterogene toerusting, kan jy oorweeg REDFISH API. As al die hardeware van een verskaffer is, is dit dikwels geriefliker om gereedgemaakte bestuursinstrumente te gebruik (byvoorbeeld HP ILO Amplifier, DELL OpenManage, ens.).

Om die bedryfstelsel op fisiese bedieners te installeer, het ons die bekende Cobbler gebruik, wat 'n stel installasieprofiele definieer wat met die bedryfsdiens ooreengekom is. Wanneer 'n nuwe bediener by die infrastruktuur gevoeg is, het die ingenieur die bediener se MAC-adres aan die vereiste profiel in Cobbler gekoppel. Toe die bediener vir die eerste keer oor die netwerk selflaai, het die bediener 'n tydelike adres en 'n nuwe bedryfstelsel ontvang. Toe is dit na die teiken VLAN/IP-adressering oorgedra en daar is voortgegaan met werk. Ja, die verandering van VLAN neem tyd en vereis koördinasie, maar dit bied bykomende beskerming teen toevallige installering van die bediener in 'n produksie-omgewing.

Ons het virtuele bedieners geskep gebaseer op sjablone wat met HashiСorp Packer voorberei is. Die rede was dieselfde: om moontlike menslike foute te voorkom wanneer die bedryfstelsel geïnstalleer word. Maar, anders as fisiese bedieners, elimineer Packer die behoefte aan PXE, netwerkselflaai en VLAN-veranderinge. Dit het dit makliker en eenvoudiger gemaak om virtuele bedieners te skep.

Rys. 1. Bestuur van die installering van bedryfstelsels.

Bestuur van geheime

Enige konfigurasiebestuurstelsel bevat data wat vir gewone gebruikers weggesteek behoort te word, maar wat nodig is om stelsels voor te berei. Dit is wagwoorde vir plaaslike gebruikers en diensrekeninge, sertifikaatsleutels, verskeie API-tokens, ens. Dit word gewoonlik "geheime" genoem.

As jy nie van die begin af bepaal waar en hoe om hierdie geheime te stoor nie, is die volgende bergingsmetodes waarskynlik, afhangende van die erns van die inligtingsekuriteitsvereistes:

• direk in die konfigurasiebeheerkode of in lêers in die bewaarplek;
• in gespesialiseerde konfigurasiebestuurnutsmiddels (byvoorbeeld Ansible Vault);
• in CI/CD-stelsels (Jenkins/TeamCity/GitLab/ens.) of in konfigurasiebestuurstelsels (Ansible Tower/Ansible AWX);
• geheime kan ook “handmatig” oorgedra word. Hulle word byvoorbeeld op 'n gespesifiseerde plek uitgelê, en dan word hulle deur konfigurasiebestuurstelsels gebruik;
• verskeie kombinasies van bogenoemde.

Elke metode het sy eie nadele. Die belangrikste een is die gebrek aan beleide vir toegang tot geheime: dit is onmoontlik of moeilik om te bepaal wie sekere geheime kan gebruik. Nog 'n nadeel is die gebrek aan toegangsouditering en 'n volle lewensiklus. Hoe om byvoorbeeld 'n publieke sleutel vinnig te vervang wat in die kode en in 'n aantal verwante stelsels geskryf is?

Ons het die gesentraliseerde geheime berging HashiCorp Vault gebruik. Dit het ons toegelaat:

• bewaar geheime veilig. Hulle is geïnkripteer, en selfs al kry iemand toegang tot die Vault-databasis (byvoorbeeld deur dit vanaf 'n rugsteun te herstel), sal hulle nie die geheime wat daar gestoor is, kan lees nie;
• reël beleide vir toegang tot geheime. Slegs die geheime wat aan hulle "toegewys" is, is beskikbaar vir gebruikers en toepassings;
• oudit toegang tot geheime. Enige aksies met geheime word in die Vault-ouditlogboek aangeteken;
• organiseer 'n volwaardige "lewensiklus" van werk met geheime. Hulle kan geskep, herroep word, 'n vervaldatum stel, ens.
• maklik om te integreer met ander stelsels wat toegang tot geheime benodig;
• en gebruik ook end-tot-end-enkripsie, eenmalige wagwoorde vir die bedryfstelsel en databasis, sertifikate van gemagtigde sentrums, ens.

Kom ons gaan nou oor na die sentrale verifikasie- en magtigingstelsel. Dit was moontlik om daarsonder klaar te kom, maar die administrasie van gebruikers in baie verwante stelsels is te nie-triviaal. Ons het stawing en magtiging deur die LDAP-diens opgestel. Andersins sal Vault voortdurend verifikasietokens vir gebruikers moet uitreik en op hoogte hou. En om gebruikers uit te vee en by te voeg, sal 'n soeke word: "het ek hierdie gebruikersrekening oral geskep of uitgevee?"

Ons voeg nog 'n vlak by ons stelsel: geheime bestuur en sentrale verifikasie/magtiging:

Rys. 2. Geheime bestuur.

Konfigurasiebestuur

Ons het by die kern gekom - die CMS-stelsel. In ons geval is dit 'n kombinasie van Ansible en Red Hat Ansible AWX.

In plaas van Ansible, kan Chef, Puppet, SaltStack gebruik word. Ons het Ansible gekies op grond van verskeie kriteria.

• Eerstens is dit veelsydigheid. 'n Stel klaargemaakte modules vir beheer dit is indrukwekkend. En as jy nie genoeg daarvan het nie, kan jy op GitHub en Galaxy soek.
• Tweedens is dit nie nodig om agente op bestuurde toerusting te installeer en te ondersteun, te bewys dat hulle nie met die vrag inmeng nie, en die afwesigheid van "boekmerke" te bevestig.
• Derdens het Ansible 'n lae versperring vir toegang. 'n Bekwame ingenieur sal letterlik 'n werkende speelboek skryf op die eerste dag van werk met die produk.

Maar Ansible alleen in 'n produksie-omgewing was nie vir ons genoeg nie. Andersins sou baie probleme ontstaan ​​met die beperking van toegang en die ouditering van die optrede van administrateurs. Hoe om toegang te beperk? Dit was immers vir elke departement nodig om sy eie stel bedieners te bestuur (lees: hardloop die Ansible-speelboek). Hoe om slegs sekere werknemers toe te laat om spesifieke Ansible-speelboeke te laat loop? Of hoe om op te spoor wie die speelboek bekendgestel het sonder om baie plaaslike kennis op te stel op bedieners en toerusting wat Ansible gebruik?

Die grootste deel van sulke kwessies word deur Red Hat opgelos Ansible toring, of sy oopbron-stroomop-projek Ansible AWX. Daarom het ons dit vir die kliënt verkies.

En nog 'n aanraking aan die portret van ons CMS-stelsel. Ansible speelboek moet in kodebewaarplekbestuurstelsels gestoor word. Ons het dit GitLab CE.

Dus, die konfigurasies self word bestuur deur 'n kombinasie van Ansible/Ansible AWX/GitLab (sien Fig. 3). Natuurlik is AWX/GitLab geïntegreer met 'n enkele verifikasiestelsel, en Ansible-speelboek is geïntegreer met HashiCorp Vault. Konfigurasies betree die produksie-omgewing slegs deur Ansible AWX, waarin al die "spelreëls" gespesifiseer word: wie kan wat opstel, waar om die konfigurasiebestuurskode vir die CMS te kry, ens.

Rys. 3. Konfigurasiebestuur.

Toetsbestuur

Ons konfigurasie word in kodevorm aangebied. Daarom word ons gedwing om volgens dieselfde reëls as sagteware-ontwikkelaars te speel. Ons moes die prosesse van ontwikkeling, deurlopende toetsing, aflewering en toepassing van konfigurasiekode op produksiebedieners organiseer.

As dit nie onmiddellik gedoen word nie, sal die rolle wat vir die konfigurasie geskryf is óf ophou om ondersteun en gewysig te word, óf sal ophou om in produksie bekendgestel te word. Die genesing vir hierdie pyn is bekend, en dit het homself bewys in hierdie projek:

• elke rol word deur eenheidstoetse gedek;
• toetse word outomaties uitgevoer wanneer daar enige verandering is in die kode wat die konfigurasies bestuur;
• veranderinge in die konfigurasiebestuurskode word eers in die produksie-omgewing vrygestel nadat alle toetse en kodehersiening suksesvol geslaag is.

Kode-ontwikkeling en konfigurasiebestuur het kalmer en meer voorspelbaar geword. Om deurlopende toetse te organiseer, het ons die GitLab CI/CD-gereedskapstel gebruik en geneem Ansible Molekule.

Wanneer daar 'n verandering in die konfigurasiebestuurskode is, roep GitLab CI/CD Molecule:

• dit kontroleer die kode-sintaksis,
• lig die Docker-houer op,
• pas die gewysigde kode toe op die geskepte houer,
• kontroleer die rol vir idempotensie en voer toetse vir hierdie kode uit (die korreligheid hier is op die moontlike rolvlak, sien Fig. 4).

Ons het konfigurasies aan die produksie-omgewing gelewer deur Ansible AWX te gebruik. Bedryfsingenieurs het konfigurasieveranderinge deur vooraf gedefinieerde sjablone toegepas. AWX het onafhanklik die nuutste weergawe van die kode van die GitLab-meestertak “versoek” elke keer as dit gebruik is. Op hierdie manier het ons die gebruik van ongetoetste of verouderde kode in die produksie-omgewing uitgesluit. Natuurlik het die kode eers na toetsing, hersiening en goedkeuring die meestertak binnegekom.

Rys. 4. Outomatiese toetsing van rolle in GitLab CI/CD.

Daar is ook 'n probleem wat verband hou met die werking van produksiestelsels. In die werklike lewe is dit baie moeilik om konfigurasieveranderinge alleen deur CMS-kode aan te bring. Noodsituasies ontstaan ​​wanneer 'n ingenieur die konfigurasie "hier en nou" moet verander sonder om te wag vir koderedigering, toetsing, goedkeuring, ens.

As gevolg hiervan, as gevolg van handmatige veranderinge, verskyn teenstrydighede in die konfigurasie op dieselfde tipe toerusting (byvoorbeeld, sysctl-instellings word anders opgestel op HA-kluster nodusse). Of die werklike konfigurasie op die toerusting verskil van die een wat in die CMS-kode gespesifiseer word.

Daarom, bykomend tot deurlopende toetsing, gaan ons produksie-omgewings na vir konfigurasie-afwykings. Ons het die eenvoudigste opsie gekies: hardloop die CMS-konfigurasiekode in "droëloop"-modus, dit wil sê sonder om veranderinge toe te pas, maar met kennisgewing van alle verskille tussen die beplande en werklike konfigurasie. Ons het dit geïmplementeer deur gereeld alle Ansible-speelboeke met die "-check"-opsie op produksiebedieners te laat loop. Soos altyd is Ansible AWX verantwoordelik vir die bekendstelling en hou van die speelboek op datum (sien Fig. 5):

Rys. 5. Kontroleer vir konfigurasieafwykings in Ansible AWX.

Na kontrole stuur AWX 'n teenstrydigheidsverslag aan administrateurs. Hulle bestudeer die problematiese konfigurasie en maak dit dan reg deur aangepaste speelboeke. Dit is hoe ons die konfigurasie in die produksie-omgewing handhaaf en die CMS is altyd op datum en gesinchroniseer. Dit skakel onaangename "wonderwerke" uit wanneer CMS-kode op "produksie"-bedieners gebruik word.

Ons het nou 'n belangrike toetslaag wat bestaan ​​uit Ansible AWX/GitLab/Molecule (Figuur 6).

Rys. 6. Toetsbestuur.

Moeilik? Ek stry nie. Maar so 'n kompleks van konfigurasiebestuur het 'n omvattende antwoord geword op baie vrae wat verband hou met die outomatisering van bedienerkonfigurasie. Nou het 'n kleinhandelaar se standaardbedieners altyd 'n streng gedefinieerde konfigurasie. CMS, anders as 'n ingenieur, sal nie vergeet om die nodige instellings by te voeg, gebruikers te skep en dosyne of honderde vereiste instellings uit te voer nie.

Daar is vandag geen “geheime kennis” in die instellings van bedieners en omgewings nie. Alle nodige kenmerke word in die speelboek weerspieël. Geen kreatiwiteit en vae instruksies meer nie: "Installeer dit soos gewone Oracle, maar jy moet 'n paar sysctl-instellings spesifiseer en gebruikers byvoeg met die vereiste UID. Vra die ouens in operasie, hulle weet".

Die vermoë om konfigurasieafwykings op te spoor en proaktief reg te stel, bied gemoedsrus. Sonder 'n konfigurasiebestuurstelsel lyk dit gewoonlik anders. Probleme hoop op totdat dit eendag in produksie "skiet". Daarna word 'n ontlonting gedoen, konfigurasies word nagegaan en reggestel. En die siklus herhaal weer

En natuurlik het ons die bekendstelling van bedieners in werking van 'n paar dae na ure versnel.

Wel, op Oujaarsaand self, toe kinders vreugdevol besig was om geskenke uit te pak en volwassenes wense gemaak het terwyl die klokke geslaan het, het ons ingenieurs die SAP-stelsel na nuwe bedieners gemigreer. Selfs Kersvader sal sê dat die beste wonderwerke dié is wat goed voorberei is.

NS Ons span kom dikwels teë met die feit dat kliënte konfigurasiebestuurprobleme so eenvoudig as moontlik wil oplos. Ideaal gesproke, asof by towerkrag - met een instrument. Maar in die lewe is alles meer ingewikkeld (ja, silwer koeëls is nie weer afgelewer nie): jy moet 'n hele proses skep deur gereedskap te gebruik wat gerieflik is vir die kliënt se span.

Skrywer: Sergey Artemov, departementsargitek DevOps-oplossings "Jet Infosystems"

Bron: will.com