Från "startup" till tusentals servrar i ett dussin datacenter. Hur vi jagade tillväxten av Linux-infrastrukturen

Om din IT-infrastruktur växer för snabbt, kommer du förr eller senare att stå inför valet – att linjärt öka personalresurserna för att stödja den, eller att börja automatisera. Fram till en viss punkt levde vi i den första paradigmen, och sedan började den långa vägen mot Infrastructure-as-Code.

Självklart är NSPK inte en startup, men en sådan atmosfär rådde i företaget under de första åren, och det var mycket intressanta år. Jag heter Dmitrij Kornev, jag har i över 10 år stöttat Linux-infrastruktur med höga tillgänglighetskrav. Jag gick med i NSPK i januari 2016 och fick tyvärr inte uppleva företagets början, men jag kom in på en tid med stora förändringar.

Överlag kan man säga att vårt team levererar två produkter för företaget. Första produkten är infrastrukturer. E-posten måste gå, DNS måste fungera, och domänkontrollerna måste släppa in er på servrar som inte får falla. Företagets IT-landskap är enormt! Detta är affärs- och mission-critical system, vissa har tillgänglighetskrav på 99,999. Den andra produkten är själva servrarna, både fysiska och virtuella. De befintliga måste ö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 ansvarar för livscykeln servrar.

Framstegens början

I början av vår resa såg vår teknikstack ut så här:
OS CentOS 7
Domänkontroller FreeIPA
Automatisering – Ansible(+Tower), Cobbler

Allt detta var fördelat på 3 domäner, spridda över flera datacenter. I ett datacenter fanns kontorssystem och testmiljöer, i de andra PROD.

Skapandet av servrar såg vid något tillfälle ut så här:

I mallen för VM CentOS minimal och den nödvändiga minimigränsen som en korrekt /etc/resolv.conf, resten kommer via Ansible.

CMDB – Excel.

Om servern är fysisk, installeras operativsystemet direkt istället för att kopiera en virtuell maskin till den, med hjälp av Cobbler – MAC-adresserna för den målservern läggs till i Cobbler-konfigurationen, servern får IP-adress via DHCP, och sedan installeras operativsystemet.

I början försökte vi till och med göra någon slags configuration management i Cobbler. Men med tiden började det orsaka problem med portabilitet av konfigurationer både till andra datacenter och i Ansible-kod för att förbereda VM.

Många av oss uppfattade Ansible som en bekväm utvidgning av Bash och var inte försiktiga med att använda konstruktioner med shell, sed. I stort sett var det Bashsible. Detta ledde till att om en playbook av någon anledning inte fungerade på servern, var det enklare att ta bort servern, justera playbooken och köra om. Det fanns i praktiken ingen versionering av skripten, inte heller någon bärbarhet i konfigurationerna.

Till exempel ville vi ändra en konfiguration på alla servrar:

1. Ändrar konfigurationen på befintliga servrar i den logiska segmentet/datacentret. Ibland inte på en dag – tillgångskrav och storhetens lag tillåter inte att alla ändringar tillämpas på en gång. Vissa ändringar kan potentiellt vara destruktiva och kräver omstart av något – från tjänster till själva operativsystemet.
2. Fixar i Ansible
3. Fixar i Cobbler
4. Upprepa N gånger för varje logiskt segment/datacenter

För att alla ändringar ska gå smidigt måste man ta hänsyn till många faktorer, och ändringar sker hela tiden.

• Refaktorering av ansible-kod, konfigurationsfiler
• Ändring av interna bästa metoder
• Ändringar efter utvärdering av incidenter/olyckor
• Ändring av säkerhetsstandarder, både interna och externa. Till exempel PCI DSS kompletteras varje år med nya krav.

Tillväxt av infrastrukturen och början av resan

Antalet servrar/logiska domäner/datacenter ökade, liksom antalet fel i konfigurationerna. Vid något tillfälle kom vi fram till tre områden som vi behövde utveckla konfigurationshantering åt:

1. Automatisering. Så mycket som möjligt, bör vi undvika den mänskliga faktorn i repetitiva operationer.
2. Repetitivitet. Det är mycket enklare att hantera infrastrukturen när den är förutsägbar. Konfigurationen av servrar och verktyg för deras förberedelse bör vara densamma överallt. Det är också viktigt för produktteam – applikationen måste garanteras hamna i produktionsmiljö efter testning, inställd på samma sätt som testmiljön.
3. Enkelhet och transparens i att göra ändringar i konfigurationshanteringen.

Det kvarstår bara att lägga till ett par verktyg.

Som kodförvaring valde vi GitLab CE, inte minst för dess inbyggda CI/CD-moduler.

För hemlighetslagring – Hashicorp Vault, också för dess utmärkta API.

Testkonfigurationer och Ansible-roller – Molecule + Testinfra. Tester går mycket snabbare om du ansluter mitogen till Ansible. Samtidigt började vi skriva vår egen CMDB och orkestrator för automatisk distribution (på bilden ovanför Cobbler), men det är en helt annan historia som min kollega och huvudutvecklare av dessa system kommer att berätta om i framtiden.

Vårt val:

Molecule + Testinfra
Ansible + Tower + AWX
Världen av servrar + DITNET (Egen utveckling)
Cobbler
Gitlab + GitLab-runner
Hashicorp Vault

Förresten om Ansible-roller. Till en början fanns det bara en, men efter flera refaktoriseringar blev det 17. Jag rekommenderar starkt att dela upp monoliten i idempotenta roller som kan köras separat, och ni kan dessutom lägga till taggar. Vi delade upp rollerna baserat på funktionalitet – nätverk, loggning, paket, hårdvara, molekyl osv. Och i allmänhet följde vi strategin nedan. Jag påstår inte att detta är den enda sanna metoden, men det fungerade för oss.

• Kopiera servrar från "guldbilden" – en dålig idé!De huvudsakliga nackdelarna är att du helt enkelt inte vet i vilket skick bilderna är just nu, och att alla ändringar kommer att påverka alla bilder i alla virtualiseringsfarmar.
• Använd standardkonfigurationsfiler så lite som möjligt och kom överens med andra avdelningar om att du ansvarar för de huvudsakliga systemfilerna, till exempel:
  1. Lämna /etc/sysctl.conf tom, inställningarna bör ligga i /etc/sysctl.d/. Din standard i en fil, anpassningar för applikationen i en annan.
  2. Använd override-filer för att redigera systemd-enheter.
• Mallar alla konfigurationer och lägg in dem helt, så mycket som möjligt inga sed- eller liknande kommandon i playbooks.
• Refaktorisera koden för konfigurationshanteringssystemet:
  1. Dela upp uppgifterna i logiska enheter och skriv om monoliten till roller.
  2. Använd linters! Ansible-lint, yaml-lint, osv.
  3. Ändra tillvägagångssätt! Ingen bashsible. Det behöver beskrivas hur systemets tillstånd ska vara.
• För alla Ansible-roller måste tester skrivas i Molecule och rapporter genereras en gång om dagen.
• I vårt fall, efter att testerna (mer än 100) förbereddes, hittades omkring 70 000 fel. Det tog flera månader att rätta till.

Vår implementering

Så, Ansible-rollerna var klara, mallade och kontrollerade av linters. Och även git var uppe överallt. Men frågan om tillförlitlig kodleverans till olika segment förblev öppen. Vi beslutade att synkronisera med skript. Så här ser det ut:

Efter att ändringen har anlänt, startas CI, en testserver skapas, roller körs och testas med Molecule. Om allt ser bra ut, går koden till produktionsgrenen. Men vi tillämpar inte ny kod på existerande servrar automatiskt. Detta är en slags stoppmekanism som behövs för att säkerställa hög tillgänglighet i våra system. När infrastrukturen blir enorm, spelar också storhetens lag in – även om du är säker på att förändringen är harmlös, kan den leda till sorgliga konsekvenser.

Det finns många alternativ för att skapa servrar. Vi valde till slut anpassade skript i Python. Och för CI använder vi Ansible:

- name: create1.yml - Skapa en VM från en mall
  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}}"

Så här har vi kommit fram, systemet fortsätter att leva och utvecklas.

• 17 Ansible-roller för serverkonfiguration. Varje roll är avsedd för att lösa en specifik logisk uppgift (loggning, revision, användarautentisering, övervakning osv.).
• Testning av roller. Molecule + TestInfra.
• Egenutveckling: CMDB + Orkestrator.
• Serverns skapande tar cirka 30 minuter, är automatiserat och påverkas praktiskt taget inte av köer av uppgifter.
• Samma tillstånd/namn på infrastrukturen i alla segment – playbooks, repository, virtualiseringselement.
• Daglig kontroll av serverstatus med rapportgenerering om avvikelser från standard.

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 ni?

Källa: habr.com