Het was bijna Nieuwjaar. Kinderen in het hele land hadden hun brieven al naar de Kerstman gestuurd of wensen gedaan voor cadeaus, en de belangrijkste uitvoerder daarvan ā een van de grote detailhandelaars ā bereidde zich voor op het hoogtepunt van de verkopen. In december neemt de belasting op zijn datacenter vele malen toe. Daarom besloot het bedrijf het datacenter te moderniseren en tientallen nieuwe servers in gebruik te nemen ter vervanging van apparatuur waarvan de levensduur was verstreken. Na deze inleiding op de achtergrond van flonkerende sneeuwvlokken begint de thriller.
De apparatuur arriveerde enkele maanden voor de piekverkoop. De exploitatieafdeling weet natuurlijk hoe en wat er op de servers moet worden ingesteld om ze in de productieomgeving te nemen. Maar we moesten dit automatiseren en de menselijke factor uitsluiten. Bovendien vervingen de servers de set SAP-systemen, die cruciaal waren voor het bedrijf, vĆ³Ć³r de migratie.
De activering van de nieuwe servers was strikt gebonden aan een deadline. Het verzetten ervan zou de levering van een miljard cadeaus en de migratie van systemen in gevaar brengen. Zelfs het team van de Kerstman of de goede Sint had de datum niet kunnen veranderen ā het migreren van het SAP-systeem voor voorraadbeheer kan namelijk maar Ć©Ć©n keer per jaar gebeuren. Van 31 december op 1 januari stoppen de enorme magazijnen van de detailhandelaar, samen groot als 20 voetbalvelden, 15 uur met hun werkzaamheden. En dat is het enige tijdsvenster voor de migratie van het systeem. We hadden geen speelruimte voor fouten bij het activeren van de servers.
Laat me meteen uitleggen: mijn verhaal weerspiegelt de tools en het proces van configuratiebeheer dat ons team toepast.
Het configuratiebeheersysteem bestaat uit verschillende niveaus. De belangrijkste component is het CMS-systeem. Bij industriƫle werking zou het ontbreken van een van de niveaus onvermijdelijk leiden tot onaangename verrassingen.
Bestuur van de installatie van het besturingssysteem
Het eerste niveau is het systeem voor het beheer van de installatie van besturingssystemen op fysieke en virtuele servers. Het creƫert basisconfiguraties van het besturingssysteem en elimineert de menselijke factor.
Met dit systeem kregen we gestandaardiseerde en voor verdere automatisering geschikte serverinstellingen met een besturingsysteem. Bij de 'uitrol' kregen ze een minimale set van lokale gebruikers en SSH-publieke sleutels, evenals een consistente configuratie van het besturingsysteem. We konden de servers gegarandeerd beheren via een CMS en waren ervan overtuigd dat er 'onder de motorkap', op het niveau van het besturingsysteem, geen verrassingen waren.
De 'maximale' taak voor het installatiebeheersysteem is het automatisch configureren van servers van het BIOS/Firmware niveau tot het besturingssysteem. Veel hangt hier af van de hardware en configuratietaken. Voor heterogene hardware kan men overwegen . Als alle 'hardware' van Ć©Ć©n leverancier afkomstig is, is het vaak handiger om gebruik te maken van kant-en-klare beheertools (bijvoorbeeld HP ILO Amplifier, DELL OpenManage, enzovoort).
Voor de installatie van besturingssystemen op fysieke servers maakten we gebruik van de welbekende Cobbler, waarin een set goedgekeurde installatieprofielen is gedefinieerd. Bij het toevoegen van een nieuwe server aan de infrastructuur koppelde de ingenieur het MAC-adres van de server aan het vereiste profiel in Cobbler. Bij de eerste netboot kreeg de server een tijdelijk adres en een nieuw besturingssysteem. Vervolgens werd hij overgezet naar de doel VLAN/IP-adressering en werd daar verder gewerkt. Ja, het wisselen van VLAN kost tijd en vereist afstemming, maar het biedt extra bescherming tegen onbedoelde installatie van een server in een productieomgeving.
Virtuele servers creƫerden we op basis van sjablonen die werden voorbereid met behulp van HashiCorp Packer. De reden was dezelfde: om mogelijke menselijke fouten bij de installatie van het besturingssysteem te voorkomen. Maar in tegenstelling tot fysieke servers maakt Packer het mogelijk om geen gebruik te maken van PXE, netboot en VLAN-wissels. Dit vereenvoudigde en vergemakkelijkte de creatie van virtuele servers.
Figuur 1. Beheer van de installatie van besturingssystemen.
Beheer van geheimen
Elke configuratiebeheersysteem bevat gegevens die verborgen moeten blijven voor reguliere gebruikers, maar nodig zijn voor het voorbereiden van systemen. Dit zijn wachtwoorden voor lokale gebruikers en service-accounts, certificaatsleutels, allerlei API Tokens, enzovoort. Deze worden meestal 'geheimen' genoemd.
Als vanaf het begin niet wordt bepaald waar en hoe deze geheimen moeten worden opgeslagen, zijn er afhankelijk van de striktheid van de informatiebeveiligingseisen de volgende opslagmethoden waarschijnlijk:
- direct in the configuration management code or in files in the repository;
- in specialized configuration management tools (for example, Ansible Vault);
- in CI/CD systems (Jenkins/TeamCity/GitLab/etc.) or in configuration management systems (Ansible Tower/Ansible AWX);
- secrets can also be transferred through 'manual management'. For example, they are placed in an agreed location and then used by configuration management systems;
- various combinations of the above.
Each method has its drawbacks. The main one is the lack of access policies for secrets: it is difficult to determine who can use certain secrets. Another downside is the absence of access audit and a complete life cycle. How quickly can, for example, a public key be replaced that is written in the code and in several related systems?
We used a centralized secret storage solution from HashiCorp Vault. This allowed us to:
- store secrets securely. They are encrypted, and even if someone gains access to the Vault storage database (for example, by restoring it from a backup), they will not be able to read the secrets stored there;
- organize access policies for secrets. Users and applications have access only to the 'designated' secrets;
- conduct an audit of access to secrets. Any actions with secrets are recorded in the Vault audit log;
- organize a full 'life cycle' for secrets. They can be created, revoked, set to expire, etc.
- easily integrate with other systems that require access to secrets;
- and also apply end-to-end encryption, one-time passwords for OS and databases, certificates from authorized centers, etc.
Now let's move on to the central authentication and authorization system. It could have been done without it, but managing users across multiple supporting systems is too non-trivial. We set up authentication and authorization through the LDAP service. Otherwise, in the same Vault, we would have to continuously issue and keep track of authentication tokens for users. And adding and removing users would turn into the quest: 'have I created/removed this account everywhere?'
Let's add another level to our system: secret management and central authentication/authorization:
Fig. 2. Secret management.
Configuratiebeheer
We zijn aangekomen bij de kern ā het CMS-systeem. In ons geval is dit de combinatie van Ansible en Red Hat Ansible AWX.
Naast Ansible kunnen ook Chef, Puppet en SaltStack worden gebruikt. We hebben Ansible gekozen op basis van verschillende criteria.
- Ten eerste is er de veelzijdigheid. De set kant-en-klare modules voor beheer . En als er iets ontbreekt, kan je het op GitHub en Galaxy zoeken.
- Ten tweede is het niet nodig om agenten op het beheerde apparaat te installeren en te onderhouden, en te bewijzen dat ze de belasting niet beĆÆnvloeden en te bevestigen dat er geen 'achterdeurtjes' zijn.
- Ten derde heeft Ansible een lage instapdrempel. Een bekwame ingenieur kan binnen de eerste werkdag een werkende playbook schrijven.
Maar alleen Ansible was niet voldoende in een industriĆ«le omgeving. Anders zouden er veel problemen ontstaan met toegangsbeperkingen en het auditen van de acties van beheerders. Hoe deel je de toegang? Het was nodig dat elke afdeling beheer (lees ā het uitvoeren van Ansible playbook) had over 'hun' set servers. Hoe stel je in dat specifieke Ansible playbooks alleen door bepaalde medewerkers kunnen worden uitgevoerd? Of hoe volg je op wie een playbook heeft uitgevoerd, zonder veel lokale gebruikersaccounts op servers en apparatuur onder Ansible te creĆ«ren?
Een groot deel van dergelijke vragen wordt opgelost door Red Hat , of zijn open-source upstream project . Daarom hebben we het gekozen voor de klant.
En nog een aspect van het profiel van ons CMS-systeem. Ansible playbooks moeten worden opgeslagen in code repository-beheersystemen. Voor ons is dit .
Dus de configuraties worden beheerd door de combinatie van Ansible/Ansible AWX/GitLab (zie Figuur 3). Uiteraard zijn AWX/GitLab geĆÆntegreerd met een enkel authenticatiesysteem, terwijl Ansible playbooks zijn verbonden met HashiCorp Vault. Configuraties komen alleen in de productieomgeving via Ansible AWX, waarin alle 'spelregels' zijn ingesteld: wie wat kan configureren, waar de code voor configuratiebeheer voor het CMS vandaan komt, enzovoort.
Figuur 3. Configuratiebeheer.
Testbeheer
Onze configuratie wordt gepresenteerd in de vorm van code. Daarom moeten wij ons houden aan dezelfde regels als softwareontwikkelaars. We moesten processen voor ontwikkeling, continue testing, levering en toepassing van configuratiecode op productie-servers organiseren.
Als dit niet meteen wordt gedaan, zouden de geschreven rollen voor de configuratie ofwel niet meer ondersteund en aangepast worden, ofwel zouden ze stoppen met draaien in productie. De oplossing voor deze pijn is bekend en heeft zich in dit project bewezen:
- elke rol is gedekt met modulaire tests;
- de tests worden automatisch uitgevoerd bij elke wijziging in de code die de configuraties beheert;
- wijzigingen in de code voor het beheer van configuraties komen pas in de productieomgeving nadat ze succesvol alle tests en codebeoordelingen hebben doorstaan.
De ontwikkeling van code en het beheer van configuraties zijn rustiger en voorspelbaarder geworden. Voor het organiseren van continue testing hebben we GitLab CI/CD-tools gebruikt, en als testframework hebben we gekozen voor .
Bij elke wijziging in de code voor het beheer van configuraties roept GitLab CI/CD Molecule aan:
- dit controleert de syntaxis van de code,
- start een Docker-container,
- past de gewijzigde code toe in de aangemaakte container,
- controleert de rol op idempotentie en voert tests uit voor deze code (de granulariteit hier is op het niveau van de ansible rol, zie Figuur 4).
Configuraties in de productieomgeving hebben we geleverd met behulp van Ansible AWX. De ingenieurs die verantwoordelijk zijn voor de exploitatie maakten wijzigingen in de configuratie via vooraf gedefinieerde sjablonen. AWX vroeg bij elke toepassing automatisch de laatste versie van de code op van de masterbranch van GitLab. Zo uitsloten we het gebruik van ongecontroleerde of verouderde code in de productieomgeving. Natuurlijk kwam de code in de masterbranch alleen na testen, beoordeling en goedkeuring.
Figuur 4. Automatische testing van rollen in GitLab CI/CD.
Er is ook nog een probleem met de exploitatie van productie systemen. In de praktijk is het erg moeilijk om wijzigingen in de configuratie alleen via de CMS-code aan te brengen. Er ontstaan noodsituaties waarbij de ingenieur de configuratie 'hier en nu' moet wijzigen, zonder te wachten op aanpassing van de code, testen, goedkeuring, enz.
Als gevolg hiervan ontstaan door handmatige wijzigingen verschillen in de configuratie op soortgelijke apparatuur (bijvoorbeeld, op HA-cluster knooppunten verschillende configuraties van sysctl-instellingen). Of de werkelijke configuratie op de apparatuur wijkt af van diegene die in de CMS-code is gespecificeerd.
Daarom controleren we naast voortdurende tests de productieomgevingen op afwijkingen in configuraties. We hebben de eenvoudigste optie gekozen: het uitvoeren van de configuratiecode van de CMS in de modus 'dry run', dat wil zeggen zonder wijzigingen door te voeren, maar met een melding van alle afwijkingen tussen de geplande en de werkelijke configuratie. We hebben dit gerealiseerd met behulp van periodieke uitvoeringen van alle Ansible-playbooks met de optie '--check' op de productie-servers. Ansible AWX is, zoals altijd, verantwoordelijk voor de uitvoering en actualiteit van de playbooks (zie Figuur 5):
Figuur 5. Controle op afwijkingen in configuraties in Ansible AWX.
Na de controles verstuurt AWX een rapport over de afwijkingen naar de beheerders. Zij bestuderen de problematische configuratie en corrigeren deze vervolgens via gecorrigeerde playbooks. Zo houden we de configuratie in de productieomgeving up-to-date, en is de CMS altijd in een actuele en gesynchroniseerde staat. Dit voorkomt onaangename 'wonderen' wanneer de CMS-code wordt toegepast op de 'live' servers.
Nu hebben we een belangrijk testniveau dat bestaat uit Ansible AWX/GitLab/Molecule (Figuur 6).
Figuur 6. Testbeheer.
Lastig? Daar ben ik het mee eens. Maar zo'n complexe configuratiebeheer is een allesomvattend antwoord op veel vragen die samenhangen met de automatisering van serverconfiguraties. Nu heeft de retailer voor standaardservers altijd een strikt gedefinieerde configuratie. De CMS zal, in tegenstelling tot een ingenieur, niet vergeten de noodzakelijke instellingen toe te voegen, gebruikers aan te maken en tientallen of honderden vereiste instellingen uit te voeren.
In de instellingen van servers en omgevingen zijn er vandaag de dag geen 'verborgen kennis'. Alle noodzakelijke kenmerken zijn vastgelegd in de playbooks. Geen creativiteit meer en vage instructies: 'stel in als een gewone Oracle, maar dan moeten er een paar sysctl-instellingen worden vastgelegd, en gebruikers met de juiste UID moeten worden toegevoegd. Vraag het de jongens van exploitatie, zij weten het.Ā».
De mogelijkheid om afwijkingen in configuraties te ontdekken en deze van tevoren te corrigeren geeft rust. Zonder een configuratiebeheersysteem ziet het er doorgaans anders uit. Problemen stapelen zich op totdat ze op een dag in productie 'ontploffen'. Daarna wordt er een evaluatie gedaan, worden configuraties gecontroleerd en gecorrigeerd. En de cyclus herhaalt zich weer.
En natuurlijk hebben we de inbedrijfstelling van servers versneld van enkele dagen naar enkele uren.
Op de oudejaarsnacht, wanneer kinderen blij hun cadeaus uitpakken en volwassenen wensen onder het geslinger van de klokken, migreerden onze ingenieurs het SAP-systeem naar nieuwe servers. Zelfs de Kerstman zou zeggen dat de beste wonderen goed voorbereid zijn.
P.S. Ons team komt vaak tegen dat klanten zo eenvoudig mogelijk de configuratiebeheer-taak willen oplossen. Idealiter als bij magie ā met Ć©Ć©n tool. Maar in de praktijk is alles ingewikkelder (ja, er zijn weer geen zilveren kogels geleverd): we moeten een volledig proces opzetten met behulp van handige tools voor het team van de klant.
Auteur: Sergey Artemov, architect van de afdeling InfoSystemen Jet
Bron: habr.com
