Github Link: Here
This project was created as a hands-on DevOps learning lab, combining GitLab and Traefik running on Docker Swarm, with Vagrant providing a local virtual machine and Ansible handling provisioning and deployment.
The goal is not to deliver a production-ready platform, but to offer a solid, realistic, and extensible foundation for engineers who want to understand how these technologies work together in practice.
If something does not work on the first try, that is intentional. Debugging, adjusting, and improving the setup is part of the learning process. This repository should be seen as a starting point, not a final solution.
Project Purpose
The main objective of this project is to help engineers:
- Understand GitLab architecture when running in containers
- Learn how Traefik works as a reverse proxy and ingress controller
- Practice Docker Swarm concepts such as services and overlay networks
- Automate infrastructure provisioning with Ansible
- Use Vagrant to create isolated and reproducible local environments
All components are integrated in a way that mirrors real-world infrastructure, while remaining simple enough for experimentation and study.
Architecture Overview
The architecture follows common best practices found in real environments:
- GitLab running as a containerized application
- PostgreSQL for persistent data storage
- Redis for cache and internal queues
- Traefik as a reverse proxy and entry point
- Docker Swarm as the container orchestrator
- Ansible for provisioning and deployment
- Vagrant for local virtual machine management
Each service is isolated, connected through overlay networks, and deployed via automation, minimizing manual intervention and configuration drift.
GitLab
GitLab is an open-source platform for source code management and CI/CD pipelines. In this project, GitLab runs using the container image sameersbn/gitlab.
This image abstracts much of the installation complexity and allows configuration entirely through environment variables. For advanced customization, reviewing the image documentation is highly recommended, as it exposes many additional configuration options.
The GitLab stack in this lab uses:
- PostgreSQL for persistent data storage
- Redis for caching and internal job queues
This separation of concerns aligns with best practices and makes the environment easier to understand, maintain, and extend.
Traefik as a Reverse Proxy
Traefik acts as the reverse proxy and ingress controller, responsible for service exposure, routing, and HTTPS management.
In this setup, Traefik integrates directly with Docker Swarm and automatically discovers services through container labels. This removes the need for manual routing configuration whenever services change.
Static configuration is centralized, while routing rules are defined at the service level. When something does not behave as expected, the first troubleshooting step should always be validating the service labels.
As a natural next step, you can extend this setup by:
- Adding security middlewares
- Enforcing HTTPS redirection
- Configuring HTTP security headers
- Implementing basic authentication or other access controls
Docker Swarm
Docker Swarm is used as the container orchestrator in this lab. It provides native support for service distribution, overlay networking, and declarative service management.
The Swarm cluster is initialized automatically by the Ansible playbooks, along with the required overlay networks. This reinforces automation principles and avoids manual cluster setup steps.
Ansible: Provisioning and Deployment
Ansible is responsible for provisioning the environment and deploying all services.
Its responsibilities include:
- Installing Docker inside the virtual machine
- Initializing Docker Swarm
- Creating overlay networks
- Deploying GitLab, Traefik, PostgreSQL, and Redis stacks
Using Ansible enforces Infrastructure as Code principles, ensuring reproducibility and consistency. When issues occur, reviewing inventory definitions, variables, and connectivity is usually the best place to start troubleshooting.
Vagrant: Local Isolated Environment
Vagrant is used to create an isolated local virtual machine, keeping the lab environment completely separated from the host operating system.
This approach enables:
- Safe experimentation
- Fast environment teardown and recreation
- Repeatable and consistent testing
Vagrant integrates directly with Ansible, allowing the entire environment to be created and provisioned automatically with minimal effort.
Recommended Workflow
A typical workflow for this project looks like:
- Adjust project variables to match your environment
- Deploy the automated environment
- Validate services in Docker Swarm
- Test routing, access, and integrations
- Incrementally evolve the setup
If the environment becomes inconsistent, destroying and recreating it is expected and encouraged. Repetition reinforces understanding.
Possible Extensions
This project is intentionally designed to be extended. Some ideas include:
- Adding monitoring and metrics
- Implementing automated GitLab backups
- Creating alerting pipelines
- Improving Traefik security configuration
- Expanding to multi-node Swarm clusters
Making mistakes, researching solutions, and applying fixes is a fundamental part of learning DevOps.
References
- GitLab: https://docs.gitlab.com/
- Traefik: https://traefik.io/
- Docker: https://docs.docker.com/
- Docker Swarm: https://docs.docker.com/engine/swarm/
- Ansible: https://docs.ansible.com/
- Vagrant: https://www.vagrantup.com/docs
- PostgreSQL: https://www.postgresql.org/docs/
- Redis: https://redis.io/documentation
💡 Who am I?
I'm Gabriel Carmo, passionate about technology (especially Open Source). I have experience in Cloud, Kubernetes, OpenShift, Zabbix, Dynatrace and much more! Always exploring new technologies and sharing knowledge. 🚀
📬 Let's connect?
🔗 LinkedIn
🐙 GitHub
🦊 GitLab
🏅 Credly
📧 Contato: contato@gabrielandre.com.br