Det närmade sig nyår. Barn över hela landet hade redan skickat brev till jultomten eller gjort presenter till sig själva, och deras huvudexekutor, en av de stora återförsäljarna, förberedde sig för försäljningens apoteos. I december ökar belastningen på dess datacenter flera gånger. Därför beslutade företaget att modernisera datacentret och sätta flera dussin nya servrar i drift istället för utrustning som var på väg att nå slutet av sin livslängd. Detta avslutar berättelsen mot bakgrund av virvlande snöflingor, och thrillern börjar.

Utrustningen anlände till platsen flera månader innan försäljningstoppen. Drifttjänsten vet naturligtvis hur och vad den ska konfigurera på servrarna för att få in dem i produktionsmiljön. Men vi behövde automatisera detta och eliminera den mänskliga faktorn. Dessutom byttes servrarna ut innan migreringen av en uppsättning SAP-system som var kritiska för företaget.

Driftsättningen av nya servrar var strikt bunden till en deadline. Och att flytta den innebar att äventyra både transporten av en miljard gåvor och migreringen av system. Inte ens ett team bestående av Fader Frost och Santa Claus kunde ändra datumet - du kan överföra SAP-systemet för lagerhantering endast en gång om året. Från 31 december till 1 januari stoppar återförsäljarens enorma lager, totalt 20 fotbollsplaner, sitt arbete i 15 timmar. Och detta är den enda tidsperioden för att flytta systemet. Vi hade inget utrymme för fel när vi introducerade servrar.

Låt mig vara tydlig: min historia speglar verktygen och konfigurationshanteringsprocessen som vårt team använder.

Konfigurationshanteringskomplexet består av flera nivåer. Nyckelkomponenten är CMS-systemet. I industriell drift skulle frånvaron av en av nivåerna oundvikligen leda till obehagliga mirakel.

OS installationshantering

Den första nivån är ett system för att hantera installationen av operativsystem på fysiska och virtuella servrar. Det skapar grundläggande OS-konfigurationer, vilket eliminerar den mänskliga faktorn.

Med detta system fick vi standardserverinstanser med OS som lämpar sig för ytterligare automatisering. Under "hällningen" fick de en minsta uppsättning lokala användare och offentliga SSH-nycklar, samt en konsekvent OS-konfiguration. Vi kunde garanterat hantera servrarna genom CMS och var säkra på att det inte fanns några överraskningar "nere under" på OS-nivå.

Den "maximala" uppgiften för installationshanteringssystemet är att automatiskt konfigurera servrar från BIOS/Firmware-nivå till OS. Mycket här beror på utrustningen och installationsuppgifterna. För heterogen utrustning kan du överväga REDFISH API. Om all hårdvara kommer från en leverantör är det ofta bekvämare att använda färdiga hanteringsverktyg (till exempel HP ILO Amplifier, DELL OpenManage, etc.).

För att installera operativsystemet på fysiska servrar använde vi den välkända Cobbler, som definierar en uppsättning installationsprofiler som överenskommits med drifttjänsten. När en ny server lades till i infrastrukturen knöt ingenjören serverns MAC-adress till den önskade profilen i Cobbler. Vid uppstart över nätverket för första gången fick servern en tillfällig adress och ett nytt operativsystem. Sedan överfördes den till mål VLAN/IP-adresseringen och fortsatte arbetet där. Ja, att ändra VLAN tar tid och kräver samordning, men det ger ytterligare skydd mot oavsiktlig installation av servern i en produktionsmiljö.

Vi skapade virtuella servrar baserade på mallar framtagna med HashiСorp Packer. Anledningen var densamma: att förhindra möjliga mänskliga fel vid installation av operativsystemet. Men till skillnad från fysiska servrar eliminerar Packer behovet av PXE, nätverksstart och VLAN-ändringar. Detta har gjort det enklare och enklare att skapa virtuella servrar.

Ris. 1. Hantera installationen av operativsystem.

Hantera hemligheter

Alla konfigurationshanteringssystem innehåller data som bör döljas för vanliga användare, men som behövs för att förbereda system. Dessa är lösenord för lokala användare och tjänstekonton, certifikatnycklar, olika API-tokens, etc. De kallas vanligtvis "hemligheter".

Om du inte redan från början bestämmer var och hur du ska lagra dessa hemligheter, är följande lagringsmetoder sannolikt, beroende på hur strikt informationssäkerhetskraven är:

• direkt i konfigurationskontrollkoden eller i filer i förvaret;
• i specialiserade verktyg för konfigurationshantering (till exempel Ansible Vault);
• i CI/CD-system (Jenkins/TeamCity/GitLab/etc.) eller i konfigurationshanteringssystem (Ansible Tower/Ansible AWX);
• hemligheter kan också överföras "manuellt". Till exempel läggs de ut på en specificerad plats, och sedan används de av konfigurationshanteringssystem;
• olika kombinationer av ovanstående.

Varje metod har sina egna nackdelar. Den viktigaste är bristen på policyer för tillgång till hemligheter: det är omöjligt eller svårt att avgöra vem som kan använda vissa hemligheter. En annan nackdel är bristen på åtkomstrevision och en fullständig livscykel. Hur byter man snabbt ut till exempel en publik nyckel som är skriven i koden och i ett antal relaterade system?

Vi använde den centraliserade hemliga lagringen HashiCorp Vault. Detta tillät oss:

• hålla hemligheter säkra. De är krypterade, och även om någon får tillgång till Vault-databasen (till exempel genom att återställa den från en säkerhetskopia), kommer de inte att kunna läsa hemligheterna som lagras där;
• organisera policyer för tillgång till hemligheter. Endast de hemligheter som "tilldelats" till dem är tillgängliga för användare och applikationer;
• granska tillgång till hemligheter. Alla åtgärder med hemligheter registreras i Vault-revisionsloggen;
• organisera en fullfjädrad "livscykel" av att arbeta med hemligheter. De kan skapas, återkallas, ange ett utgångsdatum, etc.
• lätt att integrera med andra system som behöver tillgång till hemligheter;
• och även använda end-to-end-kryptering, engångslösenord för operativsystemet och databasen, certifikat från auktoriserade centra, etc.

Låt oss nu gå vidare till det centrala autentiserings- och auktoriseringssystemet. Det var möjligt att klara sig utan det, men att administrera användare i många relaterade system är för otrivialt. Vi har konfigurerat autentisering och auktorisering genom LDAP-tjänsten. Annars skulle Vault kontinuerligt behöva utfärda och hålla reda på autentiseringstoken för användare. Och att ta bort och lägga till användare skulle förvandlas till ett uppdrag "skapade/rade jag det här användarkontot överallt?"

Vi lägger till ytterligare en nivå till vårt system: hemlighetshantering och central autentisering/auktorisering:

Ris. 2. Hemlighetshantering.

Konfigurationshantering

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

Istället för Ansible kan Chef, Puppet, SaltStack användas. Vi valde Ansible utifrån flera kriterier.

• För det första är det mångsidighet. En uppsättning färdiga moduler för kontroll det är imponerande. Och om du inte har tillräckligt med det kan du söka på GitHub och Galaxy.
• För det andra finns det inget behov av att installera och stödja agenter på hanterad utrustning, bevisa att de inte stör belastningen och bekräfta frånvaron av "bokmärken".
• För det tredje har Ansible en låg inträdesbarriär. En kompetent ingenjör kommer att skriva en fungerande lekbok bokstavligen den första dagen av att arbeta med produkten.

Men Ansible ensam i en produktionsmiljö räckte inte för oss. Annars skulle många problem uppstå med att begränsa åtkomst och granska administratörers agerande. Hur begränsar man åtkomsten? När allt kommer omkring var det nödvändigt för varje avdelning att hantera (läs: köra Ansible-spelboken) "sin egen" uppsättning servrar. Hur tillåter man endast vissa anställda att köra specifika Ansible-spelböcker? Eller hur man spårar vem som lanserade spelboken utan att sätta upp en massa lokalkännedom på servrar och utrustning som kör Ansible?

Lejonparten av sådana frågor löses av Red Hat Ansible Tower, eller hans uppströmsprojekt med öppen källkod Ansible AWX. Det var därför vi föredrog det för kunden.

Och ytterligare en touch till porträttet av vårt CMS-system. Ansible playbook bör lagras i kodlagerhanteringssystem. Vi har det GitLab CE.

Så, själva konfigurationerna hanteras av en kombination av Ansible/Ansible AWX/GitLab (se fig. 3). Naturligtvis är AWX/GitLab integrerat med ett enda autentiseringssystem, och Ansible playbook är integrerat med HashiCorp Vault. Konfigurationer går endast in i produktionsmiljön genom Ansible AWX, där alla "spelets regler" är specificerade: vem kan konfigurera vad, var man kan hämta konfigurationshanteringskoden för CMS, etc.

Ris. 3. Konfigurationshantering.

Testhantering

Vår konfiguration presenteras i kodform. Därför är vi tvungna att spela enligt samma regler som mjukvaruutvecklare. Vi behövde organisera processerna för utveckling, kontinuerlig testning, leverans och applicering av konfigurationskod till produktionsservrar.

Om detta inte görs omedelbart, skulle de roller som skrivs för konfigurationen antingen sluta stödjas och modifieras, eller sluta lanseras i produktion. Botemedlet för denna smärta är känt, och det har visat sig i detta projekt:

• varje roll täcks av enhetstester;
• tester körs automatiskt när det sker någon förändring i koden som hanterar konfigurationerna;
• ändringar i konfigurationshanteringskoden släpps till produktionsmiljön först efter att alla tester och kodgranskning har godkänts.

Kodutveckling och konfigurationshantering har blivit lugnare och mer förutsägbar. För att organisera kontinuerliga tester använde vi GitLab CI/CD-verktygslådan och tog Ansible molekyl.

Närhelst det sker en förändring i konfigurationshanteringskoden anropar GitLab CI/CD Molecule:

• den kontrollerar kodsyntaxen,
• höjer Docker-behållaren,
• tillämpar den ändrade koden på den skapade behållaren,
• kontrollerar rollen för idempotens och kör tester för den här koden (granulariteten här är på den möjliga rollnivån, se fig. 4).

Vi levererade konfigurationer till produktionsmiljön med Ansible AWX. Driftingenjörer tillämpade konfigurationsändringar genom fördefinierade mallar. AWX "begärde" oberoende den senaste versionen av koden från GitLabs mastergren varje gång den användes. På så sätt uteslöt vi användningen av oprövad eller föråldrad kod i produktionsmiljön. Naturligtvis kom koden in i huvudgrenen först efter testning, granskning och godkännande.

Ris. 4. Automatisk testning av roller i GitLab CI/CD.

Det finns också ett problem i samband med driften av produktionssystem. I verkliga livet är det mycket svårt att göra konfigurationsändringar enbart genom CMS-kod. Nödsituationer uppstår när en ingenjör måste ändra konfigurationen "här och nu", utan att vänta på kodredigering, testning, godkännande, etc.

Som ett resultat, på grund av manuella ändringar, uppträder avvikelser i konfigurationen på samma typ av utrustning (till exempel konfigureras sysctl-inställningarna annorlunda på HA-klusternoder). Eller så skiljer sig den faktiska konfigurationen på utrustningen från den som anges i CMS-koden.

Därför kontrollerar vi, förutom kontinuerliga tester, produktionsmiljöer för konfigurationsavvikelser. Vi valde det enklaste alternativet: köra CMS-konfigurationskoden i "torrkörningsläge", det vill säga utan att tillämpa ändringar, men med meddelande om alla avvikelser mellan den planerade och faktiska konfigurationen. Vi implementerade detta genom att med jämna mellanrum köra alla Ansible-spelböcker med alternativet "-check" på produktionsservrar. Som alltid ansvarar Ansible AWX för att lansera och hålla spelboken uppdaterad (se fig. 5):

Ris. 5. Kontrollerar efter konfigurationsavvikelser i Ansible AWX.

Efter kontroller skickar AWX en avvikelserapport till administratörer. De studerar den problematiska konfigurationen och fixar den sedan genom anpassade spelböcker. Det är så vi underhåller konfigurationen i produktionsmiljön och CMS är alltid uppdaterat och synkroniserat. Detta eliminerar obehagliga "mirakel" när CMS-kod används på "produktions"-servrar.

Vi har nu ett viktigt testlager bestående av Ansible AWX/GitLab/Molecule (Figur 6).

Ris. 6. Testledning.

Svår? Jag argumenterar inte. Men ett sådant komplex av konfigurationshantering har blivit ett heltäckande svar på många frågor relaterade till automatisering av serverkonfiguration. Nu har en återförsäljares standardservrar alltid en strikt definierad konfiguration. CMS, till skillnad från en ingenjör, kommer inte att glömma att lägga till de nödvändiga inställningarna, skapa användare och utföra dussintals eller hundratals nödvändiga inställningar.

Det finns ingen "hemlig kunskap" i inställningarna för servrar och miljöer idag. Alla nödvändiga funktioner återspeglas i spelboken. Ingen mer kreativitet och vaga instruktioner: "Installera det som vanligt Oracle, men du måste ange ett par sysctl-inställningar och lägga till användare med det nödvändiga UID. Fråga killarna i drift, de vet".

Möjligheten att upptäcka konfigurationsavvikelser och korrigera dem proaktivt ger sinnesfrid. Utan ett konfigurationshanteringssystem ser detta vanligtvis annorlunda ut. Problem ackumuleras tills de en dag "skjuter" in i produktionen. Därefter genomförs en debriefing, konfigurationer kontrolleras och korrigeras. Och cykeln upprepas igen

Och naturligtvis påskyndade vi lanseringen av servrar i drift från flera dagar till timmar.

Nåväl, på självaste nyårsafton, när barn med glädje packade upp presenter och vuxna ställde önskningar när klockan slog, migrerade våra ingenjörer SAP-systemet till nya servrar. Även jultomten kommer att säga att de bästa miraklen är de som är väl förberedda.

PS Vårt team stöter ofta på det faktum att kunder vill lösa problem med konfigurationshantering så enkelt som möjligt. Helst som genom ett trollslag - med ett verktyg. Men i livet är allt mer komplicerat (ja, silverkulor levererades inte igen): du måste 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 "Jet Infosystems"

Källa: will.com