Chef è uno strumento appropriato da utilizzare per la distribuzione delle applicazioni? [chiuso]

Question

Chef è uno strumento appropriato da utilizzare per la distribuzione delle applicazioni? [chiuso]

#1 da (4 voti)
#2 da (0 voti)

5

Usiamo lo Chef sia per la gestione della configurazione (assicurandoci che un "nodo DB" abbia la giusta versione del DB corretto su di esso, che un "App Server" abbia la versione giusta di Java e di env vars su di esso, ecc.) . così come la distribuzione ( chef-client --once ) delle nostre app ai nodi appropriati del server delle app.

Per me, personalmente, mi sembra che il deployment appartenga al regno del server CI. Tutto a parte l'app (il contenitore, il sistema operativo, gli strumenti di sistema, la configurazione del sistema, ecc.) Appartiene alla gestione della configurazione ed è quindi meglio gestito da strumenti come Chef, Puppet, ecc.

Attualmente, le nostre build CI producono un artefatto (un JAR eseguibile con un contenitore Tomcat incorporato), quindi esegue lo Chef-Client su tutti i nodi su cui il JAR deve essere distribuito. Lo Chef-Client è configurato per estrarre il JAR dal server CI. Mi sembra un hacker e sto cercando di trovare una soluzione migliore e più convincente.

Quindi chiedo:

La distribuzione appartiene al server CI o allo strumento CM? Perché?
Se appartiene al server CI, quali meccanismi (SSH, SCP, ecc.) devono essere utilizzati dal server CI per eseguire effettivamente la distribuzione? Usiamo Bamboo ma potremmo altrettanto facilmente parlare di Jenkins, Hudson, ecc.
C'è una differenza tra distribuire (posizionando l'app sul nodo) e in esecuzione . L'esecuzione appartiene anche al server CI, allo strumento CM o ad altri processi? In altre parole, cosa dovrebbe smettere la "vecchia" versione dell'app, sostituirla con la "nuova" versione e quindi avviare la nuova versione? È un candidato per qualcosa come Run Deck?

continuous-integration deployment configuration-management orchestration

posta herpylderp 01.08.2014 - 21:27

fonte

2 risposte

Leggi altre domande sui tag continuous-integration deployment configuration-management orchestration

Coerenza finale nei sistemi bancari Perché le eccezioni F # generalmente non sono suffissate con "Eccezione"?

score 4 · Answer 1

Sospetto che le risposte saranno in gran parte basate sull'opinione pubblica e rifletteranno l'atmosfera politica delle aziende per cui lavorano, ma qui ...

Direi che tutto inizia con "perché?" Perché costruiamo app? Per soddisfare gli obiettivi di business. Perché costruiamo infrastrutture? Per eseguire app che soddisfano gli obiettivi aziendali. Quindi sembra che ci sia una gerarchia naturale qui. I server CI costruiscono app e le testano su qualcosa . Gli strumenti CM creano server. Pertanto, una catena DevOps opportunamente configurata probabilmente utilizza i server CI per richiamare gli strumenti CM per assicurarsi che il luogo in cui sta per distribuire sia configurato correttamente. Quindi, una volta superati i test, quegli stessi server CI invocano gli strumenti di distribuzione (se necessario) per inviare il codice ai server di produzione che potrebbero essere compilati con gli script CM in caso di necessità, se necessario. In altre parole, gli script diventano la definizione di ciò che è lì - non vengono apportate modifiche ai server che non sono prima sottoposti a script. Per quanto riguarda il rimbalzo dell'app esistente, ciò dipenderà dalla configurazione della tua infrastruttura. Se puoi tranquillamente portare offline un server di app (senza influire sugli utenti), distribuire nuovo codice, eseguire un smoke test e riportare tutto in linea in uno script scorrevole in una farm di server, questo è quello che stai cercando - continua capacità di consegna che non influenzano gli utenti finali.

score 0 · Answer 2

La mia opinione è che la distribuzione appartenga al server CI. Uno strumento CM come lo chef è quello di costruire la tua infrastruttura allo stato desiderato. Ma l'implementazione è più di questo. Si supponga di dover implementare un sistema che include un'applicazione Web front-end su più server con bilanciamento del carico, alcuni script di modifica DB e alcuni servizi di back-end su un altro set di server. Ci sono dipendenze e ordine coinvolti nella distribuzione. per esempio. Il DB cambia prima dei servizi di back-end su tutti i server e prima dell'applicazione Web front-end. Potrebbero essere necessarie azioni da intraprendere in caso di errore in qualsiasi fase. Lo chef, come ho capito, non può gestire questo tipo di scenari, mentre qualsiasi strumento CI competente sarebbe.
L'altro problema è spesso che l'infrastruttura delle volte è condivisa tra più app e viene aggiornata / aggiornata in una cadenza diversa rispetto alle app e infatti un'app non dovrebbe aggiornare l'infrastruttura in quanto non la possiede. Questo è un altro motivo per tenere separati CI e CM.