Hvis din IT-infrastruktur vokser for hurtigt, vil du før eller senere stå over for valget - enten at øge bemandingen lineært for at støtte den eller begynde at automatisere. Indtil et vist punkt levede vi i den første paradigme, hvorefter den lange rejse mod Infrastructure-as-Code begyndte.
Selvfølgelig er NSPK ikke en startup, men sådan en atmosfære herskede i virksomheden de første år af dens eksistens, og det var meget spændende år. Mit navn er , jeg har i over 10 år understøttet Linux-infrastruktur med høje tilgængelighedskrav. Jeg sluttede mig til NSPK-teamet i januar 2016 og, desværre, fik jeg ikke opleve virksomhedens tidlige dage, men kom ind i en fase med store ændringer.
Generelt kan man sige, at vores team leverer to produkter til virksomheden. Det første er infrastrukturen. E-mail skal fungere, DNS skal fungere, og domænecontrollere skal give dig adgang til serverne, som ikke må gå ned. IT-landskabet i virksomheden er enormt! Det drejer sig om business & mission critical systemer, nogle med tilgængelighedskrav på 99,999. Det andet produkt er selve serverne, både fysiske og virtuelle. De eksisterende skal overvåges, og nye skal regelmæssigt leveres til kunderne fra mange afdelinger. I denne artikel vil jeg fokusere på, hvordan vi udviklede infrastrukturen, der er ansvarlig for livscyklussen servere.
Starten på rejsen
I starten så vores teknologi-stack sådan ud:
OS CentOS 7
Domænecontrollere FreeIPA
Automatisering — Ansible(+Tower), Cobbler
Alt dette var placeret i 3 domæner, spredt over flere datacentre. I ét datacenter - kontorsystemer og testmiljøer, i de andre PROD.
Oprettelse af servere så på et tidspunkt sådan ud:
I VM-skabelonen CentOS minimal og det nødvendige minimum som korrekt /etc/resolv.conf, resten kommer gennem Ansible.
CMDB – Excel.
Hvis serveren er fysisk, blev OS installeret ved hjælp af Cobbler i stedet for at kopiere den virtuelle maskine til den - MAC-adresserne på den målserver tilføjes til Cobbler-konfigurationen, serveren får en IP-adresse via DHCP, og derefter installeres OS.
I starten forsøgte vi endda at lave en form for konfigurationsstyring i Cobbler. Men med tiden begyndte det at medføre problemer med portabiliteten af konfigurationerne både til andre datacentre og til Ansible-koden til forberedelse af VM.
Ansible blev dengang opfattet af mange af os som en praktisk udvidelse af Bash, og vi var ikke tilbageholdende med at bruge konstruktioner med shell og sed. Generelt som Bashsible. Dette førte til, at hvis en playbook af en eller anden grund ikke fungerede på serveren, var det lettere at slette serveren, rette playbooken og køre den igennem igen. Der var i praksis ingen versionering af scripts, og konfigurationens portabilitet var også fraværende.
For eksempel ønskede vi at ændre en konfiguration på alle servere:
- Ændrer konfigurationen på eksisterende servere i det logiske segment/datacenter. Nogle gange ikke på en dag – kravene til tilgængelighed og loven om store tal tillader ikke at anvende alle ændringer på én gang. Nogle ændringer er potentielt destruktive og kræver genstart af noget – fra tjenester til selve operativsystemet.
- Retter i Ansible
- Retter i Cobbler
- Gentager N gange for hver logisk sektion/datacenter
For at sikre, at alle ændringer forløber glat, var det nødvendigt at tage højde for adskillige faktorer, og ændringerne forekommer konstant.
- Refactoring af Ansible-kode, konfigurationsfiler
- Ændring af interne best practices
- Ændringer baseret på gennemgang af hændelser/uheld
- Ændring af sikkerhedsstandarder, både interne og eksterne. For eksempel bliver PCI DSS hvert år suppleret med nye krav.
Vækst af infrastrukturen og begyndelsen af vejen
Antallet af servere/logiske domæner/datacentre voksede, og dermed også antallet af fejl i konfigurationerne. På et tidspunkt kom vi til tre områder, som vi skulle udvikle configuration management i retning af:
- Automatisering. I det omfang det er muligt, skal den menneskelige faktor undgås i gentagne operationer.
- Gentagelighed. Det er meget lettere at administrere infrastrukturen, når den er forudsigelig. Konfigurationen af servere og værktøjer til deres opsætning skal være ens overalt. Dette er også vigtigt for produktteams – applikationen skal garanteret efter testning komme ind i produktionsmiljøet, som er konfigureret på samme måde som testmiljøet.
- Simplicity and transparency in making changes in configuration management.
Det er tid til at tilføje et par værktøjer.
Som kodeopbevaring valgte vi GitLab CE, ikke mindst på grund af tilstedeværelsen af indbyggede CI/CD-moduler.
Opbevaring af hemmeligheder — Hashicorp Vault, bl.a. for det fantastiske API.
Test af konfigurationer og ansible-roller – Molecule+Testinfra. Testene kører meget hurtigere, når du tilslutter ansible mitogen. Samtidig er vi begyndt at skrive vores egen CMDB og orkestrator til automatisk udrulning (på billedet over Cobbler), men det er en helt anden historie, som min kollega og hovedudvikler af disse systemer vil fortælle om i fremtiden.
Vores valg:
Molecule + Testinfra
Ansible + Tower + AWX
Verden af Servere + DITNET (Egen udvikling)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault
For resten om ansible-roller. Før var der kun én, efter flere refaktoreringer er der blevet 17. Jeg anbefaler kategorisk at opdele monolitten i idempotente roller, som derefter kan køres separat, og der kan desuden tilføjes tags. Vi har opdelt rollerne efter funktionalitet – netværk, logging, pakker, hardware, molecule osv. Generelt fulgte vi strategien nedenfor. Jeg påstår ikke, at dette er den eneste sandhed, men det virkede for os.
- Kopiering af servere fra "guldbilledet" – ondt!Blandt de vigtigste ulemper – du ved præcist ikke, hvilken tilstand billederne er i nu, og at alle ændringer vil komme til alle billeder i alle virtualiseringsfarmene.
- Brug som minimum de standard konfigurationsfiler, og aftal med andre afdelinger, at du er ansvarlig for de vigtigste systemfiler., for eksempel:
- Hold /etc/sysctl.conf tomt, indstillingerne skal kun ligge i /etc/sysctl.d/. Din standard i én fil, tilpasning til applikationen i en anden.
- Brug override-filer til redigering af systemd-enheder.
- Template alle konfigurationer og indsæt dem helt, så vidt muligt ingen sed og dens analoger i playbooks.
- Refaktorerer koden for konfigurationsstyringssystemer:
- Opdel opgaverne i logiske enheder og omskriv monolitten til roller.
- Brug linters! Ansible-lint, yaml-lint osv.
- Ændre tilgangen! Ingen bashsible. Det er nødvendigt at beskrive systemets tilstand.
- For alle Ansible-roller skal der skrives tests i molecule, og rapporter skal genereres én gang om dagen.
- I vores tilfælde, efter forberedelse af tests (som er mere end 100), blev der fundet omkring 70.000 fejl. Det tog flere måneder at rette.
Vores implementering
Så ansible-rollerne var klar, templated og verificeret af linters. Og endda var git-repositorierne hævet overalt. Men spørgsmålet om pålidelig levering af koden til forskellige segmenter var stadig åbent. Vi besluttede at synkronisere med scripts. Det ser således ud:
Når ændringen ankommer, starter CI'en, der oprettes en testserver, rollerne køres, og der testes med Molecule. Hvis alt er i orden, går koden videre til produktionsgrenen. Men vi anvender ikke ny kode automatisk på eksisterende servere. Dette er en form for stop, der er nødvendig for at sikre høj tilgængelighed af vores systemer. Og når infrastrukturen bliver enorm, spiller loven om store tal ind – selv hvis du er sikker på, at ændringen er harmløs, kan den føre til triste konsekvenser.
Der er mange måder at oprette servere på. Vi valgte i sidste ende tilpassede scripts i Python. Og til CI Ansible:
- name: create1.yml - Opret en VM fra en skabelon
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}}"Her er vi nået til, systemet fortsætter med at eksistere og udvikle sig.
- 17 Ansible-roller til serverkonfiguration. Hver rolle er designet til at løse en bestemt logisk opgave (logging, revision, brugergodkendelse, overvågning osv.).
- Testning af roller. Molecule + TestInfra.
- Egenudvikling: CMDB + Orkestrator.
- Tiden til oprettelse af en server er ca. 30 minutter, automatiseret og næsten uafhængig af opgavelisten.
- Ensartet stat/navn på infrastrukturen i alle segmenter – playbooks, repositories, virtualiseringselementer.
- Daglig kontrol af servernes tilstand med generering af rapporter om forskelle fra referencen.
Jeg håber, at min fortælling vil være nyttig for dem, der er i begyndelsen af deres rejse. Hvilket automatiseringsstack bruger I?
Kilde: habr.com
