Automatizzare la distribuzione del server


28

Trovo che continuo a configurare server e VPS praticamente identici per un certo numero di miei clienti e può richiedere molto tempo. Spesso l'unica cosa che cambia tra ogni distribuzione è il diverso sito Web che deve essere offerto. Esiste un modo semplice per automatizzare tutto ciò e assumere la noiosa monotonia di configurare 56 server identici?

I server che ho distribuito finora sono stati solo Ubuntu, ma potrebbe essere possibile che io inizi a utilizzare altri sistemi operativi Linux o persino Windows. Finora ho guardato Capistrano, ma sembra che mi concentri sulla scrittura di piccoli programmi di rubini con cui fare il lavoro, e non ho alcuna conoscenza


Risposte:


20

Puppet sembra perfetto per quello che stai cercando di fare, con l'avvertenza che al momento non c'è supporto per Windows.

Nel tuo caso, definiresti un nodo Server in termini di tutti i pacchetti identici tra le macchine. Quindi, si definiscono i singoli host come nodi che ereditano dal server e si impostano le cose uniche specifiche per esso.

Puppet è dichiarativo: ti consente di descrivere le tue scatole in termini di risorse che ogni scatola dovrebbe avere. Quindi se vuoi ssh- scrivi una classe per quella risorsa - e all'interno della classe puoi includere una logica su come ssh viene chiamato leggermente diverso su FreeBSD vs Ubuntu. Sa anche usare yumall'interno di Redhat e apt-getnelle distribuzioni basate su Debian e portsnei BSD. Ora nel tuo nodo Server, avrai solo una linea come include ssh- e il burattino farà la cosa giusta e metterà SSH sulla macchina senza che tu debba ricordare se si tratta di Ubuntu o Redhat o FreeBSD.

La cosa bella è che tutte le cose del server vivono in un unico posto - e se in qualsiasi momento aggiungessi alla definizione del nodo del server, TUTTE le macchine aggiornerebbero la loro configurazione di conseguenza.

In questo momento, sto solo gestendo tre scatole usando Puppet - ma è già stato pagato. Dopo aver trascorso una settimana a configurare un box che useremo per la presentazione dello stimolo in un esperimento, si è scoperto che il driver della scheda grafica era troppo vecchio nella versione di Ubuntu che ho inserito (8.04). Ho dovuto installare l'ultima versione di Ubuntu (9.04), ma dopo ho dovuto solo apt-get ed eseguire il pupazzo - e tutto ciò che avevo trascorso una settimana a configurare è stato ripristinato.

Puppet ha un po 'di una curva di apprendimento, ma ho evitato con successo di imparare Ruby - so che lo sto usando, poiché è quello in cui è scritto il burattino - ma finora sono riuscito a modificare gli esempi in la documentazione e le ricette sul wiki . Un altro aspetto negativo è che il burattino impiega un po 'più tempo a fare le cose la prima volta. Il lato positivo è che tutto ciò che cambi su tutte le tue macchine è archiviato in un unico posto - è prassi normale mantenere la configurazione fantoccio in un sistema di controllo versione - in modo da poter sempre guardare indietro e vedere come hai impostato i server in passato - o ripristinare alcune modifiche non riuscite.

Infine, ecco un breve video che fa una semplice demo di marionette che mi ha fatto iniziare rapidamente.


3
Digg.com usa le marionette per gestire i propri server, alcuni esempi di base sono disponibili sul loro blog: blog.digg.com/?p=335 blog.digg.com/?p=562
Adam Gibbins,

Credo che anche il team amministrativo di Fedora utilizzi le marionette.
Mei,

9

Noi usiamo Cobbler e burattini per accumulo e l'automazione della configurazione di entrambe le macchine reali e virtuali.

Cobbler collega DHCP, avvio PXE e kickstart per rendere la distribuzione niente più che aggiungere un profilo macchina e premere il pulsante di accensione. Per le macchine virtuali, il koan comando esegue (nel nostro caso) Xen magic per avviare l'installazione - sul dom0tipo ho appena digitato:

koan --system vps.fqdn --server cobbler --no-gfx

quindi virsh consoleguardare un edificio VPS senza alcuna interazione.

Usiamo RHEL e abbiamo un sacco di profili impostati per partizionare i dischi, configurare la rete e installare pacchetti di base per diverse classi di server. Cobbler supporta le razze Debian e Ubuntu ma non l'ho mai provato. A parte: altri usi interessanti per Cobbler includono l'esecuzione di ISO memtest e aggiornamenti del firmware HP .

Una volta che i nostri sistemi sono costruiti con Cobbler Puppet prende il sopravvento per configurare le applicazioni, i demoni di sistema, registrare la scatola con RHN, ecc. Puppet funziona come un demone che controlla periodicamente che la configurazione del sistema corrisponda ai manifesti definiti - sai che i tuoi aggiornamenti sono andati a tutti i server. È anche un ottimo modo per essere certi che una scatola che è stata utilizzata per la manutenzione abbia la configurazione corretta prima di restituirla al servizio live.

Puppet è davvero fantastico. Non hai bisogno di tenere sotto controllo ogni aspetto della tua configurazione: inizia facendo in modo che gestisca qualcosa di semplice che devi configurare su ogni box ( sudoersè l'esempio canonico) e prendilo da lì. Assicurati che anche i tuoi manifest Puppet siano versionati; niente è meglio che essere in grado di tornare facilmente a una configurazione ben nota senza dover ricordare cosa regolare.


6

Dove sto lavorando al momento, dobbiamo gestire la parte Linux della nostra server farm che è poco più di 300 server Linux. Ciò include principalmente HP Proliants, seguiti da IBM 3850, alcuni blade IBM, VMware ESX e alcuni KVM per i nostri server di gestione interni.

ciabattino

Abbiamo esaminato il calzolaio, ma il problema era che il calzolaio è molto specifico per RHEL / Red Hat. Dobbiamo supportare almeno RHEL e SLES e Ubuntu è il prossimo.

fantoccio

Abbiamo preso in considerazione le marionette, tuttavia in seguito abbiamo deciso di non farlo poiché dipende da Ruby, il che significa che un aggiornamento di Ruby potrebbe potenzialmente rompere il nostro sistema di gestione.

hotwire

Hotwire è ciò che utilizziamo (sviluppato internamente, ma è open-source) e lo abbiamo fatto negli ultimi anni. In primo luogo, l'inventario dei sistemi che verranno costruiti, il che significa inventariare il data center, il rack, l'hardware, il sistema operativo, la rete, ecc., E in secondo luogo eseguire la rapida compilazione e distribuzione. Una volta creato il sistema, l'inventario automatico di hotwire mantiene sincronizzato l'inventario, mentre cfengine li mantiene. Hotwire conosce l'hardware del server parlando con i dati SMBIOS / DMI nel BIOS tramite python-dmidecode .

I punti bonus sono che combina l'inventario e il processo di creazione in uno, quindi c'è meno da gestire, e la funzione di inventario dal vivo è eccezionale, come sappiamo se qualcosa non va bene.

Gli svantaggi sono che l'interfaccia utente ha ancora bisogno di essere lucidata, e ci sono bug qua e là, ma lo sviluppo è ancora caldo e i bug segnalati sono stati corretti relativamente velocemente.

cfengine

Usiamo cfengine perché a parte questo, e fantoccio, non c'è nient'altro. In realtà è un buon strumento, ma "buono" solo in funzione di quanto sono buone le vostre politiche - se impostate politiche pericolose, allora un piccolo errore può causare molti danni. Ad esempio, per politica, non "modifichiamo" i file, o li sostituiamo o no. Inoltre, tutti i file sostituiti hanno un'intestazione che fa in modo che chiunque lo modifichi sappia che verrà sostituito alla successiva esecuzione (viene eseguito tramite cron ogni ora).

Anche la configurazione e tutti i file inviati da cfengine ai server sono mantenuti in un SCM e, usando possibilmente hook post-commit, controlliamo la sintassi e se fallisce, il commit viene rifiutato. Questo è facile per belle applicazioni come Apache, ma non così facile per la maggior parte delle applicazioni aziendali.


Hai deciso contro Puppet perché dipende da Ruby? Sulla base di questo puoi decidere contro quasi tutto, perché un aggiornamento di libc o kernel potrebbe romperlo.
Cristian Ciupitu,

2
Sollevi un punto, ma alla fine è un compromesso: di quanti pacchetti voglio "preoccuparmi" per il prossimo aggiornamento. Se l'aggiornamento del kernel / glibc va storto - normalmente ti aspetteresti di scoprirlo quasi immediatamente poiché è il componente più fondamentale del sistema operativo, tuttavia se Ruby esce leggermente diverso, non lo noteresti davvero, ma quando lo fai, potresti avere 300 server già aggiornati e in esecuzione su quella versione, e ora Puppet è una vittima. Ma ancora una volta, non sto scolpendo nulla nella pietra; questa è solo la mia preferenza in materia.
Serse


3

Per automatizzare l'installazione in base al sistema di destinazione:

  • Debian / Ubuntu: FAI o di preconfigurazione
  • RedHat / Fedora: kickstart
  • Novell / openSuSE: AutoYaST
  • Solaris: Jumpstart
  • Windows: unattended.sourceforge.net

Per la gestione della configurazione, ti consiglio di usare Puppet.



2

Un altro voto per Puppet qui. Lo utilizziamo ampiamente per eseguire tutte le installazioni di server e applicazioni e la gestione della configurazione. Oltre 200 nodi e conteggio. Apparentemente il supporto di Windows è in fase di sviluppo, anche se in quale stato non sono sicuro.

Stiamo ancora esaminando il lato iniziale del bootstrap del sistema operativo, ma come detto sopra Cobbler sembra interessante. Attualmente stiamo usando un mix di avvio PXE con preconfigurazione Debian / Ubuntu, ma non è certo ottimale.


Ehi Mike, pensi di poter aggiungere il tag fantoccio a questa domanda? Lo farei, ma non ho il rappresentante richiesto
Paul Ivanov,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.