Het naderde het nieuwe jaar. Kinderen in het hele land hadden al brieven naar de Kerstman gestuurd of cadeautjes voor zichzelf gemaakt, en hun belangrijkste executeur, een van de grote detailhandelaren, bereidde zich voor op de apotheose van de verkoop. In december neemt de belasting van het datacenter verschillende keren toe. Daarom besloot het bedrijf het datacenter te moderniseren en enkele tientallen nieuwe servers in gebruik te nemen in plaats van apparatuur die het einde van zijn levensduur bereikte. Dit eindigt het verhaal tegen de achtergrond van wervelende sneeuwvlokken, en de thriller begint.

De apparatuur arriveerde enkele maanden vóór de piek van de verkoop op de locatie. De operationele dienst weet uiteraard hoe en wat hij op de servers moet configureren om deze in de productieomgeving te brengen. Maar we moesten dit automatiseren en de menselijke factor elimineren. Bovendien werden de servers vervangen vóór de migratie van een reeks SAP-systemen die cruciaal waren voor het bedrijf.

De ingebruikname van nieuwe servers was strikt aan een deadline gebonden. En het verplaatsen ervan betekende dat zowel de verzending van een miljard geschenken als de migratie van systemen in gevaar kwamen. Zelfs een team bestaande uit Vadertje Vorst en de Kerstman kon de datum niet wijzigen - je kunt het SAP-systeem voor magazijnbeheer slechts één keer per jaar overzetten. Van 31 december tot 1 januari leggen de enorme magazijnen van de retailer, in totaal zo groot als 20 voetbalvelden, 15 uur lang hun werk stil. En dit is de enige periode waarin het systeem kan worden verplaatst. Bij de introductie van servers was er geen ruimte voor fouten.

Laat ik duidelijk zijn: mijn verhaal weerspiegelt de tools en het configuratiemanagementproces dat ons team gebruikt.

Het configuratiemanagementcomplex bestaat uit verschillende niveaus. Het belangrijkste onderdeel is het CMS-systeem. Bij industrieel gebruik zou de afwezigheid van een van de niveaus onvermijdelijk tot onaangename wonderen leiden.

Beheer van besturingssysteeminstallatie

Het eerste niveau is een systeem voor het beheer van de installatie van besturingssystemen op fysieke en virtuele servers. Het creëert basisconfiguraties van het besturingssysteem, waardoor de menselijke factor wordt geëlimineerd.

Met behulp van dit systeem ontvingen we standaard serverinstances met een besturingssysteem dat geschikt was voor verdere automatisering. Tijdens het “gieten” ontvingen ze een minimale set lokale gebruikers en openbare SSH-sleutels, evenals een consistente OS-configuratie. We konden er zeker van zijn dat we de servers via het CMS zouden beheren en waren er zeker van dat er “down below” op OS-niveau geen verrassingen zouden zijn.

De "maximale" taak voor het installatiebeheersysteem is het automatisch configureren van servers vanaf het BIOS/Firmware-niveau naar het besturingssysteem. Veel hangt hier af van de apparatuur en de installatietaken. Voor heterogene apparatuur kunt u overwegen ROODVIS API. Als alle hardware van één leverancier is, is het vaak handiger om kant-en-klare beheertools te gebruiken (bijvoorbeeld HP ILO Amplifier, DELL OpenManage, etc.).

Om het besturingssysteem op fysieke servers te installeren, hebben we de bekende Cobbler gebruikt, die een reeks installatieprofielen definieert die zijn overeengekomen met de bedieningsservice. Bij het toevoegen van een nieuwe server aan de infrastructuur koppelde de engineer het MAC-adres van de server aan het vereiste profiel in Cobbler. Toen de server voor de eerste keer via het netwerk opstartte, ontving hij een tijdelijk adres en een nieuw besturingssysteem. Vervolgens werd het overgebracht naar de doel-VLAN/IP-adressering en werd daar verder gewerkt. Ja, het veranderen van VLAN kost tijd en vereist coördinatie, maar het biedt extra bescherming tegen onbedoelde installatie van de server in een productieomgeving.

We hebben virtuele servers gemaakt op basis van sjablonen die zijn voorbereid met HashiСorp Packer. De reden was dezelfde: om mogelijke menselijke fouten bij het installeren van het besturingssysteem te voorkomen. Maar in tegenstelling tot fysieke servers elimineert Packer de noodzaak van PXE, het opstarten van het netwerk en VLAN-wijzigingen. Dit heeft het steeds eenvoudiger gemaakt om virtuele servers te creëren.

Rijst. 1. Beheer van de installatie van besturingssystemen.

Geheimen beheren

Elk configuratiebeheersysteem bevat gegevens die voor gewone gebruikers verborgen zouden moeten blijven, maar die nodig zijn om systemen voor te bereiden. Dit zijn wachtwoorden voor lokale gebruikers en serviceaccounts, certificaatsleutels, verschillende API-tokens, enz. Ze worden meestal “geheimen” genoemd.

Als u niet vanaf het allereerste begin bepaalt waar en hoe u deze geheimen moet opslaan, zijn, afhankelijk van de strengheid van de informatiebeveiligingsvereisten, de volgende opslagmethoden waarschijnlijk:

• rechtstreeks in de configuratiecontrolecode of in bestanden in de repository;
• in gespecialiseerde configuratiebeheertools (bijvoorbeeld Ansible Vault);
• in CI/CD-systemen (Jenkins/TeamCity/GitLab/etc.) of in configuratiebeheersystemen (Ansible Tower/Ansible AWX);
• geheimen kunnen ook “handmatig” worden overgedragen. Ze worden bijvoorbeeld op een specifieke locatie neergezet en vervolgens gebruikt door configuratiebeheersystemen;
• verschillende combinaties van bovenstaande.

Elke methode heeft zijn eigen nadelen. De belangrijkste is het gebrek aan beleid voor toegang tot geheimen: het is onmogelijk of moeilijk om te bepalen wie bepaalde geheimen kan gebruiken. Een ander nadeel is het gebrek aan toegangscontrole en een volledige levenscyclus. Hoe vervang je bijvoorbeeld snel een publieke sleutel die in de code en in een aantal gerelateerde systemen geschreven staat?

We gebruikten de gecentraliseerde geheime opslag HashiCorp Vault. Hierdoor konden we:

• geheimen veilig bewaren. Ze zijn gecodeerd en zelfs als iemand toegang krijgt tot de Vault-database (bijvoorbeeld door deze te herstellen vanaf een back-up), zal hij of zij de daarin opgeslagen geheimen niet kunnen lezen;
• beleid voor toegang tot geheimen organiseren. Alleen de geheimen die aan hen zijn “toegewezen” zijn beschikbaar voor gebruikers en applicaties;
• toegang tot geheimen controleren. Alle acties met geheimen worden vastgelegd in het Vault-auditlogboek;
• organiseer een volwaardige ‘levenscyclus’ van het werken met geheimen. Ze kunnen worden aangemaakt, ingetrokken, een vervaldatum instellen, enz.
• eenvoudig te integreren met andere systemen die toegang tot geheimen nodig hebben;
• en gebruik ook end-to-end-codering, eenmalige wachtwoorden voor het besturingssysteem en de database, certificaten van geautoriseerde centra, enz.

Laten we nu verder gaan met het centrale authenticatie- en autorisatiesysteem. Het was mogelijk om zonder te doen, maar het beheren van gebruikers in veel gerelateerde systemen is te triviaal. We hebben authenticatie en autorisatie geconfigureerd via de LDAP-service. Anders zou Vault voortdurend authenticatietokens voor gebruikers moeten uitgeven en bijhouden. En het verwijderen en toevoegen van gebruikers zou een zoektocht worden: "Heb ik dit gebruikersaccount overal aangemaakt/verwijderd?"

We voegen een nieuw niveau toe aan ons systeem: geheimenbeheer en centrale authenticatie/autorisatie:

Rijst. 2. Beheer van geheimen.

Configuratiebeheer

We kwamen tot de kern: het CMS-systeem. In ons geval is dit een combinatie van Ansible en Red Hat Ansible AWX.

In plaats van Ansible kan Chef, Puppet, SaltStack worden gebruikt. We hebben voor Ansible gekozen op basis van verschillende criteria.

• Ten eerste is het veelzijdigheid. Een set kant-en-klare modules voor besturing indrukwekkend. En als je er niet genoeg van hebt, kun je zoeken op GitHub en Galaxy.
• Ten tweede is het niet nodig om agenten op beheerde apparatuur te installeren en te ondersteunen, te bewijzen dat ze de belasting niet verstoren en de afwezigheid van “bladwijzers” te bevestigen.
• Ten derde heeft Ansible een lage toetredingsdrempel. Een competente ingenieur schrijft letterlijk op de eerste dag dat hij met het product werkt een werkend draaiboek.

Maar Ansible alleen in een productieomgeving was voor ons niet genoeg. Anders zouden er veel problemen ontstaan ​​bij het beperken van de toegang en het controleren van de acties van beheerders. Hoe de toegang beperken? Het was immers noodzakelijk dat elke afdeling “zijn eigen” set servers beheerde (lees: het Ansible-playbook draaide). Hoe kan ik toestaan ​​dat alleen bepaalde werknemers specifieke Ansible-playbooks uitvoeren? Of hoe kun je bijhouden wie het draaiboek heeft gelanceerd zonder veel lokale kennis op te zetten over servers en apparatuur waarop Ansible draait?

Het leeuwendeel van dergelijke problemen wordt opgelost door Red Hat Ansible-toren, of zijn open-source upstream-project Ansible AWX. Daarom gaven wij er de voorkeur aan voor de klant.

En nog een keer het portret van ons CMS-systeem. Het Ansible-playbook moet worden opgeslagen in beheersystemen voor coderepository's. We hebben het GitLab CE.

De configuraties zelf worden dus beheerd door een combinatie van Ansible/Ansible AWX/GitLab (zie figuur 3). Uiteraard is AWX/GitLab geïntegreerd met een enkel authenticatiesysteem, en is Ansible playbook geïntegreerd met HashiCorp Vault. Configuraties komen alleen de productieomgeving binnen via Ansible AWX, waarin alle ‘spelregels’ zijn vastgelegd: wie kan wat configureren, waar kan de configuratiebeheercode voor het CMS worden verkregen, enz.

Rijst. 3. Configuratiebeheer.

Testbeheer

Onze configuratie wordt gepresenteerd in codevorm. Daarom zijn we gedwongen om volgens dezelfde regels te spelen als softwareontwikkelaars. We moesten de processen van ontwikkeling, continu testen, levering en toepassing van configuratiecode op productieservers organiseren.

Als dit niet onmiddellijk gebeurt, worden de rollen die voor de configuratie zijn geschreven niet langer ondersteund en aangepast, of worden ze niet meer in productie gelanceerd. De remedie tegen deze pijn is bekend en heeft zichzelf bewezen in dit project:

• elke rol wordt gedekt door unit-tests;
• tests worden automatisch uitgevoerd wanneer er een wijziging is in de code die de configuraties beheert;
• wijzigingen in de configuratiebeheercode worden pas vrijgegeven in de productieomgeving nadat alle tests en codebeoordeling met succes zijn doorstaan.

Codeontwikkeling en configuratiebeheer zijn rustiger en voorspelbaarder geworden. Om continu testen te organiseren, hebben we de GitLab CI/CD-toolkit gebruikt en genomen Ansible Molecuul.

Telkens wanneer er een wijziging is in de configuratiebeheercode, roept GitLab CI/CD Molecule aan:

• het controleert de syntaxis van de code,
• verhoogt de Docker-container,
• past de gewijzigde code toe op de gemaakte container,
• controleert de rol op idempotentie en voert tests uit voor deze code (de granulariteit bevindt zich hier op het niveau van de weerwortrol, zie figuur 4).

We leverden configuraties aan de productieomgeving met behulp van Ansible AWX. Operationele ingenieurs pasten configuratiewijzigingen toe via vooraf gedefinieerde sjablonen. AWX “vroeg” onafhankelijk van elkaar de laatste versie van de code van de GitLab master branch elke keer dat deze werd gebruikt. Zo hebben we het gebruik van ongeteste of verouderde code in de productieomgeving uitgesloten. Uiteraard kwam de code pas in de masterbranch terecht na testen, review en goedkeuring.

Rijst. 4. Automatisch testen van rollen in GitLab CI/CD.

Er is ook een probleem verbonden aan de werking van productiesystemen. In het echte leven is het erg moeilijk om configuratiewijzigingen door te voeren met alleen CMS-code. Er ontstaan ​​noodsituaties wanneer een engineer de configuratie ‘hier en nu’ moet wijzigen, zonder te wachten op codebewerking, testen, goedkeuring, etc.

Als gevolg hiervan verschijnen er, als gevolg van handmatige wijzigingen, verschillen in de configuratie op hetzelfde type apparatuur (sysctl-instellingen zijn bijvoorbeeld anders geconfigureerd op HA-clusterknooppunten). Of de daadwerkelijke configuratie op de apparatuur wijkt af van de configuratie die in de CMS-code staat vermeld.

Daarom controleren we, naast het continue testen, productieomgevingen op configuratieverschillen. We kozen voor de eenvoudigste optie: het uitvoeren van de CMS-configuratiecode in “dry run”-modus, dat wil zeggen zonder wijzigingen door te voeren, maar met melding van alle discrepanties tussen de geplande en daadwerkelijke configuratie. We hebben dit geïmplementeerd door periodiek alle Ansible-playbooks uit te voeren met de optie “—check” op productieservers. Zoals altijd is Ansible AWX verantwoordelijk voor het lanceren en up-to-date houden van het playbook (zie figuur 5):

Rijst. 5. Controleert op configuratieverschillen in Ansible AWX.

Na controles stuurt AWX een discrepantierapport naar beheerders. Ze bestuderen de problematische configuratie en lossen deze vervolgens op via aangepaste draaiboeken. Zo onderhouden wij de configuratie in de productieomgeving en is het CMS altijd up-to-date en gesynchroniseerd. Dit elimineert onaangename “wonderen” wanneer CMS-code wordt gebruikt op “productie”-servers.

We hebben nu een belangrijke testlaag bestaande uit Ansible AWX/GitLab/Molecule (Figuur 6).

Rijst. 6. Testmanagement.

Moeilijk? Ik maak geen ruzie. Maar een dergelijk complex van configuratiebeheer is een alomvattend antwoord geworden op veel vragen met betrekking tot de automatisering van serverconfiguratie. Nu hebben de standaardservers van een retailer altijd een strikt gedefinieerde configuratie. CMS zal, in tegenstelling tot een ingenieur, niet vergeten de nodige instellingen toe te voegen, gebruikers aan te maken en tientallen of honderden vereiste instellingen uit te voeren.

Er bestaat tegenwoordig geen “geheime kennis” in de instellingen van servers en omgevingen. Alle benodigde functionaliteiten zijn terug te vinden in het draaiboek. Geen creativiteit en vage instructies meer: ​​“Installeer het zoals gewoon Oracle, maar u moet een aantal sysctl-instellingen opgeven en gebruikers toevoegen met de vereiste UID. Vraag het aan de jongens van de operatie, zij weten het.

De mogelijkheid om configuratieverschillen te detecteren en deze proactief te corrigeren, zorgt voor gemoedsrust. Zonder configuratiemanagementsysteem ziet dit er doorgaans anders uit. De problemen stapelen zich op totdat ze op een dag in productie ‘schieten’. Vervolgens vindt er een debriefing plaats, worden configuraties gecontroleerd en gecorrigeerd. En de cyclus herhaalt zich opnieuw

En uiteraard hebben we de ingebruikname van servers versneld van enkele dagen naar uren.

Welnu, op oudejaarsavond zelf, toen kinderen vrolijk cadeautjes uitpakten en volwassenen wensen uitten toen het klokkenspel klonk, hebben onze technici het SAP-systeem naar nieuwe servers gemigreerd. Zelfs de Kerstman zal zeggen dat de beste wonderen die zijn die goed voorbereid zijn.

PS Ons team komt vaak tegen dat klanten configuratiemanagementproblemen zo eenvoudig mogelijk willen oplossen. Idealiter, als bij toverslag - met één stuk gereedschap. Maar in het leven is alles ingewikkelder (ja, wonderkogels zijn niet opnieuw geleverd): je moet een heel proces creëren met tools die handig zijn voor het team van de klant.

Auteur: Sergey Artemov, afdelingsarchitect DevOps-oplossingen "Jet-infosystemen"

Bron: www.habr.com