È ragionevole eseguire processi con strumenti CI?

Nella mia azienda, abbiamo una serie di lavori cron disparati (su più sistemi) e avviato manualmente i processi che mantengono il funzionamento della nostra attività che è il risultato di anni di sviluppo conveniente e conseguente abbandono.

Un giorno, avremo bisogno di trovare una soluzione più centralizzata per ovvie ragioni.

Un pensiero che ci stiamo dando da fare è usare il nostro software di integrazione continua (Jenkins) per eseguire questi processi, il che sembra logico.

La mia domanda è: lo stanno facendo altre aziende? È una pratica generalmente accettata? Questo conflitto con la definizione di uno strumento CI non è implicito nel suo nome? Ci sono altre opzioni?

Nota: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

Jenkins afferma di concentrarsi sul "Monitoraggio delle esecuzioni di lavori eseguiti esternamente, come cron lavori e procmail". Non sono sicuro se questo è esattamente ciò di cui sto parlando.

Usiamo Jenkins come cronista da un paio d'anni ormai, e qui ci sono alcuni pro e contro:

Professionisti

• Se gestisci un gran numero di processi su dozzine di server e ambienti multipli, questo semplifica molte cose. Ricevi avvisi e-mail pronti all'uso, una dashboard comune per tutto, un'interfaccia Web per i registri e un modo semplice per impostare nodi aggiuntivi su cui eseguire i lavori. I team di supporto apprezzano in particolare la posizione centrale per il controllo dei problemi e la riesecuzione dei lavori.

• L'ecosistema di plug-in di Jenkins è molto attivo e offre una serie di funzionalità aggiuntive ... Penso che questa sia davvero la funzione "killer" di Jenkins, poiché se Jenkins stesso non fornisce ciò che stai cercando (spesso il caso), altro spesso c'è un plugin che lo fa. Alcuni dei miei preferiti: Cron Column, Rebuild, NodeLabel Parameter, Log Parser ed Email-ext.

• Pianificazione avanzata / supporto trigger: la sintassi della pianificazione è fondamentalmente cron, quindi hai la stessa flessibilità lì, ma questo è integrato da Trigger, API REST e API Groovy / Java

Contro

• Punto centrale di errore: poiché tutti i tuoi lavori vengono avviati da un server, se quella casella non funziona e nessuno se ne accorge, Big Trouble. Quindi è meglio avere un buon monitoraggio per rilevare immediatamente le interruzioni, così come tutte le configurazioni salvate nel controllo del codice sorgente. Anche se non è possibile eseguire il backup del server originale, purché si configurino le configurazioni del lavoro, è banale installarle da qualche altra parte. Se il tempo necessario per la risoluzione è un problema, probabilmente anche avere uno standby preconfigurato da qualche parte è una buona idea.

• Se si dispone di più ambienti (Dev, UAT, Prod), in genere si hanno versioni leggermente diverse di un lavoro in esecuzione su ciascun ambiente. Avere tutti questi lavori su uno Jenkins può diventare ingombrante e configurarli manualmente può essere una seccatura. Nel nostro caso, eseguiamo un'istanza "Cron" di Jenkins separata per ciascun ambiente. Le istanze vengono installate e configurate automaticamente utilizzando uno strumento di distribuzione interno. Potresti non avere qualcosa del genere, ma ci sono strumenti open source che fanno cose simili (generano configurazioni usando modelli). Se riesci a risolvere il problema di generazione della configurazione, ciò semplifica notevolmente la configurazione e la distribuzione di Jenkins, oltre a semplificare il controllo del codice sorgente.

• L'aggiornamento di Jenkins a volte interrompe la funzionalità, specialmente con i plugin. Non aggiornare l'istanza Jenkins di importanza critica fino a quando non hai provato prima la nuova versione da qualche altra parte. Qui è utile avere un ambiente Dev mirror con la propria istanza Jenkins.

Una cosa forse da sottolineare: in effetti utilizziamo anche Jenkins per CI, ma questa è un'istanza separata ... le istanze "cron" sono dedicate alla gestione dei lavori e l'istanza "CI" è dedicata a CI. Separare le preoccupazioni sembra rendere le cose più pulite.

Come nota a margine, uso Jenkins invece di cron sul mio Linux box a casa :)

A proposito, questo è in realtà un caso d'uso piuttosto comune di Jenkins. Ad esempio, Sandia National Lab utilizza Jenkins in questo modo: https://software.sandia.gov/trac/fast/wiki/Hudson

E ci sono numerosi post sul blog e tutorial che descrivono questo. Ecco un paio di esempi: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

http://morgajel.net/2011/12/12/1108

Dovrei anche aggiungere che questo riguarda solo Jenkins e non tutti gli strumenti di CI in generale. Solo perché Jenkins è adatto a farlo non significa che altri (TeamCity, buildbot, ecc.) Siano ...

Avrei detto che non stai usando lo strumento giusto per il lavoro qui, poiché il punto principale degli strumenti CI è che monitorano qualcosa - il tuo codice sorgente in genere - e quando c'è un cambiamento danno il via a una build / deploy / qualunque cosa .

Tuttavia, questi strumenti possono eseguire lavori pianificati (ad esempio TeamCity), quindi è possibile distribuire un sito Web (ad esempio) quando non c'è nessuno in giro. Quindi avere un unico elenco centrale di tutte le attività che esegui è in realtà una buona idea. Gli strumenti dovrebbero anche consentire di decidere quando e con quale frequenza eseguire questi lavori.

Un altro vantaggio è che puoi persino monitorare il sistema da remoto (se lo desideri).

Quindi, a conti fatti, direi che è stata una cosa sensata da fare.

Sembra che cron sia già uno strumento appropriato per le tue esigenze. Ti consiglio di iniziare documentando meglio il tuo sistema. Controlla i vari sistemi e metti insieme un elenco completo di quali processi funzionano su quali macchine.

Quindi prendere in considerazione la designazione di una macchina dedicata per eseguire tutti questi processi cron. Assicurati di documentare quale macchina è e di assegnare i privilegi di amministratore appropriati per controllarla. Metti tutti i cronjob su quella macchina e avrai un punto di controllo centrale per i tuoi vari processi automatizzati.

La mia reazione istintiva è la stessa, che stai usando uno strumento che ha un concetto di pianificazione, per fare il lavoro di un programmatore di lavoro.

Non hai menzionato quali sono i tuoi lavori, ma la tua menzione di CRON mi fa indovinare che sono script di shell, ecc. Esistono pacchetti open source e commerciali di scheduler di lavori. A volte vengono definiti programmatori batch. Alcuni concluderanno CRON e lo renderanno più amichevole. Alcuni, come lo schedulatore Quartz, svolgono una potente gestione dei lavori, ma richiedono che siano implementati come classi Java. Potresti potenzialmente usarlo e concludere le chiamate di runtime ai tuoi vari script usando un wrapper Java. Credo che troverai molte opzioni se guardi oltre.

Non utilizzare CI per l'esecuzione di attività periodiche non correlate alla compilazione.

Evita anche cron per le attività non correlate alla manutenzione del sistema.

Usa gli strumenti giusti. Per esigenze applicative, prova a utilizzare soluzioni basate su AMQP.

PS Vedo, quel cron si adatta al tuo caso. D'altra parte hai un sacco di compiti - quindi prova a scrivere app supervisore per loro.

È necessario utilizzare un bus di servizio aziendale (ESB) per questo tipo di attività.

Ora il mio background è in windows / BizTalk, ma sono sicuro che tutti gli equivalenti esistono anche dal lato unix delle cose. Quello che normalmente faremmo è impostare processi nella casella BizTalk che sarebbero incaricati di dare il via alle cose sull'altra scatola, monitorare l'avanzamento / errori e riportare lo stato al portale di SharePoint (o web) o inviare e-mail e tale se ha bisogno di attenzione.

I vantaggi di questo approccio sono che tutta la configurazione e la gestione dei vari processi aziendali sono centralizzati, in modo da sapere da dove iniziare a cercare. Il software esiste già che ti consente di sottrarre la parte di codifica dalla configurazione fisica (in BizTalk puoi programmare contro una 'porta' logica come un server sql, e quindi in prod, se una casella sql cambia posizione o viene aggiornata o altro, tu possono cambiare la porta fisica configurata usando il loro strumento di amministrazione, di nuovo, sono sicuro che esistano equivalenti sul lato Unix).

I vantaggi dell'utilizzo di uno strumento CI sarebbero: se il tuo errore di processo ti consente di inviare automaticamente i messaggi e puoi impostare un ambiente di failover cluster, con un sistema di registrazione e registrazione più adatto; inoltre, una volta installato il sistema, ti consentirebbe di iniziare a progettare la tua organizzazione da utilizzare o utilizzare meglio la SOA. Il lato negativo è che, a seconda delle dimensioni dell'organizzazione, lo sforzo di sviluppo potrebbe essere elevato e i costi di licenza potrebbero essere proibitivi.

Teoricamente ha senso avere una singola posizione per controllare tutti i lavori disparati, tuttavia in base all'esperienza del settore che è come il "Santo Graal" avrai bisogno di lavori cron qui, bash script lì e script cli qui.

C'è anche un mantra "Se non è rotto, non aggiustarlo", quindi mentre si spostano, inizialmente concentrati sulla documentazione di quali script hai in esecuzione, cosa fanno e quali sistemi toccano in modo che tu "sappia "come viene gestita la tua attività.

Quindi, come strategia a lungo termine, imposta un sistema centralizzato per l'esecuzione dei lavori, scegli saggiamente la tua soluzione perché dovrai convivere con essa. Quindi, per ogni richiesta di modifica, miglioramento, aggiornamento, correzione di bug o nuova soluzione aggiunta all'interno dell'architettura aziendale, assicurarsi che le attività pianificate e automatizzate vengano aggiunte alla "soluzione di controllo aziendale".

In questo modo si passa gradualmente da una serie di script a un ambiente più aziendale.

Nei grandi sistemi aziendali con cui ho lavorato, tendono a utilizzare uno strumento progettato per la pianificazione. Il più popolare che ho usato è CA7. Ti consente di centralizzare tutta la programmazione per tutti i tuoi sistemi.

Cron è generalmente usato per la singola macchina, anche se puoi "hackerarlo" facendo chiamate remote ssh. Tuttavia, non avrà il concetto di dipendenze e altre cose. Quando si tratta di team operativi in ​​cui il loro ambito è ancora più limitato, è meglio utilizzare uno strumento.