Se la vostra infrastruttura IT cresce troppo rapidamente, prima o poi vi troverete di fronte a una scelta: aumentare linearmente le risorse umane per supportarla o iniziare l'automazione. Fino a un certo punto, abbiamo vissuto nella prima scelta, poi è iniziato un lungo percorso verso l'Infrastructure-as-Code.
Naturalmente, NSPK non è un startup, ma questa atmosfera permeava l'azienda nei primi anni di vita, e sono stati anni molto interessanti. Mi chiamo , da oltre 10 anni gestisco l'infrastruttura Linux con elevate esigenze di disponibilità. Sono entrato nel team di NSPK a gennaio 2016 e, sfortunatamente, non ho vissuto l'inizio dell'azienda, ma sono arrivato in un periodo di grandi cambiamenti.
In generale, si può dire che il nostro team fornisce all'azienda 2 prodotti. Il primo è l'infrastruttura. La posta deve funzionare, il DNS deve lavorare, e i controller di dominio devono permettervi di accedere ai server, che non devono mai bloccarsi. Il paesaggio IT dell'azienda è enorme! Si tratta di sistemi critici per il business e per la missione, con requisiti di disponibilità per alcuni del 99,999%. Il secondo prodotto sono i server stessi, fisici e virtuali. È necessario monitorare i server esistenti e fornire regolarmente nuovi server ai clienti provenienti da molteplici divisioni. In questo articolo voglio sottolineare come abbiamo sviluppato l'infrastruttura che gestisce il ciclo di vita server.
Inizio del percorso
All'inizio del nostro percorso, il nostro stack tecnologico era composto da:
OS CentOS 7
Controller di dominio FreeIPA
Automazione — Ansible(+Tower), Cobbler
Tutto ciò era distribuito su 3 domini, sparsi su diversi data center. In un data center – sistemi d'ufficio e ambienti di test, negli altri PROD.
La creazione di server in un certo momento si presentava così:
Nel template VM CentOS minimal e il minimo necessario come un corretto /etc/resolv.conf, il resto arriva tramite Ansible.
CMDB – Excel.
Se il server è fisico, invece di copiare una macchina virtuale, veniva installato il sistema operativo tramite Cobbler: negli config di Cobbler si aggiungono gli indirizzi MAC del server target, il server ottiene un indirizzo IP tramite DHCP, e successivamente viene installato il sistema operativo.
Inizialmente abbiamo anche provato a realizzare una sorta di gestione della configurazione in Cobbler. Ma col tempo questo ha iniziato a portare problemi di portabilità delle configurazioni sia verso altri data center che nel codice Ansible per la preparazione delle VM.
Ansible era visto da molti di noi come un comodo ampliamento di Bash, e non ci si è trattenuti nell'utilizzare costrutti con shell, sed. In generale, Bashsible. Questo alla fine portava al fatto che, se un playbook per qualche motivo non funzionava sul server, era più semplice eliminare il server, correggere il playbook e riprovare. In sostanza, non c'era alcun versioning degli script, né portabilità delle configurazioni.
Ad esempio, abbiamo voluto modificare qualche configurazione su tutti i server:
- Modifichiamo la configurazione sui server esistenti nel segmento logico/centro dati. A volte non in un solo giorno: i requisiti di disponibilità e la legge dei grandi numeri non permettono di applicare tutte le modifiche contemporaneamente. Alcune modifiche sono potenzialmente distruttive e richiedono il riavvio di qualcosa, dai servizi fino al sistema operativo stesso.
- Correggiamo in Ansible
- Correggiamo in Cobbler
- Ripetiamo N volte per ogni segmento logico/centro dati
Per garantire che tutte le modifiche avvengano senza intoppi, era necessario tenere conto di numerosi fattori, e le modifiche avvengono costantemente.
- Refactoring del codice ansible, dei file di configurazione
- Modifica delle best practice interne
- Modifiche sulla base di analisi di incidenti/emergenze
- Modifica degli standard di sicurezza, sia interni che esterni. Ad esempio, il PCI DSS ogni anno si arricchisce di nuovi requisiti
Crescita dell'infrastruttura e inizio del percorso
Il numero di server/domini logici/centri dati cresceva, così come il numero di errori nelle configurazioni. A un certo punto, ci siamo trovati a dover sviluppare configuration management in tre direzioni:
- Automazione. Il più possibile, dobbiamo evitare il fattore umano nelle operazioni ripetitive.
- Ripetibilità. Gestire l'infrastruttura è molto più semplice quando è prevedibile. La configurazione dei server e gli strumenti per la loro preparazione devono essere gli stessi ovunque. Questo è altrettanto importante per i team di prodotto: l'applicazione deve garantire di passare in ambiente di produzione dopo i test, configurata in modo analogo all'ambiente di test.
- Semplicità e trasparenza nell'introduzione di modifiche nel configuration management.
È rimasto da aggiungere un paio di strumenti.
Come repository di codice abbiamo scelto GitLab CE, non ultimo per la presenza di moduli CI/CD integrati.
Il repository dei segreti è Hashicorp Vault, anche per l'eccellente API.
Testare le configurazioni e i ruoli ansible – Molecule+Testinfra. I test procedono molto più velocemente se si collega mitogen ad ansible. Parallelamente, abbiamo iniziato a scrivere il nostro CMDB e orchestratore per il deployment automatico (nella foto sopra Cobbler), ma questa è un'altra storia, di cui in futuro parlerà il mio collega e capo sviluppatore di questi sistemi.
La nostra scelta:
Molecule + Testinfra
Ansible + Tower + AWX
Mondo Server + DITNET(Sviluppo Interno)
Cobbler
Gitlab + GitLab runner
Hashicorp Vault
A proposito dei ruoli ansible. Inizialmente ce n'era uno, dopo diversi refactoring sono diventati 17. Raccomando assolutamente di suddividere il monolite in ruoli idempotenti, che possono essere eseguiti separatamente; è possibile aggiungere anche dei tag. Abbiamo suddiviso i ruoli in base alle funzionalità – network, logging, packages, hardware, molecule ecc. In generale, abbiamo seguito la strategia sottostante. Non pretendo che sia la verità universale, ma ha funzionato per noi.
- Copiare server da un "immagine oro" è un male!Tra i principali svantaggi – non si sa esattamente in che stato siano le immagini adesso, e che tutte le modifiche arriveranno a tutte le immagini in tutte le fattorie di virtualizzazione.
- Utilizzate i file di configurazione di default il meno possibile e concordate con gli altri dipartimenti che siete voi a responsabilizzarvi per i principali file di sistema, per esempio:
- Lasciate vuoto /etc/sysctl.conf, le impostazioni devono trovarsi solo in /etc/sysctl.d/. Il vostro default in un file, la personalizzazione per l'applicazione in un altro.
- Utilizzate i file di override per modificare le unità systemd.
- Templatezzate tutte le configurazioni e inseritele interamente, evitando per quanto possibile sed e i suoi equivalenti nei playbook
- Refactoring del codice del sistema di gestione delle configurazioni:
- Suddividete i compiti in entità logiche e riscrivete il monolite in ruoli
- Usate i linters! Ansible-lint, yaml-lint, ecc.
- Cambiati l'approccio! Niente più bashsible. Bisogna descrivere lo stato del sistema
- Per tutti i ruoli Ansible bisogna scrivere dei test in molecule e generare rapporti una volta al giorno.
- Nel nostro caso, dopo la preparazione dei test (di cui oltre 100), sono stati trovati circa 70000 errori. Abbiamo corretto per mesi.
La nostra implementazione
Quindi, i ruoli ansible erano pronti, templatezzati e verificati dai linters. E anche i git erano attivi ovunque. Ma la questione della consegna affidabile del codice in diversi segmenti è rimasta aperta. Abbiamo deciso di sincronizzare tramite script. Ecco come appare:
Dopo che è arrivata la modifica, viene avviato CI, viene creato un server di test, vengono applicati i ruoli e viene testato con molecola. Se tutto va bene, il codice viene inviato nel ramo di produzione. Tuttavia, non applichiamo il nuovo codice ai server esistenti automaticamente. Questo è un tipo di fermo necessario per l'alta disponibilità dei nostri sistemi. E quando l'infrastruttura diventa enorme, entra in gioco anche la legge dei grandi numeri: anche se sei sicuro che la modifica sia innocua, può portare a conseguenze spiacevoli.
Ci sono molte opzioni per la creazione di server. Alla fine, abbiamo scelto script personalizzati in Python. E per CI Ansible:
- name: create1.yml - Crea una VM da un modello
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}}"Ecco dove siamo arrivati, il sistema continua a vivere e a svilupparsi.
- 17 ruoli ansible per la configurazione del server. Ciascuno dei ruoli è destinato a risolvere un compito logico specifico (logging, audit, autorizzazione degli utenti, monitoraggio, ecc.).
- Testing dei ruoli. Molecola + TestInfra.
- Sviluppo interno: CMDB + Orchestratore.
- Tempo di creazione del server ~30 minuti, automatizzato e praticamente non dipendente dalla coda delle attività.
- Stato/nome uniforme dell'infrastruttura in tutti i segmenti – playbook, repository, elementi di virtualizzazione.
- Controllo quotidiano dello stato dei server con generazione di report sulle discrepanze rispetto al modello di riferimento.
Spero che il mio racconto sia utile a chi è all'inizio del percorso. Quale stack di automazione utilizzate voi?
Fonte: habr.com
