A integração contínua e a entrega contínua (CI/CD) são pilares do desenvolvimento de software moderno, e o GitLab CI/CD é uma das ferramentas mais poderosas para essa automação. Um dos seus recursos mais cobrados em concursos é a capacidade de executar jobs de automação dentro de contêineres Docker. Isso garante um ambiente de build limpo, consistente e isolado. A questão da prova para Analista da PGM de Niterói (2023, FGV) é um exemplo perfeito de como as bancas testam o conhecimento fundamental sobre a configuração desses ambientes. A questão exigia saber como especificar a imagem Docker principal para o job de build e, crucialmente, como “anexar” um serviço secundário, como um banco de dados, também em um contêiner. Dominar essas duas diretivas, image e services, é o primeiro passo para gabaritar qualquer questão sobre o tema.
O Ambiente de Execução do Job: A Cláusula image
No coração de um job que roda com Docker no GitLab CI/CD está a palavra-chave image. Sua função é única e essencial: definir a imagem Docker que será usada para criar o contêiner onde os scripts do seu job serão executados. [2] Pense nela como a “planta” do sistema operacional e das ferramentas que seu job terá à disposição. Se você precisa compilar um código Java, usará uma image que contenha o JDK. Se for uma aplicação Node.js, usará uma imagem com Node.js.
No contexto da questão, o BuildJob precisa de um ambiente para automatizar o build da aplicação PGMApp. A diretiva image é a que fornece esse ambiente principal.
Exemplo de uso no arquivo .gitlab-ci.yml:
build_job:
stage: build
image: node:18-alpine
script:
- echo "Executando dentro de um contêiner baseado na imagem node:18-alpine..."
- npm install
- npm run build
Serviços de Apoio: A Cláusula services
Muitas aplicações não funcionam sozinhas. Elas dependem de serviços externos, como bancos de dados, servidores de cache ou APIs. A cláusula services foi criada exatamente para isso. Ela permite definir uma ou mais imagens Docker que rodarão em contêineres separados, mas vinculados em rede ao contêiner principal do job. [1]
No cenário da questão, a aplicação PGMApp precisa de um banco de dados para ser testada durante o build. Em vez de instalar um servidor de banco de dados do zero a cada execução (o que seria lento e ineficiente), Ana, a analista, pode simplesmente declarar uma imagem de banco de dados como um serviço. O GitLab Runner se encarrega de iniciar o contêiner do banco de dados e garantir que o contêiner do job (definido pela image) consiga se comunicar com ele. [3, 4]
Analisando as Alternativas Incorretas: Por que workflow e artifacts Estão Errados?
Entender por que as outras opções estão erradas é tão importante quanto saber a certa. Isso demonstra um domínio completo do fluxo de trabalho do GitLab CI/CD.
O Erro Conceitual de workflow
A palavra-chave workflow é utilizada no nível mais alto (top-level) do arquivo .gitlab-ci.yml. Sua função é controlar se e quando um pipeline inteiro deve ser executado. Por exemplo, você pode usar workflow:rules para impedir a execução de pipelines duplicados para merge requests ou para executar pipelines apenas em branches específicos. Ela não tem nenhuma relação com a definição de imagens Docker dentro de um job específico.
O Erro Conceitual de artifacts
A palavra-chave artifacts define os resultados de um job que devem ser preservados e disponibilizados para jobs posteriores no mesmo pipeline. Pense nela como a “saída” ou o “produto” de um job. Por exemplo, após o BuildJob compilar a aplicação, ele pode declarar o arquivo binário gerado como um artefato. Um DeployJob em um estágio seguinte poderia então baixar e usar esse artefato para fazer a implantação. Portanto, artifacts lida com o que o job *produz*, enquanto image e services lidam com o ambiente em que o job *executa*.
Expandindo o Conhecimento: Conceitos Correlacionados
O Arquivo .gitlab-ci.yml
Este é o arquivo central que define todo o seu pipeline de CI/CD. Ele é escrito em YAML (YAML Ain’t Markup Language), um formato de serialização de dados legível por humanos. A estrutura é hierárquica e utiliza palavras-chave (keywords) reservadas, como image, services, script, stages, workflow e artifacts, para descrever o que, quando e como automatizar.
Runners com Executor Docker
Nada disso funcionaria sem um GitLab Runner. O Runner é o agente que efetivamente executa os jobs. Ele pode ser configurado com diferentes “executores”, que determinam como o job será rodado (ex: `shell`, `virtualbox`, `kubernetes`). Para que as cláusulas image e services funcionem, o Runner deve estar configurado com o executor docker ou docker-machine. [2]
Apelidos (alias) para Serviços
E se você precisar de dois bancos de dados da mesma imagem? Por padrão, ambos teriam o mesmo hostname, causando um conflito. Para resolver isso, você pode usar a palavra-chave alias dentro da definição do serviço. Isso permite que você defina um hostname personalizado para o serviço, garantindo que ele seja unicamente acessível pelo contêiner do job. [5]
test_job:
image: ruby:3.1
services:
- name: postgres:14
alias: db-primario
- name: postgres:14
alias: db-secundario
script:
- "bundle exec rspec" # Script de teste que pode acessar 'db-primario' e 'db-secundario'
Compreendendo a função distinta de image, services, artifacts e workflow, você não apenas resolve a questão proposta, mas se prepara para uma vasta gama de problemas práticos e teóricos sobre automação com GitLab CI/CD.
Mapa da Aprovação: Resumo Esquematizado
Cláusula (.gitlab-ci.yml) | Função Principal | Contexto de Uso | Analogia para Memorização |
|---|---|---|---|
image | Define o ambiente de execução principal do job. | Dentro de um job, para especificar o contêiner Docker base. | A Cozinha: Onde todo o trabalho principal é feito. |
services | Define contêineres auxiliares (dependências) para o job. | Dentro de um job, para fornecer serviços como bancos de dados ou caches. | Os Eletrodomésticos: Ferramentas de apoio (micro-ondas, batedeira) que a cozinha usa. |
artifacts | Preserva arquivos e diretórios gerados por um job. | Dentro de um job, para passar seus resultados para jobs futuros. | O Prato Pronto: O resultado final que sai da cozinha para ser servido. |
workflow | Controla a execução do pipeline como um todo. | No nível raiz do arquivo, para definir regras globais de execução. | O Cardápio: Define quais pratos (pipelines) serão feitos hoje. |
Teste Seus Conhecimentos: Questões de Fixação
Referências:
- [1] Services | GitLab Docs
- [2] Run your CI/CD jobs in Docker containers – GitLab Docs
- [3] Index · Services · Ci · Help · GitLab
- [4] Index · Services · Ci · Help · GitLab – ETSI Labs
- [5] GitLab Services in CI/CD Pipelines | by Anju – Medium
