Si stava avvicinando il nuovo anno. I bambini di tutto il paese avevano già inviato lettere a Babbo Natale o fatto regali per se stessi, e il loro principale esecutore, uno dei maggiori rivenditori, si stava preparando per l'apoteosi delle vendite. A dicembre, il carico sul suo data center aumenta più volte. Pertanto, l'azienda ha deciso di modernizzare il data center e di mettere in funzione diverse decine di nuovi server al posto delle apparecchiature che stavano raggiungendo la fine della loro vita utile. Questo conclude la storia sullo sfondo di fiocchi di neve vorticosi e inizia il thriller.
L'attrezzatura è arrivata sul posto diversi mesi prima del picco delle vendite. Il servizio operativo, ovviamente, sa come e cosa configurare sui server per portarli nell'ambiente di produzione. Ma dovevamo automatizzarlo ed eliminare il fattore umano. Inoltre, prima della migrazione di una serie di sistemi SAP critici per l'azienda, sono stati sostituiti i server.
La messa in funzione dei nuovi server era strettamente legata ad una scadenza. E spostarlo significava mettere a repentaglio sia la spedizione di un miliardo di doni sia la migrazione dei sistemi. Anche una squadra composta da Babbo Natale e Babbo Natale non è riuscita a cambiare la data: puoi trasferire il sistema SAP per la gestione del magazzino solo una volta all'anno. Dal 31 dicembre al 1 gennaio, gli enormi magazzini del rivenditore, grandi in totale quanto 20 campi da calcio, interrompono il lavoro per 15 ore. E questo è l’unico periodo di tempo per spostare il sistema. Non avevamo margine di errore durante l'introduzione dei server.
Vorrei essere chiaro: la mia storia riflette gli strumenti e il processo di gestione della configurazione utilizzati dal nostro team.
Il complesso di gestione della configurazione è composto da diversi livelli. Il componente chiave è il sistema CMS. Nel funzionamento industriale, l'assenza di uno dei livelli porterebbe inevitabilmente a spiacevoli miracoli.
Gestione dell'installazione del sistema operativo
Il primo livello è un sistema per gestire l'installazione dei sistemi operativi su server fisici e virtuali. Crea configurazioni di base del sistema operativo, eliminando il fattore umano.
Utilizzando questo sistema, abbiamo ricevuto istanze server standard con sistema operativo adatto per un'ulteriore automazione. Durante il “versamento” hanno ricevuto un set minimo di utenti locali e chiavi SSH pubbliche, nonché una configurazione coerente del sistema operativo. Avevamo la garanzia di gestire i server tramite il CMS ed eravamo sicuri che non ci fossero sorprese “giù in basso” a livello di sistema operativo.
Il compito "massimo" del sistema di gestione dell'installazione è configurare automaticamente i server dal livello BIOS/firmware al sistema operativo. Molto qui dipende dall'attrezzatura e dalle attività di installazione. Per apparecchiature eterogenee, puoi prendere in considerazione . Se tutto l'hardware proviene da un fornitore, spesso è più conveniente utilizzare strumenti di gestione già pronti (ad esempio HP ILO Amplifier, DELL OpenManage, ecc.).
Per installare l'OS sui server fisici abbiamo utilizzato il noto Cobbler, che definisce una serie di profili di installazione concordati con il servizio operativo. Quando ha aggiunto un nuovo server all'infrastruttura, l'ingegnere ha collegato l'indirizzo MAC del server al profilo richiesto in Cobbler. Al primo avvio dalla rete, il server ha ricevuto un indirizzo temporaneo e un nuovo sistema operativo. Successivamente è stato trasferito all'indirizzamento VLAN/IP di destinazione e lì ha continuato a lavorare. Sì, la modifica della VLAN richiede tempo e coordinamento, ma fornisce una protezione aggiuntiva contro l'installazione accidentale del server in un ambiente di produzione.
Abbiamo creato server virtuali basati su modelli preparati utilizzando HashiСorp Packer. Il motivo era lo stesso: prevenire possibili errori umani durante l'installazione del sistema operativo. Ma, a differenza dei server fisici, Packer elimina la necessità di PXE, avvio di rete e modifiche VLAN. Ciò ha reso più facile e semplice la creazione di server virtuali.
Riso. 1. Gestire l'installazione dei sistemi operativi.
Gestire i segreti
Qualsiasi sistema di gestione della configurazione contiene dati che dovrebbero essere nascosti agli utenti ordinari, ma sono necessari per preparare i sistemi. Si tratta di password per utenti locali e account di servizio, chiavi di certificato, vari token API, ecc. Di solito vengono chiamati "segreti".
Se non si determina fin dall'inizio dove e come archiviare questi segreti, a seconda della severità dei requisiti di sicurezza delle informazioni, sono probabili i seguenti metodi di archiviazione:
- direttamente nel codice di controllo 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);
- i segreti possono essere trasferiti anche “manualmente”. Ad esempio, sono disposti in una posizione specifica e quindi vengono utilizzati dai sistemi di gestione della configurazione;
- varie combinazioni di quanto sopra.
Ogni metodo ha i suoi svantaggi. Il principale è la mancanza di policy per l’accesso ai segreti: è impossibile o difficile determinare chi può utilizzare determinati segreti. Un altro svantaggio è la mancanza di controllo degli accessi e di un ciclo di vita completo. Come sostituire rapidamente, ad esempio, una chiave pubblica scritta nel codice e in una serie di sistemi correlati?
Abbiamo utilizzato l'archivio segreto centralizzato HashiCorp Vault. Questo ci ha permesso:
- mantenere i segreti al sicuro. Sono crittografati e, anche se qualcuno riesce ad accedere al database del Vault (ad esempio ripristinandolo da un backup), non sarà in grado di leggere i segreti ivi archiviati;
- organizzare le policy per l'accesso ai segreti. Solo i segreti loro “assegnati” sono a disposizione degli utenti e delle applicazioni;
- controllare l'accesso ai segreti. Qualsiasi azione con segreti viene registrata nel registro di controllo di Vault;
- organizzare un vero e proprio "ciclo di vita" lavorando con i segreti. Possono essere creati, revocati, impostati una data di scadenza, ecc.
- facile da integrare con altri sistemi che necessitano di accesso ai segreti;
- e utilizza anche crittografia end-to-end, password monouso per il sistema operativo e il database, certificati di centri autorizzati, ecc.
Passiamo ora al sistema centrale di autenticazione e autorizzazione. Era possibile farne a meno, ma amministrare gli utenti in molti sistemi correlati è troppo semplice. Abbiamo configurato l'autenticazione e l'autorizzazione tramite il servizio LDAP. Altrimenti, Vault dovrebbe emettere e tenere traccia continuamente dei token di autenticazione per gli utenti. E l'eliminazione e l'aggiunta di utenti si trasformerebbe in una ricerca "ho creato/eliminato questo account utente ovunque?"
Aggiungiamo un altro livello al nostro sistema: gestione dei segreti e autenticazione/autorizzazione centrale:
Riso. 2. Gestione dei segreti.
Gestione della configurazione
Siamo arrivati al nocciolo della questione: il sistema CMS. Nel nostro caso, si tratta di una combinazione di Ansible e Red Hat Ansible AWX.
Invece di Ansible, è possibile utilizzare Chef, Puppet, SaltStack. Abbiamo scelto Ansible in base a diversi criteri.
- Innanzitutto è la versatilità. Una serie di moduli già pronti per il controllo . E se non ne hai abbastanza, puoi cercare su GitHub e Galaxy.
- In secondo luogo, non è necessario installare e supportare agenti sulle apparecchiature gestite, dimostrare che non interferiscono con il carico e confermare l'assenza di "segnalibri".
- In terzo luogo, Ansible ha una bassa barriera all’ingresso. Un ingegnere competente scriverà un playbook funzionante letteralmente il primo giorno di lavoro con il prodotto.
Ma Ansible da solo in un ambiente di produzione non ci bastava. Altrimenti sorgerebbero molti problemi con la limitazione dell’accesso e il controllo delle azioni degli amministratori. Come limitare l'accesso? Dopotutto, era necessario che ciascun dipartimento gestisse (leggi: eseguisse il playbook Ansible) il “proprio” set di server. Come consentire solo a determinati dipendenti di eseguire playbook Ansible specifici? Oppure come tenere traccia di chi ha lanciato il playbook senza impostare molte conoscenze locali sui server e sulle apparecchiature che eseguono Ansible?
La parte del leone in questi problemi viene risolta da Red Hat o il suo progetto upstream open source . Ecco perché lo abbiamo preferito per il cliente.
E un tocco in più al ritratto del nostro sistema CMS. Il playbook Ansible dovrebbe essere archiviato nei sistemi di gestione del repository di codice. Ce l'abbiamo .
Pertanto, le configurazioni stesse sono gestite da una combinazione di Ansible/Ansible AWX/GitLab (vedere Fig. 3). Naturalmente, AWX/GitLab è integrato con un unico sistema di autenticazione e il playbook Ansible è integrato con HashiCorp Vault. Le configurazioni entrano nell'ambiente di produzione solo attraverso Ansible AWX, in cui vengono specificate tutte le “regole del gioco”: chi può configurare cosa, dove prendere il codice di gestione della configurazione per il CMS, ecc.
Riso. 3. Gestione della configurazione.
Gestione delle prove
La nostra configurazione è presentata sotto forma di codice. Pertanto, siamo costretti a giocare secondo le stesse regole degli sviluppatori di software. Avevamo bisogno di organizzare i processi di sviluppo, test continui, consegna e applicazione del codice di configurazione ai server di produzione.
Se ciò non viene fatto immediatamente, i ruoli scritti per la configurazione cesseranno di essere supportati e modificati oppure cesseranno di essere lanciati in produzione. La cura per questo dolore è nota e si è dimostrata efficace in questo progetto:
- ogni ruolo è coperto da unit test;
- i test vengono eseguiti automaticamente ogni volta che c'è qualche cambiamento nel codice che gestisce le configurazioni;
- le modifiche al codice di gestione della configurazione vengono rilasciate nell'ambiente di produzione solo dopo aver superato con successo tutti i test e la revisione del codice.
Lo sviluppo del codice e la gestione della configurazione sono diventati più tranquilli e prevedibili. Per organizzare test continui, abbiamo utilizzato il toolkit GitLab CI/CD e abbiamo utilizzato .
Ogni volta che viene apportata una modifica al codice di gestione della configurazione, GitLab CI/CD chiama Molecule:
- controlla la sintassi del codice,
- solleva il contenitore Docker,
- applica il codice modificato al contenitore creato,
- controlla l'idempotenza del ruolo ed esegue i test per questo codice (la granularità qui è a livello di ruolo ansible, vedere Fig. 4).
Abbiamo fornito configurazioni all'ambiente di produzione utilizzando Ansible AWX. Gli ingegneri operativi hanno applicato le modifiche alla configurazione tramite modelli predefiniti. AWX “richiedeva” autonomamente l'ultima versione del codice al ramo master di GitLab ogni volta che veniva utilizzato. In questo modo abbiamo escluso l'utilizzo di codice non testato o obsoleto nell'ambiente di produzione. Naturalmente il codice è entrato nel ramo master solo dopo essere stato testato, revisionato e approvato.
Riso. 4. Test automatico dei ruoli in GitLab CI/CD.
C'è anche un problema associato al funzionamento dei sistemi di produzione. Nella vita reale, è molto difficile apportare modifiche alla configurazione solo tramite il codice CMS. Situazioni di emergenza si verificano quando un tecnico deve modificare la configurazione “qui e ora”, senza attendere la modifica del codice, i test, l’approvazione, ecc.
Di conseguenza, a causa di modifiche manuali, appaiono discrepanze nella configurazione sullo stesso tipo di apparecchiatura (ad esempio, le impostazioni sysctl sono configurate in modo diverso sui nodi del cluster HA). Oppure la configurazione effettiva sull'apparecchiatura è diversa da quella specificata nel codice CMS.
Pertanto, oltre ai test continui, controlliamo gli ambienti di produzione per individuare discrepanze di configurazione. Abbiamo scelto l'opzione più semplice: eseguire il codice di configurazione del CMS in modalità “dry run”, ovvero senza applicare modifiche, ma con notifica di tutte le discrepanze tra la configurazione pianificata e quella effettiva. Lo abbiamo implementato eseguendo periodicamente tutti i playbook Ansible con l'opzione "—check" sui server di produzione. Come sempre, Ansible AWX è responsabile del lancio e del mantenimento aggiornato del playbook (vedere Fig. 5):
Riso. 5. Controlla le discrepanze di configurazione in Ansible AWX.
Dopo i controlli, AWX invia un rapporto sulle discrepanze agli amministratori. Studiano la configurazione problematica e poi la risolvono attraverso playbook adeguati. In questo modo manteniamo la configurazione nell'ambiente di produzione e il CMS è sempre aggiornato e sincronizzato. In questo modo si evitano spiacevoli “miracoli” quando il codice CMS viene utilizzato su server di “produzione”.
Ora disponiamo di un importante livello di test costituito da Ansible AWX/GitLab/Molecule (Figura 6).
Riso. 6. Gestione delle prove.
Difficile? Non discuto. Ma una gestione della configurazione così complessa è diventata una risposta completa a molte domande relative all'automazione della configurazione del server. Ora i server standard di un rivenditore hanno sempre una configurazione rigorosamente definita. CMS, a differenza di un ingegnere, non dimenticherà di aggiungere le impostazioni necessarie, creare utenti ed eseguire dozzine o centinaia di impostazioni richieste.
Oggi non esiste una “conoscenza segreta” nelle impostazioni di server e ambienti. Tutte le funzionalità necessarie si riflettono nel playbook. Niente più creatività e istruzioni vaghe: “Installalo come un normale Oracle, ma devi specificare un paio di impostazioni sysctl e aggiungere utenti con l'UID richiesto. Chiedi ai ragazzi in funzione, lo sanno'.
La capacità di rilevare discrepanze di configurazione e correggerle in modo proattivo garantisce tranquillità. Senza un sistema di gestione della configurazione, di solito questo appare diverso. I problemi si accumulano finché un giorno non si “sparano” alla produzione. Successivamente viene effettuato un debriefing, le configurazioni vengono controllate e corrette. E il ciclo si ripete ancora
E, naturalmente, abbiamo accelerato la messa in funzione dei server da diversi giorni a ore.
Ebbene, proprio alla vigilia di Capodanno, quando i bambini scartavano con gioia i regali e gli adulti esprimevano gli auguri al suono dei rintocchi, i nostri ingegneri hanno migrato il sistema SAP su nuovi server. Anche Babbo Natale dirà che i miracoli migliori sono quelli ben preparati.
PS Il nostro team si imbatte spesso nel fatto che i clienti desiderano risolvere i problemi di gestione della configurazione nel modo più semplice possibile. Idealmente, come per magia, con un unico strumento. Ma nella vita tutto è più complicato (sì, la soluzione miracolosa non è stata ancora consegnata): devi creare un intero processo utilizzando strumenti convenienti per il team del cliente.
Autore: Sergey Artemov, architetto del dipartimento "Sistemi informativi dei jet"
Fonte: habr.com