Docker: komendy i domyślne kontenery
XXX to pierwsze litery ID kontenera.
Bash w kontenerze
docker exec -it XXX /bin/bash
Polityka restartu
docker update --restart=always XXX
Moje domyślne kontenery
Bazy i broker wystawiam tylko na 127.0.0.1
PostgreSQL 18
Wygodnie jest podmontować sobie bazę znajdującą się na dysku, ale na dłuższą metę powoduje to problemy w Windows:
docker run --name postgres18 --restart=always --stop-timeout=30 -e POSTGRES_PASSWORD=YOUR_SUPER_SECRET_LOCAL_PASS -d -p 127.0.0.1:5432:5432 -v c:/postgres:/var/lib/postgresql postgres:18
Większą niezawodność i wydajność daje docker volume:
docker volume create postgres-data
docker run --name postgres18 --restart=always --shm-size=1g --stop-timeout=60 -e POSTGRES_PASSWORD=YOUR_SUPER_SECRET_LOCAL_PASS -d -p 127.0.0.1:5432:5432 -v postgres-data:/var/lib/postgresql postgres:18
Warto pamiętać, że od wersji 18 punkt montowania zmienił się na /var/lib/postgresql, a dane
są w podkatalogu 18/docker. W sumie przydatne przy późniejszej migracji, np. do Postgresa 19.
Redis
docker run -d --name redis -p 127.0.0.1:6379:6379 --restart=always -e REDIS_PASSWORD=YOUR_SUPER_SECRET_LOCAL_PASS bitnami/redis:latest
FlareSolverr
Proxy do obchodzenia zabezpieczeń Cloudflare i anty-botów.
docker run -d --name=flaresolverr --restart=always -p 8191:8191 -e LOG_LEVEL=error --tmpfs /tmp:rw,size=4g,mode=1777 ghcr.io/flaresolverr/flaresolverr:latest
--tmpfs: /tmp w RAM, max 4 GB. Crashe Chromium dzięki temu nie trafiają do kontenera,
więc docker_data.vhdx przez nie nie rośnie. Czyści się z restartem kontenera.
RabbitMQ + konsola
docker run -d --name rabbit01 --hostname rabbit01 --restart=always -e RABBITMQ_DEFAULT_USER=rabbit-user -e RABBITMQ_DEFAULT_PASS=YOUR_SUPER_SECRET_LOCAL_PASS -p 127.0.0.1:15672:15672 -p 127.0.0.1:5672:5672 rabbitmq:management
Port 5672 to AMQP, 15672 jest dla konsoli webowej.
--hostname: RabbitMQ trzyma dane w katalogu nazwanym od hostname. Bez stałego nowy kontener
dostaje losowy i nie widzi starych danych.
Automatyczne aktualizacje
Nie polecam dla PostgreSQL — bazę lepiej aktualizować ręcznie, w wybranym momencie. Tag
postgres:18 i tak ciągnie tylko 18.x; nowy major wymaga migracji bazy.
Ale np. FlareSolverr warto mieć zawsze w najnowszej wersji. Najprościej przez compose.yaml:
services:
flaresolverr:
image: ghcr.io/flaresolverr/flaresolverr:latest
pull_policy: daily
restart: unless-stopped
ports:
- "8191:8191"
environment:
LOG_LEVEL: error
tmpfs:
- /tmp:rw,size=4g,mode=1777
i komendy podpięte w Task Schedulerze (dwie akcje w jednym zadaniu):
docker compose -f C:\docker\flaresolverr\compose.yaml up -d
docker image prune -f
Zadanie startuje w System32, stąd pełna ścieżka w -f. image prune usuwa stare obrazy,
które zostają po aktualizacji.
Dzięki pull_policy: daily sprawdzenie wykona się najwyżej raz na dobę. Jeśli obraz się nie
zmienił, kontener nie zostanie utworzony ponownie.
Przy przejściu z docker run najpierw usuń stary kontener, inaczej port 8191 będzie zajęty:
docker rm -f flaresolverr