Kestra: operações automatizadas além de CI/CD

Segunda-feira, 9h Um desenvolvedor precisa de um servidor de teste. Ele abriu o sistema de tickets, digitou o nome do host, sistema operacional e centro de custo e esperou. Um dia, às vezes três. Em algum momento, a VM acabou na caixa de entrada, definida como há duas semanas, porque ninguém havia mexido no modelo desde então.

O reflexo para resolver este problema com as ferramentas existentes é compreensível. Pipelines no Azure DevOps ou GitHub Actions são escritos rapidamente. Mas as ferramentas de CI/CD são criadas para outras coisas: construir código, testar, implantar. Você cumpre seu compromisso, cumpre-o e pronto. Fluxos de trabalho de longa duração, lógica de repetição e gerenciamento de estado não são domínio deles.

Kestra preenche essa lacuna. A ferramenta foi desenvolvida pela Kestra Technologies desde 2021 e estará disponível ao público a partir de fevereiro de 2022 – principalmente como um projeto de código aberto sob a licença Apache 2.0. As funções empresariais comerciais complementam o núcleo do OSS. Kestra se vê como um orquestrador universal: para automação de operações, pipelines de dados, fluxos de trabalho orientados a eventos e cada vez mais para agentes e fluxos de trabalho de IA; Tudo é declarativo no YAML, tudo é diversificável no Git. Este artigo usa um exemplo concreto para mostrar como isso acontece na prática: um desenvolvedor pede ao Hetzner VM para usar o formulário, o Kestra provisiona automaticamente usando o Terraform. Todo o código para Terraform, configuração do Kestra e Kestra Flows pode ser encontrado no repositório GitHub do autor.

Orquestração não é o mesmo que automação

Quando você ouve falar do Kestra pela primeira vez, provavelmente pensa que é apenas mais uma ferramenta que agrupa scripts de shell em uma interface de usuário bonita. Isso não se aplica. A diferença de conceito: script de shell ou sequência de pipeline de CI/CD: etapa A seguida de B, depois C e, no final, o status é concluído ou com falha. A ferramenta não está interessada no que acontece no meio. O Kestra, por outro lado, orquestra: conhece o status de cada etapa individual, pode esperar por eventos externos, tratar erros especiais, paralelizar as etapas e continuar o fluxo de trabalho após horas ou dias no ponto exato onde foi interrompido.

Esta não é uma distinção puramente acadêmica. Na prática, isso significa que o Kestra pode desenhar fluxos de trabalho que não podem ser representados com ferramentas clássicas de pipeline: um projeto de provisionamento que espera até que o sistema externo esteja pronto, um pipeline de dados que faz uma pausa de três minutos se houver um erro HTTP e depois tenta novamente, uma implantação que só continua após uma liberação manual. Outro dispositivo chamado “tubo” é o fluxo no Kestra.

A equipe de desenvolvimento por trás do projeto posicionou deliberadamente o Kestra para usos múltiplos. Focar em:

• Automação de operações: Infraestrutura de provedores, clusters de provedores, automatizando tarefas operacionais contínuas.
• Pipeline de dados: Kestra compete diretamente com Apache Airflow e Prefect
• Fluxo de trabalho orientado a eventos: fluxos que respondem a webhooks, mensagens de fila ou alterações de arquivo.
• Fluxo de trabalho KI: Kestra gerencia agentes de IA como tarefas clássicas de operações.

Quatro blocos de construção básicos

Kestra tem quatro conceitos que os desenvolvedores precisam internalizar primeiro para compreender melhor a abordagem geral da ferramenta.

UM Fluxo é a unidade superior, comparável à definição do pipeline, mas com expressividade significativamente maior. Cada fluxo possui um ID, um namespace para configuração e uma lista de tarefas. Ele reside como um arquivo YAML no Git e pode ser desviado e distribuído por meio dele.

tarefa são etapas individuais no fluxo. Kestra vem com uma biblioteca completa de tipos de tarefas integradas: solicitações HTTP, operações de arquivo, comandos shell, execução de contêiner, loops, condições e paralelização. Uma tarefa pode produzir resultados que tarefas subsequentes usam como entrada. Isso cria um fluxo de dados compreensível entre as etapas individuais do fluxo.

Acionar determinar quando o fluxo começa. Você pode escolher entre um agendamento (Cron), webhooks, outros fluxos como gatilhos ou execução manual por meio da UI. O gatilho manual não deve ser subestimado: ele abre automaticamente o formulário de entrada na UI do Kestra para todas as entradas declaradas.

Plug-ins expandindo Kestra com integração externa. O ecossistema oficial de plugins inclui Terraform, Kubernetes, AWS, Azure, GCP, Slack, dbt e Airbyte e muito mais. O plugin é uma versão JAR que o Kestra carrega na inicialização, sem gerenciamento de dependência separado ou pip install.

A lista abaixo mostra o fluxo mínimo:

id: hello-kestra
namespace: demo

inputs:
  - id: message
    type: STRING
    defaults: "Hallo von Kestra"

tasks:
  - id: log
    type: io.kestra.plugin.core.log.Log
    message: "{{ inputs.message }}"

Este fluxo mostra algo importante: namespaces demo A estrutura do fluxo na IU é semelhante às pastas. Entrada message aparece como um campo de texto quando executado manualmente. A tarefa faz referência à entrada usando a sintaxe do modelo Pebble {{ inputs.message }}. A mesma sintaxe pode ser usada em qualquer lugar do fluxo para segredos, para saída de tarefas anteriores e metadados de execução.

Não é um substituto, mas um acréscimo

Uma pergunta confiável: já temos Azure DevOps? Nós realmente precisamos disso? A resposta é sim e não. O Azure DevOps ou o GitHub Actions permanecem imbatíveis no que você pode fazer: compilar código, testar, criar contêineres e implantar artefatos. Quem quiser mudar de tarefa tem o problema errado, porque Kestra começa em um ponto diferente.

CI/CD continua sendo a camada certa para tudo que vem do warehouse: construção, teste, envio. No entanto, muitos processos operacionais começam com pedidos e não com compromissos: é necessário criar ambientes, verificar as alterações, libertar recursos ou integrar serviços externos. É exatamente aqui que o Kestra complementa o cenário CI/CD existente.

Exemplo concreto: um desenvolvedor deseja provisionar um cluster Kubernetes. Isso pode ser representado tecnicamente no pipeline do Azure DevOps terraform apply como uma tarefa de script. O que está faltando é tudo ao redor: nenhum formulário de entrada estruturado para desenvolvedores e nenhuma lógica de repetição limpa se o provedor de nuvem não responder. Também não há registros mostrando quem solicitou recursos e quando. Acima de tudo, o pipeline cuida do Terraform no estilo “dispare e esqueça”: inicie o script, execute-o, espere o resultado – o que acontece no meio é intangível. Kestra, por outro lado, encapsula completamente cada execução com seus parâmetros: estado, registro e comportamento de nova tentativa que são claramente atribuídos a uma execução específica e podem ser entendidos na IU. Se uma etapa falhar, Kestra sabe onde, com que entrada e em que estado, e pode reagir especificamente em vez de começar às cegas desde o início.

Comparação com Airflow e Prefect: o ponto de vista é importante

A alternativa ao Kestra é questionável dependendo da perspectiva, que é muito diferente entre engenharia de dados e engenharia de plataforma. Quem vem de um ambiente de engenharia de dados costuma pensar no Apache Airflow, hoje um projeto de alto nível da Apache Software Foundation, ou Prefect, desenvolvido pela empresa de mesmo nome. Airflow é um padrão estabelecido para pipelines de dados baseados em DAG com dependências, agendamento e lógica de repetição. Prefect é uma alternativa mais moderna que pontua com custos operacionais mais baixos e uma API mais enxuta. Kestra ocupa o mesmo espaço, mas é menos centrado em Python: os fluxos são definidos em YAML, as tarefas são chamadas de plugins, o conhecimento de Python não é necessário. Isso torna o Kestra mais acessível, especialmente para equipes mistas.

No entanto, na engenharia de plataformas, são utilizadas diferentes ferramentas. Os mais comuns incluem Argo Workflows como orquestrador nativo do Kubernetes, Ansible Automation Platform para tarefas operacionais e gerenciamento de configuração e Terraform Cloud para fluxos de trabalho de infraestrutura como código. Todas essas ferramentas resolvem problemas do mundo real, mas cada uma está firmemente inserida em seu próprio paradigma. Terraform Cloud faz Terraform, Argo faz fluxos de trabalho Kubernetes, Ansible Automation Platform faz Ansible. Kestra tornou-se intencionalmente mais universal aqui: um fluxo pode iniciar um contêiner Terraform, executar um script PowerShell, chamar a API HTTP e relatar os resultados no Slack – em um único fluxo YAML, sem que a ferramenta precise prestar atenção à tecnologia subjacente.

Do ponto de vista do desenvolvedor, o Azure DevOps e o GitHub Actions continuam sendo a primeira escolha para a camada CI/CD. O Airflow ou o Prefect podem continuar a servir em um ambiente baseado em dados. No entanto, Kestra complementa onde nenhuma dessas ferramentas é interna: é uma camada de orquestração que mantém unida uma paisagem de ferramentas heterogênea, mas ao mesmo tempo pode atuar como um substituto para ferramentas individuais.

Teste localmente, opere em um cluster

Kestra pode ser iniciado localmente usando Docker Compose. O Docker-compose.yml completo está no repositório GitHub. encomendado docker compose up -d suficiente, então a UI pode ser contatado diretamente:

Existe um gráfico oficial do Helm para operações produtivas no Kubernetes. Os componentes (servidor, agendador, executor e trabalhador) são executados como implantações separadas e podem ser dimensionados de forma independente. Os trabalhadores assumem a execução real das tarefas e são as principais alavancas de escala: mais execução paralela significa mais réplicas de trabalhadores, o resto da infraestrutura permanece estável. Se você também deseja gerenciar recursos Kestra (fluxos, namespaces, segredos, usuários e funções) como código, use o provedor oficial do Terraform: ele mapeia todas as configurações do Kestra como recursos do Terraform e pode ser perfeitamente integrado aos pipelines de infraestrutura como código existentes.