Setting up a standalone Redis Instance
Redis is a very popular in-memory database when it comes to caching. This post covers the basic configurations for setting up a Redis instance in docker.
Directory Structure
Create a directory named redisdb and ensure the following file structure.
redisdb/
├── data/
├── redis.conf
The data directory will contain the snapshots taken over time (as .rdb and/or .aof).
The redis.conf file will contain the instance configurations.
Configurations
The below configurations are what seems important in general. Rest can be left to defaults.
Network
bind 0.0.0.0 # bind to all available interfaces
protectedmode no # since we're not serving over localhost
port 6379 # default porttcp-backlog 511 # high backlog value helps avoid slow client
connection issues, helpful in
high-request-per-second environmentstimeout 0 # disable idle connection timeout
tcp-keepalive 300
General
Since we’re going to run it inside a container, no background process of service is required.
daemonize no
supervised no
databases # valid between 1-16. Indexed with 0Snapshotting
These settings will generate snapshots of the data from memory and save them with .rdb file extension under the data/ directory that we created above based on the specified policies.
save 900 1 # save <seconds> <writes>
save 300 10
save 60 10000stop-writes-on-bgsave-error yes # stop accepting writes if
snapshotting fails. This limits
the risk of losing data.
Security
The basic security involves setting a server password.
requirepass PASSWORD # set the server passwordHowever, if the data is sensitive, it is risky to just authenticate using a server password. Because a single FLUSHALL command can delete everything. It can be mitigated with an Access Control List (ACL) which is a list containing username/passwords with the allowed list of commands.
Memory Management (IMPORTANT)
Since Redis is an in-memory database, you don’t want it to flood the node it is running on thereby compromising all other services. A suitable memory management policy saves the day.
Eviction Policies
noeviction: return errors when the memory limit was reached and the client is trying to execute commands that could result in more memory to be used.
allkeys-lru: evict keys by trying to remove the less recently used (LRU) keys first, in order to make space for the new data added.
volatile-lru: evict keys by trying to remove the less recently used (LRU) keys first, but only among keys that have an expiry set, in order to make space for the new data added.
allkeys-random: evict keys randomly in order to make space for the new data added.
volatile-random: evict keys randomly in order to make space for the new data added, but only evict keys with an expire set.
volatile-ttl: evict keys with an expire set, and try to evict keys with a shorter time to live (TTL) first.
The list of available eviction policies can be found here.
Persistence
Append Only File (aof) is an alternative persistence mode that provides much better durability compared to rdb since it creates something similar to a point in time snapshot.
Some problems associated with aof files are,
- The AOF file size is proportional to the number of writes. It will get bigger and bigger.
- The bigger the AOF file is, the longer the server will take to restart.
- So we need a way to compact the AOF from time to time. Again in a non-blocking way, while the server is running receiving read and write queries.
Hence, consider this option only when you have very sensitive data and can not afford to lose.
Here is the link to a detailed comparison between rdb and aof option.
Start the instance
Run the following command under the redisdb/ directory since the local path must be absolute in the -v option.
