Docker

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

Dokumentacja

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