È ragionevole eseguire processi con strumenti CI?

Usiamo Jenkins come cron per un paio di anni fa, e qui ci sono alcuni pro e contro:

Pro

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

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

• Supporto di programmazione / trigger avanzato: la sintassi del programma è fondamentalmente cron, quindi hai la stessa flessibilità, ma questo è completato da Trigger, l'API REST e l'API Groovy / Java

Contro

• Punto centrale di errore: poiché tutti i tuoi lavori vengono avviati da un server, se quella casella si interrompe e nessuno nota, Big Trouble. Quindi è meglio avere un buon monitoraggio per arrestare le interruzioni immediatamente, così come tutte le configurazioni salvate nel controllo del codice sorgente. Anche se non è possibile ripristinare il server originale, finché hai le configurazioni del tuo lavoro è banale farle installare da qualche altra parte. Se il tempo di risoluzione è un problema, avere uno standby preconfigurato da qualche parte è probabilmente anche 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 poco maneggevole, e configurarli manualmente diventa un enorme dolore. Nel nostro caso, eseguiamo un'istanza separata di Cron di Jenkins 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 (generate configurazioni usando template). Se riesci a risolvere il problema della generazione di configurazioni, questo rende molto più facile l'impostazione e la distribuzione di Jenkins, e rende anche più facile mantenere tutte le tue risorse nel controllo del codice sorgente.

• L'aggiornamento di Jenkins a volte interrompe la funzionalità, specialmente con i plugin. Non aggiornare la tua istanza Jenkins mission critical finché non hai provato la nuova versione da qualche altra parte prima. È qui che avere un ambiente Dev mirror con la sua istanza Jenkins è molto utile.

Una cosa da sottolineare: usiamo anche Jenkins per CI, ma questa è un'istanza separata ... le istanze di "cron" sono dedicate alla gestione dei lavori e l'istanza di "CI" è dedicata all'elemento della configurazione. Separare le preoccupazioni sembra rendere le cose più pulite.

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

A proposito, questo è in realtà un caso d'uso Jenkins piuttosto comune. Ad esempio, Sandia National Lab utilizza Jenkins in questo modo: link

E ci sono numerosi post sul blog e tutorial che lo descrivono. Ecco alcuni esempi: link

link

Devo anche aggiungere che questo riguarda solo Jenkins, e non tutti gli strumenti della CI in generale. Solo perché Jenkins è adatto per fare questo non significa che gli altri (TeamCity, buildbot, ecc) sono ...

Avrei detto che non stai usando lo strumento giusto per il lavoro in quanto il punto principale degli strumenti CI è che monitorano qualcosa - tipicamente il tuo codice sorgente - e quando c'è un cambiamento danno inizio a una build / deploy / che mai.

Tuttavia, questi strumenti possono eseguire lavori programmati (ad esempio, TeamCity), quindi è possibile distribuire un sito Web (ad esempio) quando non c'è nessuno intorno. Quindi avere una sola lista centrale di tutti i compiti che svolgi è di fatto una buona idea. Gli strumenti dovrebbero anche consentire di decidere quando e quanto spesso questi lavori vengono eseguiti.

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 crea un elenco completo dei processi che vengono eseguiti su quali macchine.

Quindi considera la possibilità di designare una macchina dedicata per eseguire tutti questi processi cron. Assicurati di documentare quale macchina è, e assegna i privilegi di amministratore appropriati per controllarlo. Metti tutti i cronjobs su quella macchina, e poi hai un punto di controllo centrale per i vari processi automatizzati.

La mia reazione istintiva è la stessa, che stai usando uno strumento che ha un concetto di pianificazione in esso, 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. Ci sono pacchetti di pianificazione di lavoro open source e commerciali là fuori. Talvolta vengono definiti scheduler batch. Alcuni completeranno semplicemente CRON e renderanno più amichevole. Alcuni, come il programma di pianificazione Quartz, svolgono una potente gestione dei lavori, ma richiede che vengano implementati come classi Java. Potresti potenzialmente usarlo e concludere le chiamate di runtime ai vari script usando un wrapper java. Credo che troverai molte opzioni se guardi oltre.

Non utilizzare l'elemento della configurazione per eseguire attività periodiche non correlate alla creazione.

Evita anche cron per le attività che non riguardano la manutenzione del sistema.

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

P.S. 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 sul lato unix delle cose. Quello che faremmo normalmente è impostare i processi nella casella BizTalk che dovrebbe occuparsi del kicking delle cose sull'altra casella, monitorare i progressi / errori e riportare lo stato al portale 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, quindi sai dove iniziare a cercare. Il software esiste già che ti permette di astrarre la parte di codifica dalla configurazione fisica (in BizTalk puoi programmare contro una 'porta' logica come un server sql, e poi in prod, se una casella sql cambia posizione o è aggiornata o altro, tu può cambiare la porta fisica configurata usando il loro strumento di amministrazione, di nuovo, sono sicuro che esistono equivalenti sul lato unix).

I vantaggi nell'utilizzo di strumenti CI sono cose del tipo, se il tuo errore di processo è possibile automaticamente, inviare nuovamente i messaggi in modo fisico ed è possibile impostare un ambiente di failover in cluster, con un sistema di registrazione e registrazione più adatto; inoltre, una volta installato il sistema, ti consentirebbe di avviare l'architet- tura della tua organizzazione da utilizzare o meglio utilizzando SOA. Il lato negativo è che, a seconda delle dimensioni della tua organizzazione, lo sforzo di sviluppo potrebbe essere elevato ei costi delle licenze potrebbero essere proibitivi.

In teoria è logico che tu abbia un'unica posizione per controllare tutti i lavori più disparati, tuttavia basandoti su un'esperienza del settore simile a "Holy Grail" avrai bisogno di cron job qui, bash scripts lì e cli script qui.

Esiste anche un mantra "Se non è rotto, non aggiustarlo", così mentre stanno arrancando, concentrati inizialmente sul documentare quali script hai in esecuzione, cosa fanno e quali sistemi toccano in modo che tu "sai" come viene gestita la tua attività.

Quindi, come strategia a lungo termine, imposta un sistema centralizzato per l'esecuzione dei lavori, scegli saggiamente la soluzione perché devi conviverci. Quindi, per ogni richiesta di modifica, miglioramento, aggiornamento, correzione di bug o nuova soluzione che aggiungi all'interno della tua architettura aziendale, assicurati che le attività programmate e automatizzate siano aggiunte alla tua "soluzione di controllo aziendale".

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

Nei sistemi aziendali di grandi dimensioni con cui ho lavorato, tendono a utilizzare uno strumento progettato per la pianificazione. Il più popolare che ho usato è CA7. Permette di centralizzare tutte le programmazioni per tutti i tuoi sistemi.

Cron viene generalmente utilizzato per la singola macchina, anche se puoi "hackerarlo" effettuando 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.