CI/CD Nativo no OpenShift com Pipelines

Introdução à Automação de Deploy no OpenShift

A adoção de práticas de DevOps e a implementação de pipelines de integração e entrega contínuas (CI/CD) são fundamentais para o sucesso de equipes de desenvolvimento modernas. No ecossistema OpenShift, essa automação é nativa e poderosa, permitindo que você defina suas pipelines como código (pipelines-as-code). Isso significa que a lógica de build, teste e deploy não reside apenas em ferramentas externas, mas é versionada junto com o código da aplicação dentro do próprio repositório Git.

O OpenShift utiliza o Pipeline as Code, baseado na tecnologia Tekton, para orquestrar essas tarefas. Essa abordagem oferece vantagens significativas: imutabilidade das configurações de build, rastreabilidade completa através do histórico do Git e portabilidade entre ambientes. Neste tutorial, vamos guiar você, sysadmin e desenvolvedor, pela configuração de um pipeline completo no OpenShift, desde a criação dos recursos necessários até o deploy automático de uma aplicação containerizada.

Pré-requisitos e Preparação do Ambiente

Antes de iniciar a configuração das pipelines, é essencial garantir que seu ambiente esteja preparado. Você precisará de acesso ao cluster OpenShift com permissões suficientes para criar projetos (namespaces) e recursos de pipeline.

1. Instalação do CLI: Certifique-se de ter o oc CLI instalado e configurado para apontar para seu cluster. Faça login usando o comando:

oc login --server=https://your-openshift-cluster:6443 -u username -p password

2. Criação do Projeto: Crie um novo projeto (namespace) para isolar sua aplicação e seus recursos de CI/CD. Isso facilita a gestão de permissões e limpeza posterior.

oc new-project meu-app-ci-cd --description="Projeto Demo CI/CD" --display-name="Meu App"

3. Seleção do Projeto: Defina o projeto como padrão para suas operações subsequentes.

oc project meu-app-ci-cd

Criando o Serviço de Build (Source-to-Image)

O primeiro passo em uma pipeline é transformar o código-fonte em uma imagem Docker. No OpenShift, a forma mais integrada e eficiente de fazer isso é utilizando a tecnologia Source-to-Image (S2I). Embora o Tekton seja o motor das pipelines, ele pode orquestrar builds S2I nativos do OpenShift.

Criaremos um BuildConfig que define como sua imagem deve ser construída. Suponha que você tenha uma aplicação simples em Python ou Node.js no seu repositório Git.

cat <<EOF | oc apply -f -
apiVersion: build.openshift.io/v1
kind: BuildConfig
metadata:
  name: meu-app-build
spec:
  strategy:
    type: Source
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: python:3.9-slim
  output:
    to:
      kind: ImageStreamTag
      name: meu-app:latest
  triggers:
    - type: GitHub
      github:
        secret: webhooksecret123
    - type: Generic
      generic:
        secret: webhooksecret123
EOF

Neste exemplo, estamos usando uma imagem base python:3.9-slim. O OpenShift detectará automaticamente arquivos como requirements.txt ou package.json e instalará as dependências. A saída será um ImageStreamTag chamado meu-app:latest.

Definindo a Pipeline com Tekton (Pipelines-as-Code)

Agora que temos a definição de build, precisamos orquestrar as etapas de teste e deploy. Para isso, utilizamos o recurso PipelineRun do Tekton. No entanto, para simplificar e manter tudo versionado no Git, usaremos o padrão de arquivo .tekton/pipeline.yaml dentro do seu repositório.

Crie a estrutura de diretórios no seu projeto local:

mkdir -p .tekton
touch .tekton/pipeline.yaml

O conteúdo do arquivo .tekton/pipeline.yaml deve definir os passos (tasks) que compõem sua pipeline. Abaixo, um exemplo completo que realiza o build, executa testes simples e faz o deploy no cluster.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: meu-app-pipeline
spec:
  params:
    - name: repo-url
      type: string
    - name: revision
      type: string
  tasks:
    - name: fetch-source
      taskRef:
        name: git-clone
      params:
        - name: url
          value: "$(params.repo-url)"
        - name: revision
          value: "$(params.revision)"

    - name: run-tests
      taskRef:
        name: run-unit-tests
      runAfter:
        - fetch-source
      params:
        - name: source-dir
          value: "."

    - name: build-image
      taskRef:
        name: buildah
      runAfter:
        - run-tests
      params:
        - name: IMAGE
          value: "image-registry.openshift-image-registry.svc:5000/meu-app-ci-cd/meu-app"
        - name: DOCKERFILE
          value: "Dockerfile"

    - name: deploy
      taskRef:
        name: openshift-client
      runAfter:
        - build-image
      params:
        - name: SCRIPT
          value: |
            oc set image deployment/meu-app-deployment app=$(params.IMAGE):$(tasks.build-image.results.IMAGE_DIGEST)
EOF

Análise da Pipeline:

• fetch-source: Clona o repositório definido no parâmetro repo-url.
• run-tests: Executa scripts de teste. Neste exemplo, assumimos uma task customizada ou padrão que verifica a integridade do código.
• build-image: Utiliza o buildah para criar a imagem container usando o Dockerfile presente no repositório e push para o registry interno do OpenShift.
• deploy: Atualiza o Deployment existente no cluster para usar a nova imagem, realizando um deploy contínuo.

Configurando os Recursos de Deploy no Cluster

Para que a etapa final da pipeline funcione, é necessário que uma aplicação (Deployment) já exista no cluster. O pipeline não cria a aplicação do zero, ele atualiza a imagem dela.

cat <<EOF | oc apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: meu-app-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: meu-app
  template:
    metadata:
      labels:
        app: meu-app
    spec:
      containers:
      - name: app
        image: image-registry.openshift-image-registry.svc:5000/meu-app-ci-cd/meu-app:latest
        ports:
        - containerPort: 8080
EOF

Não esqueça de criar o Service para expor a aplicação:

cat <<EOF | oc apply -f -
apiVersion: v1
kind: Service
metadata:
  name: meu-app-service
spec:
  selector:
    app: meu-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
EOF

Integração com Git e Gatilhos (Triggers)

O poder real do CI/CD no OpenShift é a automação. Você não deve executar a pipeline manualmente para cada commit. Configure gatilhos para que o sistema reaja a eventos do seu repositório Git.

O OpenShift possui um controlador chamado Pipeline as Code Controller. Quando você cria uma branch no repositório e adiciona o arquivo .tekton/pipeline.yaml, o controlador detecta essa mudança e cria automaticamente os recursos Tekton necessários (PipelineRun) para executar aquela pipeline específica.

Passos para ativar a integração:

1. Commitar o arquivo de pipeline: Adicione o diretório .tekton ao seu repositório Git e faça o commit.

git add .tekton/
git commit -m "Adicionar configuração de pipeline CI/CD"
git push origin main

2. Verificação do Status: Após o push, verifique se o PipelineRun foi criado. Você pode usar a CLI ou a console web do OpenShift.

tkn pipeline list

Se você não tiver o tkn CLI instalado, pode verificar os recursos via oc:

oc get pipelineruns

Otimizações e Boas Práticas para Produção

Ao levar suas pipelines de CI/CD para um ambiente de produção no OpenShift, considere as seguintes práticas para garantir robustez e segurança:

1. Gestão de Credenciais Seguras

Nunca armazene senhas ou tokens SSH diretamente nos arquivos de pipeline. Utilize os recursos Secrets do Kubernetes e Service Accounts para injetar credenciais como variáveis de ambiente ou volumes montados.

oc create secret generic git-creds \
  --from-literal=username=seu_usuario \
  --from-literal=password=seu_token

2. Cache de Dependências

Para acelerar os builds, utilize volumes persistentes para cache de dependências (como node_modules ou cache do pip). Isso reduz o tempo de execução das pipelines e a carga na rede.

3. Validação de Imagens

Integre ferramentas de análise estática de código e varredura de vulnerabilidades (como Trivy ou Clair) em uma task intermediária da pipeline, antes do deploy.

4. Rollback Automático

O OpenShift facilita rollbacks. Se a nova imagem falhar nos testes de saúde (health checks), o deployment strategy RollingUpdate padrão reverte automaticamente para a versão anterior, minimizando o tempo de inatividade.

Monitoramento e Troubleshooting

Ao longo do desenvolvimento das suas pipelines, você precisará monitorar o status das execuções. O OpenShift fornece visibilidade granular através da aba "Pipelines" na console web ou via CLI.

Para visualizar os logs de uma task específica dentro de um PipelineRun:

tkn pipeline logs meu-app-pipeline-run-xyz -f

Se a pipeline falhar, verifique as seguintes causas comuns:

• Acesso ao Registry: Certifique-se de que o Service Account da pipeline tem permissão para fazer push no ImageStream.
• Dockerfile Inválido: Erros de sintaxe ou caminhos incorretos no Dockerfile são comuns. Verifique o log da task buildah.
• Falta de Recursos: Se os pods do pipeline ficarem em estado Pending, verifique se há recursos suficientes (CPU/Memory) no cluster ou se as limitações de recurso (ResourceQuota) estão sendo respeitadas.