Re: [linux_var] alternativa debian a ubuntu uck

[Luca Lesinigo <luca@lesinigo.it>]

Il giorno 25/mar/2015, alle ore 18:44, Giovanni Orlandi <orlangio@gmail.com> ha scritto:
> ho delle macchine in giro per il mondo e devo reinstallarle una tantum, queste di adesso in particolare sono in sardegna.
> L'installazione è particolare a seconda delle macchine, minimo cambia l'indirizzo IP, poi il partizionamento dei dischi che sono in numero ed in dimensione differente,
> per quanto riguarda i pacchetti che variano parecchio in realtà mi basterebbe un set minimo comune comprendente openssh-server e poi vado da remoto di apt-get.
[....]

Io a lavoro ho adottato ormai da parecchio tempo questa prassi, non è detto che si adatti pienamente al tuo caso ma magari ti può essere di spunto.
Per mettere del contesto, si tratta praticamente quasi solo di installazioni Ubuntu Server LTS (sempre l'ultima disponibile, quindi ora sarebbe la 14.04), con qualche CentOS buttata nel mix ogni tanto (idem sempre l'ultima disponibile).

1- provisioning
Installiamo nuove macchine, o rifacciamo quelle esistenti, relativamente di rado: nei periodi più movimentati arriviamo al massimo a due o tre la settimana.
I dettagli in fase di installazione sono molto variabili: le virtual machine o cose tipo raspberry e beaglebone tipicamente partono con le schede di rete old-school (eth0, eth1, etc...) mentre le installazioni "su metallo" nascono con i nomi nuovi (p2p0 o roba simile). Allo stesso modo il partizionamento dei dischi è molto variabile da caso a caso. Mettici anche che spesso le macchine si trovano in reti di clienti su cui non abbiamo moltissimo controllo (es. dhcp e tftp servers potrebbero esserci o non esserci e potremmo avere modo di customizzarli oppure no).
Alla fin fine per noi automatizzare troppo non vale lo sbattimento, quindi l'installazione iniziale la facciamo manualmente tanto ci mettiamo pochi minuti.
Quindi a mano facciamo la configurazione iniziale della rete ed il partizionamento, a quel punto ci ritroviamo un sistema completamente gestibile da remoto via ssh.

Il 99% delle installazioni remote che facciamo sono di macchine virtuali quindi ci viene fornito l'accesso completo a quello che serve, se proprio c'è da fare un server fisico remoto ci è capitato di cavarcela istruendo la persona dall'altra parte a fare il boot da chiavetta USB e poi procediamo noi tramite KVM (keyboard-video-monitor remoti, non kvm la virtualizzazione di linux ;) o tramite console su porta seriale (e serial-over-lan che trovi in tutti i server dotati di IPMI 2.0 o similare).

2a- configurazione iniziale dei sistemi non gestiti
Un bash script (solitamente customizzato per cliente) installa le cose di base comuni a tutti i sistemi: NTPd, haveged, smartmontools (se fisica), open-vm-tools (se sotto vmware), screen, vim, tcpdump, nmap, htop, e via dicendo

2b- sistemi gestiti
Stiamo lavorando /molto/ con Puppet, quindi spesso e volentieri dopo l'installazione iniziale del sistema l'unica cosa da fare è lanciare uno script che scarica il .deb dei repository puppetlabs, installa puppet, lo punta al puppetserver specifico per il cliente in questione e stop. Da lì in poi non serve fare più nulla manualmente, nemmeno configurare i server di monitoraggio, perché è tutto gestito tramite Puppet. In molte installazioni che facciamo l'unica interazione tra esseri umani ed il sistema in questione è solo il lancio iniziale di questo script e poi non ci si collega più direttamente.

3- fine :-)

Una via di mezzo tra i due casi potrebbe essere mettere su un minimo di moduli Ansible da lanciare sui nuovi nodi, se poi non li devi gestire nel tempo (o non farlo tramite strumenti automatizzati) può essere una buona soluzione principalmente perché è agent-less e sul nodo ti basta avere solo SSH. Se poi va gestito nel tempo in maniera automatizzata Ansible non è comunque male ma manca di diverse feature più avanzate che si trovano in Puppet (prime tra tutte l'uso di exported resources e di hiera) e quindi non fa al caso nostro.

my two cents :-)

--
Luca Lesinigo

_______________________________________________
Talking mailing list
Talking@ml.linuxvar.it
http://ml.linuxvar.it/cgi-bin/mailman/listinfo/talking