a. Visão geral

As práticas de DevOps buscam encurtar o ciclo de vida de desenvolvimento de software automatizando as etapas de build, teste e deploy. Duas práticas fundamentais sustentam essa automação¹:

Visão geral de CI/CD. Fonte: ByteByteGo - A Crash Course in CI/CD

• Integração Contínua (CI) — os desenvolvedores fazem merge de mudanças com frequência; cada merge dispara um ciclo automatizado de build e teste.
• Entrega Contínua (CD) — toda mudança que passa pela CI é empacotada automaticamente e fica pronta para o deploy em qualquer ambiente.

flowchart LR
    dev([Desenvolvedor]) -->|git push| scm[Controle de Versão]
    scm -->|webhook / poll| ci[Servidor de CI\nJenkins]
    subgraph pipeline [Pipeline]
        direction LR
        build[Build] --> test[Teste] --> image[Empacotar\nImagem Docker] --> push[Push\nRegistry]
    end
    ci --> pipeline
    push -->|deploy| env([Ambiente\nde Destino])
    classDef highlight fill:#FCBE3E
    class ci highlight

O Jenkins é um dos servidores de automação open source mais adotados. Ele orquestra pipelines de CI/CD por meio de um rico ecossistema de plugins e suporta Pipeline as Code — definições de pipeline versionadas no repositório, junto com o código da aplicação, em um arquivo chamado Jenkinsfile².

1. Configuração — Jenkins em container

Executar o Jenkins dentro do Docker mantém a máquina hospedeira limpa e torna o ambiente reproduzível entre máquinas.

📁 api/
📁 jenkins/
└──  compose.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

name: ops

services:

  jenkins:
    container_name: jenkins
    build:
      dockerfile_inline: |
        FROM jenkins/jenkins:jdk25
        USER root

        # Install Tools
        RUN apt-get update && apt-get install -y lsb-release net-tools iputils-ping maven curl

        # Install Docker
        RUN curl -fsSLo /usr/share/keyrings/docker-archive-keyring.asc \
          https://download.docker.com/linux/debian/gpg
        RUN echo "deb [arch=$(dpkg --print-architecture) \
          signed-by=/usr/share/keyrings/docker-archive-keyring.asc] \
          https://download.docker.com/linux/debian \
          $(lsb_release -cs) stable" > /etc/apt/sources.list.d/docker.list
        RUN apt-get update && apt-get install -y docker-ce

        # Install kubectl
        RUN curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/$(dpkg --print-architecture)/kubectl" \
            && chmod +x kubectl \
            && mv kubectl /usr/local/bin/kubectl

        # Install AWS CLI
        RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-$(arch).zip" -o "awscliv2.zip" && \
            echo "Unzipping AWS CLI..." && \
            unzip awscliv2.zip && \
            ./aws/install --update && \
            rm awscliv2.zip && \
            rm -rf ./aws

        RUN usermod -aG docker jenkins
    ports:
      - 9080:8080
    volumes:
      - ${CONFIG:-./config}/jenkins:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
    restart: always

O compose.yaml constrói uma imagem personalizada sobre jenkins/jenkins:jdk25, com ferramentas extras pré-instaladas:

O processo do Jenkins é adicionado ao grupo docker para que os pipelines possam executar comandos docker sem precisar de root. Para isso, o socket do Docker do host (/var/run/docker.sock) é montado (bind mount) dentro do container³.

Inicie o servidor:

jenkins/# docker compose up -d --build

[+] Running 2/2
 ✔ jenkins Created              0.1s
 ✔ Container jenkins Started    0.2s

O Jenkins agora está disponível em http://localhost:9080/.

2. Configuração inicial

Desbloqueie o Jenkins

Na primeira inicialização, o Jenkins gera uma senha inicial de administrador aleatória para impedir acessos não autorizados⁴. Abra a interface e informe-a quando solicitado:

Recupere a senha com um dos comandos:

docker logs jenkins 2>&1 | grep -A 3 "initialAdminPassword"

docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

Depois de informar a senha, escolha Install suggested plugins e crie um usuário administrador.

Número de executores

Um executor é um slot onde o Jenkins executa uma etapa (stage) de pipeline ou um job. O padrão é 2; aumentar esse número permite que vários jobs rodem em paralelo, o que é útil ao fazer o build de vários microsserviços na mesma instância.

Manage Jenkins → Nodes → Built-In Node → Configure → Number of executors → 10

3. Credenciais

Antes de criar pipelines que publicam imagens Docker, armazene o segredo do Docker Hub no repositório de credenciais do Jenkins. As credenciais são injetadas nos pipelines em tempo de execução — nunca são gravadas em disco nem aparecem nos logs⁵.

Manage Jenkins → Credentials → System → Global credentials → Add Credentials

4. Pipeline as Code

Um Jenkinsfile descreve o pipeline em uma DSL declarativa e fica na raiz do repositório. O Jenkins faz o checkout dele automaticamente quando um build é disparado, de modo que o pipeline evolui junto com o código⁷.

flowchart LR
    repo[Repositório Git\nJenkinsfile] -->|checkout do SCM| jenkins[Job do Jenkins]
    jenkins --> s1[Stage: Build]
    s1 --> s2[Stage: Teste]
    s2 --> s3[Stage: Build & Push da Imagem]
    s3 --> s4[Stage: Deploy]

O Jenkins suporta duas sintaxes de pipeline:

Os exemplos abaixo usam a sintaxe declarativa.

5. Exemplos

account — Apenas build

O primeiro pipeline compila o módulo account e gera o artefato:

📁 api/
└── 📁 account/
    └──  Jenkinsfile

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

pipeline {

    agent any

    stages {
        stage('Build') {
            steps {
                sh 'mvn -B -DskipTests clean install'
            }
        }
    }

}

A única etapa, Build, executa mvn -B -DskipTests clean install. A flag -B habilita o batch mode (sem prompts interativos), o que é necessário em ambientes de CI não interativos.

Criando um job

Crie um New Item, escolha o tipo Pipeline e defina a Definition como Pipeline script from SCM. O Jenkins vai clonar o repositório e ler o Jenkinsfile a cada build.

account-service — Build, empacotamento e push

Um pipeline completo que faz o build do serviço, cria uma imagem Docker multiplataforma e a publica no Docker Hub:

📁 api/
└── 📁 account-service/
    └──  Jenkinsfile

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

pipeline {
    agent any
    environment {
        SERVICE = 'account' // Name of the service being built
        NAME = "humbertosandmann/${env.SERVICE}" // Docker Hub repository name
    }
    stages {
        stage('Dependecies') {
            steps {
                build job: 'account', wait: true
            }
        }
        stage('Build') { 
            steps {
                sh 'mvn -B -DskipTests clean package'
            }
        }      
        stage('Build & Push Image') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'dockerhub-credential',
                    usernameVariable: 'USERNAME',
                    passwordVariable: 'TOKEN')])
                {
                    sh "docker login -u $USERNAME -p $TOKEN"
                    sh "docker buildx create --use --platform=linux/arm64,linux/amd64 --node multi-platform-builder-${env.SERVICE} --name multi-platform-builder-${env.SERVICE}"
                    sh "docker buildx build --platform=linux/arm64,linux/amd64 --push --tag ${env.NAME}:latest --tag ${env.NAME}:${env.BUILD_ID} -f Dockerfile ."
                    sh "docker buildx rm --force multi-platform-builder-${env.SERVICE}"
                }
            }
        }
    }
}

Passo a passo

Bloco environment

environment {
    SERVICE = 'account'
    NAME    = "humbertosandmann/${env.SERVICE}"
}

Declara duas variáveis válidas em todo o pipeline. NAME é o nome completo do repositório no Docker Hub. Referenciar env.SERVICE dentro de NAME evita duplicar o nome do serviço.

Etapa Dependencies

stage('Dependencies') {
    steps {
        build job: 'account', wait: true
    }
}

Dispara jobs upstream do Jenkins antes de prosseguir. wait: true bloqueia até que cada job termine com sucesso, garantindo que os artefatos das dependências estejam atualizados antes do build do serviço atual.

Etapa Build

sh 'mvn -B -DskipTests clean package'

Compila o projeto e gera o JAR executável. Os testes são pulados intencionalmente aqui — adicione uma etapa Test separada com mvn test se quiser que o pipeline exija a aprovação nos testes.

Etapa Build & Push Image

withCredentials([usernamePassword(
    credentialsId: 'dockerhub-credential',
    usernameVariable: 'USERNAME',
    passwordVariable: 'TOKEN')]) {

    sh "docker login -u $USERNAME -p $TOKEN"
    sh "docker buildx create --use \
          --platform=linux/arm64,linux/amd64 \
          --node multi-platform-builder-${env.SERVICE} \
          --name multi-platform-builder-${env.SERVICE}"
    sh "docker buildx build \
          --platform=linux/arm64,linux/amd64 \
          --push \
          --tag ${env.NAME}:latest \
          --tag ${env.NAME}:${env.BUILD_ID} \
          -f Dockerfile ."
    sh "docker buildx rm --force multi-platform-builder-${env.SERVICE}"
}

• withCredentials — injeta no ambiente de build o token do Docker Hub armazenado no passo 3. Os valores são mascarados em todos os logs do Jenkins⁵.
• docker buildx — cria um builder BuildKit que faz a compilação cruzada de imagens tanto para linux/arm64 (Apple Silicon, AWS Graviton) quanto para linux/amd64 (x86-64 padrão)⁸.
• Duas tags — :latest oferece uma referência estável; :<BUILD_ID> fixa um build específico do Jenkins, de modo que qualquer imagem possa ser rastreada até o commit de origem.
• A instância do builder é removida após o push para liberar recursos do sistema.