Il periodo si avvicinava al Capodanno. I bambini di tutto il paese avevano già inviato lettere a Babbo Natale o avevano desiderato regali per sé, mentre il principale attore di questa attività — uno dei grandi rivenditori — si preparava all'apice delle vendite. A dicembre, il carico sul suo centro di dati cresce di diverse volte. Per questo motivo, l'azienda ha deciso di modernizzare il data center e di mettere in funzione diverse decine di nuovi server al posto dell'hardware la cui vita utile stava per scadere. La nostra storia termina qui, sullo sfondo di fiocchi di neve che cadono, e inizia il thriller.
L'hardware è arrivato sul sito alcuni mesi prima del picco delle vendite. Il servizio operativo, ovviamente, sa come e cosa configurare sui server per metterli in ambiente di produzione. Ma avevamo bisogno di automatizzare questo processo ed escludere il fattore umano. Inoltre, i server sostituivano, prima della migrazione, un insieme di sistemi SAP critici per l'azienda.
L'attivazione dei nuovi server era rigidamente legata a una scadenza. Spostarla significava mettere in pericolo sia la spedizione di un miliardo di regali che la migrazione dei sistemi. Nessuna squadra, nemmeno quella di Babbo Natale o di Santa Claus, avrebbe potuto cambiare la data; il sistema SAP per la gestione del magazzino può essere spostato solo una volta all'anno. Dal 31 dicembre al 1 gennaio, i giganteschi magazzini del rivenditore, per un totale come 20 campi da calcio, interrompono la loro attività per 15 ore. E questo è l'unico intervallo di tempo disponibile per il trasferimento del sistema. Non avevamo margini di errore nell'attivazione dei server.
Spiego subito: il mio racconto riflette gli strumenti e il processo di gestione delle configurazioni utilizzati dal nostro team.
Il complesso di gestione delle configurazioni è composto da più livelli. Il componente chiave è il sistema CMS. In un'operazione industriale, l'assenza di uno dei livelli avrebbe inevitabilmente portato a inconvenienti indesiderati.
Gestione dell'installazione del sistema operativo
Il primo livello è il sistema di gestione dell'installazione dei sistemi operativi su server fisici e virtuali. Crea configurazioni di sistema operativo di base, eliminando il fattore umano.
Con questo sistema ottenevamo esemplari standard e adatti per ulteriori automazioni dei server con OS. Durante il "deployment" ottenevano un insieme minimo di utenti locali e chiavi pubbliche SSH, oltre a una configurazione concordata dell'OS. Potevamo gestire i server garantendo l'accesso tramite CMS e eravamo certi che "in basso", a livello di OS, non ci fossero sorprese.
L'obiettivo "massimo" per il sistema di gestione dei deployment è quello di configurare automaticamente i server dal livello BIOS/Firmware fino all'OS. Molto dipende qui dall'hardware e dalle attività di configurazione. Per hardware eterogeneo si può considerare . Se tutto "l'hardware" proviene da un unico fornitore, spesso è più conveniente utilizzare strumenti di gestione predefiniti (ad esempio, HP ILO Amplifier, DELL OpenManage, ecc.).
Per l'installazione dell'OS sui server fisici abbiamo utilizzato il ben noto Cobbler, nel quale era definito un insieme di profili di installazione concordati con il servizio di operazioni. Quando un nuovo server veniva aggiunto all'infrastruttura, l'ingegnere associava l'indirizzo MAC del server al profilo richiesto in Cobbler. Durante il primo avvio in rete, il server riceveva un indirizzo temporaneo e un nuovo OS. Successivamente veniva trasferito nella VLAN/allocazione IP target e continuava a lavorare lì. Sì, cambiare la VLAN richiede tempo e approvazione, ma offre ulteriore protezione contro l'installazione accidentale del server nell'ambiente di produzione.
I server virtuali li creavamo sulla base di modelli, preparati con HashiCorp Packer. La ragione era la stessa: prevenire possibili errori umani durante l'installazione dell'OS. Ma, a differenza dei server fisici, Packer permette di non utilizzare PXE, avvio di rete e cambio VLAN. Questo ha reso più facile e semplice la creazione di server virtuali.
Fig. 1. Gestione dell'installazione dei sistemi operativi.
Gestione dei segreti
Qualsiasi sistema di gestione delle configurazioni contiene dati che devono essere nascosti agli utenti normali, ma necessari per la preparazione dei sistemi. Questi sono le password degli utenti locali e degli account di servizio, le chiavi dei certificati, vari API Tokens, ecc. Di solito vengono chiamati "segreti".
Se fin dall'inizio non si definisce dove e come conservare questi segreti, a seconda della severità dei requisiti di sicurezza delle informazioni, sono probabili i seguenti metodi di archiviazione:
- direttamente nel codice di gestione della configurazione o nei file nel repository;
- in strumenti specializzati di gestione della configurazione (ad esempio, Ansible Vault);
- in sistemi CI/CD (Jenkins/TeamCity/GitLab/ecc.) o in sistemi di gestione della configurazione (Ansible Tower/Ansible AWX);
- inoltre, i segreti possono essere trasmessi tramite "gestione manuale". Ad esempio, vengono collocati in luoghi concordati e poi utilizzati dai sistemi di gestione della configurazione;
- diverse combinazioni di quanto sopra descritto.
Ogni metodo ha i suoi svantaggi. Il principale di essi è l'assenza di politiche di accesso ai segreti: è impossibile o difficile definire chi può utilizzare determinati segreti. Un'altra svantaggio è l'assenza di audit dell'accesso e di un ciclo di vita completo. Come sostituire rapidamente, ad esempio, una chiave pubblica che è scritta nel codice e in vari sistemi correlati?
Abbiamo utilizzato un deposito centralizzato per i segreti, HashiCorp Vault. Questo ci ha permesso di:
- custodire i segreti in sicurezza. Sono crittografati, e anche se qualcuno ottiene accesso al database del deposito Vault (ad esempio, recuperandolo da un backup), non sarà in grado di leggere i segreti ivi custoditi;
- organizzare politiche di accesso ai segreti. Solo i segreti "dedicati" sono accessibili a utenti e applicazioni;
- effettuare audit dell'accesso ai segreti. Qualsiasi azione con i segreti viene registrata nel registro audit di Vault;
- organizzare un "ciclo di vita" completo per la gestione dei segreti. È possibile crearli, revocarli, impostare la durata, ecc.
- integrarsi facilmente con altri sistemi che necessitano di accesso ai segreti;
- e inoltre applicare crittografia end-to-end, password temporanee per OS e DB, certificati di centri autorizzati, ecc.
Ora passiamo al sistema centrale di autenticazione e autorizzazione. Si potrebbe fare a meno di esso, ma gestire gli utenti in molti sistemi correlati non è affatto semplice. Abbiamo configurato l'autenticazione e l'autorizzazione tramite il servizio LDAP. Altrimenti, in Vault si dovrebbe continuamente emettere e tenere traccia dei token di autenticazione per gli utenti. E la rimozione e l'aggiunta di utenti si trasformerebbero in una questione del tipo "ho creato/rimosso questo ID ovunque?"
Aggiungiamo un ulteriore livello al nostro sistema: gestione dei segreti e autenticazione/autorization centrale:
Fig. 2. Gestione dei segreti.
Gestione delle configurazioni
Siamo arrivati al cuore — al sistema CMS. In questo caso si tratta di una combinazione tra Ansible e Red Hat Ansible AWX.
Al posto di Ansible possono esserci Chef, Puppet, SaltStack. Abbiamo scelto Ansible per diversi motivi.
- In primo luogo, è la versatilità. Il set di moduli pronti per la gestione . E se non basta, si può cercare su GitHub e Galaxy.
- In secondo luogo, non è necessario installare e mantenere agenti sull'hardware gestito, dimostrare che non interferiscono con il carico di lavoro e confermare l'assenza di "backdoor".
- In terzo luogo, Ansible ha una bassa barriera di ingresso. Un ingegnere competente può scrivere un playbook funzionante letteralmente nel primo giorno di utilizzo del prodotto.
Ma Ansible da solo in un ambiente industriale non era sufficiente per noi. Altrimenti, ci sarebbero stati molti problemi con la limitazione degli accessi e l'audit delle azioni degli amministratori. Come delimitare l'accesso? Era necessario che ogni divisione gestisse (leggi: eseguisse un Ansible playbook) il proprio insieme di server. Come consentire l'esecuzione di specifici Ansible playbook solo a determinati dipendenti? O come monitorare chi ha eseguito il playbook, senza dover creare molti account locali sui server e sull'hardware gestito da Ansible?
La maggior parte di tali domande è risolta da Red Hat , o dal suo progetto open-source upstream . Ecco perché lo abbiamo preferito per il cliente.
Un'ulteriore caratteristica del nostro sistema CMS. Gli Ansible playbook devono essere memorizzati nei sistemi di gestione del codice sorgente. Nel nostro caso si tratta di .
Dunque, le configurazioni vengono gestite dalla combinazione Ansible/Ansible AWX/GitLab (vedi Fig. 3). Naturalmente, AWX/GitLab sono integrati con un sistema unico di autenticazione, mentre gli Ansible playbook sono con HashiCorp Vault. Le configurazioni entrano nell'ambiente di produzione solo attraverso Ansible AWX, nel quale sono definite tutte le "regole del gioco": chi e cosa può configurare, da dove prelevare il codice di gestione delle configurazioni per il CMS e così via.
Fig. 3. Gestione delle configurazioni.
Gestione dei test
La nostra configurazione è rappresentata sotto forma di codice. Pertanto, siamo costretti a rispettare le stesse regole degli sviluppatori software. Era necessario organizzare i processi di sviluppo, test continuo, consegna e applicazione del codice di configurazione sui server di produzione.
Se non si fa subito, i ruoli scritti per la configurazione smetterebbero di supportare e modificare, oppure smetterebbero di essere avviati in produzione. La soluzione a questo problema è nota e si è rivelata efficace in questo progetto:
- ogni ruolo è coperto da test modulari;
- i test vengono eseguiti automaticamente ad ogni modifica del codice che gestisce le configurazioni;
- le modifiche nel codice di gestione delle configurazioni arrivano nell'ambiente di produzione solo dopo il superamento con successo di tutti i test e della revisione del codice.
Lo sviluppo del codice e la gestione delle configurazioni sono diventati più tranquilli e prevedibili. Per organizzare il test continuo abbiamo utilizzato lo strumento GitLab CI/CD, e come framework per l'organizzazione dei test abbiamo scelto .
Ogni volta che ci sono modifiche nel codice di gestione delle configurazioni, GitLab CI/CD invoca Molecule:
- essa verifica la sintassi del codice,
- avvia un contenitore Docker,
- applica il codice modificato al contenitore creato,
- verifica il ruolo per l'idempotenza e esegue i test per quel codice (la granularità qui è a livello di ruolo ansible, si veda Fig. 4).
Le configurazioni nell'ambiente di produzione sono state fornite tramite Ansible AWX. Gli ingegneri responsabili della gestione delle operazioni applicavano modifiche alle configurazioni attraverso modelli predefiniti. AWX richiedeva automaticamente ogni volta l'ultima versione del codice dal ramo master di GitLab. In questo modo escludevamo l'uso di codice non verificato o obsoleto nell'ambiente di produzione. Naturalmente, il codice arrivava nel ramo master solo dopo test, revisione e approvazione.
Fig. 4. Test automatici dei ruoli in GitLab CI/CD.
C'è anche un problema legato all'operatività dei sistemi di produzione. Nella vita reale è molto difficile apportare modifiche alla configurazione solo attraverso il codice CMS. Ci sono situazioni straordinarie in cui un ingegnere deve modificare la configurazione 'qui e ora', senza aspettare la modifica del codice, il testing, l'approvazione, ecc.
Di conseguenza, a causa delle modifiche manuali, sorgono discrepanze nella configurazione su attrezzature simili (ad esempio, nei nodi di un cluster HA la configurazione delle impostazioni sysctl è diversa). Oppure la configurazione reale sull'hardware differisce da quella definita nel codice CMS.
Pertanto, oltre al test continuo, verifichiamo gli ambienti di produzione per eventuali discrepanze nelle configurazioni. Abbiamo scelto la soluzione più semplice: eseguire il codice di configurazione CMS in modalità "dry run", ovvero senza applicare le modifiche, ma notificando tutte le discrepanze tra la configurazione pianificata e quella reale. Abbiamo realizzato questo attraverso l'esecuzione periodica di tutti i playbook Ansible con l'opzione "--check" sui server di produzione. Come sempre, Ansible AWX si occupa dell'esecuzione e dell'aggiornamento dei playbook (vedi Fig. 5):
Fig. 5. Controlli sulle discrepanze delle configurazioni in Ansible AWX.
Dopo i controlli, AWX invia un rapporto sulle discrepanze agli amministratori. Essi esaminano la configurazione problematica e poi la correggono tramite playbook aggiornati. In questo modo manteniamo la configurazione negli ambienti di produzione e il CMS è sempre aggiornato e sincronizzato. Questo ci libera da spiacevoli "sorprese" quando il codice CMS viene applicato sui server di produzione.
Ora abbiamo un importante livello di testing, composto da Ansible AWX/GitLab/Molecule (Fig. 6).
Fig. 6. Gestione dei test.
Difficile? Non lo nego. Ma tale insieme di gestione delle configurazioni è diventato una risposta esaustiva a molte domande relative all'automazione della configurazione dei server. Ora il rivenditore ha sempre una configurazione rigorosamente definita per i server standard. A differenza di un ingegnere, il CMS non dimenticherà di aggiungere le impostazioni necessarie, creare utenti e completare decine o centinaia di configurazioni richieste.
Nelle impostazioni dei server e degli ambienti oggi non esistono più "conoscenze segrete". Tutte le necessarie peculiarità sono riflesse nei playbook. Niente più creatività e istruzioni vaghe: "installa come un normale Oracle, ma bisogna aggiungere un paio di impostazioni sysctl e creare gli utenti con il giusto UID. Chiedi ai ragazzi dell'esercizio, lo sanno"».
La possibilità di rilevare discrepanze nelle configurazioni e di correggerle in anticipo dà tranquillità. Senza un sistema di gestione delle configurazioni, tutto ciò di solito appare in modo diverso. I problemi si accumulano fino a quando un giorno "scoppiano" in produzione. Poi si svolge un'analisi, si verificano e si correggono le configurazioni. E il ciclo si ripete di nuovo.
E naturalmente, abbiamo accelerato l'avvio dei server in produzione da diversi giorni a poche ore.
Ma nella notte di Capodanno, quando i bambini aprivano felicemente i regali e gli adulti esprimevano desideri al suono della mezzanotte, i nostri ingegneri hanno migrato il sistema SAP su nuovi server. Anche Babbo Natale direbbe che i migliori miracoli sono ben pianificati.
P.S. Il nostro team si trova spesso di fronte alla richiesta dei clienti di risolvere in modo semplice il problema della gestione delle configurazioni. Idealmente, come per magia — con un solo strumento. Ma nella vita tutto è più complicato (sì, di nuovo non hanno fornito proiettili d'argento): dobbiamo creare un intero processo utilizzando strumenti comodi per il team del cliente.
Autore: Sergey Artemov, architetto del dipartimento «Infosistemi Jet»
Fonte: habr.com
