#redis

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

Największe klucze

redis-cli --bigkeys

Przechodzi SCAN-em po całej bazie i pokazuje największy klucz każdego typu.

Uwaga na jednostki: dla stringów liczy bajty, dla kolekcji liczbę elementów. Lista z milionem krótkich wpisów wyjdzie tu „większa” niż jeden string na 10 MB.

Ile to waży naprawdę

redis-cli --memkeys

To samo przejście, ale liczone przez MEMORY USAGE — czyli faktyczne bajty. Wolniejsze, za to nie kłamie. Od Redisa 6.

Pojedynczy klucz:

redis-cli MEMORY USAGE klucz

Oba przejścia idą po całej przestrzeni kluczy. Na dużej bazie dorzuć -i 0.1, żeby robiły przerwy między porcjami i nie obciążały serwera.

Statystyki komend

INFO commandstats

Ile razy każda komenda poszła i ile średnio zajęła (usec_per_call). Zwykle tu wychodzi, że to nie Redis jest wolny, tylko ktoś wali KEYS w pętli.

Wyzerowanie liczników przed pomiarem:

CONFIG RESETSTAT

redis-cli --scan --pattern 'KEY_PREFIX*' | xargs -r -n 500 redis-cli UNLINK

--scan chodzi po kluczach porcjami.

UNLINK — zwalnia w osobnym wątku, nie blokuje. -n 500 żeby nie odpalać procesu na każdy klucz z osobna, -r pomija wywołanie, jak nic nie znalazło.

Najpierw zobacz, co zostanie usunięte:

redis-cli --scan --pattern 'KEY_PREFIX*' | head

--scan przeszukuje tylko aktualny node, pod który jesteś podpięty (sprawdź –cluster call dla klastra)