Se la tua infrastruttura IT cresce troppo rapidamente, prima o poi ti troverai di fronte a una scelta: aumentare in modo lineare le risorse umane per supportarla o avviare l’automazione. Fino a un certo punto abbiamo vissuto nel primo paradigma, poi è iniziato il lungo percorso verso Infrastructure-as-Code.
Naturalmente, NSPK non è una startup, ma una tale atmosfera regnava nell'azienda nei primi anni della sua esistenza, e quelli furono anni molto interessanti. Mi chiamo , supporto l'infrastruttura Linux con requisiti di elevata disponibilità da oltre 10 anni. È entrato a far parte del team NSPK nel gennaio 2016 e, sfortunatamente, non ha visto l'inizio dell'esistenza dell'azienda, ma è arrivato in una fase di grandi cambiamenti.
In generale possiamo dire che il nostro team fornisce 2 prodotti per l'azienda. Il primo sono le infrastrutture. La posta dovrebbe funzionare, il DNS dovrebbe funzionare e i controller di dominio dovrebbero consentirti di accedere a server che non dovrebbero bloccarsi. Il panorama IT dell'azienda è enorme! Si tratta di sistemi business&mission critical, i requisiti di disponibilità per alcuni sono 99,999. Il secondo prodotto sono i server stessi, fisici e virtuali. Quelli esistenti devono essere monitorati e quelli nuovi devono essere consegnati regolarmente ai clienti di molti dipartimenti. In questo articolo voglio concentrarmi su come abbiamo sviluppato l'infrastruttura responsabile del ciclo di vita del server.
Inizio di un viaggio
All'inizio del nostro viaggio, il nostro stack tecnologico appariva così:
Sistema operativo CentOS 7
Controller di dominio IPA gratuiti
Automazione: Ansible(+Tower), Cobbler
Tutto questo era localizzato in 3 domini, distribuiti su diversi data center. In un data center ci sono sistemi di ufficio e siti di test, nel resto c'è PROD.
La creazione dei server a un certo punto assomigliava a questa:
Nel modello VM, CentOS è minimo e il minimo richiesto è come il /etc/resolv.conf corretto, il resto arriva tramite Ansible.
CMDB-Excel.
Se il server è fisico, invece di copiare la macchina virtuale, il sistema operativo è stato installato su di essa utilizzando Cobbler: gli indirizzi MAC del server di destinazione vengono aggiunti alla configurazione di Cobbler, il server riceve un indirizzo IP tramite DHCP e quindi il sistema operativo è aggiunto.
All'inizio abbiamo anche provato a eseguire una sorta di gestione della configurazione in Cobbler. Ma nel tempo, ciò ha iniziato a portare problemi con la portabilità delle configurazioni sia su altri data center che sul codice Ansible per la preparazione delle VM.
A quel tempo, molti di noi percepivano Ansible come una comoda estensione di Bash e non lesinavano sui progetti che utilizzavano shell e sed. Nel complesso Bashsible. Ciò alla fine ha portato al fatto che se per qualche motivo il playbook non funzionava sul server, era più semplice eliminare il server, correggere il playbook ed eseguirlo di nuovo. Essenzialmente non esisteva il controllo delle versioni degli script, né la portabilità delle configurazioni.
Ad esempio, volevamo modificare alcune configurazioni su tutti i server:
- Modifichiamo la configurazione sui server esistenti nel segmento logico/data center. A volte non in un giorno: i requisiti di accessibilità e la legge dei grandi numeri non consentono di applicare tutte le modifiche in una volta. E alcune modifiche sono potenzialmente distruttive e richiedono il riavvio di qualcosa, dai servizi al sistema operativo stesso.
- Risolto il problema in Ansible
- Lo sistemiamo in Cobbler
- Ripetere N volte per ciascun segmento logico/data center
Affinché tutti i cambiamenti avvengano senza intoppi, è stato necessario tenere conto di molti fattori e i cambiamenti si verificano costantemente.
- Refactoring del codice ansible, file di configurazione
- Modifica delle migliori pratiche interne
- Modifiche basate sui risultati dell'analisi degli incidenti/incidenti
- Cambiare gli standard di sicurezza, sia interni che esterni. Ad esempio, PCI DSS viene aggiornato ogni anno con nuovi requisiti
Crescita delle infrastrutture e inizio del viaggio
È cresciuto il numero di server/domini logici/data center e con essi il numero di errori nelle configurazioni. Ad un certo punto, siamo arrivati a tre direzioni in cui deve essere sviluppata la gestione della configurazione:
- Automazione. L’errore umano nelle operazioni ripetitive dovrebbe essere evitato il più possibile.
- Ripetibilità. È molto più semplice gestire l’infrastruttura quando è prevedibile. La configurazione dei server e degli strumenti per la loro preparazione dovrebbe essere la stessa ovunque. Questo è importante anche per i team di prodotto: dopo il test, deve essere garantito che l'applicazione finisca in un ambiente di produzione configurato in modo simile all'ambiente di test.
- Semplicità e trasparenza nell'apportare modifiche alla gestione della configurazione.
Resta da aggiungere un paio di strumenti.
Abbiamo scelto GitLab CE come repository del codice, anche per i suoi moduli CI/CD integrati.
Deposito di segreti - Hashicorp Vault, incl. per la fantastica API.
Test di configurazioni e ruoli ansible – Molecule+Testinfra. I test vanno molto più velocemente se ti connetti ad ansible mitogen. Allo stesso tempo, abbiamo iniziato a scrivere il nostro CMDB e il nostro orchestratore per la distribuzione automatica (nella foto sopra Cobbler), ma questa è una storia completamente diversa, che il mio collega e principale sviluppatore di questi sistemi racconterà in futuro.
La nostra scelta:
Molecola + Testinfra
Ansible + Torre + AWX
Mondo dei server + DITNET (sviluppo proprio)
Ciabattino
Corridore Gitlab + GitLab
Cripta di Hashicorp
A proposito, sui ruoli ansible. All'inizio ce n'era solo uno, ma dopo diversi refactoring erano 17. Consiglio vivamente di suddividere il monolite in ruoli idempotenti, che possono poi essere avviati separatamente; inoltre è possibile aggiungere tag. Abbiamo diviso i ruoli per funzionalità: rete, registrazione, pacchetti, hardware, molecola, ecc. In generale, abbiamo seguito la strategia seguente. Non insisto sul fatto che questa sia l’unica verità, ma per noi ha funzionato.
- Copiare i server dall'“immagine d'oro” è un male!Lo svantaggio principale è che non si sa esattamente in quale stato si trovano le immagini adesso e che tutte le modifiche verranno apportate a tutte le immagini in tutte le farm di virtualizzazione.
- Utilizza i file di configurazione predefiniti al minimo e concorda con gli altri reparti che sei responsabile dei file di sistema principali, ad esempio:
- Lascia vuoto /etc/sysctl.conf, le impostazioni dovrebbero essere solo in /etc/sysctl.d/. Il valore predefinito in un file, quello personalizzato per l'applicazione in un altro.
- Utilizza i file di override per modificare le unità systemd.
- Modella tutte le configurazioni e includile interamente; se possibile, niente sed o suoi analoghi nei playbook
- Refactoring del codice del sistema di gestione della configurazione:
- Suddividi le attività in entità logiche e riscrivi il monolite in ruoli
- Usa i linter! Ansible-lint, yaml-lint, ecc
- Cambia il tuo approccio! Nessun bashable. È necessario descrivere lo stato del sistema
- Per tutti i ruoli Ansible è necessario scrivere test in molecola e generare report una volta al giorno.
- Nel nostro caso, dopo aver preparato i test (di cui ce ne sono più di 100), sono stati rilevati circa 70000 errori. Ci sono voluti diversi mesi per risolverlo.
La nostra implementazione
Quindi, i ruoli ansible erano pronti, modellati e controllati dai linter. E anche gli idioti vengono allevati ovunque. Ma la questione della consegna affidabile del codice ai diversi segmenti è rimasta aperta. Abbiamo deciso di sincronizzarci con gli script. Sembra così:
Dopo l'arrivo della modifica, viene avviata la CI, viene creato un server di test, i ruoli vengono implementati e testati dalla molecola. Se tutto è ok, il codice va al ramo prod. Ma non applichiamo il nuovo codice ai server esistenti nella macchina. Questo è un tipo di tappo necessario per l'elevata disponibilità dei nostri sistemi. E quando l’infrastruttura diventa enorme, entra in gioco la legge dei grandi numeri: anche se si è sicuri che il cambiamento sia innocuo, può portare a conseguenze disastrose.
Ci sono anche molte opzioni per creare server. Alla fine abbiamo scelto script Python personalizzati. E 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}}"Questo è ciò a cui siamo arrivati, il sistema continua a vivere e svilupparsi.
- 17 Ruoli Ansible per la configurazione del server. Ciascuno dei ruoli è progettato per risolvere un compito logico separato (registrazione, controllo, autorizzazione utente, monitoraggio, ecc.).
- Test di ruolo. Molecola + TestInfra.
- Sviluppo proprio: CMDB + Orchestrator.
- Il tempo di creazione del server è di circa 30 minuti, automatizzato e praticamente indipendente dalla coda delle attività.
- Lo stesso stato/denominazione dell'infrastruttura in tutti i segmenti: playbook, repository, elementi di virtualizzazione.
- Controllo giornaliero dello stato dei server con generazione di report sulle discrepanze rispetto allo standard.
Spero che la mia storia possa essere utile a coloro che sono all'inizio del loro viaggio. Quale stack di automazione usi?
Fonte: habr.com