Hvis IT-infrastrukturen din vokser for raskt, vil du før eller siden stå overfor et valg: lineært øke menneskelige ressurser for å støtte den eller starte automatisering. Inntil et tidspunkt levde vi i det første paradigmet, og så begynte den lange veien til Infrastructure-as-Code.
Selvfølgelig er ikke NSPK en startup, men en slik atmosfære hersket i selskapet de første årene av dets eksistens, og det var veldig interessante år. Mitt navn er , Jeg har støttet Linux-infrastruktur med høye tilgjengelighetskrav i over 10 år. Han begynte i NSPK-teamet i januar 2016 og så dessverre ikke begynnelsen av selskapets eksistens, men kom på et stadium med store endringer.
Generelt kan vi si at teamet vårt leverer 2 produkter til selskapet. Den første er infrastruktur. E-post skal fungere, DNS skal fungere, og domenekontrollere skal slippe deg inn på servere som ikke skal krasje. Selskapets IT-landskap er enormt! Dette er forretnings- og forretningskritiske systemer, tilgjengelighetskravene for noen er 99,999. Det andre produktet er selve serverne, fysiske og virtuelle. Eksisterende må overvåkes, og nye må jevnlig leveres til kunder fra mange avdelinger. I denne artikkelen ønsker jeg å fokusere på hvordan vi utviklet infrastrukturen som er ansvarlig for serverlivssyklusen.
Begynnelsen av en reise
I begynnelsen av reisen vår så teknologistabelen vår slik ut:
OS CentOS 7
FreeIPA domenekontrollere
Automatisering - Ansible(+Tårn), Skomaker
Alt dette var lokalisert i 3 domener, fordelt på flere datasentre. I ett datasenter er det kontorsystemer og teststeder, i resten er det PROD.
Å lage servere på et tidspunkt så slik ut:
I VM-malen er CentOS minimal og det nødvendige minimum er som den korrekte /etc/resolv.conf, resten kommer gjennom Ansible.
CMDB - Excel.
Hvis serveren er fysisk, i stedet for å kopiere den virtuelle maskinen, ble operativsystemet installert på den ved hjelp av Cobbler - MAC-adressene til målserveren legges til Cobbler-konfigurasjonen, serveren mottar en IP-adresse via DHCP, og deretter OS er lagt til.
Først prøvde vi til og med å gjøre en form for konfigurasjonsadministrasjon i Cobbler. Men over tid begynte dette å bringe problemer med portabiliteten av konfigurasjoner både til andre datasentre og til Ansible-koden for klargjøring av VM-er.
På den tiden oppfattet mange av oss Ansible som en praktisk forlengelse av Bash og sparte ikke på design med shell og sed. Generelt Bashsible. Dette førte til slutt til at hvis playbook av en eller annen grunn ikke fungerte på serveren, var det lettere å slette serveren, fikse playbooken og kjøre den på nytt. Det var i hovedsak ingen versjonering av skript, ingen portabilitet av konfigurasjoner.
For eksempel ønsket vi å endre noen konfigurasjoner på alle servere:
- Vi endrer konfigurasjonen på eksisterende servere i logisk segment/datasenter. Noen ganger ikke på en dag - tilgjengelighetskrav og loven om store tall tillater ikke at alle endringer tas i bruk på en gang. Og noen endringer er potensielt ødeleggende og krever omstart av noe - fra tjenester til selve operativsystemet.
- Retter det i Ansible
- Vi fikser det i Cobbler
- Gjenta N ganger for hvert logisk segment/datasenter
For at alle endringene skulle gå greit, var det nødvendig å ta hensyn til mange faktorer, og endringer skjer hele tiden.
- Refaktorering av mulig kode, konfigurasjonsfiler
- Endring av interne beste praksis
- Endringer basert på resultater av analyse av hendelser/ulykker
- Endring av sikkerhetsstandarder, både interne og eksterne. For eksempel oppdateres PCI DSS med nye krav hvert år
Infrastrukturvekst og starten på reisen
Antall servere/logiske domener/datasentre vokste, og med dem også antall feil i konfigurasjoner. På et tidspunkt kom vi til tre retninger der konfigurasjonsstyring må utvikles:
- Automasjon. Menneskelige feil ved repeterende operasjoner bør unngås så mye som mulig.
- Repeterbarhet. Det er mye enklere å administrere infrastruktur når den er forutsigbar. Konfigurasjonen av servere og verktøy for deres forberedelse bør være den samme overalt. Dette er også viktig for produktteam – etter testing må applikasjonen garantert havne i et produksjonsmiljø konfigurert på samme måte som testmiljøet.
- Enkelhet og åpenhet ved å gjøre endringer i konfigurasjonsadministrasjon.
Det gjenstår å legge til et par verktøy.
Vi valgte GitLab CE som vårt kodelager, ikke minst for sine innebygde CI/CD-moduler.
Vault of secrets - Hashicorp Vault, inkl. for det flotte API.
Testing av konfigurasjoner og mulige roller – Molecule+Testinfra. Tester går mye raskere hvis du kobler til mulig mitogen. Samtidig begynte vi å skrive vår egen CMDB og orkestrator for automatisk distribusjon (på bildet over Cobbler), men dette er en helt annen historie, som min kollega og hovedutvikleren av disse systemene vil fortelle i fremtiden.
Vårt valg:
Molekyl + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (egen utvikling)
Skomaker
Gitlab + GitLab-løper
Hashicorp hvelv
Forresten, om mulige roller. Først var det bare én, men etter flere refaktoriseringer var det 17 av dem. Jeg anbefaler på det sterkeste å dele monolitten i idempotente roller, som deretter kan lanseres separat; i tillegg kan du legge til tagger. Vi delte rollene etter funksjonalitet - nettverk, logging, pakker, maskinvare, molekyl etc. Generelt fulgte vi strategien nedenfor. Jeg insisterer ikke på at dette er den eneste sannheten, men det fungerte for oss.
- Å kopiere servere fra "det gylne bildet" er ondskapsfullt!Den største ulempen er at du ikke vet nøyaktig hvilken tilstand bildene er i nå, og at alle endringer vil komme til alle bilder i alle virtualiseringsfarmer.
- Bruk standard konfigurasjonsfiler til et minimum og avtal med andre avdelinger at du er ansvarlig for hovedsystemfilene, for eksempel:
- La /etc/sysctl.conf stå tomt, innstillingene skal bare være i /etc/sysctl.d/. Din standard i én fil, tilpasset for applikasjonen i en annen.
- Bruk overstyringsfiler for å redigere systemd-enheter.
- Mal alle konfigurasjoner og inkluder dem helt; hvis mulig, ingen sed eller dets analoger i playbooks
- Refaktorering av konfigurasjonsstyringssystemkoden:
- Bryt oppgaver ned i logiske enheter og omskriv monolitten til roller
- Bruk linters! Ansible-lo, yaml-lo, etc
- Endre tilnærmingen din! Ingen bashible. Det er nødvendig å beskrive tilstanden til systemet
- For alle Ansible-roller må du skrive tester i molekyl og generere rapporter en gang om dagen.
- I vårt tilfelle, etter å ha forberedt testene (som det er mer enn 100), ble det funnet rundt 70000 XNUMX feil. Det tok flere måneder å fikse det.
Vår implementering
Så de aktuelle rollene var klare, malt og kontrollert av linters. Og til og med gits heves overalt. Men spørsmålet om pålitelig kodelevering til forskjellige segmenter forble åpent. Vi bestemte oss for å synkronisere med skript. Ser sånn ut:
Etter at endringen kommer, lanseres CI, en testserver opprettes, roller rulles ut og testes av molekylet. Hvis alt er ok, går koden til prod-grenen. Men vi bruker ikke ny kode på eksisterende servere i maskinen. Dette er en slags stopper som er nødvendig for høy tilgjengelighet av systemene våre. Og når infrastrukturen blir enorm, spiller loven om store tall inn – selv om du er sikker på at endringen er ufarlig, kan det føre til alvorlige konsekvenser.
Det er også mange alternativer for å lage servere. Vi endte opp med å velge tilpassede Python-skript. Og for CI ansible:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Det er dette vi har kommet til, systemet fortsetter å leve og utvikle seg.
- 17 Ansible roller for å sette opp serveren. Hver av rollene er designet for å løse en egen logisk oppgave (logging, revisjon, brukerautorisasjon, overvåking osv.).
- Rolletesting. Molekyl + TestInfra.
- Egen utvikling: CMDB + Orchestrator.
- Serveropprettingstiden er ~30 minutter, automatisert og praktisk talt uavhengig av oppgavekøen.
- Samme tilstand/navngivning av infrastrukturen i alle segmenter - playbooks, repositories, virtualiseringselementer.
- Daglig sjekk av serverstatus med generering av rapporter om avvik med standarden.
Jeg håper historien min vil være nyttig for de som er i begynnelsen av reisen. Hvilken automatiseringsstabel bruker du?
Kilde: www.habr.com