Without Compose, deploying an application with multiple containers (app + database + cache + ...) requires long `docker run` commands that are difficult to maintain.
With Compose:
- **Declarative configuration**: Everything is defined in a `compose.yml` file
My Docker Compose stacks are available in the Ansible repository under `stacks/`. Here are some representative examples:
### Example 1: Traefik - Advanced Reverse Proxy
Traefik is the entry point for the entire infrastructure. This compose illustrates an advanced configuration with **two Traefik instances** (public and private):
- Ability to restrict certain services to local only
### 5. Restart policies and graceful shutdown
Resilience configuration:
```yaml
restart: unless-stopped
stop_grace_period: 10s
```
-`unless-stopped`: Restarts automatically except if manually stopped
-`stop_grace_period`: Time to terminate cleanly before SIGKILL
### 6. Watchtower for update monitoring
Label to enable monitoring:
```yaml
labels:
- "com.centurylinklabs.watchtower.enable=true"
```
**Important**: Watchtower is used **only for notifications** of new available image versions. Updates are performed **manually** to maintain control over changes.
In the [Future Homelab](../homelab-futur/index.md), automated update management will be implemented via Renovate Bot integrated directly with Forgejo.
## Managing stacks with Docker Compose
### Essential commands
```bash
# Start all services
docker compose up -d
# Stop all services
docker compose down
# View logs for a service
docker compose logs -f service_name
# Restart a service
docker compose restart service_name
# Update images and redeploy
docker compose pull
docker compose up -d
# View container status
docker compose ps
```
### Deployment via Ansible
In my configuration, stacks are automatically deployed by Ansible:
1. Generation of `.env` files from templates
2. Synchronization of `stacks/` folders to `/opt/stacks/`
3. Execution of `docker compose up -d` for each stack
See the [Ansible Playbooks](./playbooks-ansible.md) page for more details.
## Advantages of Docker Compose for a homelab
### Simplicity
- Readable and maintainable YAML files
- No complex syntax like Kubernetes
- Gentle learning curve
### Performance
- Instant service startup
- Low overhead (no Kubernetes cluster)
- Ideal for modest machines
### Flexibility
- Easy to add/remove services
- Ability to quickly test new applications
- Configuration by environment (dev, staging, prod)
### Rich ecosystem
- Docker Hub: thousands of ready-to-use images
- LinuxServer.io: optimized and well-maintained images
- Active community: documentation and support
## Docker Compose limitations
Despite its advantages, Docker Compose has limitations for large-scale production use:
1.**No high availability**: Everything is on a single machine
2.**No horizontal scaling**: Impossible to distribute load across multiple servers
3.**No advanced orchestration**: No rolling updates, canary deployments, etc.
4.**Manual management**: Deployments via Ansible, no native GitOps
**Note**: Using `restart: unless-stopped` ensures automatic restart of containers after an unexpected stop, providing a basic form of resilience.
These limitations explain why I'm migrating to **Kubernetes (K3S)** for the future homelab. See the [Future Homelab](../homelab-futur/index.md) section.
When considering the evolution of my infrastructure, **Docker Swarm** was evaluated as an alternative to Kubernetes for container orchestration.
### Docker Swarm: a tempting but outdated choice
**Advantages of Docker Swarm**:
- Natively integrated with Docker (no additional installation)
- Simpler configuration than Kubernetes
- Gentler learning curve
- Uses Docker Compose files directly (with some adaptations)
- Less resource-intensive than Kubernetes
**Why I didn't choose it**:
1.**Kubernetes is the industry standard**: The vast majority of companies use Kubernetes in production. Learning K8S provides skills directly transferable to the professional world.
2.**Ecosystem and community**: Kubernetes benefits from a much richer ecosystem (Helm, operators, numerous DevOps tools) and a much larger community.
3.**Advanced features**: Kubernetes offers capabilities that Docker Swarm doesn't have:
4.**Evolution and support**: Docker Inc. has clearly oriented its development toward Kubernetes rather than Swarm. Swarm is maintained, but no longer evolves much.
5.**Learning objective**: My goal being to acquire modern DevOps skills, mastering Kubernetes is a better long-term investment.
**Conclusion**: Although Docker Swarm is simpler and sufficient for many homelabs, I preferred to invest directly in learning Kubernetes, which has become the essential standard for container orchestration.
