Det nærmet seg nyttår. Barn over hele landet hadde allerede sendt brev til julenissen eller laget gaver til seg selv, og deres hovedutøver, en av de store forhandlerne, forberedte seg på salgets apoteos. I desember øker belastningen på datasenteret flere ganger. Derfor bestemte selskapet seg for å modernisere datasenteret og sette i drift flere titalls nye servere i stedet for utstyr som nådde slutten av levetiden. Dette avslutter historien på bakgrunn av virvlende snøfnugg, og thrilleren begynner.

Utstyret kom til stedet flere måneder før toppen av salget. Driftstjenesten vet selvfølgelig hvordan og hva som skal konfigureres på serverne for å bringe dem inn i produksjonsmiljøet. Men vi trengte å automatisere dette og eliminere den menneskelige faktoren. I tillegg ble serverne byttet ut før migreringen av et sett med SAP-systemer som var kritiske for selskapet.

Igangkjøringen av nye servere var strengt bundet til en tidsfrist. Og å flytte den innebar å sette både forsendelsen av en milliard gaver og migreringen av systemer i fare. Selv et team bestående av Fader Frost og Julenissen kunne ikke endre datoen - du kan overføre SAP-systemet for lagerstyring kun en gang i året. Fra 31. desember til 1. januar stopper forhandlerens enorme varehus, totalt på størrelse med 20 fotballbaner, arbeidet i 15 timer. Og dette er den eneste tidsperioden for å flytte systemet. Vi hadde ikke rom for feil når vi introduserte servere.

La meg være tydelig: historien min gjenspeiler verktøyene og konfigurasjonsadministrasjonsprosessen som teamet vårt bruker.

Konfigurasjonsadministrasjonskomplekset består av flere nivåer. Nøkkelkomponenten er CMS-systemet. I industriell drift vil fraværet av et av nivåene uunngåelig føre til ubehagelige mirakler.

OS installasjonsadministrasjon

Det første nivået er et system for å administrere installasjonen av operativsystemer på fysiske og virtuelle servere. Det skaper grunnleggende OS-konfigurasjoner, og eliminerer den menneskelige faktoren.

Ved å bruke dette systemet mottok vi standard serverforekomster med OS egnet for ytterligere automatisering. Under "hellingen" mottok de et minimumssett med lokale brukere og offentlige SSH-nøkler, samt en konsistent OS-konfigurasjon. Vi kunne være garantert å administrere serverne gjennom CMS og var sikre på at det ikke var noen overraskelser "ned under" på OS-nivå.

Den "maksimale" oppgaven for installasjonsadministrasjonssystemet er å automatisk konfigurere servere fra BIOS/fastvarenivå til OS. Mye her avhenger av utstyret og oppsettsoppgavene. For heterogent utstyr kan du vurdere REDFISH API. Hvis all maskinvaren er fra én leverandør, er det ofte mer praktisk å bruke ferdige administrasjonsverktøy (for eksempel HP ILO Amplifier, DELL OpenManage, etc.).

For å installere OS på fysiske servere brukte vi den velkjente Cobbler, som definerer et sett med installasjonsprofiler som er avtalt med driftstjenesten. Da han la til en ny server til infrastrukturen, knyttet ingeniøren serverens MAC-adresse til den nødvendige profilen i Cobbler. Ved oppstart over nettverket for første gang fikk serveren en midlertidig adresse og et nytt operativsystem. Deretter ble den overført til mål-VLAN/IP-adresseringen og arbeidet videre der. Ja, endring av VLAN tar tid og krever koordinering, men det gir ekstra beskyttelse mot utilsiktet installasjon av serveren i et produksjonsmiljø.

Vi laget virtuelle servere basert på maler utarbeidet med HashiСorp Packer. Årsaken var den samme: å forhindre mulige menneskelige feil ved installasjon av OS. Men, i motsetning til fysiske servere, eliminerer Packer behovet for PXE, nettverksoppstart og VLAN-endringer. Dette har gjort det enklere og enklere å lage virtuelle servere.

Ris. 1. Administrere installasjonen av operativsystemer.

Håndtere hemmeligheter

Ethvert konfigurasjonsstyringssystem inneholder data som skal være skjult for vanlige brukere, men som er nødvendig for å klargjøre systemer. Dette er passord for lokale brukere og tjenestekontoer, sertifikatnøkler, ulike API-tokens osv. De kalles vanligvis "hemmeligheter".

Hvis du ikke helt fra begynnelsen bestemmer hvor og hvordan du skal lagre disse hemmelighetene, er følgende lagringsmetoder sannsynlig, avhengig av alvorlighetsgraden av informasjonssikkerhetskravene:

• direkte i konfigurasjonskontrollkoden eller i filer i depotet;
• i spesialiserte verktøy for konfigurasjonsadministrasjon (for eksempel Ansible Vault);
• i CI/CD-systemer (Jenkins/TeamCity/GitLab/etc.) eller i konfigurasjonsstyringssystemer (Ansible Tower/Ansible AWX);
• hemmeligheter kan også overføres "manuelt". For eksempel er de lagt ut på et spesifisert sted, og deretter brukes de av konfigurasjonsstyringssystemer;
• ulike kombinasjoner av de ovennevnte.

Hver metode har sine egne ulemper. Den viktigste er mangelen på retningslinjer for tilgang til hemmeligheter: det er umulig eller vanskelig å avgjøre hvem som kan bruke visse hemmeligheter. En annen ulempe er mangelen på tilgangsrevisjon og en full livssyklus. Hvordan raskt erstatte for eksempel en offentlig nøkkel som er skrevet i koden og i en rekke relaterte systemer?

Vi brukte den sentraliserte hemmelige lagringen HashiCorp Vault. Dette tillot oss:

• holde hemmeligheter trygt. De er kryptert, og selv om noen får tilgang til Vault-databasen (for eksempel ved å gjenopprette den fra en sikkerhetskopi), vil de ikke kunne lese hemmelighetene som er lagret der;
• organisere retningslinjer for tilgang til hemmeligheter. Bare hemmelighetene "tildelt" til dem er tilgjengelige for brukere og applikasjoner;
• revisjonstilgang til hemmeligheter. Alle handlinger med hemmeligheter blir registrert i Vault-revisjonsloggen;
• organisere en fullverdig "livssyklus" for å jobbe med hemmeligheter. De kan opprettes, tilbakekalles, angi en utløpsdato osv.
• lett å integrere med andre systemer som trenger tilgang til hemmeligheter;
• og bruker også ende-til-ende-kryptering, engangspassord for operativsystemet og databasen, sertifikater fra autoriserte sentre, etc.

La oss nå gå videre til det sentrale autentiserings- og autorisasjonssystemet. Det var mulig å klare seg uten det, men å administrere brukere i mange relaterte systemer er for lite trivielt. Vi har konfigurert autentisering og autorisasjon gjennom LDAP-tjenesten. Ellers må Vault kontinuerlig utstede og holde styr på autentiseringstokener for brukere. Og å slette og legge til brukere ville bli til et oppdrag "opprettet/slettet jeg denne brukerkontoen overalt?"

Vi legger til et nytt nivå til systemet vårt: hemmelighetsbehandling og sentral autentisering/autorisasjon:

Ris. 2. Secrets management.

Konfigurasjonsstyring

Vi kom til kjernen - CMS-systemet. I vårt tilfelle er dette en kombinasjon av Ansible og Red Hat Ansible AWX.

I stedet for Ansible kan Chef, Puppet, SaltStack brukes. Vi valgte Ansible ut fra flere kriterier.

• For det første er det allsidighet. Et sett med ferdige moduler for kontroll det er imponerende. Og hvis du ikke har nok av det, kan du søke på GitHub og Galaxy.
• For det andre er det ikke nødvendig å installere og støtte agenter på administrert utstyr, bevise at de ikke forstyrrer belastningen og bekrefte fraværet av "bokmerker".
• For det tredje har Ansible en lav inngangsbarriere. En kompetent ingeniør vil skrive en fungerende lekebok bokstavelig talt den første dagen av arbeidet med produktet.

Men Ansible alene i et produksjonsmiljø var ikke nok for oss. Ellers ville det oppstå mange problemer med å begrense tilgangen og revidere handlingene til administratorer. Hvordan begrense tilgangen? Tross alt var det nødvendig for hver avdeling å administrere (les: kjøre Ansible-spilleboken) "sitt eget" sett med servere. Hvordan tillate bare enkelte ansatte å kjøre spesifikke Ansible-spillebøker? Eller hvordan spore hvem som lanserte spilleboken uten å sette opp mye lokalkunnskap på servere og utstyr som kjører Ansible?

Brorparten av slike problemer løses av Red Hat Ansible Tower, eller hans åpen kildekode oppstrømsprosjekt Ansible AWX. Derfor foretrakk vi det for kunden.

Og enda et trykk til portrettet av CMS-systemet vårt. Ansible playbook bør lagres i styringssystemer for kodelager. Vi har det GitLab CE.

Så selve konfigurasjonene administreres av en kombinasjon av Ansible/Ansible AWX/GitLab (se fig. 3). Selvfølgelig er AWX/GitLab integrert med et enkelt autentiseringssystem, og Ansible playbook er integrert med HashiCorp Vault. Konfigurasjoner går kun inn i produksjonsmiljøet gjennom Ansible AWX, der alle "spillereglene" er spesifisert: hvem kan konfigurere hva, hvor du kan hente konfigurasjonsstyringskoden for CMS, etc.

Ris. 3. Konfigurasjonsadministrasjon.

Testledelse

Vår konfigurasjon presenteres i kodeform. Derfor er vi tvunget til å spille etter de samme reglene som programvareutviklere. Vi trengte å organisere prosessene med utvikling, kontinuerlig testing, levering og bruk av konfigurasjonskode til produksjonsservere.

Hvis dette ikke gjøres umiddelbart, vil rollene som er skrevet for konfigurasjonen enten slutte å bli støttet og modifisert, eller slutte å bli lansert i produksjon. Kuren for denne smerten er kjent, og den har vist seg i dette prosjektet:

• hver rolle dekkes av enhetstester;
• tester kjøres automatisk når det er noen endring i koden som administrerer konfigurasjonene;
• endringer i konfigurasjonsstyringskoden frigis til produksjonsmiljøet først etter at alle tester og kodegjennomgang er bestått.

Kodeutvikling og konfigurasjonsstyring har blitt roligere og mer forutsigbar. For å organisere kontinuerlig testing brukte vi GitLab CI/CD-verktøysettet, og tok Ansible molekyl.

Hver gang det er en endring i konfigurasjonsadministrasjonskoden, kaller GitLab CI/CD Molecule:

• den sjekker kodesyntaksen,
• hever Docker-beholderen,
• bruker den endrede koden på den opprettede beholderen,
• sjekker rollen for idempotens og kjører tester for denne koden (granulariteten her er på ansible rollenivå, se fig. 4).

Vi leverte konfigurasjoner til produksjonsmiljøet ved hjelp av Ansible AWX. Driftsingeniører brukte konfigurasjonsendringer gjennom forhåndsdefinerte maler. AWX "forespurte" uavhengig den siste versjonen av koden fra GitLab-mastergrenen hver gang den ble brukt. På denne måten ekskluderte vi bruken av utestet eller utdatert kode i produksjonsmiljøet. Naturligvis kom koden inn i mastergrenen først etter testing, gjennomgang og godkjenning.

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

Det er også et problem knyttet til driften av produksjonssystemer. I det virkelige liv er det svært vanskelig å gjøre konfigurasjonsendringer gjennom CMS-kode alene. Nødsituasjoner oppstår når en ingeniør må endre konfigurasjonen "her og nå", uten å vente på koderedigering, testing, godkjenning osv.

Som et resultat, på grunn av manuelle endringer, vises avvik i konfigurasjonen på samme type utstyr (for eksempel er sysctl-innstillinger konfigurert annerledes på HA-klyngenoder). Eller den faktiske konfigurasjonen på utstyret er forskjellig fra den som er spesifisert i CMS-koden.

Derfor, i tillegg til kontinuerlig testing, sjekker vi produksjonsmiljøer for konfigurasjonsavvik. Vi valgte det enkleste alternativet: å kjøre CMS-konfigurasjonskoden i "tørrkjøringsmodus", det vil si uten å bruke endringer, men med varsling om alle avvik mellom den planlagte og faktiske konfigurasjonen. Vi implementerte dette ved å kjøre alle Ansible-spillebøker med jevne mellomrom med "—sjekk"-alternativet på produksjonsservere. Som alltid er Ansible AWX ansvarlig for å lansere og holde spilleboken oppdatert (se fig. 5):

Ris. 5. Sjekker for konfigurasjonsavvik i Ansible AWX.

Etter kontroller sender AWX en avviksrapport til administratorer. De studerer den problematiske konfigurasjonen og fikser den deretter gjennom justerte spillebøker. Slik vedlikeholder vi konfigurasjonen i produksjonsmiljøet og CMS er alltid oppdatert og synkronisert. Dette eliminerer ubehagelige "mirakler" når CMS-kode brukes på "produksjons"-servere.

Vi har nå et viktig testlag bestående av Ansible AWX/GitLab/Molecule (Figur 6).

Ris. 6. Testledelse.

Vanskelig? Jeg krangler ikke. Men et slikt kompleks av konfigurasjonsadministrasjon har blitt et omfattende svar på mange spørsmål knyttet til automatisering av serverkonfigurasjon. Nå har en forhandlers standardservere alltid en strengt definert konfigurasjon. CMS, i motsetning til en ingeniør, vil ikke glemme å legge til de nødvendige innstillingene, opprette brukere og utføre dusinvis eller hundrevis av nødvendige innstillinger.

Det er ingen "hemmelig kunnskap" i innstillingene til servere og miljøer i dag. Alle nødvendige funksjoner gjenspeiles i lekeboken. Ikke mer kreativitet og vage instruksjoner: "Installer det som vanlig Oracle, men du må spesifisere et par sysctl-innstillinger og legge til brukere med nødvendig UID. Spør gutta i drift, de vet'.

Evnen til å oppdage konfigurasjonsavvik og korrigere dem proaktivt gir trygghet. Uten et konfigurasjonsstyringssystem ser dette vanligvis annerledes ut. Problemer hoper seg opp til de en dag "skyter" i produksjon. Deretter gjennomføres en debriefing, konfigurasjoner kontrolleres og korrigeres. Og syklusen gjentas igjen

Og selvfølgelig akselererte vi lanseringen av servere i drift fra flere dager til timer.

Vel, på selve nyttårsaften, da barn med glede pakkede ut gaver og voksne kom med ønsker mens klokkespillet slo inn, migrerte ingeniørene våre SAP-systemet til nye servere. Selv julenissen vil si at de beste miraklene er de som er godt forberedt.

PS Teamet vårt møter ofte det faktum at kunder ønsker å løse problemer med konfigurasjonsadministrasjon så enkelt som mulig. Ideelt sett, som ved et trylleslag - med ett verktøy. Men i livet er alt mer komplisert (ja, sølvkuler ble ikke levert igjen): du må lage en hel prosess ved å bruke verktøy som er praktiske for kundens team.

Forfatter: Sergey Artemov, avdelingsarkitekt DevOps-løsninger "Jet infosystemer"

Kilde: www.habr.com