É razoável executar processos com ferramentas de IC?

Na minha empresa, temos uma variedade de tarefas cron díspares (em vários sistemas) e iniciamos manualmente os processos que mantêm nossos negócios funcionando, resultado de anos de desenvolvimento conveniente e subseqüente negligência.

Um dia, precisaremos encontrar uma solução mais centralizada por razões óbvias.

Um pensamento que estamos discutindo é usar nosso software de Integração Contínua (Jenkins) para executar esses processos, o que parece lógico.

Minha pergunta é: outras empresas estão fazendo isso? Essa é uma prática geralmente aceita? Isso não entra em conflito com a definição de uma ferramenta de IC implícita em seu nome? Existem outras opções?

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

Jenkins afirma que se concentra em "Monitorando execuções de tarefas executadas externamente, como tarefas cron e tarefas procmail". Não tenho certeza se é exatamente disso que estou falando.

Estamos usando o Jenkins como cron cron há alguns anos e aqui estão alguns prós e contras:

Prós

• Se você estiver gerenciando um grande número de processos em dezenas de servidores e vários ambientes, isso facilitará muitas coisas. Você recebe alertas por e-mail imediatamente, um painel comum para tudo, uma interface da web para logs e uma maneira fácil de configurar nós adicionais para executar tarefas. As equipes de suporte apreciam especialmente a localização central para verificar problemas e executar novamente os trabalhos.

• O ecossistema de plug-ins do Jenkins é muito ativo e oferece uma série de funcionalidades adicionais ... Acho que esse é realmente o recurso "matador" do Jenkins, pois se o próprio Jenkins não fornecer o que você está procurando (geralmente o caso), mais Muitas vezes, existe um plugin que faz. Alguns dos meus favoritos: Coluna Cron, Reconstruir, Parâmetro NodeLabel, Analisador de Log e Email-ext.

• Suporte avançado de agendamento / acionador: a sintaxe do agendamento é basicamente cron, portanto, você tem a mesma flexibilidade, mas isso é complementado pelos acionadores, pela API REST e pela API Groovy / Java.

Contras

• Ponto central da falha: como todos os seus trabalhos são iniciados por um servidor, se essa caixa for desativada e ninguém perceber, Big Trouble. Então é melhor você ter um bom monitoramento para detectar interrupções imediatamente, bem como todas as suas configurações salvas no controle de origem. Mesmo que você não consiga fazer o backup do servidor original, contanto que você tenha as suas configurações de trabalho, é trivial configurá-las em outro lugar. Se o tempo para resolução é uma preocupação, ter uma espera pré-configurada em algum lugar provavelmente também é uma boa idéia.

• Se você possui vários ambientes (Dev, UAT, Prod), normalmente você tem versões ligeiramente diferentes de um trabalho em execução em cada ambiente. Ter todos esses trabalhos em um Jenkins pode se tornar pesado, e configurá-los manualmente é uma grande dor. No nosso caso, executamos uma instância separada do Jenkins 'Cron' para cada ambiente. As instâncias são instaladas e configuradas automaticamente usando uma ferramenta de implantação interna. Você pode não ter algo assim, mas existem ferramentas de código aberto que fazem coisas semelhantes (gerar configurações usando modelos). Se você puder resolver o problema de geração de configurações, isso facilita muito a instalação e a implantação do Jenkins, além de manter todas as suas coisas sob controle de origem.

• Às vezes, atualizar o Jenkins interrompe a funcionalidade, especialmente com plugins. Não atualize sua instância de missão crítica do Jenkins até experimentar a nova versão em outro lugar primeiro. É aqui que ter um ambiente Dev de espelho com sua própria instância Jenkins é realmente útil.

Uma coisa a ser enfatizada: De fato, também usamos o Jenkins para CI, mas essa é uma instância separada ... as instâncias 'cron' são dedicadas ao gerenciamento de tarefas e a instância 'CI' é dedicada ao CI. Separar as preocupações parece tornar as coisas mais limpas.

Como uma observação lateral, eu uso o Jenkins em vez do cron na minha caixa do Linux em casa :)

A propósito, esse é realmente um caso de uso Jenkins bastante comum. Por exemplo, o Sandia National Lab usa Jenkins desta maneira: https://software.sandia.gov/trac/fast/wiki/Hudson

E existem inúmeras postagens em blog e tutoriais descrevendo isso. Aqui estão alguns exemplos: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

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

Devo acrescentar também que isso realmente se refere a Jenkins, e nem todas as ferramentas de IC em geral. Só porque Jenkins é adequado para fazer isso não significa que outros (TeamCity, buildbot, etc.) sejam ...

Eu diria que você não está usando a ferramenta certa para o trabalho aqui, pois o principal ponto das ferramentas de CI é que elas monitoram algo - seu código-fonte normalmente - e quando há uma alteração, elas iniciam uma compilação / implantação / o que quer que seja .

No entanto, essas ferramentas podem executar tarefas agendadas (o TeamCity executa, por exemplo), para que você possa implantar um site (por exemplo) quando não houver ninguém por perto. Portanto, ter uma lista central única de todas as tarefas que você executa é de fato uma boa idéia. As ferramentas também devem permitir que você decida quando e com que frequência esses trabalhos serão executados.

Outro benefício é que você pode monitorar o sistema remotamente (se desejar).

Então, pensando bem, eu diria que era uma coisa sensata a se fazer.

Parece que o cron já é uma ferramenta apropriada para suas necessidades. Eu recomendo que você comece documentando melhor o seu sistema. Audite os vários sistemas e monte uma lista abrangente de quais processos são executados em quais máquinas.

Em seguida, considere designar uma máquina dedicada para executar todos esses processos cron. Documente qual é a máquina e atribua os privilégios de administrador apropriados para controlá-la. Coloque todos os cronjobs nessa máquina e você terá um ponto de controle central para seus vários processos automatizados.

Minha reação intestinal é a mesma: você está usando uma ferramenta que possui um conceito de agendamento, para fazer o trabalho de um agendador de tarefas.

Você não mencionou quais são seus trabalhos, mas sua menção ao CRON me faz adivinhar que são scripts de shell, etc. Existem pacotes de agendador de trabalhos de código aberto e comerciais por aí. Às vezes, eles são chamados de agendadores em lote. Alguns apenas encerram o CRON e o tornam mais amigável. Alguns, como o Quartz scheduler, realizam um gerenciamento poderoso de tarefas, mas exigem que elas sejam implementadas como classes Java. Você pode usar isso potencialmente e finalizar as chamadas de tempo de execução para seus vários scripts usando um wrapper java. Acredito que você encontrará muitas opções se procurar mais.

Não use o IC para executar tarefas periódicas não relacionadas à construção.

Evite também o cron para tarefas não relacionadas à manutenção do sistema.

Use as ferramentas certas. Para necessidades de aplicativos - tente usar soluções baseadas em AMQP.

PS Entendo, esse cron se encaixa no seu caso. Por outro lado, você tem muitas tarefas - tente escrever um aplicativo supervisor para elas.

Você precisa usar um barramento de serviço corporativo (ESB) para esse tipo de tarefa.

Agora, meu histórico é no windows / BizTalk, mas tenho certeza de que todos os equivalentes também existem no lado unix. O que normalmente faríamos é configurar processos na caixa do BizTalk que seriam responsáveis ​​por iniciar as coisas na outra caixa, monitorar o progresso / erros e relatar o status para o portal do SharePoint (ou web) ou enviar e-mails e tal se precisar de atenção.

Os benefícios dessa abordagem são que toda a configuração e gerenciamento de seus vários processos de negócios estão localizados centralmente, para que você saiba por onde começar a procurar. Já existe o software que permite abstrair a parte de codificação da configuração física (no BizTalk, você pode programar em uma 'porta' lógica como um servidor sql e, em seguida, em prod, se uma caixa sql mudar de local ou for atualizada ou qualquer outra coisa, você pode alterar a porta física configurada usando sua ferramenta de administração; novamente, tenho certeza de que existem equivalentes no lado do unix).

Os benefícios do uso de ferramentas de IC seriam coisas como, se o seu processo errar, você pode automaticamente reenviar fisicamente as mensagens e configurar um ambiente de failover em cluster, com um sistema de registro e registro mais adequado; Além disso, uma vez que você tenha o sistema instalado, você poderá começar a arquitetar sua organização para usar ou utilizar melhor a SOA. O lado negativo é que, dependendo do tamanho da sua organização, o esforço de desenvolvimento pode ser alto e os custos de licenciamento podem ser proibitivos.

Teoricamente, faz sentido que você tenha um único local para controlar todos os trabalhos díspares; no entanto, com base na experiência do setor que é como o "Santo Graal", você precisará de trabalhos cron aqui, bash scripts lá e scripts cli por aqui.

Também existe um mantra "Se não está quebrado, não conserte", portanto, enquanto eles estão caminhando, concentre-se inicialmente em documentar quais scripts você está executando, o que eles executam e quais sistemas tocam para que você "saiba" "como sua empresa está sendo administrada.

Então, como estratégia de longo prazo, configure um sistema centralizado para executar as tarefas, escolha sua solução com sabedoria, porque você terá que viver com ela. Em seguida, para cada solicitação de mudança, aprimoramento, atualização, correção de bug ou nova solução adicionada na arquitetura de negócios, assegure que suas tarefas agendadas e automatizadas sejam adicionadas à sua "solução de controle corporativo".

Dessa forma, você migra gradualmente de um lote de scripts para um ambiente mais corporativo.

Nos grandes sistemas corporativos com os quais trabalhei, eles tendem a usar uma ferramenta projetada para agendamento. O mais popular que eu usei é o CA7. Permite centralizar todo o agendamento para todos os seus sistemas.

O Cron é geralmente usado para uma única máquina, embora você possa "hackear" fazendo chamadas remotas ssh. No entanto, não terá o conceito de dependências e outras coisas. Quando se trata de equipes de operações cujo escopo é ainda mais limitado, é melhor que uma ferramenta seja usada.