Om din IT-infrastruktur växer för snabbt kommer du förr eller senare att ställas inför ett val: att linjärt öka personalresurserna för att stödja den eller starta automatisering. Tills någon gång levde vi i det första paradigmet, och sedan började den långa vägen till Infrastructure-as-Code.
Naturligtvis är NSPK inte en startup, men en sådan atmosfär rådde i företaget under de första åren av dess existens, och det var mycket intressanta år. Mitt namn är , Jag har stött Linux-infrastruktur med höga tillgänglighetskrav i över 10 år. Han gick med i NSPK-teamet i januari 2016 och såg tyvärr inte början av företagets existens, men kom i ett skede av stora förändringar.
Generellt kan vi säga att vårt team levererar 2 produkter till företaget. Den första är infrastruktur. Mail ska fungera, DNS ska fungera och domänkontrollanter ska släppa in dig på servrar som inte ska krascha. Företagets IT-landskap är enormt! Dessa är affärs- och uppdragskritiska system, tillgänglighetskraven för vissa är 99,999. Den andra produkten är själva servrarna, fysiska och virtuella. Befintliga behöver övervakas och nya måste regelbundet levereras till kunder från många avdelningar. I den här artikeln vill jag fokusera på hur vi utvecklade infrastrukturen som är ansvarig för serverns livscykel.
Början på en resa
I början av vår resa såg vår teknikstack ut så här:
OS CentOS 7
FreeIPA domänkontrollanter
Automation - Ansible(+Tower), Skomakare
Allt detta fanns i 3 domäner, fördelade på flera datacenter. I ett datacenter finns kontorssystem och testplatser, i resten finns PROD.
Att skapa servrar vid ett tillfälle såg ut så här:
I VM-mallen är CentOS minimal och det erforderliga minimumet är som den korrekta /etc/resolv.conf, resten kommer genom Ansible.
CMDB - Excel.
Om servern är fysisk, istället för att kopiera den virtuella maskinen, installerades operativsystemet på den med Cobbler - MAC-adresserna för målservern läggs till i Cobbler-konfigurationen, servern får en IP-adress via DHCP och sedan OS är adderat.
Först försökte vi till och med göra någon form av konfigurationshantering i Cobbler. Men med tiden började detta skapa problem med portabiliteten av konfigurationer både till andra datacenter och till Ansible-koden för att förbereda virtuella datorer.
På den tiden uppfattade många av oss Ansible som en bekväm förlängning av Bash och snålade inte med design med skal och sed. Överlag Bashsible. Detta ledde i slutändan till att om spelboken av någon anledning inte fungerade på servern var det lättare att ta bort servern, fixa spelboken och köra den igen. Det fanns i princip ingen versionshantering av skript, ingen portabilitet av konfigurationer.
Till exempel ville vi ändra några konfigurationer på alla servrar:
- Vi ändrar konfigurationen på befintliga servrar i det logiska segmentet/datacentret. Ibland inte på en dag - tillgänglighetskrav och lagen om stora siffror tillåter inte att alla ändringar tillämpas på en gång. Och vissa förändringar är potentiellt destruktiva och kräver att något startas om - från tjänster till själva operativsystemet.
- Fixar det i Ansible
- Vi fixar det i Cobbler
- Upprepa N gånger för varje logiskt segment/datacenter
För att alla förändringar skulle gå smidigt var det nödvändigt att ta hänsyn till många faktorer, och förändringar sker ständigt.
- Refaktorering av eventuell kod, konfigurationsfiler
- Ändra interna bästa praxis
- Förändringar baserat på resultat av analys av tillbud/olyckor
- Förändrade säkerhetsstandarder, både interna och externa. Till exempel uppdateras PCI DSS med nya krav varje år
Infrastrukturtillväxt och början på resan
Antalet servrar/logiska domäner/datacenter växte, och med dem antalet fel i konfigurationer. Vid något tillfälle kom vi till tre riktningar där konfigurationshantering måste utvecklas:
- Automatisering. Mänskliga fel vid upprepade operationer bör undvikas så mycket som möjligt.
- Repeterbarhet. Det är mycket lättare att hantera infrastruktur när den är förutsägbar. Konfigurationen av servrar och verktyg för deras förberedelse bör vara densamma överallt. Detta är också viktigt för produktteam – efter testning måste applikationen garanteras hamna i en produktionsmiljö konfigurerad på liknande sätt som testmiljön.
- Enkelhet och transparens för att göra ändringar i konfigurationshantering.
Det återstår att lägga till ett par verktyg.
Vi valde GitLab CE som vårt kodlager, inte minst för dess inbyggda CI/CD-moduler.
Vault of secrets - Hashicorp Vault, inkl. för det stora API:et.
Testa konfigurationer och eventuella roller – Molecule+Testinfra. Tester går mycket snabbare om du ansluter till ansible mitogen. Samtidigt började vi skriva vår egen CMDB och orkestrator för automatisk driftsättning (på bilden ovan Cobbler), men det här är en helt annan historia, som min kollega och huvudutvecklaren av dessa system kommer att berätta i framtiden.
Vårt val:
Molekyl + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Egen utveckling)
Skomakare
Gitlab + GitLab löpare
Hashicorp valv
Förresten, om möjliga roller. Först fanns det bara en, men efter flera refaktoreringar fanns det 17 av dem. Jag rekommenderar starkt att dela upp monoliten i idempotenta roller, som sedan kan startas separat; dessutom kan du lägga till taggar. Vi delade upp rollerna efter funktionalitet - nätverk, loggning, paket, hårdvara, molekyl mm. I allmänhet följde vi strategin nedan. Jag insisterar inte på att detta är den enda sanningen, men det fungerade för oss.
- Att kopiera servrar från den "gyllene bilden" är ont!Den största nackdelen är att du inte vet exakt vilket tillstånd bilderna är i nu, och att alla ändringar kommer att komma till alla bilder i alla virtualiseringsfarmar.
- Använd standardkonfigurationsfiler till ett minimum och kom överens med andra avdelningar om att du är ansvarig för huvudsystemfilerna, till exempel:
- Lämna /etc/sysctl.conf tom, inställningarna ska bara finnas i /etc/sysctl.d/. Din standard i en fil, anpassad för applikationen i en annan.
- Använd åsidosättande filer för att redigera systemd-enheter.
- Malla alla konfigurationer och inkludera dem helt, om möjligt, inga sed eller dess analoger i playbooks
- Refaktorering av koden för konfigurationshanteringssystemet:
- Bryt ner uppgifter i logiska enheter och skriv om monoliten till roller
- Använd linters! Ansible-lint, yaml-lint, etc
- Ändra ditt förhållningssätt! Inget tjatigt. Det är nödvändigt att beskriva systemets tillstånd
- För alla Ansible-roller behöver du skriva tester i molekyl och generera rapporter en gång om dagen.
- I vårt fall, efter att ha förberett testerna (av vilka det finns fler än 100), hittades cirka 70000 XNUMX fel. Det tog flera månader att fixa det.
Vår implementering
Så, de ansible rollerna var klara, mallade och kontrollerade av linters. Och även gits höjs överallt. Men frågan om tillförlitlig kodleverans till olika segment förblev öppen. Vi bestämde oss för att synkronisera med skript. Ser ut så här:
Efter att ändringen har kommit lanseras CI, en testserver skapas, roller rullas ut och testas av molekylen. Om allt är ok, går koden till prod-grenen. Men vi tillämpar inte ny kod på befintliga servrar i maskinen. Detta är ett slags propp som är nödvändigt för hög tillgänglighet av våra system. Och när infrastrukturen blir enorm spelar lagen om stora siffror in – även om man är säker på att förändringen är ofarlig kan den leda till ödesdigra konsekvenser.
Det finns också många alternativ för att skapa servrar. Det slutade med att vi valde anpassade Python-skript. Och för 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 är detta vi har kommit fram till, systemet fortsätter att leva och utvecklas.
- 17 Ansible roller för att sätta upp servern. Var och en av rollerna är utformade för att lösa en separat logisk uppgift (loggning, revision, användarauktorisering, övervakning, etc.).
- Rolltestning. Molekyl + TestInfra.
- Egen utveckling: CMDB + Orchestrator.
- Tid för att skapa server är ~30 minuter, automatiserad och praktiskt taget oberoende av uppgiftskön.
- Samma tillstånd/namngivning av infrastrukturen i alla segment - playbooks, repositories, virtualiseringselement.
- Daglig kontroll av serverstatus med generering av rapporter om avvikelser mot standarden.
Jag hoppas att min berättelse kommer att vara användbar för dem som är i början av sin resa. Vilken automatiseringsstack använder du?
Källa: will.com