Estrutura do projeto

Neste laboratório, vamos montar um ambiente completo de CI/CD rodando totalmente local, usando ferramentas open source de nível enterprise — sem custos e sem depender de nuvem.

---

Pré-requisitos do ambiente

Ferramentas no host (Windows)

• Docker Desktop
• Kubernetes local (Kind)
• kubectl
• Helm
• Git
• Java 17

O que isso resolve?

Esse conjunto cria um ambiente enterprise-like, mas totalmente local — um CI/CD sem custos.

Docs oficiais:

• Docker Desktop
• Kind
• kubectl
• Helm

---

1. Arquitetura do laboratório

Visão geral do fluxo CI/CD

Código → Github → Jenkins → Kaniko (CI) → Registry no Kubernetes → ArgoCD (CD) → Aplicação no Cluster

Fluxo Técnico Detalhado (Passo a Passo Real)

1️⃣ Developer → GitHub

• Alteramos o código
• Commit inclui: código Java, Dockerfile, Jenkinsfile e (opcional) helm/

Ponto crítico: Jenkinsfile versionado → pipeline imutável.

---

2️⃣ GitHub → Jenkins

• Trigger via SCM Polling — como estamos rodando em localhost, o GitHub não consegue descobrir o Jenkins via webhook, por isso configuramos polling a cada 2 minutos.

---

3️⃣ Jenkins → Pod Efêmero (Kubernetes Plugin)

Pod gerado dinamicamente contendo:

• jnlp — conecta ao controller
• kaniko — build de imagem (alternativa moderna)

Decisão de arquitetura:

• Sem Docker-in-Docker (DinD)
• Sem privileged container
• Totalmente cloud-native

---

4️⃣ Build da Aplicação

Dentro do pod:

mvn clean package -DskipTests

Resultado: JAR/WAR no workspace (emptyDir)

---

5️⃣ Build da Imagem com Kaniko

/kaniko/executor \
  --context=${WORKSPACE} \
  --dockerfile=${WORKSPACE}/Dockerfile \
  --destination=${REGISTRY_CI}/${PROJECT}/${IMAGE_NAME}:${TAG} \
  --insecure \
  --skip-tls-verify \
  --cleanup

📌 O que é Kaniko? Kaniko é uma ferramenta open source para criar imagens de contêineres a partir de um Dockerfile diretamente dentro de um contêiner ou cluster Kubernetes, sem depender de um daemon Docker. Ideal para ambientes de CI/CD seguros — ele executa cada comando no espaço do usuário, cria as camadas e empurra direto para o registry.

---

6️⃣ Push → Docker Registry

O registry local recebe a imagem com sua tag.

---

7️⃣ Docker Registry Local → ArgoCD → Kubernetes

O ArgoCD:

• Observa alterações no repositório gitops-repo
• Os manifests Kubernetes apontam para a imagem no registry: image: localhost:5000/cicd/cicd-api:30
• Quando há mudança no Git: sincroniza o estado, aplica o Deployment e o Kubernetes faz o pull da imagem do registry no namespace cicd

👉 O ArgoCD não faz build — ele apenas aplica manifests. O build já foi feito pelo Kaniko.

---

2. Pré-requisitos do ambiente local

Infra base (máquina host):

• Docker Desktop ou Podman
• Kubernetes local: Kind (recomendado) ou k3d
• kubectl
• Helm 3.x
• Java 17 (para Jenkins pipelines e apps Java)
• Git
• Conta no GitHub

---

3. Kubernetes local com Kind

Manual de instalação: kind.sigs.k8s.io

Se estiver usando WSL:

curl -Lo kind https://kind.sigs.k8s.io/dl/v0.31.0/kind-linux-amd64
chmod +x kind
sudo mv kind /usr/local/bin/kind
kind version

O Kind (Kubernetes IN Docker) cria clusters Kubernetes usando containers Docker. É ideal para labs, CI pipelines e testes locais — rápido, descartável e reproduzível.

Criar o cluster

kind create cluster --name cicd-lab
kubectl cluster-info

Após o comando, você verá:

Set kubectl context to "kind-cicd-lab"
You can now use your cluster with: kubectl cluster-info --context kind-cicd-lab

Caso ocorra erro de versão (WSL/Docker Desktop)

Crie o arquivo kind-config.yaml:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: cicd-lab

nodes:
  - role: control-plane
    image: kindest/node:v1.29.4

containerdConfigPatches:
  - |-
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."localhost:5000"]
    endpoint = ["http://localhost:5000"]
    insecure_skip_verify = true

Depois:

kind create cluster --config kind-config.yaml --wait 5m

---

4. Configurar namespace no Kubernetes

kubectl create namespace cicd

Saída esperada: namespace/cicd created

Por que usar namespaces? Eles permitem isolamento lógico, organização por responsabilidade e simulação de ambientes (dev, cicd, infra).

Docs: kubernetes.io/docs/.../namespaces

---

5. Registry no Kubernetes

Subimos um Docker Registry oficial (registry:2) como Deployment no namespace cicd.

Componentes:

• Deployment: 1 réplica, porta 5000, hostPort: 5000 para expor diretamente no nó Kind
• Volume: emptyDir (não persistente, suficiente para lab)
• Service: Exposição interna no cluster (registry.cicd.svc.cluster.local:5000)

👉 Aqui o registry é um Pod Kubernetes, diferente do setup clássico com Docker externo.

Crie o arquivo registry.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: registry
  namespace: cicd
spec:
  replicas: 1
  selector:
    matchLabels:
      app: registry
  template:
    metadata:
      labels:
        app: registry
    spec:
      containers:
        - name: registry
          image: registry:2
          ports:
            - containerPort: 5000
              hostPort: 5000
          volumeMounts:
            - name: registry-data
              mountPath: /var/lib/registry
      volumes:
        - name: registry-data
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: registry
  namespace: cicd
spec:
  selector:
    app: registry
  ports:
    - port: 5000
      targetPort: 5000

Aplique e valide:

kubectl apply -f registry.yaml
kubectl get pods -n cicd

O hostPort: 5000 permite que o registry seja acessado via http://localhost:5000, facilitando testes locais com curl e push de imagens sem NodePort ou Ingress.

⚠️ hostPort é aceitável em labs, não recomendado em produção.

---

6. Jenkins no Kubernetes

Utilize o projeto como base: github.com/guigomes91/cicd — e deixe uma ⭐!

Instalação via Helm

helm repo add jenkins https://charts.jenkins.io
helm repo update

helm install jenkins jenkins/jenkins \
  -n cicd \
  --set controller.serviceType=NodePort

Por que NodePort no lab?

Item	Situação
Kubernetes	Kind (local)
Infra	Docker Desktop + WSL2
LoadBalancer	❌ Não existe
Ingress Controller	❌ Ainda não instalado

Em produção, o padrão é:

Ambiente	Exposição
Dev local	NodePort
Staging	Ingress
Produção	Ingress + TLS + LB

Acessar o Jenkins

kubectl get svc -n cicd
# jenkins   NodePort   ...   8080:30170/TCP

kubectl port-forward -n cicd svc/jenkins 8080:8080

Acesse: http://localhost:8080

Senha inicial do Jenkins

kubectl exec -n cicd deploy/jenkins -c jenkins -- cat /run/secrets/additional/chart-admin-password

# Alternativa:
kubectl get secret -n cicd jenkins -o jsonpath="{.data.jenkins-admin-password}" | base64 -d

Criando o Pipeline

Clique em + Nova tarefa:

Informe o nome da tarefa (ex: cicd-api) e selecione Pipeline. Após criada, clique no link do job e depois em Configurar:

Na seção Triggers, marque Consultar periodicamente o SCM e configure o agendamento:

Na seção Pipeline, em Definition selecione Pipeline script from SCM:

Informe a URL do repositório e a branch (ex: master):

Em Script Path, deixe Jenkinsfile e clique em Save:

O que o Jenkins faz?

O Jenkins é o motor de CI: executa pipelines, compila código, roda testes, builda imagens Docker e publica artefatos. Ele não faz deploy — prepara tudo para o CD.

Docs: jenkins.io/doc | Helm Chart

---

Configurar SSH para o Kaniko atualizar o GitOps repo

Para o Kaniko atualizar o Deployment no repositório gitops-repo, é necessário configurar autenticação SSH dentro do pod, pois:

• ❌ O container do Jenkins não conhece o host github.com
• ❌ Não existe chave SSH válida dentro do pod
• ➡️ Cada pod é um ambiente totalmente limpo

Crie um secret no namespace cicd com o nome jenkins-gitops-ssh:

sudo nano jenkins-gitops-ssh.yaml

apiVersion: v1
kind: Secret
metadata:
  name: jenkins-gitops-ssh
  namespace: cicd
type: Opaque
data:
  id_ed25519: <BASE64_DA_CHAVE_PRIVADA>
  known_hosts: <BASE64_DO_KNOWN_HOSTS>

Verificar chaves existentes:

ls -l ~/.ssh

Se não existir nenhuma chave, gere uma ED25519:

ssh-keygen -t ed25519 -C "jenkins-gitops"
# Pressione ENTER em todas as perguntas, sem senha

Gerar os valores Base64:

# Chave privada
base64 -w 0 ~/.ssh/id_ed25519

# Known hosts do GitHub
ssh-keyscan github.com > /tmp/known_hosts
base64 -w 0 /tmp/known_hosts

Adicionar a chave pública no GitHub:

• Repositório gitops-repo → Settings → Deploy Keys
• Marcar ✅ Allow write access

Aplique o secret:

kubectl apply -f jenkins-gitops-ssh.yaml

# Validar
kubectl get secret jenkins-gitops-ssh -n cicd -o yaml

---

7. ArgoCD

# Criar namespace
kubectl create namespace argocd

# Aplicar manifests oficiais
kubectl apply -n argocd \
  -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

# Aguardar pods
kubectl get pods -n argocd

Acesso à interface web

kubectl port-forward svc/argocd-server -n argocd 8083:443

Acesse: https://localhost:8083 — usuário: admin

Recuperar senha inicial:

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath="{.data.password}" | base64 -d

Após o primeiro login, altere a senha.

Criando uma Application (GitOps)

Repositório de exemplo: gitops-repo/cicd-api/app/deployment.yaml

sudo nano application-argocd.yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cicd-api
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/seu-user/gitops-repo.git
    targetRevision: master
    path: cicd-api/app
  destination:
    server: https://kubernetes.default.svc
    namespace: cicd-api
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

kubectl apply -f application-argocd.yaml

Após isso, a aplicação aparece no dashboard do ArgoCD e qualquer alteração no Git é refletida no cluster.

Regra fundamental do GitOps

Nunca altere recursos diretamente no cluster. Qualquer mudança via kubectl edit ou apply será revertida para o estado definido no Git.

Validar sincronização:

kubectl get applications -n argocd

Ou acompanhe na interface web — Status: Synced | Health: Healthy

☝️ O ponto-chave: O ArgoCD não faz build, não baixa imagem e não decide registry. Ele faz apenas uma coisa: aplica no Kubernetes exatamente o que está no Git. Quem decide de onde vem a imagem é exclusivamente o Deployment.

---

8. Aplicação de exemplo (Java Spring Boot)

Repositório: github.com/guigomes91/cicd

app/
 ├── Dockerfile
 ├── Jenkinsfile
 ├── pom.xml
 └── src/

Dockerfile:

FROM eclipse-temurin:17-jre
COPY target/app.jar app.jar
ENTRYPOINT ["java","-jar","/app.jar"]

---

9. Cenários práticos para treino

Exercício 1 – CI

• Faça um commit que quebra o build
• Valide a falha no Jenkins

Exercício 2 – CD

• Suba uma nova imagem e observe o deploy automático
• Acompanhe o rollout no Kubernetes:

kubectl rollout status deployment cicd-api

Exercício 3 – Rollback

kubectl rollout undo deployment cicd-api

---

10. Evoluções do laboratório

Depois do básico, você pode adicionar:

• SonarQube — quality gate
• Trivy — scan de imagem
• Prometheus + Grafana — observabilidade
• Feature flags
• Separação de namespace por ambiente — dev, homolog e produção
• Multi-branch pipeline — separação por branch (dev, hml, prod)

---

11. Resultado final

Ao final do laboratório, você terá praticado:

• ✅ CI real com Jenkins
• ✅ Docker Registry local no Kubernetes
• ✅ Deploy via ArgoCD (GitOps)
• ✅ Kubernetes local com Kind
• ✅ Rollout, rollback e versionamento de imagens