🥇Da una "startup" à migliaia di servitori in una decina di centri di dati. Cumu perseguitemu a crescita di l'infrastruttura Linux

Se a vostra infrastruttura IT cresce troppu rapidamente, prima o poi sarete affruntatu cù una scelta: aumentà linearmente e risorse umane per sustenela o inizià l'automatizazione. Finu à un certu puntu, avemu campatu in u primu paradigma, è dopu a longa strada di Infrastructure-as-Code principia.

Di sicuru, NSPK ùn hè micca una startup, ma una tale atmosfera hà regnatu in a cumpagnia in i primi anni di a so esistenza, è quelli eranu anni assai interessanti. Mi chjamu Kornyakov Dmitry, Aghju supportatu l'infrastruttura Linux cù esigenze di alta dispunibilità per più di 10 anni. S'hè unitu à a squadra NSPK in ghjennaghju 2016 è, sfurtunatamenti, ùn hà micca vistu u principiu di l'esistenza di a cumpagnia, ma hè ghjuntu in una tappa di grandi cambiamenti.

In generale, pudemu dì chì a nostra squadra furnisce 2 prudutti per a cumpagnia. U primu hè l'infrastruttura. U mail duveria travaglià, u DNS deve travaglià, è i cuntrolli di duminiu duveranu lascià in i servitori chì ùn deve micca crash. U paisaghju IT di a cumpagnia hè enormu! Quessi sò sistemi di affari è missioni critichi, i requisiti di dispunibilità per alcuni sò 99,999. U sicondu pruduttu sò i servitori stessi, fisici è virtuali. L'esistenti deve esse monitoratu, è i novi devenu esse regulati à i clienti da parechji dipartimenti. In questu articulu vogliu fucalizza nantu à cumu avemu sviluppatu l'infrastruttura chì hè rispunsevule per u ciclu di vita di u servitore.

U principiu di a strada

À u principiu di u nostru viaghju, a nostra pila di tecnulugia pareva cusì:
OS CentOS 7
Controller di Dominiu FreeIPA
Automatizazione - Ansible (+ Tower), Cobbler

Tuttu chistu era situatu in 3 duminii, spargugliati in parechji centri di dati. In un centru di dati ci sò sistemi d'uffiziu è siti di teste, in u restu ci hè PROD.

A creazione di servitori in un puntu pareva cusì:

In u mudellu VM, CentOS hè minimu è u minimu necessariu hè cum'è u correctu /etc/resolv.conf, u restu vene da Ansible.

CMDB - Excel.

Se u servitore hè fisicu, invece di copià a macchina virtuale, u SO hè stata installata nantu à questu cù Cobbler - l'indirizzi MAC di u servitore di destinazione sò aghjuntu à a cunfigurazione di Cobbler, u servitore riceve un indirizzu IP via DHCP, è dopu u SO. hè aghjuntu.

À u primu, avemu ancu pruvatu à fà una certa gestione di cunfigurazione in Cobbler. Ma cù u tempu, questu hà cuminciatu à purtà prublemi cù a portabilità di cunfigurazioni à l'altri centri di dati è à u codice Ansible per a preparazione di VM.

À quellu tempu, assai di noi perceve Ansible cum'è una estensione còmuda di Bash è ùn anu micca scuntatu nantu à i disinni cù shell è sed. Bashsible in generale. Questu ultimamente hà purtatu à u fattu chì se u playbook per una certa ragione ùn hà micca travagliatu nantu à u servitore, era più faciule per sguassà u servitore, riparà u playbook è eseguite di novu. Ùn ci era essenzialmente micca versione di scripts, nè portabilità di cunfigurazioni.

Per esempiu, vulemu cambià qualchì cunfigurazione in tutti i servitori:

Cambiamu a cunfigurazione nantu à i servitori esistenti in u segmentu logicu / centru di dati. A volte micca in un ghjornu - i bisogni di l'accessibilità è a lege di grandi numeri ùn permettenu micca tutti i cambiamenti per esse applicati in una volta. È certi cambiamenti sò potenzialmente distruttivi è necessitanu di riavvià qualcosa - da i servizii à u SO stessu.
Fixing lu in Ansible
Fixemu in Cobbler
Repetite N volte per ogni segmentu logicu / centru di dati

Per chì tutti i cambiamenti vanu bè, era necessariu di piglià in contu parechji fatturi, è i cambiamenti sò sempre.

Refactoring codice ansible, schedarii di cunfigurazione
Cambiamentu di e migliori pratiche interne
Cambiamenti basati nantu à i risultati di l'analisi di incidenti / accidenti
Cambiamentu di i normi di sicurità, sia interni sia esterni. Per esempiu, PCI DSS hè aghjurnatu cù novi esigenze ogni annu

A crescita di l'infrastruttura è u principiu di u viaghju

U numaru di servitori / duminii lògichi / centri di dati criscinu, è cun elli u numeru di errori in cunfigurazioni. À un certu puntu, avemu ghjuntu à trè direzzione in quale a gestione di cunfigurazione deve esse sviluppata:

L'automatizazione. L'errore umanu in operazioni ripetitive deve esse evitata quant'è pussibule.
Ripetibilità. Hè assai più faciule di gestisce l'infrastruttura quandu hè prevedibile. A cunfigurazione di servitori è arnesi per a so preparazione deve esse listessi in ogni locu. Questu hè ancu impurtante per e squadre di produttu - dopu a prova, l'applicazione deve esse garantita per finisce in un ambiente di produzzione cunfiguratu in modu simile à l'ambiente di prova.
Semplicità è trasparenza di fà cambiamenti à a gestione di cunfigurazione.

Resta à aghjunghje un paru di arnesi.

Avemu sceltu GitLab CE cum'è u nostru repository di codice, micca menu per i so moduli CI / CD integrati.

Vault of secrets - Hashicorp Vault, incl. per a grande API.

Testing cunfigurazioni è roli ansible - Molecule + Testinfra. I testi vanu assai più veloce si cunnetta à mitogenu ansible. À u stessu tempu, avemu cuminciatu à scrive u nostru propiu CMDB è orchestrator per u dispiegamentu automaticu (in a stampa sopra Cobbler), ma questu hè una storia completamente diversa, chì u mo cumpagnu è u sviluppatore principale di sti sistemi diciaranu in u futuru.

A nostra scelta:

Molecule + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Sviluppu propiu)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault

Per via, nantu à i roli ansible. À u principiu, ci era solu unu, ma dopu à parechji refactorings ci sò stati 17 di elli, ricumandemu fermamente di rompe u monolitu in roles idempotenti, chì ponu esse lanciati in più, pudete aghjunghje tag. Avemu divisu i roli per funziunalità - rete, logging, pacchetti, hardware, molécula, etc. In generale, avemu seguitu a strategia sottu. Ùn insistiu micca chì questu hè l'unica verità, ma hà travagliatu per noi.

Copià i servitori da a "imagine d'oru" hè male!U principale disadvantage hè chì ùn sapete micca esattamente quale statu l'imaghjini sò in avà, è chì tutti i cambiamenti venenu à tutte l'imaghjini in tutte e splutazioni di virtualizazione.
Aduprate i schedarii di cunfigurazione predeterminati à u minimu è d'accordu cù altri dipartimenti chì site rispunsevuli di i schedarii principali di u sistema, per esempiu:
1. Lasciate /etc/sysctl.conf viotu, i paràmetri sò solu in /etc/sysctl.d/. U vostru predeterminatu in un schedariu, persunalizatu per l'applicazione in un altru.
2. Aduprate i fugliali di override per edità unità di sistema.
Template tutte e cunfigurazioni è includenu sanu sanu se pussibule, senza sed o i so analoghi in playbooks
Refactoring u codice di u sistema di gestione di cunfigurazione:
1. Scompone i travaglii in entità logiche è scrive u monolitu in roli
2. Aduprate linters! Ansible-lint, yaml-lint, etc
3. Cambia u vostru approcciu! Nisun bashsible. Hè necessariu di discrive u statu di u sistema
Per tutti i roli Ansible avete bisognu di scrive testi in molecule è generà rapporti una volta à ghjornu.
In u nostru casu, dopu avè preparatu e teste (di quale ci sò più di 100), circa 70000 XNUMX errori sò stati truvati. Pigliò parechji mesi per riparà.

A nostra implementazione

Allora, i roli ansible eranu pronti, mudelli è verificati da linters. E ancu i gits sò risuscitati in ogni locu. Ma a quistione di a consegna di codice affidabile à i diversi segmenti resta aperta. Avemu decisu di sincronizà cù scripts. Sembra cusì:

Dopu chì u cambiamentu hè ghjuntu, CI hè lanciatu, un servitore di teste hè creatu, i roli sò sbulicati, è pruvati da a molécula. Se tuttu hè bè, u codice va à u ramu prod. Ma ùn applicà micca novu codice à i servitori esistenti in a macchina. Questu hè un tipu di tappu chì hè necessariu per una alta dispunibilità di i nostri sistemi. È quandu l'infrastruttura diventa enormi, a lege di i grandi numeri entra in ghjocu - ancu s'è sì sicuru chì u cambiamentu hè innocu, pò purtà à cunsequenze terribili.

Ci hè ancu parechje opzioni per creà servitori. Avemu finitu per sceglie scripts Python persunalizati. È per 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}}"

Hè ciò chì avemu ghjuntu, u sistema cuntinueghja à campà è à sviluppà.

17 Roli Ansible per a stallazione di u servitore. Ogni rolu hè pensatu per risolve un compitu logicu separatu (logging, auditing, authorization user, monitoring, etc.).
Test di rolu. Molecule + TestInfra.
Sviluppu propiu: CMDB + Orchestrator.
U tempu di creazione di u servitore hè ~ 30 minuti, automatizatu è praticamente indipendente da a fila di attività.
U stessu statu / nome di l'infrastruttura in tutti i segmenti - playbooks, repository, elementi di virtualizazione.
Cuntrolla ogni ghjornu di u statutu di u servitore cù generazione di rapporti nantu à discrepanze cù u standard.

Spergu chì a mo storia serà utile à quelli chì sò à u principiu di u so viaghju. Chì pila d'automatizazione utilizate?

Source: www.habr.com

Da un "startup" à millaie di servitori in una decina di centri di dati. Cumu perseguimu a crescita di l'infrastruttura Linux