Setting up Redis Sentinel with Docker Compose

Learn how to setup Redis Sentinel with Docker Compose

What is Redis Sentinel

Redis Sentinel is designed for high availability and automatic failover of Redis instances. It manages Redis replication and ensures that if the master node fails, a Redis slave instance is promoted to become the new master.

For Docker part, we only need Redis Docker image and configure it correctly, so fail that failover will work seamlessly.

Docker Compose configuration

In Docker Compose configuration below you can see that we have on Redis master and three Redis slave services with the addition of three Redis Sentinel services which are responsible for monitoring and managing connection to the actual Redis services. With this setup, clients should be connecting to those three Sentinels via their default port: 26379 and they should never communicate directly with Redis instances.

Configuration for Redis containers are defined directly within command. All redis-slave-1, redis-slave-2 and redis-slave-3 containers have the argument --replicaof set to redis-master which is the actual Redis master within our Docker services. Sentinel configuration is done dynamically during startup with echo statements that output it to /etc/sentinel.conf location in the container.

# compose.yaml
services:
  redis-master:
    image: redis:latest
    # Optionally mount volumes for Redis so data is persisted when containers shut down or restart
    #    volumes:
    #      - .docker/redis/redis-master:/data
    command: ["redis-server", "--appendonly", "yes", "--protected-mode", "no"]

  redis-slave-1:
    image: redis:latest
    depends_on:
      - redis-master
    # Optionally mount volumes for Redis so data is persisted when containers shut down or restart
    #    volumes:
    #      - .docker/redis/redis-slave-1:/data
    command: ["redis-server", "--replicaof", "redis-master", "6379", "--protected-mode", "no"]

  redis-slave-2:
    image: redis:latest
    depends_on:
      - redis-master
    # Optionally mount volumes for Redis so data is persisted when containers shut down or restart
    #    volumes:
    #      - .docker/redis/redis-slave-2:/data
    command: ["redis-server", "--replicaof", "redis-master", "6379", "--protected-mode", "no"]

  redis-slave-3:
    image: redis:latest
    depends_on:
      - redis-master
    # Optionally mount volumes for Redis so data is persisted when containers shut down or restart
    #    volumes:
    #      - .docker/redis/redis-slave-3:/data
    command: ["redis-server", "--replicaof", "redis-master", "6379", "--protected-mode", "no"]

  sentinel-1:
    image: redis:latest
    depends_on:
      - redis-master
      - redis-slave-1
      - redis-slave-2
      - redis-slave-3
    # Sentinel configuration is created dynamically and mounted by volume because Sentinel itself will modify the configuration
    # once it is running. If master changes this will be reflected in all configurations and some additional things are added which are
    # meant only for runtime use and not something that should be commited as base configuration.
    command: >
      sh -c 'echo "sentinel resolve-hostnames yes" > /etc/sentinel.conf &&
            echo "sentinel monitor mymaster redis-master 6379 2" >> /etc/sentinel.conf &&
            echo "sentinel down-after-milliseconds mymaster 1000" >> /etc/sentinel.conf &&
            echo "sentinel failover-timeout mymaster 5000" >> /etc/sentinel.conf &&
            echo "sentinel parallel-syncs mymaster 1" >> /etc/sentinel.conf &&
            redis-server /etc/sentinel.conf --sentinel'

  sentinel-2:
    image: redis:latest
    depends_on:
      - redis-master
      - redis-slave-1
      - redis-slave-2
      - redis-slave-3
    # Sentinel configuration is created dynamically and mounted by volume because Sentinel itself will modify the configuration
    # once it is running. If master changes this will be reflected in all configurations and some additional things are added which are
    # meant only for runtime use and not something that should be commited as base configuration.
    command: >
      sh -c 'echo "sentinel resolve-hostnames yes" > /etc/sentinel.conf &&
            echo "sentinel monitor mymaster redis-master 6379 2" >> /etc/sentinel.conf &&
            echo "sentinel down-after-milliseconds mymaster 1000" >> /etc/sentinel.conf &&
            echo "sentinel failover-timeout mymaster 5000" >> /etc/sentinel.conf &&
            echo "sentinel parallel-syncs mymaster 1" >> /etc/sentinel.conf &&
            redis-server /etc/sentinel.conf --sentinel'

  sentinel-3:
    image: redis:latest
    depends_on:
      - redis-master
      - redis-slave-1
      - redis-slave-2
      - redis-slave-3
    # Sentinel configuration is created dynamically and mounted by volume because Sentinel itself will modify the configuration
    # once it is running. If master changes this will be reflected in all configurations and some additional things are added which are
    # meant only for runtime use and not something that should be commited as base configuration.
    command: >
      sh -c 'echo "sentinel resolve-hostnames yes" > /etc/sentinel.conf &&
            echo "sentinel monitor mymaster redis-master 6379 2" >> /etc/sentinel.conf &&
            echo "sentinel down-after-milliseconds mymaster 1000" >> /etc/sentinel.conf &&
            echo "sentinel failover-timeout mymaster 5000" >> /etc/sentinel.conf &&
            echo "sentinel parallel-syncs mymaster 1" >> /etc/sentinel.conf &&
            redis-server /etc/sentinel.conf --sentinel'

We can start all containers with: docker compose up -d.