GitLab: CI/CD

Como utilizar o GitLab CI/CD

👋 Bem-vindo à documentação da Stackhero!

A Stackhero disponibiliza uma solução GitLab cloud pronta a usar, pensada para equipas que necessitam de um ambiente rápido, seguro e escalável:

• Utilizadores, repositórios, transferências de dados e tempo de processamento CI/CD ilimitados para máxima flexibilidade.
• Atualizações simples com um só clique, mantendo o seu ambiente sempre atualizado sem tempo de indisponibilidade.
• Nome de domínio personalizado protegido com HTTPS (por exemplo, https://git.sua-empresa.com) para uma imagem profissional e maior segurança.
• Desempenho consistente e elevada segurança na sua própria infraestrutura privada e dedicada. Sem vizinhos ruidosos e com total isolamento.
• Escolha da localização de alojamento: 🇪🇺 Europa ou 🇺🇸 USA, conforme as suas necessidades de conformidade ou latência.

Comece rapidamente e foque-se no seu código. A solução de GitLab cloud hosting da Stackhero fica pronta a usar em cerca de 5 minutos.

Introdução

O GitLab CI/CD é uma funcionalidade poderosa e integrada do GitLab, uma plataforma open-source amplamente utilizada para controlo de versões e colaboração. Esta ferramenta permite-lhe automatizar e otimizar as etapas críticas de construção, teste e deployment do seu software, garantindo uma entrega mais rápida e fiável de aplicações de alta qualidade.

Por exemplo, com o GitLab CI/CD, pode configurar testes unitários automáticos que são executados sempre que um novo commit é enviado para um repositório GitLab. Após a aprovação destes testes, o seu código pode ser construído e implementado num ambiente de staging para avaliações adicionais. Depois de passar todos os testes em staging, o sistema pode promover o código para o ambiente de produção, tornando-o disponível para os utilizadores finais.

Uma das principais vantagens do GitLab CI/CD é a sua integração direta no próprio GitLab. Isto permite-lhe definir e gerir os seus pipelines CI/CD diretamente nos repositórios dos seus projetos, simplificando a orquestração e o acompanhamento de todo o seu workflow.

O GitLab CI/CD suporta uma vasta gama de linguagens de programação, frameworks e ferramentas, tornando-o suficientemente versátil para se adaptar a diferentes tipos de projetos. O seu sistema de pipelines personalizáveis permite-lhe ajustar cada etapa do processo CI/CD às suas necessidades, seja para construir, testar ou fazer deployment em múltiplos ambientes.

Em resumo, o GitLab CI/CD é uma solução completa concebida para automatizar e melhorar os processos de entrega de software. Permite aos developers focarem-se na escrita e melhoria do código, enquanto a plataforma gere de forma eficiente as tarefas operacionais.

Como construir imagens Docker no seu GitLab CI

Se o repositório do seu projeto inclui ficheiros Dockerfile, pode automatizar o processo de construção, execução e, se necessário, publicação de imagens Docker para um registry.

Passo 1: Ativar o suporte Docker in Docker (DinD)

Para começar, ative o suporte "Docker in Docker" (DinD) no seu dashboard Stackhero.

Ativar o suporte DinD representa um risco de segurança, especialmente se pretende isolar os seus utilizadores e evitar que acedam aos projetos uns dos outros.

Passo 2: Configurar o pipeline GitLab CI

De seguida, atualize o seu ficheiro gitlab-ci.yml para incluir uma configuração de pipeline que construa o seu Dockerfile utilizando DinD. Segue-se um exemplo de configuração:

image: docker:29

build:
  stage: build
  services:
    - name: docker:29-dind
      alias: docker
  variables:
    # Aponta o CLI do Docker para o serviço Docker-in-Docker, através do seu porto
    # simples (sem TLS). Veja a nota abaixo sobre a importância do DOCKER_HOST.
    DOCKER_HOST: "tcp://docker:2375"
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker info
  script:
    # Substitua "my-docker-image" pelo nome da imagem pretendida:
    - docker build -t my-docker-image .
    # Opcionalmente, teste a imagem Docker:
    # - docker run my-docker-image /script/to/run/tests

O serviço docker:29-dind inicia um daemon Docker ao lado do seu job, e o DOCKER_HOST indica ao CLI docker para o utilizar. Defina sempre o DOCKER_HOST quando declarar um serviço docker:dind: se o omitir, o CLI liga-se silenciosamente a outro daemon, e o seu build pode ter sucesso mesmo que o serviço esteja mal configurado, ocultando problemas reais. DOCKER_TLS_CERTDIR: "" utiliza o porto simples 2375 na rede interna do job.

Como alternativa mais simples, pode remover completamente o bloco services e ambas as variáveis: o runner da Stackhero já expõe um daemon Docker pronto a usar através de um socket montado, pelo que um simples docker build funciona imediatamente.

Para mais informações sobre como construir imagens Docker com o GitLab CI, consulte a documentação oficial do GitLab.

Executar os seus testes com Testcontainers

Se a sua suite de testes utiliza Testcontainers, uma biblioteca que inicia serviços reais (bases de dados, message brokers, entre outros) como contentores Docker descartáveis durante a execução dos testes, a configuração acima já cobre este cenário. Mantenha o serviço docker:29-dind e ambas as variáveis: o Testcontainers utiliza o DOCKER_HOST para aceder ao daemon Docker e ligar-se aos contentores que inicia, não sendo necessária mais nenhuma configuração.

Omissão do DOCKER_HOST é a causa mais comum de falhas do Testcontainers em CI. A biblioteca recorre então ao socket Docker montado pelo runner e não consegue aceder aos seus próprios contentores de teste, o que normalmente se manifesta como um timeout do contentor auxiliar Ryuk.