Skip to content
Ansible 3 min read

GitLab com Traefik: um laboratório DevOps com Docker Swarm, Ansible e Vagrant

Laboratório GitLab e Traefik executado em Docker Swarm

Read this article in English.


Link do GitHub: acesse aqui

Criei este projeto como um laboratório prático de DevOps. Nele, GitLab e Traefik são executados no Docker Swarm, o Vagrant fornece a máquina virtual local e o Ansible cuida do provisionamento e do deployment.

A proposta não foi entregar uma plataforma pronta para produção. O objetivo foi criar uma base realista e extensível para entender, na prática, como essas tecnologias trabalham juntas.

Se algo não funcionar na primeira tentativa, tudo bem. Investigar, ajustar e evoluir o ambiente faz parte do aprendizado. O repositório é um ponto de partida, não uma solução final.


Objetivo do projeto

O projeto ajuda a explorar os seguintes pontos:

Os componentes foram integrados de uma forma próxima à encontrada em ambientes reais, mas ainda simples o bastante para estudo e experimentação.


Visão geral da arquitetura

A arquitetura reúne componentes comuns em ambientes reais:

Cada serviço fica isolado, conectado por redes overlay e implantado por automação. Isso reduz intervenções manuais e configuration drift.


GitLab

O GitLab é uma plataforma open source para gerenciamento de código-fonte e pipelines de CI/CD. Neste projeto, ele é executado com a imagem de container sameersbn/gitlab.

A imagem abstrai boa parte da complexidade da instalação e permite configurar o serviço por variáveis de ambiente. Para customizações avançadas, vale consultar sua documentação, que expõe outras opções.

A stack do GitLab utiliza:

Essa separação de responsabilidades torna o ambiente mais fácil de entender, manter e evoluir.


Traefik como reverse proxy

O Traefik atua como reverse proxy e ingress controller, responsável pela exposição dos serviços, roteamento e gerenciamento do HTTPS.

Neste ambiente, o Traefik se integra diretamente ao Docker Swarm e descobre os serviços pelas labels dos containers. Assim, mudanças nos serviços não exigem configuração manual de cada rota.

A configuração estática fica centralizada, enquanto as regras de roteamento são definidas em cada serviço. Quando algo foge do esperado, o primeiro passo da investigação é validar essas labels.

Como próximos passos, o ambiente pode receber:


Docker Swarm

O Docker Swarm é o orquestrador de containers do laboratório. Ele oferece distribuição de serviços, redes overlay e gerenciamento declarativo de forma nativa.

Os playbooks do Ansible inicializam o cluster Swarm e criam as redes overlay necessárias. Dessa forma, o preparo do cluster também faz parte da automação.


Ansible: provisionamento e deployment

O Ansible é responsável por provisionar o ambiente e implantar todos os serviços.

Entre suas responsabilidades estão:

O uso do Ansible aplica os princípios de Infrastructure as Code e mantém o processo reproduzível e consistente. Quando surge algum problema, inventory, variáveis e conectividade costumam ser os primeiros pontos que verifico.


Vagrant: um ambiente local e isolado

O Vagrant cria uma máquina virtual local e mantém o laboratório isolado do sistema operacional do host.

Essa abordagem permite:

O Vagrant se integra diretamente ao Ansible, permitindo criar e provisionar todo o ambiente automaticamente.


Fluxo de uso recomendado

Um fluxo comum para utilizar o projeto é:

  1. Ajustar as variáveis do projeto para o seu ambiente
  2. Executar o deployment automatizado
  3. Validar os serviços no Docker Swarm
  4. Testar roteamento, acesso e integrações
  5. Evoluir a configuração de forma incremental

Se o ambiente ficar inconsistente, destruí-lo e recriá-lo faz parte do exercício. A repetição ajuda a entender o papel de cada etapa.


Possíveis evoluções

O projeto foi pensado para continuar evoluindo. Algumas possibilidades são:

Errar, investigar e aplicar os ajustes encontrados faz parte do aprendizado em DevOps.


Referências


💡 Quem sou eu?

Sou Gabriel Carmo, CNCF Kubestronaut, com certificações CKA, CKAD, CKS, KCNA e KCSA, além de Red Hat Certified OpenShift Administrator.

Atuo em DevOps Engineering, construindo e evoluindo plataformas Kubernetes multi-cloud. Meu trabalho tem como foco reduzir a carga cognitiva das equipes de engenharia por meio de platform engineering, automação, GitOps e experiências self-service.

No dia a dia, conecto infraestrutura como código, cloud networking, governança, segurança, observabilidade e práticas de SRE para criar plataformas mais padronizadas, resilientes e fáceis de operar.

LinkedIn | GitHub | GitLab | Credly | E-mail