Hvis din it-infrastruktur vokser for hurtigt, vil du før eller siden stå over for et valg: lineært øge de menneskelige ressourcer for at understøtte den eller starte automatisering. Indtil et tidspunkt levede vi i det første paradigme, og så begyndte den lange vej til Infrastructure-as-Code.
Selvfølgelig er NSPK ikke en startup, men sådan en atmosfære herskede i virksomheden i de første år af dens eksistens, og det var meget interessante år. Mit navn er , Jeg har understøttet Linux-infrastruktur med høje tilgængelighedskrav i over 10 år. Han kom til NSPK-teamet i januar 2016 og så desværre ikke begyndelsen af virksomhedens eksistens, men kom på et stadium med store forandringer.
Generelt kan vi sige, at vores team leverer 2 produkter til virksomheden. Den første er infrastruktur. Mail skal fungere, DNS skal fungere, og domænecontrollere skal lade dig komme ind på servere, der ikke burde gå ned. Virksomhedens IT-landskab er enormt! Disse er forretnings- og missionskritiske systemer, tilgængelighedskravene for nogle er 99,999. Det andet produkt er selve serverne, fysiske og virtuelle. Eksisterende skal overvåges, og nye skal løbende leveres til kunder fra mange afdelinger. I denne artikel vil jeg fokusere på, hvordan vi udviklede den infrastruktur, der er ansvarlig for serverens livscyklus.
Begyndelsen af en rejse
I begyndelsen af vores rejse så vores teknologistabel sådan ud:
OS CentOS 7
FreeIPA domænecontrollere
Automation - Ansible(+tårn), skomager
Alt dette var placeret i 3 domæner, fordelt på flere datacentre. I det ene datacenter er der kontorsystemer og teststeder, i resten er der PROD.
Oprettelse af servere på et tidspunkt så således ud:
I VM-skabelonen er CentOS minimal, og det nødvendige minimum er ligesom den korrekte /etc/resolv.conf, resten kommer gennem Ansible.
CMDB - Excel.
Hvis serveren er fysisk, i stedet for at kopiere den virtuelle maskine, blev operativsystemet installeret på den ved hjælp af Cobbler - MAC-adresserne på målserveren føjes til Cobbler-konfigurationen, serveren modtager en IP-adresse via DHCP, og derefter OS er tilføjet.
Først prøvede vi endda at lave en form for konfigurationsstyring i Cobbler. Men med tiden begyndte dette at bringe problemer med portabiliteten af konfigurationer både til andre datacentre og til Ansible-koden til at forberede VM'er.
På det tidspunkt opfattede mange af os Ansible som en bekvem forlængelse af Bash og sparede ikke på design ved hjælp af shell og sed. Samlet Bashsible. Dette førte i sidste ende til, at hvis playbook af en eller anden grund ikke virkede på serveren, var det nemmere at slette serveren, rette playbooken og køre den igen. Der var i det væsentlige ingen versionering af scripts, ingen portabilitet af konfigurationer.
For eksempel ønskede vi at ændre nogle konfigurationer på alle servere:
- Vi ændrer konfigurationen på eksisterende servere i det logiske segment/datacenter. Nogle gange ikke på én dag - tilgængelighedskrav og loven om store tal tillader ikke, at alle ændringer anvendes på én gang. Og nogle ændringer er potentielt ødelæggende og kræver genstart af noget - fra tjenester til selve OS.
- Retter det i Ansible
- Vi ordner det i Cobbler
- Gentag N gange for hvert logisk segment/datacenter
For at alle ændringerne skulle forløbe glat, var det nødvendigt at tage højde for mange faktorer, og der sker konstant ændringer.
- Refaktorering af mulig kode, konfigurationsfiler
- Ændring af intern bedste praksis
- Ændringer baseret på resultater af analyse af hændelser/ulykker
- Ændring af sikkerhedsstandarder, både interne og eksterne. For eksempel bliver PCI DSS opdateret med nye krav hvert år
Infrastrukturvækst og starten på rejsen
Antallet af servere/logiske domæner/datacentre voksede, og med dem antallet af fejl i konfigurationer. På et tidspunkt kom vi til tre retninger, hvor konfigurationsstyring skal udvikles:
- Automatisering. Menneskelige fejl ved gentagne operationer bør så vidt muligt undgås.
- Gentagelighed. Det er meget nemmere at administrere infrastrukturen, når den er forudsigelig. Konfigurationen af servere og værktøjer til deres forberedelse bør være den samme overalt. Dette er også vigtigt for produktteams - efter test skal applikationen garanteres at ende i et produktionsmiljø, der er konfigureret på samme måde som testmiljøet.
- Enkelhed og gennemsigtighed ved at foretage ændringer i konfigurationsstyring.
Det er tilbage at tilføje et par værktøjer.
Vi valgte GitLab CE som vores kodelager, ikke mindst for dets indbyggede CI/CD-moduler.
Vault of secrets - Hashicorp Vault, inkl. for den store API.
Test af konfigurationer og mulige roller – Molecule+Testinfra. Tests går meget hurtigere, hvis du opretter forbindelse til et muligt mitogen. Samtidig begyndte vi at skrive vores egen CMDB og orkestrator til automatisk implementering (på billedet ovenfor Cobbler), men det er en helt anden historie, som min kollega og hovedudvikleren af disse systemer vil fortælle i fremtiden.
Vores valg:
Molekyle + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Egen udvikling)
tærte
Gitlab + GitLab runner
Hashicorp Vault
I øvrigt om mulige roller. Først var der kun én, men efter adskillige refactorings var der 17 af dem. Jeg anbefaler kraftigt at opdele monolitten i idempotente roller, som derefter kan lanceres separat. Derudover kan du tilføje tags. Vi opdelte rollerne efter funktionalitet - netværk, logning, pakker, hardware, molekyle mm. Generelt fulgte vi nedenstående strategi. Jeg insisterer ikke på, at dette er den eneste sandhed, men det virkede for os.
- At kopiere servere fra det "gyldne billede" er ondskabsfuldt!Den største ulempe er, at du ikke ved præcis, hvilken tilstand billederne er i nu, og at alle ændringer vil komme til alle billeder i alle virtualiseringsfarme.
- Brug standardkonfigurationsfiler til et minimum, og aftal med andre afdelinger, at du er ansvarlig for hovedsystemfilerne, for eksempel:
- Lad /etc/sysctl.conf stå tomt, indstillingerne skal kun være i /etc/sysctl.d/. Din standard i én fil, tilpasset til applikationen i en anden.
- Brug tilsidesættelsesfiler til at redigere systemd-enheder.
- Skabelon alle konfigurationer og medtag dem fuldstændigt; hvis det er muligt, ingen sed eller dets analoger i playbooks
- Refaktorering af konfigurationsstyringssystemkoden:
- Bryd opgaver ned i logiske enheder og omskriv monolitten til roller
- Brug linters! Ansible-lint, yaml-lint osv
- Skift din tilgang! Ingen bashible. Det er nødvendigt at beskrive systemets tilstand
- For alle Ansible roller skal du skrive test i molekyle og generere rapporter en gang om dagen.
- I vores tilfælde, efter at have forberedt testene (som der er mere end 100 af), blev der fundet omkring 70000 fejl. Det tog flere måneder at rette op på det.
Vores implementering
Så de relevante roller var klar, skabeloner og kontrolleret af linters. Og selv gits rejses overalt. Men spørgsmålet om pålidelig kodelevering til forskellige segmenter forblev åbent. Vi besluttede at synkronisere med scripts. Ser sådan ud:
Efter ændringen ankommer, startes CI, en testserver oprettes, roller rulles ud og testes af molekylet. Hvis alt er ok, går koden til prod-grenen. Men vi anvender ikke ny kode på eksisterende servere i maskinen. Dette er en slags stopper, der er nødvendig for høj tilgængelighed af vores systemer. Og når infrastrukturen bliver enorm, spiller loven om store tal ind – selvom man er sikker på, at ændringen er ufarlig, kan det få voldsomme konsekvenser.
Der er også mange muligheder for at oprette servere. Vi endte med at vælge brugerdefinerede Python-scripts. 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 det, vi er kommet til, systemet fortsætter med at leve og udvikle sig.
- 17 Ansible roller til opsætning af serveren. Hver af rollerne er designet til at løse en separat logisk opgave (logning, revision, brugerautorisation, overvågning osv.).
- Rolletest. Molekyle + TestInfra.
- Egen udvikling: CMDB + Orchestrator.
- Serveroprettelsestid er ~30 minutter, automatiseret og praktisk talt uafhængig af opgavekøen.
- Samme tilstand/navngivning af infrastrukturen i alle segmenter - playbooks, repositories, virtualiseringselementer.
- Daglig kontrol af serverstatus med generering af rapporter om uoverensstemmelser med standarden.
Jeg håber, at min historie vil være nyttig for dem, der er i begyndelsen af deres rejse. Hvilken automatiseringsstack bruger du?
Kilde: www.habr.com