Året nærmede sig nytår. Børnene i hele landet havde allerede sendt breve til Julemanden eller ønsket sig gaver, og hovedpersonen bag dem — en af de store detailhandlere — gjorde sig klar til salgets kulmination. I december stiger belastningen på deres datacenter flere gange. Derfor besluttede virksomheden at opgradere datacentret og sætte flere dusin nye servere i drift i stedet for udstyr, hvis levetid var udløbet. Her ender fortællingen, mens snefnuggene svæver omkring, og thrillerens begyndelse tager fat.

Udstyret ankom til lokationen flere måneder før salgstoppen. Driftsafdelingen ved selvfølgelig, hvordan man konfigurerer serverne for at få dem i produktion. Men vi havde brug for at automatisere dette og eliminere den menneskelige faktor. Derudover erstattede serverne et system af SAP, som var kritisk vigtigt for virksomheden, inden migrationen.

Aktiveringen af de nye servere var strengt knyttet til en deadline. At flytte dén ville have sat både udleveringen af milliarder gaver og systemmigreringen i fare. Selv Julemandens og Santa Claus' team kunne ikke ændre datoen — SAP-systemet til lagerstyring kan kun flyttes én gang om året. Fra den 31. december til den 1. januar stopper de enorme lagre hos detailhandleren, til sammen på størrelse med 20 fodboldbaner, deres arbejde i 15 timer. Og det er den eneste tidsramme til at flytte systemet. Vi havde ikke råd til fejl med aktiveringen af serverne.

Lad mig straks forklare: Min fortælling afspejler det værktøj og den proces til konfiguration management, som vores team anvender.

Konfiguration management-systemet består af flere lag. Den centrale komponent er CMS-systemet. I industriel drift ville fraværet af et af lagene uundgåeligt føre til ubehagelige overraskelser.

Håndtering af OS-installation

Det første niveau er systemet til håndtering af installation af operativsystemer på fysiske og virtuelle servere. Det skaber grundlæggende OS-konfigurationer, hvilket eliminerer den menneskelige faktor.

Med dette system kunne vi opnå standardiserede og automatiserbare eksemplarer af servere med OS. Ved 'udrulning' modtog de et minimum af lokale brugere og offentlige SSH-nøgler samt en enhedskonfiguration af OS. Vi kunne garanteret styre serverne via CMS og var sikre på, at der ikke var nogen overraskelser 'dernede', på OS-niveau.

Maksimal opgave for installationsstyringssystemet er automatisk at konfigurere servere fra BIOS/Firmware til OS. Meget afhænger af hardwaren og konfigurationsopgaverne. For heterogen hardware kan man overveje REDFISH API. Hvis alt 'hardware' er fra én leverandør, er det ofte lettere at bruge eksisterende administrationsværktøjer (f.eks. HP ILO Amplifier, DELL OpenManage osv.).

Til installation af OS på fysiske servere anvendte vi den velkendte Cobbler, hvor der er defineret en række profiler for installationen, der er aftalt med driftsafdelingen. Ved tilføjelse af en ny server til infrastrukturen knyttede ingeniøren MAC-adressen for serveren til den ønskede profil i Cobbler. Ved første netboot fik serveren en midlertidig adresse og et friskt OS. Derefter blev den flyttet til den ønskede VLAN/IP-adressere og fortsatte arbejdet der. Ja, ændringen af VLAN tager tid og kræver koordinering, men det giver ekstra beskyttelse mod utilsigtet installation af serveren i produktionsmiljøet.

Virtuelle servere blev skabt ud fra skabeloner forberedt med HashiCorp Packer. Årsagen var den samme: at forhindre mulige menneskelige fejl ved installationen af OS. Men i modsætning til fysiske servere tillader Packer ikke brug af PXE, netværksboot og ændring af VLAN. Det lettede og forenklede oprettelsen af virtuelle servere.

Fig. 1. Administration af installationen af operativsystemer.

Håndtering af hemmeligheder

Enhver konfigurationsstyringssystem indeholder data, der skal skjules for almindelige brugere, men som er nødvendige for systemforberedelse. Det drejer sig om adgangskoder til lokale brugere og servicekonti, certifikatnøgler, forskellige API-tokens osv. De kaldes normalt 'hemmeligheder'.

Hvis man ikke fra begyndelsen definerer, hvor og hvordan disse hemmeligheder skal opbevares, afhængigt af hvor strenge informationssikkerhedskravene er, kan de mulige opbevaringsmetoder være:

• direkte i konfigurationsstyringskoden eller i filer i depotet;
• i specialiserede værktøjer til konfigurationsstyring (f.eks. Ansible Vault);
• i CI/CD-systemer (Jenkins/TeamCity/GitLab osv.) eller i konfigurationsstyringssystemer (Ansible Tower/Ansible AWX);
• desuden kan hemmeligheder overføres via 'manuelle' metoder. For eksempel kan de lægges på et aftalt sted, hvorefter de bruges af konfigurationsstyringssystemer;
• forskellige kombinationer af de ovenstående metoder.

Hver metode har sine ulemper. Den vigtigste er manglen på adgangspolitikker til hemmeligheder: det er ikke muligt eller svært at bestemme, hvem der kan bruge hvilke hemmeligheder. En anden ulempe er manglen på adgangsaudit og en fuld livscyklus. Hvordan kan man hurtigt skifte et eksempelvis offentligt nøgle, som er angivet i koden og i en række tilknyttede systemer?

Vi har brugt et centralt hemmelighedslager fra HashiCorp Vault. Det har gjort det muligt for os at:

• opbevare hemmeligheder sikkert. De er krypteret, og selv hvis nogen får adgang til databasen i Vault (f.eks. ved at gendanne den fra en sikkerhedskopi), kan de ikke læse de hemmeligheder, der opbevares der;
• organisere adgangspolitikker til hemmeligheder. Brugere og applikationer har kun adgang til de hemmeligheder, der er 'tildelt' dem;
• foretage adgangsaudit til hemmeligheder. Enhver handling med hemmeligheder registreres i Vault's revisionslog;
• organisere en fuld 'livscyklus' for arbejde med hemmeligheder. De kan oprettes, tilbagekaldes, have udløbsdatoer osv.
• let integreres med andre systemer, der har brug for adgang til hemmeligheder;
• og endda anvende ende-til-ende kryptering, engangskoder til OS og databaser, certifikater fra bemyndigede myndigheder osv.

Lad os nu gå videre til det centrale system for autentifikation og autorisation. Man kunne have klaret sig uden det, men administration af brugere i mange relaterede systemer er alt for komplekst. Vi har konfigureret autentifikation og autorisation gennem LDAP-tjenesten. Ellers ville vi i Vault skulle udstede og holde styr på autentifikationstokener for brugerne kontinuerligt. At tilføje og fjerne brugere ville have blevet til et eventyr: 'Har jeg husket at oprette/fjerne denne bruger overalt?'

Vi tilføjer endnu et niveau til vores system: styring af hemmeligheder samt central autentifikation/autorisation:

Fig. 2. Styring af hemmeligheder.

Konfigurationsstyring

Vi er kommet til kernen — til CMS-systemet. I vores tilfælde er det kombinationen af Ansible og Red Hat Ansible AWX.

Alternativt kan Chef, Puppet eller SaltStack anvendes i stedet for Ansible. Vi valgte Ansible af flere grunde.

• For det første er det alsidighed. Sættet af færdige moduler til administration giver et imponerende indtryk. Og hvis det ikke er tilstrækkeligt, kan man finde mere på GitHub og Galaxy.
• For det andet er der ingen behov for at installere og vedligeholde agenter på den administrerede hardware, overbevise om, at de ikke forstyrrer belastningen, og bekræfte fraværet af "bagdøre".
• For det tredje har Ansible en lav indgangsbarriere. En dygtig ingeniør kan skrive en fungerende playbook bogstaveligt talt den første dag med produktet.

Men Ansible alene var ikke tilstrækkeligt i et produktionsmiljø. Ellers ville der opstå mange problemer med adgangskontrol og revision af administratorers handlinger. Hvordan kan man begrænse adgangen? For det var nødvendigt at hvert team skulle styre (læs: køre Ansible playbook) deres eget sæt servere. Hvordan kan man tillade udførelse af bestemte Ansible playbooks kun til bestemte medarbejdere? Eller hvordan kan man spore, hvem der har kørt en playbook uden at oprette mange lokale brugerkonti på serverne og udstyret, der styres af Ansible?

De fleste af disse spørgsmål løses af Red Hat Ansible Tower, eller dets open-source upstream projekt Ansible AWX. Derfor valgte vi det til kunden.

Og endnu et aspekt af vores CMS-system. Ansible playbooks skal opbevares i systemer til kodeopbevaring. Vi bruger GitLab CE.

Så konfigurationerne styres af kombinationen af Ansible/Ansible AWX/GitLab (se Fig. 3). Selvfølgelig er AWX/GitLab integreret med et fælles autentifikationssystem, og Ansible playbook er integreret med HashiCorp Vault. Konfigurationer går kun i produktion via Ansible AWX, hvor alle "spileregler" er fastsat: hvem og hvad kan konfigurere, hvor der hentes kode til konfigurationsstyring til CMS osv.

Fig. 3. Konfigurationsstyring.

Teststyring

Vores konfiguration præsenteres i form af kode. Derfor er vi tvunget til at spille efter de samme regler som softwareudviklere. Vi var nødt til at organisere processerne for udvikling, kontinuerlig test, levering og anvendelse af konfigurationskoden på produktionsservere.

Hvis dette ikke gøres straks, ville de skrevne roller til konfigurationen enten holde op med at understøtte og ændre eller stoppe med at køre i produktion. Løsningen på denne smerte er kendt og har vist sig at være effektiv i dette projekt:

• hver rolle er dækket af modulære tests;
• testene køres automatisk ved enhver ændring i koden, der styrer konfigurationerne;
• ændringer i koden, der styrer konfigurationerne, kommer kun i produktion, efter at alle tests og code review er bestået.

Udviklingen af koden og forvaltningen af konfigurationerne er blevet mere rolig og forudsigelig. For at sikre kontinuerlig testning brugte vi GitLab CI/CD-værktøjet, og som framework til at organisere testene valgte vi Ansible Molecule.

Ved enhver ændring i koden, der styrer konfigurationerne, kalder GitLab CI/CD Molecule:

• den kontrollerer syntaksen af koden,
• starter en Docker-container,
• anvender den ændrede kode i den oprettede container,
• kontrollerer rollen for idempotens og kører tests for denne kode (granulariteten her er på niveauet ansible role, se Fig. 4).

Vi leverede konfigurationer til produktionsmiljøet ved hjælp af Ansible AWX. Ingeniører, der er ansvarlige for driften, anvendte ændringerne i konfigurationen gennem foruddefinerede skabeloner. AWX anmodede automatisk om den seneste version af koden fra master-grenen i GitLab ved hvert anvendelse. Dette eliminerede brugen af uafprøvet eller forældet kode i produktionsmiljøet. Selvfølgelig kom koden i master-grenen først efter test, gennemgang og godkendelse.

Fig. 4. Automatisk test af roller i GitLab CI/CD.

Der er også et problem relateret til drift af produktionssystemer. I virkeligheden er det meget svært at foretage ændringer i konfigurationen kun gennem CMS-koden. Der opstår nødsituationer, hvor en ingeniør skal ændre konfigurationen 'her og nu', uden at vente på koderevision, testning, godkendelse osv.

Som et resultat af manuelle ændringer opstår der forskelle i konfigurationen på ensartet udstyr (for eksempel har noderne i HA-klyngen forskellige sysctl-indstillingskonfigurationer). Eller den reelle konfiguration på udstyret adskiller sig fra den, der er angivet i CMS-koden.

Derfor, ud over den kontinuerlige testning, tjekker vi produktionsmiljøerne for forskelle i konfigurationerne. Vi valgte den enkleste løsning: at køre CMS-konfigurationskoden i "dry run"-tilstand, det vil sige uden at anvende ændringer, men med underretning om alle forskelle mellem den planlagte og den faktiske konfiguration. Vi har implementeret dette ved hjælp af periodiske kørsel af alle Ansible playbooks med "—check"-muligheden på produktionsserverne. Som altid er Ansible AWX ansvarlig for udførelsen og aktualiteten af playbooks (se Fig. 5):

Fig. 5. Kontrol af konfigurationsforskelle i Ansible AWX.

Efter kontrollerne sender AWX en rapport om forskellene til administratorerne. De analyserer den problematiske konfiguration og retter derefter op på den gennem korrigerede playbooks. Sådan opretholder vi konfigurationen i produktionsmiljøet, og CMS er altid i en aktuel og synkroniseret tilstand. Det forhindrer ubehagelige "mirakler", hvor CMS-koden anvendes på "live" servere.

Nu har vi fået et vigtigt testniveau bestående af Ansible AWX/GitLab/Molecule (Fig. 6).

Fig. 6. Styring af testning.

Svært? Jeg vil ikke bestride det. Men sådan en kompleks styring af konfigurationer er blevet et udtømmende svar på mange spørgsmål relateret til automatiseringen af serveropsætning. Nu har detailhandleren altid en strengt defineret konfiguration for typiske servere. CMS vil, i modsætning til ingeniøren, ikke glemme at tilføje de nødvendige indstillinger, oprette brugere og udføre titusinder eller hundreder af nødvendige indstillinger.

I opsætningerne af servere og miljøer i dag findes der ikke "hemmelig viden". Alle nødvendige funktioner er afspejlet i playbooks. Ingen mere kreativitet og tvetydige instrukser: "sæt det op som en almindelig Oracle, men der skal skrives et par sysctl-indstillinger, og brugere med den nødvendige UID skal tilføjes. Spørg drengene fra driftsafdelingen, de ved besked.».

Muligheden for at opdetectere konfigurationsforskelle og rette dem på forhånd giver en følelse af ro. Uden et konfigurationstyringssystem ser det normalt anderledes ud. Problemer ophobes indtil de en dag "exploderer" i produktionen. Derefter foretages der en efterfølgende analyse, kontrolleres og rettes konfigurationerne. Og cyklussen gentages igen.

Og selvfølgelig har vi reduceret opsætningstiden for servere fra flere dage til timer.

Men på selve nytårsaften, da børnene gladeligt åbnede gaverne og de voksne stillede ønsker under klokkenes slag, migrerede vores ingeniører SAP-systemet til nye servere. Selv Julemanden ville sige, at de bedste mirakler er godt forberedte.

P.S. Vores team møder ofte, at kunderne ønsker at løse opgaven med konfigurationstyring så enkelt som muligt. Ideelt set som ved et trylleslag — med ét værktøj. Men i virkeligheden er alt mere komplekst (ja, igen er sølvkuglerne ikke ankommet): vi må skabe en hel proces ved hjælp af de værktøjer, der er behagelige for kundens team.

Forfatter: Sergey Artemov, afdelingens arkitekt DevOps-løsninger «Infosystemer Jet»

Kilde: habr.com