Docker Compose dla środowisk produkcyjnych – jak budować bezpieczne i stabilne wdrożenia
Docker Compose dla środowisk produkcyjnych – jak budować bezpieczne i stabilne wdrożenia
Docker Compose przez wiele lat był kojarzony głównie ze środowiskami developerskimi:
Programista
↓
docker-compose.yml
↓
Lokalna aplikacja
Jednak w praktyce wiele firm wykorzystuje Compose również na produkcji, szczególnie dla:
- małych i średnich serwerów,
- aplikacji SaaS,
- środowisk edge,
- serwerów VPS,
- systemów wewnętrznych,
- instalacji on-premise.
Różnica polega na tym, że produkcyjny Docker Compose nie powinien być tylko plikiem do uruchamiania kontenerów.
Musi uwzględniać:
- bezpieczeństwo,
- trwałość danych,
- monitoring,
- aktualizacje,
- backup,
- kontrolę zasobów,
- zarządzanie sekretami.
Docker Compose w architekturze produkcyjnej
Typowe środowisko:
Internet
↓
Reverse Proxy
Nginx / Traefik / Caddy
↓
Docker Compose Network
↓
┌─────────────┬─────────────┐
Web API Worker
↓ ↓ ↓
Database
↓
Persistent Volume
Docker Compose vs Kubernetes
Częsty błąd:
„Compose nadaje się tylko do testów”.
Nie zawsze.
Porównanie:
| Cecha | Docker Compose | Kubernetes |
|---|---|---|
| Małe wdrożenia | bardzo dobre | przesada |
| Jeden serwer | idealny | rzadko |
| Skalowanie wielu hostów | ograniczone | świetne |
| Automatyczne HA | słabe | bardzo dobre |
| Prostota | wysoka | niższa |
| Zarządzanie | łatwe | złożone |
Dla pojedynczego serwera produkcyjnego dobrze skonfigurowany Compose może być bardzo rozsądnym wyborem.
Struktura projektu produkcyjnego
Nie warto trzymać wszystkiego w jednym katalogu.
Przykład:
production-app/
├── docker-compose.yml
├── .env
├── config/
│ └── nginx.conf
├── secrets/
├── backups/
├── volumes/
└── monitoring/
Podstawowy docker-compose.yml
Przykład aplikacji:
services:
app:
image: mycompany/app:v1.0
restart: unless-stopped
networks:
- backend
environment:
DATABASE_HOST: db
depends_on:
- db
db:
image: postgres:16
restart: unless-stopped
volumes:
- postgres_data:/var/lib/postgresql/data
networks:
- backend
volumes:
postgres_data:
networks:
backend:
1. Nie używaj latest
Błąd:
image: nginx:latest
Problem:
Dzisiaj:
nginx 1.27
Jutro:
nginx 1.28
Automatyczna zmiana może zepsuć produkcję.
Lepsze:
image: nginx:1.27.0
lub digest:
image:
nginx@sha256:xxxxxxxx
2. Ustaw restart policy
Produkcja musi reagować na awarie.
Przykład:
restart: unless-stopped
Dostępne opcje:
no
always
on-failure
unless-stopped
Najczęściej:
restart: unless-stopped
3. Nie uruchamiaj kontenerów jako root
Przykład:
services:
app:
user: "1000:1000"
Efekt:
Container
UID 1000
↓
Host user
4. Read-only filesystem
Bardzo dobra praktyka.
Przykład:
services:
app:
read_only: true
Teraz aplikacja nie może pisać wszędzie.
Jeżeli potrzebuje katalogu tymczasowego:
tmpfs:
- /tmp
Schemat:
Container
/read-only
+
/tmp RAM
5. Ogranicz capabilities
Domyślnie Docker daje zestaw uprawnień.
Produkcja:
cap_drop:
- ALL
Dodaj tylko wymagane:
cap_add:
- NET_BIND_SERVICE
6. Włącz no-new-privileges
Bardzo ważna opcja:
security_opt:
- no-new-privileges:true
Chroni przed:
- eskalacją uprawnień,
- wykorzystaniem SUID.
7. Seccomp w Compose
Docker domyślnie używa profilu Seccomp.
Można jawnie ustawić:
security_opt:
- seccomp=default
8. AppArmor / SELinux
security_opt:
- apparmor=my-profile
RHEL:
security_opt:
- label=type:container_t
9. Kontrola zasobów
Kontener bez limitów może zabić cały serwer.
Przykład:
services:
app:
deploy:
resources:
limits:
cpus: "1"
memory: 512M
W starszych Compose:
mem_limit: 512m
cpus: 1
10. Healthcheck
Sam restart kontenera nie wystarczy.
Przykład:
healthcheck:
test:
- CMD
- curl
- -f
- http://localhost/health
interval: 30s
timeout: 5s
retries: 3
Efekt:
System wie:
Proces działa?
TAK
Ale aplikacja?
NIE
11. Sieci Docker
Nie wrzucaj wszystkiego do jednej sieci.
Zły przykład:
frontend
database
admin
↓
jedna sieć
Lepszy model:
nginx
|
frontend-net
|
API
|
backend-net
|
Database
Compose:
networks:
frontend:
backend:
12. Nie wystawiaj bazy danych do Internetu
Źle:
ports:
- "5432:5432"
Każdy może próbować:
Internet
↓
PostgreSQL
Lepiej:
db:
expose:
- 5432
Dostęp:
tylko wewnątrz sieci Docker.
13. Zarządzanie sekretami
Zły przykład:
environment:
PASSWORD: admin123
Problem:
sekret trafia do:
- historii,
- backupów,
- repozytorium.
Lepsze:
.env
DB_PASSWORD=xxxx
lub:
Docker secrets:
secrets:
db_password:
14. Backup danych
Kontener można odtworzyć.
Dane nie.
Przykład:
volumes:
postgres_data:
Backup:
docker run \
--rm \
-v postgres_data:/data \
-v $(pwd):/backup \
tar czf /backup/db.tar.gz /data
15. Logowanie produkcyjne
Nie zostawiaj:
logging:
driver: json-file
bez limitów.
Może zapchać dysk.
Przykład:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"
Alternatywnie:
driver: journald
16. Aktualizacja kontenerów
Nie:
docker compose pull
docker compose up
bez planu.
Lepszy proces:
Backup
↓
Pull image
↓
Test
↓
Deploy
↓
Rollback
17. Blue-Green deployment z Compose
Dla ważniejszych aplikacji:
Production
↓
Blue version
Green version
↓
Test
↓
Switch traffic
Można wykorzystać:
- dwa projekty Compose,
- reverse proxy,
- DNS.
18. Monitoring
Produkcja wymaga widoczności.
Minimum:
- CPU,
- RAM,
- dysk,
- restart kontenerów,
- logi.
Popularny zestaw:
Prometheus
↓
Grafana
↓
Alertmanager
19. Audyt bezpieczeństwa
Dobry zestaw:
Docker Bench Security
+
Trivy
+
Falco
+
auditd
Schemat:
Build
↓
Scan
↓
Deploy
↓
Runtime monitoring
20. Przykład bardziej bezpiecznego Compose
services:
app:
image: myapp:1.0
restart: unless-stopped
user: "1000:1000"
read_only: true
tmpfs:
- /tmp
security_opt:
- no-new-privileges:true
cap_drop:
- ALL
networks:
- backend
mem_limit: 512m
db:
image: postgres:16
restart: unless-stopped
volumes:
- db:/var/lib/postgresql/data
networks:
- backend
volumes:
db:
networks:
backend:
Produkcyjna checklista Docker Compose
Obrazy
✅ przypięte wersje
✅ skanowanie CVE
✅ minimalne obrazy
✅ brak sekretów
Kontenery
✅ non-root
✅ read-only filesystem
✅ cap_drop ALL
✅ seccomp
✅ no-new-privileges
Dane
✅ volumes
✅ backup
✅ test odtwarzania
Sieć
✅ prywatne sieci
✅ brak wystawionej bazy
✅ firewall hosta
Monitoring
✅ logi
✅ alerty
✅ metryki
Podsumowanie
Docker Compose może być pełnoprawnym narzędziem produkcyjnym, jeżeli jest używany zgodnie z zasadami bezpieczeństwa.
Największy błąd administratorów to traktowanie pliku docker-compose.yml jako zwykłego skryptu startowego.
W środowisku produkcyjnym Compose jest częścią całej architektury:
Docker Compose
+
BuildKit
+
Multi-stage builds
+
Rootless Docker
+
Seccomp
+
AppArmor/SELinux
+
nftables
+
Monitoring
+
Backup
Dopiero takie podejście pozwala budować stabilne i bezpieczne środowiska kontenerowe.
journald – jak działa system logowania w Linux i dlaczego zastąpił klasyczne logi Logi systemowe są jednym z najważniejszych elementów Czytaj dalej
Zabezpieczanie serwera poczty przed spamem i atakami w systemie Linux Serwer poczty e-mail jest jednym z najbardziej narażonych elementów infrastruktury Czytaj dalej
