É razoável executar processos com ferramentas de IC?

29

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.

smp7d
fonte
2
Você pode esclarecer a natureza das várias tarefas e processos que tem em mente?
Stephen Gross
Uma mistura de roteiros em várias línguas, processos java, e comandos Linux
smp7d
Precisamos de mais detalhes. Qual é a natureza das tarefas? O que eles fazem? Como eles são gerenciados?
Stephen Gross
@StephenGross Reúna dados de sistemas externos para armazenamento local, envie notificações aos usuários com base em regras de negócios, verifique o uso do disco, exclua órfãos e milhares de outras coisas. Todos eles são gerenciados pelo cron se forem gerenciados nesse momento. Por que você precisa desses detalhes? Você pode simplesmente assumir que eles executam funções críticas de negócios em um cronograma.
27412 smp7d
2
A razão pela qual eu preciso desses detalhes é porque, para ajudá-lo com seu problema, preciso entender o problema. Embora você já saiba bastante sobre essas tarefas / processos, eu não; é útil entender a natureza das tarefas a serem executadas ao avaliar que tipo de solução técnica funciona melhor.
Stephen Gross

Respostas:

17

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 ...

Dylan Cali
fonte
8

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.

ChrisF
fonte
Seus sentimentos sobre o assunto refletem os meus. Como o CI geralmente é conhecido por compilar e testar, eu o vejo como uma solução não ortodoxa. As outras respostas a essa pergunta definitivamente mostraram que esse é o caso, pois muitos a veem obviamente como a ferramenta errada para o trabalho. Como o TeamCity pode executar essas tarefas adicionais, qualquer ferramenta de IC que use projetos Maven pode fazer várias coisas. Ainda me sinto desconfortável por ser uma boa ideia.
smp7d
1
@ smp7d - concordou. É uma solução possível , mas não uma solução ideal .
ChrisF
6

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.

Stephen Gross
fonte
2

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.

Guerry
fonte
Os trabalhos são uma mistura de scripts em vários idiomas, processos java e comandos linux. Só o quartzo não me dará o gerenciamento de front-end / build que o Jenkins forneceria e eu não quero criar tudo isso. Eu não ficaria surpreso se Jenkins usasse Quartz nos bastidores. Vou verificar este Quartz Manager ( terracotta.org/products/quartz-scheduler ).
smp7d 24/02
2

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.

Nikolay Fominyh
fonte
1
Obrigado pela resposta. Você pode descrever o que você quer dizer com "aplicativo supervisor"?
smp7d
Em algumas palavras - é supervisord.org . Metaprograma que controla o status e a execução de outros processos. Você pode facilmente desenvolver sua própria solução que atenda às suas necessidades. Eu tenho um lote de tarefas periódicas no meu projeto e o github.com/ask/django-celery me ajuda a sair do cron.
Nikolay Fominyh
Obrigado, eu vou olhar para Supervisor. O objetivo de usar a ferramenta de IC era impedir que precisássemos escrever nossa própria ferramenta. A ferramenta de IC é lisa como pode ser já.
smp7d
1
Acho que não tenho o representante para votar, mas é uma resposta bastante terrível - pena que tenha recebido a recompensa. O que torna uma ferramenta a "ferramenta certa"? Mesmo que tenha exatamente todos os componentes necessários, é a "ferramenta errada" porque é chamada de sistema de IC?
DougW
1

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.

aceinthehole
fonte
Talvez isso seja aplicável, mas não tenho certeza se é mais um caso de aplicação da ferramenta errada como o CI seria. Tenho a impressão de que o ESB seria usado quando fossem necessárias coreografias de comunicação ou processo. Nesse caso, queremos apenas o gerenciamento central para uma matriz de processos independentes. Estamos bem em executar comandos linux personalizados através do gerenciamento central; portanto, qualquer agnosticismo de OS / Linguagem de Programação provavelmente é um exagero. Provavelmente vale a pena investigar isso, obrigado.
smp7d
Se você é uma loja unix definitivamente concorda com isso, sei que a IBM tem um produto em sua linha websphere, e também existem métodos web que são comerciais e appache tem uma oferta de código aberto; você está certo no que diz respeito à sua definição de ESB, infelizmente o ESB se tornou um pouco ambíguo em seu uso, mas considere se você deseja adicionar relatórios de erros centralizados ou qualquer tipo de relatório como 'executou' no seu processo que é coreografia.
aceinthehole
@ smp7d Eu sei que o webMethods Integration Server tem suporte de agendamento de primeira classe. Funciona bem.
Robert Grant
1

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.

Stephen Senkomago Musoke
fonte
Estes são alguns bons pensamentos. Então você acha que o que estou procurando não existe e que uma ferramenta de IC não é uma alternativa razoável?
smp7d
Pode existir, mas o pragmatismo sobre o que você usa pode fazer com que você ainda tenha tarefas cron e scripts bash. No entanto, o uso do ambiente de IC pode ser um obstáculo mais tarde, porque o CI é principalmente para fluxos de trabalho de desenvolvimento, mas à medida que o ambiente amadurece, você procura soluções relacionadas a operações. Posteriormente, você pode optar por mover seu controle de versão / IC para a nuvem. Você não quer que isso seja atolado pela execução das operações diárias das organizações.
Stephen Senkomago Musoke
Bem, estávamos pensando em usar uma ferramenta de IC separada para gerenciamento de processos, mas entendo o que você está dizendo.
smp7d
Como você está procurando um IC separado, por que não procurar ferramentas focadas no gerenciamento, monitoramento e relatório de processos. Dessa forma, você alavancar o esforço para a criação do CI em obter a ferramenta certa para o trabalho, se ele falhar, você tem a CI para voltar a cair
Stephen Senkomago Musoke
Concordo que este é o caminho mais razoável a seguir. O Quartz Scheduler, supervisord.org e um ESB foram recomendados. Você tem alguma recomendação adicional ou opinião sobre isso? (também: Quando eu disse CI separado, Eu só quis dizer outra instalação da nossa ferramenta atual, talvez com alguma nova marca ... configuração não seria um problema)
smp7d
0

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.

Archimedes Trajano
fonte
Sua recomendação me levou a isso ... en.wikipedia.org/wiki/Job_scheduler - Surpreendentemente, ninguém jamais mencionou esse nome para essa ferramenta. Pode ser o que eu estava procurando, como se fosse projetado para fazer o que estou procurando, o tempo provavelmente mostrará que ele faz isso melhor do que uma ferramenta de IC. Vai demorar algumas pesquisas para verificar isso.
smp7d