Distribuire il nostro software usando Puppet?


8

(Mi scuso in anticipo per la stupidità in questa domanda. Normalmente sono un programmatore, non un amministratore di sistema, ma mi sono preso la responsabilità di automatizzare alcune cose e di ripulire alcune altre cose che sono automatizzate ma non nel modo più carino . :-)

Ho cercato vari strumenti per l'automazione della distribuzione del software su un gruppo di server, come cfengine, Puppet e Chef. Finora, Puppet sembra il più interessante, ma di certo non mi sono ancora impegnato in nulla.

Sembra che tutti questi strumenti possano fare un ottimo lavoro nel mantenere aggiornati un sacco di server con software preconfezionato .

Quello che non capisco è: come si usa uno strumento (come Puppet) per gestire le distribuzioni del nostro software interno? Penso di essere in perdita perché ho visto un migliaio di tutorial che mostrano come mantenere Apache ensure => latest(che è piuttosto interessante), ma niente che corrisponda abbastanza al mio caso d'uso oggi, che è qualcosa di più simile a:

  1. quando un essere umano preme il pulsante,
  2. estrarre il ramo A dal repository di controllo versione B
  3. eseguire il comando C per compilarlo
  4. copiare i file binari D sui server da E1 a E10
  5. su ciascun server, eseguire il comando F per rendere effettive tutte le modifiche

Puppet suona alla grande, e vedo totalmente il vantaggio di una configurazione dichiarativa e idempotente su alcuni script di shell, ma non ho visto nessun tutorial per "vuoi aggiornare i tuoi script di shell a Puppet (o Chef o cfengine), quindi ecco cosa dovresti ... dovrebbe". C'è una cosa del genere? È ovvio per gli altri come prendere le cose fornite nei documenti Puppet e replicare il comportamento che desidero? Non lo capisco?

Quello che mi sembra, finora, è che l'essere umano (n. 1) impacchetterebbe manualmente il software (n. 2 e n. 3) esterno a Puppet, aggiornando manualmente la configurazione Puppet, il che farebbe scattare Puppet per aggiornare i server. .. può essere? (Sono un po 'confuso qui, come sono sicuro che puoi dire.)

Grazie!


Puppet è progettato per funzionare con il modello "Pacchetti, file, servizi". Puppet sarebbe fantastico per preparare i tuoi server, ma un server di generazione continua come Jenkins potrebbe essere uno strumento migliore per questo caso d'uso.
spuder,

Risposte:


5

Usiamo le marionette, ma non le usiamo per le nostre distribuzioni di applicazioni. Come hai detto, potresti impacchettare il tuo software in debs o rpms, configurare il tuo repository privato ovunque e usare le marionette per controllare le versioni, ma sei ancora in balia dell'attesa del prossimo aggiornamento di 30 minuti su tutti i tuoi server.

Cosa farei (e questo è vicino a quello che facciamo, ma usiamo le rotaie quindi non c'è un passo di compilazione):

  • Usa le marionette per configurare tutto sul server tranne l'applicazione stessa. Dipendenze, server Web, utenti, percorsi, ecc.
  • Chiedi al tuo server di build automatizzato (bamboo, hudson, cruise control, ecc.) Di mettere i manufatti compilati in un gestore di repository come Nexus.
  • Usa capistrano per inviare build ai tuoi server.

Lo chef potrebbe avere più capacità di push in tempo reale; Non ne ho molta familiarità.


Questo particolare software non utilizza Ruby. Ho avuto l'impressione che Puppet sia piuttosto agnostico, ma Capistrano è progettato per funzionare al meglio con le app Rails. Ma sono passati un paio d'anni da quando ho usato il cappuccio, quindi forse è cambiato, e lo controllerò di nuovo ora.
Ken,

1
Capistrano si inclina verso Rails, ma è flessibile e può essere facilmente utilizzato per altre lingue. Basta leggere le ricette di distribuzione predefinite e sovrascriverle nella propria ricetta. È solo programmazione. La mia azienda distribuisce dozzine di app PHP su una manciata di server tramite Capistrano, sebbene utilizziamo il frontend Webistrano per renderlo più gestibile.
Martijn Heemels,

2
Capistrano va bene, ma MCollective e RunDeck sono ottimizzati per integrarsi con Puppet.
jgoldschrafe,

Puoi anche dare un'occhiata a Fabric; è un po 'come Capistrano, ma in Python.
Xiong Chiamiov

1

I passaggi da 1 a 3 sono comunemente automatizzati in un processo di compilazione. Normalmente, l'output di questo processo passerà attraverso un ciclo di test. Imballare l'output in modo che possa essere distribuito in un ambiente di test di integrazione. Solo se i test di integrazione superano i passaggi 4 e 5 devono verificarsi.

Il passaggio 5 implica un'interruzione della distribuzione. Per qualcosa come Apache, questo può essere gestito dall'arresto e dal riavvio durante la rotazione del registro. Uno script crontab può gestirlo. Se è possibile gestire le modifiche a rotazione per un periodo di circa un'ora, è sufficiente includere il riavvio nel passaggio di distribuzione 4. Puppet o cfengine sono strumenti appropriati per il passaggio 4. Questo può essere attivato aggiornando il repository quando i test di integrazione passano.


1

Cerca ricette di marionette e troverai tonnellate di script pronti per la produzione. Sì, è necessario impacchettare manualmente il software. Se si mantiene il proprio repository personale, è possibile utilizzare il flag sure => latest. Quindi scrivi una ricetta per dire a Puppet di installare il software. La ricetta dovrebbe essere posizionata sul server master da dove verrebbe propagata agli slave.

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.