Implicazioni dell'utilizzo del template e della clonazione di VMware per il provisioning di server Linux anziché PXE

Sembra che ci siano vantaggi di velocità quando si utilizzano i modelli di VMware per creare nuove macchine virtuali. Tuttavia, sono preoccupato per possibili implicazioni di sicurezza e flessibilità meno ovvie. Ad esempio:

• Chiavi generate dal primo avvio
• Metodi proprietari di VMware per la configurazione delle impostazioni del server (IP, nome host, ecc.)

In un negozio che è quasi interamente VMware con la maggior parte di Linux come distribuzioni basate su RHEL, qualcuno ha riscontrato alcune insidie ​​durante il provisioning dai modelli? Che ne dici di preoccupazioni durante la clonazione?

A proposito: indipendentemente dal metodo di provisioning iniziale, verrebbe utilizzato principalmente come bootstrap per Puppet per il resto della configurazione.

A seconda dell'ambiente e del processo di provisioning, potrebbe essere più veloce creare di nuovo rispetto all'utilizzo dei modelli VMware e alla funzionalità di clonazione dal modello .

Ho lavorato in un grande ambiente VMware focalizzato su Linux, dove il processo di distribuzione non era automatizzato come avrebbe dovuto essere. Ci siamo affidati ai modelli vSphere dei sistemi RHEL, ma dopo il clone iniziale era necessario un po 'di lavoro manuale.

Vantaggi del modello:

• I modelli sono buoni se stai inserendo altre applicazioni, impostazioni di configurazione e cose che si estendono oltre la portata della gestione della configurazione nel modello. ( ad esempio un complesso stack di applicazioni Oracle )
• Il tempo di clonazione è una funzione dello spazio di archiviazione e dell'infrastruttura vSphere. Ho visto processi di clonazione molto lenti e ad alta intensità di risorse.
• Ad esempio, se si utilizza Red Hat / CentOS / Debian / Ubuntu, è possibile sfruttare il sys-unconfigcomando per "annullare la configurazione" di un sistema prima della modellazione. Questo è l'equivalente Linux di Microsoft Sysprepe rimuove le regole dell'interfaccia di rete, le chiavi SSH, le impostazioni di rete, ecc.
• Gli strumenti di assegnazione IP di VMware vanno bene e non sono stati un grosso problema con i sistemi operativi Linux tradizionali.

Vantaggi della distribuzione PXE / kickstart:

• Di solito più veloce del modello / clonazione, supponendo che si disponga di un repository locale e di un'immagine di avvio di rete.
• Più flessibile in quanto è possibile apportare modifiche alle immagini / master senza il ciclo di conversione del modello in VM, modifica, riconversione e clonazione.
• Ideale se abbinato a una soluzione di gestione della configurazione.

Alla fine, dipende dall'applicazione e dalla quantità di lavoro aggiuntivo necessario dopo l'installazione iniziale del sistema operativo. Ho adottato un approccio ibrido, utilizzando cloni per le istanze più complesse e nuove build tramite un sistema di provisioning per i sistemi di routine. Non si escludono a vicenda.

Le specifiche dipendono dalla distribuzione, ma ti darò alcune cose CentOS / RHEL da ricordare durante la creazione del modello.

• Elimina le chiavi /etc/ssh/
• Rimuovere le righe del SOTTOSISTEMA in /etc/udev/rules.d/70-persistent-net.rulesriferimento alle schede NIC

Entrambi verranno rigenerati al primo avvio.

È necessario un modo per eseguire gli aggiornamenti dopo aver distribuito il modello.

Con vSphere è possibile definire la rete e il nome host. Come utente Puppet, posso semplicemente installare il client Puppet nel mio modello insieme a uno standard puppet.conf. Se sto usando più ambienti, allora ho effettivamente bisogno di un modello diverso per ogni ambiente.

Quando modifichi un modello, devi ricordare di rimuovere i file sopra.

Personalmente, mentre la distribuzione dal modello è leggermente più veloce, preferisco effettuare il provisioning da PXE in quanto è più flessibile.

Dai un'occhiata a Preparazione di VM modello Linux e post che fa riferimento, Creazione di un'immagine pronta per le marionette (CentOS / Fedora) . Forse questo aiuta.

A proposito: mi piace molto la tua idea di distribuire macchine virtuali JeOS e quindi usare le marionette per personalizzarla in un DB, Web o qualunque server.

Un altro punto a favore di kickstart di linux vm è che gli host verranno automaticamente sottoposti a patch completi durante l'installazione (i vm ottengono i pacchetti più recenti dai repository locali).

Ovviamente puoi ottenere la stessa cosa se mantieni aggiornati i tuoi modelli, ma non è qualcosa che ho visto accadere negli ambienti su cui ho lavorato.

La sezione% post dei nostri file kickstart (sì, ne abbiamo diversi a seconda di cosa per i sistemi che installiamo, come 32 o 64 bit, per esempio) installa solo l'agente cfengine e da lì gli host vengono gestiti da cfengine.

Non l'ho cronometrato ma dubito che la clonazione sia più veloce una volta che l'infrastruttura è a posto. Inoltre, se lo è, è possibile installare anche host reali ;-)

Per i sistemi basati su Debian abbiamo usato il FAI , che è anche fantastico.