{"id":90386,"date":"2020-07-31T13:42:20","date_gmt":"2020-07-31T11:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/triller-o-nastrojke-serverov-bez-chudes-s-configuration-management"},"modified":"2020-07-31T13:42:20","modified_gmt":"2020-07-31T11:42:20","slug":"triller-o-nastrojke-serverov-bez-chudes-s-configuration-management","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/triller-o-nastrojke-serverov-bez-chudes-s-configuration-management","title":{"rendered":"Thriller sulla configurazione dei server senza magie con il Configuration Management","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Si avvicinava il Capodanno. I bambini di tutto il paese avevano gi\u00e0 inviato le lettere a Babbo Natale o avevano espresso i loro desideri di regali, e il principale esecutore \u2014 uno dei grandi rivenditori \u2014 si stava preparando per l'apice delle vendite. A dicembre, il carico sul suo data center aumenta notevolmente. Pertanto, l'azienda ha deciso di modernizzare il centro dati e di mettere in funzione decine di nuovi server a sostituzione di attrezzature il cui ciclo di vita era giunto al termine. A questo punto la favola sullo sfondo dei fiocchi di neve volanti finisce, e inizia il thriller. <\/p>\n

\"Thriller
\nL'attrezzatura \u00e8 arrivata sul sito diversi mesi prima del picco delle vendite. Il servizio operativo, ovviamente, sa come e cosa configurare sui server per metterli in produzione. Ma dovevamo automatizzare questo processo ed escludere il fattore umano. Inoltre, i server sostituivano un insieme di sistemi SAP, critici per l'azienda, prima della migrazione. <\/p>\n

L'implementazione dei nuovi server era rigidamente legata a scadenze. Spostarla significava mettere a rischio sia la consegna di un miliardo di regali sia la migrazione dei sistemi. La data non poteva essere cambiata nemmeno dalla squadra composta da Babbo Natale e Santa Claus: il trasferimento del sistema SAP per la gestione del magazzino pu\u00f2 avvenire solo una volta all'anno. Dal 31 dicembre al 1 gennaio, enormi magazzini del rivenditore, complessivamente grandi come 20 campi da calcio, fermano le loro operazioni per 15 ore. E questo \u00e8 l'unico intervallo di tempo per il trasferimento del sistema. Non avevamo margine d'errore nell'implementazione dei server. <\/p>\n

Spiego subito: il mio racconto riflette gli strumenti e il processo di gestione delle configurazioni utilizzati dal nostro team.
\n<\/a><\/noindex>
\nIl complesso di gestione delle configurazioni \u00e8 composto da diversi livelli. Il componente chiave \u00e8 il sistema CMS. In un'operazione industriale, l'assenza di uno dei livelli porterebbe inevitabilmente a spiacevoli sorprese.<\/p>\n

Gestione dell'installazione del sistema operativo<\/h1>\n

\nIl primo livello \u00e8 il sistema di gestione dell'installazione dei sistemi operativi su server fisici e virtuali. Esso crea configurazioni base del sistema operativo, eliminando il fattore umano. <\/p>\n

Con questo sistema abbiamo ottenuto esemplari di server con sistema operativo gi\u00e0 configurati e pronti per ulteriore automazione. Durante il \"deployment\", venivano creati un numero minimo di utenti locali e chiavi pubbliche SSH, oltre a una configurazione coerente del sistema operativo. Potevamo gestire i server in modo garantito tramite CMS e eravamo certi che non ci fossero sorprese a livello di sistema operativo. <\/p>\n

L'obiettivo massimo per il sistema di gestione delle installazioni \u00e8 configurare automaticamente i server dal livello BIOS\/Firmware fino al sistema operativo. Molto dipende dall'hardware e dalle esigenze di configurazione. Per hardware eterogeneo, si pu\u00f2 considerare REDFISH API<\/a><\/noindex>. Se tutto l'hardware proviene dallo stesso fornitore, spesso \u00e8 pi\u00f9 utile utilizzare strumenti di gestione gi\u00e0 pronti (ad esempio, HP ILO Amplifier, DELL OpenManage, ecc.).<\/p>\n

Per l'installazione del sistema operativo sui server fisici, abbiamo utilizzato il ben noto Cobbler, in cui \u00e8 definito un insieme di profili di installazione concordati con il servizio operativo. Quando un nuovo server viene aggiunto all'infrastruttura, l'ingegnere associa l'indirizzo MAC del server al profilo richiesto in Cobbler. Al primo avvio tramite rete, il server riceve un indirizzo temporaneo e un sistema operativo aggiornato. Viene quindi trasferito nella VLAN\/indirizzamento IP di destinazione e si continua a lavorare da l\u00ec. S\u00ec, cambiare VLAN richiede tempo e approvazione, ma fornisce una protezione aggiuntiva contro l'installazione accidentale del server nell'ambiente di produzione.<\/p>\n

I server virtuali sono stati creati sulla base di modelli preparati con HashiCorp Packer. La ragione \u00e8 la medesima: prevenire possibili errori umani nell'installazione del sistema operativo. Tuttavia, a differenza dei server fisici, Packer consente di non utilizzare PXE, l'avvio di rete e il cambio della VLAN. Questo ha reso pi\u00f9 semplice e pratico il processo di creazione dei server virtuali. <\/p>\n

\"Thriller
\nFig. 1. Gestione dell'installazione dei sistemi operativi.<\/i><\/p>\n

Gestione dei segreti<\/h1>\n

\nQualsiasi sistema di gestione della configurazione contiene dati che devono essere nascosti agli utenti comuni, ma sono necessari per la preparazione dei sistemi. Questi includono le password degli utenti locali e degli account di servizio, le chiavi dei certificati, vari token API e cos\u00ec via. Di solito sono chiamati \"segreti\".<\/p>\n

Se non si definisce fin dall'inizio dove e come memorizzare questi segreti, a seconda della severit\u00e0 dei requisiti di sicurezza, le modalit\u00e0 di memorizzazione potrebbero essere le seguenti:<\/p>\n