Redis auf Debian: Cache-Blitz ohne offene Scheunentore

Redis ist brutal schnell, aber genauso brutal beleidigt, wenn du ihn wie eine normale Datenbank behandelst. Wir haben uns auf Debian angeschaut, wie Redis als Cache und Session-Storage sauber läuft, ohne dass Port 6379 fröhlich ins Internet winkt.

Installation auf Debian

Auf Debian ist Redis angenehm unspektakulär. Genau so mögen wir Infrastruktur: langweilig beim Installieren, schnell im Betrieb.

sudo apt update
sudo apt install redis-server redis-tools
sudo systemctl enable --now redis-server
redis-cli ping

Wenn PONG zurückkommt, lebt der kleine RAM-Dämon.

Den Dienststatus checkst du so:

systemctl status redis-server

Die Hauptkonfiguration liegt unter /etc/redis/redis.conf. Vor Änderungen gilt wie immer: Backup machen. Nicht heldenhaft direkt in Produktion tippen.

sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.bak

Cache oder Session-Storage? Erst denken, dann konfigurieren

Redis kann beides. Aber Cache und Session-Storage haben unterschiedliche Schmerzen.

Für reines Caching darf Redis Daten verlieren. Dann brauchst du eher sinnvolle Speichergrenzen und eine Eviction-Policy. Beispiel:

# /etc/redis/redis.conf
maxmemory 512mb
maxmemory-policy allkeys-lru
save ""
appendonly no

save "" deaktiviert RDB-Snapshots, appendonly no deaktiviert AOF. Das ist für Cache okay. Wenn die Kiste rebootet, ist der Cache leer. Tragisch? Nein. Warm-up macht kurz CPU-Yoga, dann läuft es wieder.

Für Sessions sieht die Welt anders aus. Da willst du nicht bei jedem Neustart alle Nutzer ausloggen, nur weil Redis einmal blinzelt. Dafür aktivieren wir AOF:

# /etc/redis/redis.conf
appendonly yes
appendfsync everysec
maxmemory 1gb
maxmemory-policy volatile-ttl

appendfsync everysec ist ein guter Kompromiss. Maximal etwa eine Sekunde Datenverlust, dafür keine Disk-I/O-Apokalypse. volatile-ttl schmeißt bevorzugt Keys mit Ablaufzeit raus. Sessions sollten sowieso immer ein TTL haben. Ewige Sessions sind wie vergessene Cronjobs: irgendwann beißen sie dich.

Absicherung: Redis ist kein Internet-Service

Der Klassiker unter den Redis-Fails: Dienst läuft auf 0.0.0.0, kein Passwort, Firewall offen. Danach speichern plötzlich fremde Menschen ihre Daten bei dir. Nett, aber falsch.

Auf einem einzelnen App-Server reicht meist localhost:

# /etc/redis/redis.conf
bind 127.0.0.1 ::1
protected-mode yes
port 6379

Wenn deine App und Redis auf derselben Maschine laufen, kannst du auch Unix-Sockets nutzen:

# /etc/redis/redis.conf
port 0
unixsocket /run/redis/redis-server.sock
unixsocketperm 770

Danach muss dein App-User natürlich in die passende Gruppe:

sudo usermod -aG redis www-data
sudo systemctl restart redis-server

Falls Redis über Netzwerk erreichbar sein muss: Firewall setzen. Nicht diskutieren.

sudo ufw allow from 10.0.0.0/24 to any port 6379 proto tcp
sudo ufw deny 6379/tcp

Auth ist nicht optional

Redis 6+ kann ACLs. Für einfache Setups reicht ein starker Default-User mit Passwort. Besser: dedizierter User für die App.

# /etc/redis/redis.conf
user default off
user appuser on >BitteHierEinLangesZufaelligesPasswortEinsetzen ~* +@read +@write -@dangerous

Damit darf appuser lesen und schreiben, aber keine gefährlichen Admin-Kommandos nutzen. FLUSHALL im falschen Moment ist kein Kommando, sondern ein Bewerbungsgespräch.

Test:

redis-cli -u redis://appuser:BitteHierEinLangesZufaelligesPasswortEinsetzen@127.0.0.1:6379 ping

Neustart und kurzer Reality-Check

Nach jeder Änderung:

sudo systemctl restart redis-server
redis-cli ping
redis-cli info persistence
redis-cli info memory

Bei Session-Storage prüfen wir zusätzlich, ob AOF wirklich aktiv ist:

redis-cli config get appendonly
redis-cli config get appendfsync

Typische Fehler, die wir vermeiden

Redis ohne maxmemory ist mutig. Redis ohne Auth ist fahrlässig. Redis mit offenem Port ist ein Incident mit Countdown. Und Redis als Session-Store ohne Persistence ist ein Logout-Generator mit Systemd-Unit.

Unsere Faustregel: Cache darf flüchtig sein, Sessions nicht. Redis bleibt lokal, außer es gibt einen sehr guten Grund. Und jeder Key, der irgendwann sterben darf, bekommt ein TTL. So bleibt Redis schnell, kontrollierbar und macht genau das, was er soll: Daten ausliefern, bevor die Datenbank überhaupt ihren Kaffee abgestellt hat.