Questão de Engenharia de Software — Demais Ferramentas e Tópicos Variados de Controle de Versão — INSTITUTO AOCP 2024

Pipeline CI/CD para Microsserviços: GitLab CI + Docker + Kubernetes

Gabarito: letra E. A abordagem mais adequada é implementar o GitLab CI como ferramenta de CI/CD, integrando-o com Git para versionamento, Docker para empacotamento e Kubernetes para orquestração e gerenciamento dos microsserviços. Essa combinação cobre exatamente os três requisitos do enunciado: automação do pipeline (build, teste e deploy), gerenciamento de atualizações frequentes e monitoramento do estado dos microsserviços.

O cenário descrito é o coração do DevOps: um pipeline de CI/CD que automatiza build, teste e deploy de uma aplicação em microsserviços, empacotada em contêineres Docker, versionada em Git e orquestrada por Kubernetes. Para entender a resposta, é preciso separar os papéis de cada ferramenta:

• Git é o sistema de controle de versão distribuído que rastreia mudanças no código-fonte, permitindo colaboração e histórico.

• Docker é a plataforma que empacota a aplicação e suas dependências em contêineres leves e portáveis, garantindo consistência entre ambientes.

• Kubernetes é o orquestrador de contêineres que gerencia a implantação, escalabilidade e manutenção das aplicações em contêineres de forma automatizada.

• Ferramenta de CI/CD (como GitLab CI, Jenkins, GitHub Actions) é o motor que automatiza as etapas do pipeline: integração contínua (CI) integra o código frequentemente e executa builds e testes; entrega contínua (CD) prepara o código para liberação e, no caso de deployment contínuo, implanta automaticamente em produção.

A alternativa E é a única que reúne todas as peças de forma coerente: o GitLab CI atua como ferramenta de CI/CD, integrando-se ao Git (versionamento), ao Docker (empacotamento) e ao Kubernetes (orquestração). Essa é uma stack clássica e amplamente adotada no mercado para pipelines de microsserviços.

As demais alternativas cometem erros conceituais ou funcionais:

• A confunde o papel do repositório Git: ele não realiza build de contêineres; essa é função da ferramenta de CI/CD.

• B mistura Docker Compose (ferramenta de orquestração local) com Kubernetes, atribuindo ao Compose um papel que não é o dele em produção.

• C propõe usar Docker Swarm e relegar o Kubernetes apenas ao monitoramento, o que é um uso inadequado do orquestrador.

• D atribui ao GitHub Actions a função de orquestrar contêineres e gerenciar o ciclo de vida dos microsserviços, o que é papel do Kubernetes, não da ferramenta de CI/CD.

A pegadinha central é a troca de responsabilidades: a banca tenta fazer o candidato confundir o papel de cada ferramenta no pipeline. A ferramenta de CI/CD automatiza o fluxo; o orquestrador (Kubernetes) gerencia os contêineres em produção; o Docker empacota; o Git versiona. A alternativa E respeita essa divisão.

Alternativa A — ❌ Incorreta

O erro está em afirmar que o build dos contêineres Docker é feito diretamente no repositório Git. O Git é um sistema de controle de versão, não uma ferramenta de build. O build de imagens Docker é executado por uma ferramenta de CI/CD (como GitLab CI, Jenkins, GitHub Actions) que, ao detectar um commit, dispara o pipeline. O repositório Git apenas armazena o código-fonte e o Dockerfile; a conversão em imagem é tarefa do pipeline.

Alternativa B — ❌ Incorreta

A alternativa confunde Docker Compose com uma ferramenta de CI/CD. O Docker Compose é utilizado para definir e executar aplicações multi-contêiner localmente ou em ambientes de desenvolvimento, não para definir pipelines de CI/CD. Além disso, o Kubernetes não é gerenciado pelo Docker Compose; o Compose não substitui o Kubernetes em produção. A descrição mistura conceitos de forma incorreta.

Alternativa C — ❌ Incorreta

A alternativa propõe usar Docker Swarm como orquestrador principal e relegar o Kubernetes apenas ao monitoramento de saúde dos contêineres. Isso é um uso inadequado: o Kubernetes é um orquestrador completo, capaz de gerenciar implantação, escalabilidade e saúde dos contêineres. Usá-lo apenas para monitoramento seria subutilizá-lo e não atenderia aos requisitos de deploy automático e gerenciamento dos microsserviços. Além disso, a alternativa não menciona uma ferramenta de CI/CD para automatizar o pipeline.

Alternativa D — ❌ Incorreta

A alternativa atribui ao GitHub Actions a função de "orquestrar os contêineres Docker e gerenciar o ciclo de vida dos microsserviços no Kubernetes". O GitHub Actions é uma ferramenta de CI/CD que automatiza builds, testes e deploys, mas não é um orquestrador de contêineres. A orquestração e o gerenciamento do ciclo de vida dos microsserviços são responsabilidades do Kubernetes. O GitHub Actions pode disparar deploys para o Kubernetes, mas não substitui o orquestrador.

Alternativa E — ✅ Correta ⟵ GABARITO

A alternativa E descreve a stack correta: GitLab CI como ferramenta de CI/CD, integrada ao Git para versionamento, ao Docker para empacotamento e ao Kubernetes para orquestração e gerenciamento dos microsserviços. Essa combinação atende plenamente aos objetivos do enunciado: automatizar build, teste e deploy; gerenciar atualizações frequentes (via CI); realizar deploys automáticos (via CD); e monitorar o estado dos microsserviços (via Kubernetes). É a abordagem mais adequada e amplamente utilizada em ambientes de microsserviços.

Gabarito: letra E