Det närmade sig nyår. Barnen i hela landet hade redan skickat sina brev till Jultomten eller önskat sig presenter, och den främsta aktören — en av de stora återförsäljarna — förberedde sig för försäljningens apoteos. I december ökar belastningen på deras datacenter flera gånger om. Därför beslutade företaget att modernisera datacentret och ta i drift flera dussin nya servrar istället för utrustning vars livslängd hade nått slutet. Här slutar berättelsen mot bakgrund av snurrande snöflingor, och en thriller börjar.

Utrustningen kom till platsen flera månader innan försäljningstoppen. Driftavdelningen vet självklart hur man ställer in servrarna för att sätta dem i produktionsmiljö. Men vi behövde automatisera detta och eliminera den mänskliga faktorn. Dessutom ersatte servrarna en uppsättning av kritiskt viktiga SAP-system inför migreringen för företaget.

Inverkan av de nya servrarna var strikt kopplad till en deadline. Att flytta på den skulle sätta både utskicken av en miljard presenter och migreringen av systemen i fara. Inte ens ett team bestående av Jultomten och Santa Claus skulle kunna ändra datumet — överflyttningen av SAP-systemet för lagerhantering kan endast göras en gång om året. Mellan den 31 december och 1 januari stänger de enorma lagren hos återförsäljaren, som sammanlagt är som 20 fotbollsplaner, sin verksamhet i 15 timmar. Och detta är den enda tidsperioden för systemets flytt. Vi hade ingen marginal för fel vid införandet av servrarna.

Låt mig förklara direkt: min berättelse återspeglar det verktyg och den process för konfigurationshantering som vårt team använder.

Konfigurationshanteringssystemet består av flera nivåer. Den centrala komponenten är CMS-systemet. I industriell drift skulle frånvaron av en av nivåerna ofrånkomligen leda till obehagliga överraskningar.

Hantera installationen av operativsystem

Den första nivån är systemet för hantering av installationen av operativsystem på fysiska och virtuella servrar. Det skapar grundkonfigurationer av OS och eliminerar den mänskliga faktorn.

Med detta system fick vi typiska och för framtida automatisering användbara exemplar av servrar med operativsystem. Vid "utdelning" fick de en minimal uppsättning lokala användare och offentliga SSH-nycklar, samt en överenskommen konfiguration av operativsystemet. Vi kunde garantera styrning av servrarna via CMS och var säkra på att det inte fanns några överraskningar "när nere", på operativsystemnivå.

Maximalt mål för installationshanteringssystemet är att automatiskt konfigurera servrar från BIOS/Firmware-nivå till operativsystemet. Mycket beror här på hårdvara och konfigurationsuppgifter. För heterogen hårdvara kan man överväga REDFISH API. Om all "hårdvara" kommer från en och samma leverantör är det ofta bekvämare att använda färdiga hanteringsverktyg (t.ex. HP ILO Amplifier, DELL OpenManage osv.).

För installation av operativsystem på fysiska servrar använde vi det välkända Cobbler, där en uppsättning av överenskomna installationsprofiler definieras med driftavdelningen. När en ny server läggs till infrastrukturen kopplade ingenjören MAC-adressen för servern till den nödvändiga profilen i Cobbler. Vid första nätverksstart fick servern en tillfällig adress och en ny operativsystem. Därefter flyttades den till den avsedda VLAN/IP-adresseringen och fortsatte sitt arbete där. Ja, bytet av VLAN tar tid och kräver samordning, men det ger ytterligare skydd mot oavsiktlig installation av en server i produktionsmiljön.

Vi skapade virtuella servrar baserat på mallar, förberedda med hjälp av HashiCorp Packer. Anledningen var densamma: att förhindra potentiella mänskliga fel vid installation av operativsystem. Men till skillnad från fysiska servrar tillåter Packer att man inte behöver använda PXE, nätverksstart och VLAN-byte. Detta underlättade och förenklade skapandet av virtuella servrar.

Fig. 1. Hantering av installation av operativsystem.

Hantera hemligheter

Alla konfigurationshanteringssystem innehar data som ska döljas för vanliga användare, men som behövs för systemförberedelse. Detta inkluderar lösenord för lokala användare och tjänstekonton, certifikatnycklar, olika API-tokens osv. De kallas vanligtvis "hemligheter".

Om man inte från början bestämmer var och hur man ska lagra dessa hemligheter, så finns det, beroende på strängheten i informationssäkerhetskraven, flera möjliga lagringsmetoder:

• direkt i konfigurationshanteringskoden eller i filerna i repositoryt;
• i specialiserade verktyg för konfigurationshantering (t.ex. Ansible Vault);
• i CI/CD-system (Jenkins/TeamCity/GitLab/ etc.) eller i konfigurationshanteringssystem (Ansible Tower/Ansible AWX);
• också kan hemligheter överföras med "manuell hantering". Till exempel läggs de ut på en överenskommen plats och används sedan av konfigurationshanteringssystem;
• olika kombinationer av ovanstående.

Varje metod har sina nackdelar. Den största är avsaknaden av åtkomstpolitiker för hemligheter: det går inte att eller är svårt att bestämma vem som kan använda vissa hemligheter. En annan nackdel är bristen på åtkomstrevision och en fullständig livscykel. Hur snabbt kan man byta ut, till exempel, en offentlig nyckel som är inskriven i koden och i flera angränsande system?

Vi har använt det centrala hemlagret HashiCorp Vault. Det har gjort att vi kan:

• lagra hemligheter säkert. De är krypterade, och även om någon får tillgång till databasen i Vault-lagret (t.ex. återställer den från en säkerhetskopia), kan de inte läsa de hemligheter som lagras där;
• organisera åtkomstpolitiker för hemligheter. Användare och applikationer har endast tillgång till de hemligheter som "tilldelats" dem;
• genomföra revision av åtkomst till hemligheter. Alla åtgärder med hemligheter registreras i Vaults revisionslogg;
• organisera en fullständig "livscykel" för arbete med hemligheter. De kan skapas, återkallas, sättas med en utgångstid osv.
• enkelt integrera med andra system som behöver åtkomst till hemligheter;
• och också tillämpa end-to-end-kryptering, engångslösenord för OS och databaser, certifikat från auktoriserade centra osv.

Nu går vi vidare till det centrala autentiserings- och auktoriseringssystemet. Det skulle ha gått utan det, men att administrera användare i många närstående system är för komplicerat. Vi har ställt in autentisering och auktorisering via LDAP-tjänsten. Annars skulle det i Vault ha krävts ett kontinuerligt utfärdande och uppföljning av autentiseringstokens för användarna. Att ta bort och lägga till användare skulle ha förvandlats till ett äventyr: "har jag skapat/ tagit bort detta konto överallt?"

Vi lägger till ytterligare ett lager i vårt system: hantering av hemligheter och central autentisering/auktorisering:

Fig. 2. Hantering av hemligheter.

Konfigurationhantering

Vi har kommit till kärnan - till CMS-systemet. I vårt fall är det en kombination av Ansible och Red Hat Ansible AWX.

Istället för Ansible kan Chef, Puppet eller SaltStack användas. Vi valde Ansible av flera anledningar.

• För det första är det mångsidighet. Utbudet av färdiga moduler för hantering imponerar.Om det skulle saknas något kan man leta på GitHub och Galaxy.
• För det andra behöver man inte installera och underhålla agenter på den hanterade utrustningen, bevisa att de inte påverkar belastningen och bekräfta att det inte finns några "bakdörrar".
• För det tredje har Ansible en låg inlärningströskel. En kunnig ingenjör kan skriva en fungerande playbook redan första dagen med produkten.

Men bara Ansible räcker inte i industriella miljöer. Annars skulle det uppstå många problem med åtkomstbegränsningar och granskning av administratörernas åtgärder. Hur ska man avgränsa åtkomsten? Det behövdes så att varje avdelning hanterade (läs - körde Ansible playbooks) "sitt" set av servrar. Hur ska man tillåta att endast vissa anställda får köra specifika Ansible playbooks? Eller hur ska man spåra vem som körde en playbook utan att skapa många lokala användarkonton på servrar och utrustning som hanteras av Ansible?

Det mesta av sådana frågor löses av Red Hat Ansible Tower, eller dess open-source upstream-projekt Ansible AWX. Därför föredrog vi det för kunden.

Och ytterligare en detalj om vår CMS-system. Ansible playbook måste lagras i kodhanteringssystem. I vårt fall är det GitLab CE.

Så konfigurationerna hanteras av en kombination av Ansible/Ansible AWX/GitLab (se Fig. 3). Naturligtvis är AWX/GitLab integrerade med ett enhetligt autentiseringssystem, och Ansible playbook är kopplad till HashiCorp Vault. Konfigurationerna går in i produktionsmiljön endast genom Ansible AWX, där alla "spelregler" anges: vem som kan konfigurera vad, varifrån man tar kod för konfigurationerna för CMS osv.

Fig. 3. Konfigurationhantering.

Testhantering

Vår konfiguration representeras som kod. Därför tvingas vi spela efter samma regler som programvaruutvecklarna. Vi behövde organisera processer för utveckling, kontinuerlig testning, leverans och tillämpning av konfigurationskod på produktionsservrar.

Om detta inte görs direkt, slutar de skrivna rollerna för konfigurationen antingen att stödjas och förändras, eller så slutar de att köras i produktion. Botemedlet för denna smärta är välkänt, och det har visat sig framgångsrikt i detta projekt:

• varje roll är täckt av modulära tester;
• testerna körs automatiskt vid varje ändring i koden som hanterar konfigurationerna;
• ändringar i koden som hanterar konfigurationer går i produktion endast efter att alla tester och code review har genomförts med framgång.

Utvecklingen av kod och hantering av konfigurationer har blivit lugnare och mer förutsägbar. För att organisera kontinuerlig testning använde vi GitLab CI/CD-verktyg, och som ramverk för att organisera tester valde vi Ansible Molecule.

Vid varje ändring i koden som hanterar konfigurationer anropar GitLab CI/CD Molecule:

• den kontrollerar syntaxen i koden,
• startar en Docker-behållare,
• tillämpa den ändrade koden i den skapade behållaren,
• kontrollerar rollen för idempotens och kör tester för denna kod (granularitet här är på nivån ansible-roll, se Fig. 4).

Vi levererade konfigurationer till produktion med hjälp av Ansible AWX. Ansvarsfulla ingenjörer för drift tillämpade ändringar i konfigurationen genom på förhand bestämda mallar. AWX begärde automatiskt den senaste versionen av koden från master-grenen i GitLab vid varje tillämpning. Så uteslöt vi användningen av icke-kontrollerad eller föråldrad kod i produktion. Naturligtvis kom koden till master-grenen endast efter testning, granskning och godkännande.

Fig. 4. Automatiserad testning av roller i GitLab CI/CD.

Det finns också ett problem relaterat till driften av produktionssystem. I verkliga livet är det mycket svårt att göra ändringar i konfigurationen endast genom CMS-kod. Det uppstår nödsituationer där ingenjören måste ändra konfigurationen "här och nu", utan att vänta på kodändringar, testning, godkännande osv.

Som ett resultat av manuella förändringar uppstår skillnader i konfigurationen på liknande utrustning (till exempel har noderna i HA-klustret olika sysctl-konfigurationer). Eller så skiljer sig den verkliga konfigurationen på utrustningen från den som anges i CMS-koden.

Därför, utöver kontinuerlig testning, kontrollerar vi produktionsmiljöerna för att upptäcka konfigurationsavvikelser. Vi valde det enklaste alternativet: att köra kodkonfigurationen för CMS i "dry run"-läge, vilket innebär utan att tillämpa ändringar men med meddelande om alla avvikelser mellan den planerade och den verkliga konfigurationen. Vi implementerade detta genom periodiska körningar av alla Ansible-playbooks med alternativet "--check" på produktionsservrarna. För körning och aktualitet av playbooks ansvarar alltid Ansible AWX (se Fig. 5):

Fig. 5. Kontroller för konfigurationsavvikelser i Ansible AWX.

Efter kontrollerna skickar AWX en rapport om avvikelser till administratörerna. De granskar den problematiska konfigurationen och rättar sedan till den via justerade playbooks. På så sätt håller vi konfigurationen i produktionsmiljön och CMS är alltid i ett aktuellt och synkroniserat tillstånd. Detta förhindrar obehagliga "under" när CMS-kod tillämpas på "live"-servrar.

Nu har vi fått en viktig nivå av testning bestående av Ansible AWX/GitLab/Molecule (Fig. 6).

Fig. 6. Hantering av testning.

Svårt? Jag håller med. Men en sådan sammanställning av konfigurationshantering har blivit ett uttömmande svar på många frågor relaterade till automatisering av serverkonfigurering. Nu har återförsäljaren alltid en strikt definierad konfiguration för typiska servrar. Till skillnad från en ingenjör kommer CMS inte att glömma att lägga till nödvändiga inställningar, skapa användare och utföra dussintals eller hundratals erforderliga inställningar.

I inställningarna för servrar och miljöer finns det i dag inga "hemliga kunskaper". Alla nödvändiga detaljer återspeglas i playbooks. Ingen mer kreativitet och oklara instruktioner: "ställ som en vanlig Oracle, men där måste ett par sysctl-inställningar skrivas in, och användare med rätt UID läggas till. Fråga killarna från driften, de vet.».

Möjligheten att upptäcka konfigurationsavvikelser och åtgärda dem i förväg ger trygghet. Utan system för konfigurationshantering ser det vanligtvis annorlunda ut. Problem samlas på hög tills de plötsligt "exploderar" i produktionen. Sedan görs en utredning, konfigurationerna kontrolleras och rättas. Och cykeln upprepas igen.

Och vi har självklart påskyndat lanseringen av servrar i drift från flera dagar till timmar.

Men på själva nyårsnatten, när barnen glädjefullt rev upp sina presenter och de vuxna önskade sig saker under klockslaget, migrerade våra ingenjörer SAP-systemet till nya servrar. Till och med Jultomten skulle säga att de bästa miraklen är väl förberedda.

P.S. Vårt team stöter ofta på att kunderna vill lösa hanteringen av konfigurationer så enkelt som möjligt. Helst som om det vore magi — med ett enda verktyg. Men i verkligheten är det mer komplicerat (ja, de har inte skickat några silverkulor igen): det blir nödvändigt att skapa en hel process med hjälp av verktyg som är bekväma för kundens team.

Författare: Sergey Artemov, avdelningsarkitekt DevOps-lösningar «Infosytemer Jet»

Källa: habr.com