Jenkins X: uma nova solução de CI/CD para Kubernetes – Parte 01

Motivados pelo uso crescente de contêineres (ex: Docker↳Docker46 conteúdosE o Docker Swarm? Contextos e motivadores diáriosDevSecOps · ago 2024Automatizando o ambiente de desenvolvimento e testes com DockerDevSecOps · mai 2019MySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Ver tudo em DevSecOps →), de distribuição de software, de microsserviços↳Microsserviços24 conteúdosArquitetura de Microsserviços em Node com o MoleculerJSDev (Back & Front) · jun 2025Segurança das APIs: como proteger seu ecossistema de microsserviçosDev (Back & Front) · dez 2023Você provavelmente não precisa de microsserviços (ainda)Dev (Back & Front) · mar 2026Ver tudo em Dev (Back & Front) → e do Kubernetes como plataforma de gerenciamento, uma equipe da empresa CloudBees disponibilizou recentemente à comunidade uma nova solução de CI/CD, chamada de “Jenkins X”.

A plataforma utiliza o “Core” do Jenkins (nosso velho conhecido de guerra), com algumas features adicionais que têm o objetivo de “resolver os problemas de deploy na nuvem usando o kubernetes”. Parece promissor, não?

Vamos conferir!

Features

Command-line Tool (denominado“JX”)

Isso mesmo, desenvolveram uma “command-line tool” para gerenciar o Jenkins X e os recursos do Kubernetes. A feature é semelhante ao KUBECTL (Kubernetes) e ao OC (Openshift).

É possível criar o Jenkins X em algum cluster Kubernetes existente ou até mesmo criar um cluster + Jenkins na nuvem:

• Amazon Web Services (necessário ter o KOPS);
• Microsoft Azure (Azure Kubernetes Service);
• Google Cloud (Google Kubernetes Engine);
• Ainda é possível usar uma instalação local com minikube.

Por fim, precisamos configurar uma conta GitHub durante a instalação, pois o Jenkins X vai criar alguns repositórios automaticamente para o GitOps. Calma, já já eu explico.

Ou seja, prepare-se para usar muito o comando JX! Veja alguns exemplos:

• Instalando o Jenkins

$ jx install

• Criando um cluster na AWS com Jenkins X

$ jx create cluster aws

CI/CD com GitOps

Você já ouviu falar em GitOps? Não?

É uma prática atual para desenvolvimento de aplicativos de alta velocidade, que usa ferramentas de cloud nativas. Na prática, é o “empoderamento do desenvolvedor na operação de ambientes”.

Pois bem, neste processo utilizamos ferramentas de desenvolvimento (GIT) como forma de conduzir operações nos ambientes (ex: Kubernetes). Quando passamos a utilizar o GIT como “fonte confiável”, conseguimos ter ao mesmo tempo rastreabilidade, confiabilidade (pois as operações são realizadas via PULL REQUESTS) e adotar boas práticas utilizadas em processos de CI/CD.

O GIT é o “carro-chefe” na condução de operações no Jenkins X, desde a criação de ambientes até o processo de promoção. Para tudo isso são criados PULL REQUESTS que, combinados com as automações pré-definidas na plataforma, realizam deploys sem a necessidade de uso de um CLI (kubectl) conduzindo tal operação.

Criação simplificada de Pipelines

A princípio você não precisa ser um expert em “Jenkinsfile”. Existem dois métodos para criar um projeto de forma rápida no Jenkins X usando o JX:

Importando um repositório GIT:

$ cd git-repo/
$ jx import

$ cd git-repo/
$ jx import

Após a importação do projeto, é criado um DRAFT_PACK no repositório de acordo com a linguagem, que pode ser (atualmente):

• C#
• Golang
• Graddle
• JavaScript
• Maven
• PHP
• Python
• Ruby
• Rust
• Swift

Alguns recursos deste DRAFT_PACK precisam ser versionados no repositório GIT:

• Jenkinsfile: instruções de Deploy e steps de build e versionamento;
• Dockerfile: instruções de build de acordo com a linguagem;
• HelmChart: configurações da aplicação pré-definidas (inclusive com porta default da linguagem mapeada, por exemplo: 8080->8080) para o deploy no kubernetes.

Se o usuário do GIT Jenkins X tiver permissão (commit) no repositório, um WebHook será configurado automaticamente para a pipeline recém-criada (sempre serão criadas pipelines do tipo multibranch).

Legal, não? Até aqui já economizamos um bom tempo que perderíamos criando e testando essas configurações, e ainda é possível customizar estes arquivos depois, uma vez que eles estarão em seu repositório.

2. A outra forma é usar um QuickStart template de acordo com a linguagem desejada e depois ir adicionando código. Essa forma é recomendada principalmente para início de projetos.

$ jx create quickstart -l node-http

Ambientes

Como o GitOps é o “leme” do Jenkins X, podemos criar os ambientes (ex: Staging, Production,e etc) usando a command-line tool (JX). Para isso, precisamos seguir os seguintes passos:

• Um repositório no “GitHub” com as configurações do ambiente será criado automaticamente. Como está sendo adotado o GitOps, o fluxo de promoção/deploy será via “Pull Request”;
• Criar um namespace no Kubernetes;
• Na criação, é possível passar algumas opções de política de ambiente, como se a promoção é automática ou manual, por exemplo, ou a url do GIT, caso já exista o repo com as configurações para o Jenkins X (caso tenha deletado e deseja recuperar o ambiente).

$ jx create env -n myapp-production

Depois, gerencie o ambiente via JX:

Relação dos ambientes

$ jx get envs

NAME              LABEL             KIND              PROMOTE  NAMESPACE            ORDER CLUSTER SOURCE  REF PR
myapp-production  myapp-production  myapp-production  Auto     jx-myapp-production  0

“Pull Request Preview Environment”

É aqui que o DevOps passa a fazer café (trocadilhos à parte). Quando criamos um projeto no Jenkins X geramos o “DRAFT_PACK”, que contém algumas instruções. Pois bem, detalhando:

Quando há um “Pull Request” pendente, automaticamente são gerados um BUILD e um DEPLOY em um ambiente temporário, o que chamamos de “PREVIEW”;

Também é criada uma namespace específica do Pull Request no Kubernetes, isolada dos outros ambientes, produtivos ou não, e que pode ser descartada posteriormente.

$ cd git-repo/
$ jx preview myapp

Ou seja, o DEV não precisa mais demandar a criação de um ambiente temporário para validar o PULL REQUEST, o grupo consegue validar a feature e divulgar a URL para o Product Owner sem usar o “na minha máquina funciona”. Sério, mesmo em tempos de Docker isso ainda existe. Isso permite que as quebras que possam interromper o CI sejam antecipadas, mesmo em Development.

Feedback em “ISSUES” e “Pull Request”

Também é possível usar o JX para feedback:

$ jx create issue -t "vamos deixar as coisas mais incríveis"

Ou até mesmo configurar um tracker do JIRA no repositório:

$ jx create tracker server jira https://mycompany.atlassian.net/

Add-ons

Ainda não são muitos, mas é um recurso interessante para criar recursos próprios para gerenciamento pelo JX, e não diretamente pelo cluster Kubernetes. Atualmente é possível adicionar o Grafana, Gitea:

$ jx create addon grafana

Comparativo

Prós

• O GitOps é, de fato, o “Modus operandi” no Jenkins X. Ajuda muito a converter o conceito em prática;
• O uso do Helm (gerenciador de pacotes do Kubernetes) como mecanismo para manter a integridade da aplicação, bem como as configurações do próprio ambiente (ex: environments) é positivo;
• O desenvolvimento de uma command-line tool (JX) foi essencial para este projeto, espero que surjam mais features com o tempo.

Contras

• A command-line tool “JX” atende bem, mas ainda falta alguns recursos, como a ausência de um comando para obter a relação de aplicativos ativos no “preview”, o que nos força a usar o “kubectl” para obter isso direto do cluster;
• O processo de instalação requer conhecimentos em Kubernetes, que em algum momento serão necessários para um possível “Troubleshooting”, casos nos quais o Jenkins X está sendo instalado em um cluster já existente.

Considerações finais

O objetivo de o desenvolvedor ter mais autonomia está sendo alcançado com gerenciamento simplificado (kubernetes) e um processo de deploy moderno (GitOps).

Ainda há pontos de melhoria, mas sair da zona de conforto (CloudBees) para tentar resolver problemas de CI/CD na nuvem em favor da comunidade e se adaptar às mudanças é louvável. Vale a pena testar para ter uma alternativa futuramente, visto que pipelines com “Jenkinsfile” são largamente utilizadas, o que minimiza transtornos de adaptação, além de adotar as boas práticas que estão sendo propostas pela plataforma.

Se ainda tem dúvida com o Kubernetes, tem alguns artigos que podem te ajudar:

• As diferenças entre Docker, Kubernetes e Openshift;
• Tudo o que você precisa saber sobre Kubernetes – Parte 1;
• Tudo o que você precisa saber sobre Kubernetes – Parte 2.

E se ainda quiser saber mais, pode dar uma olhada nestes artigos:

• Introducing Jenkins X: a CI/CD solution for modern cloud applications on Kubernetes;
• GitHub Jenkins X;
• Jenkins X is a CI/CD solution for modern cloud applications on Kubernetes.

Voltarei para explicar passo a passo do processo de instalação e o uso de uma aplicação Demo, beleza?

Até a próxima!

***

Este artigo foi publicado originalmente em: https://www.concrete.com.br/2018/04/26/jenkins-x-uma-nova-solucao-de-ci-cd-para-kubernetes-parte-1/