One‑Click Docker Deployment of a Redis Sharding Cluster

Introduction

Redis supports sharding clusters since version 3.0, allowing data to be automatically distributed across multiple nodes. This article demonstrates how to use Docker to achieve a one‑click deployment of a Redis sharding cluster, showcasing the power of container technology.

What is a Redis sharding cluster

Redis is a popular key‑value database that originally ran on a single machine. Before Redis 3.0, third‑party solutions were required for data partitioning. Redis 3.0 introduced native sharding via Redis Cluster, which provides automatic failover and scaling.

Client hash

Data can be distributed by the client using a consistent‑hash algorithm, but this approach lacks automatic failover and makes rebalancing difficult.

Proxy mode

Twemproxy (developed by Twitter) – the official Redis‑recommended proxy.

Codis – an open‑source solution from the Chinese community.

Proxy mode allows developers to keep using the standard Redis client SDK, simplifying maintenance.

Redis Cluster

Redis 3.0 adds native sharding and automatic failover, forming a true Redis Cluster.

1. Prepare the Redis image

The official Redis images (e.g.,

redis:3.2-alpine

) are suitable for clustering; the Alpine variant is lightweight.

2. Build a redis‑trib image

The

redis-trib.rb

script (provided by Redis) is used for cluster creation, resharding, and rebalancing. It requires a Ruby runtime, so we build a custom Docker image:

<code>FROM ruby:2.3.1-alpine

ADD https://raw.githubusercontent.com/antirez/redis/3.2.0/src/redis-trib.rb /usr/local/bin/redis-trib.rb

RUN gem install redis && chmod 755 /usr/local/bin/redis-trib.rb && \
  sed -i '/yes_or_die.msg/a return if ENV["QUIET_MODE"] == "1"' /usr/local/bin/redis-trib.rb

ADD entrypoint.sh /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]
</code>

The accompanying

entrypoint.sh

script triggers cluster creation when the container starts:

<code>#!/bin/sh

if [ "$CLUSTER_CMD" = create ]; then
  if [ -f /usr/local/etc/redis-trib.conf ] ; then
    . /usr/local/etc/redis-trib.conf
    QUIET_MODE=1 redis-trib.rb create --replicas $REPLICAS $NODES
  fi
fi
</code>

3. Prepare Redis cluster configuration

<code>port 6379
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
</code>

The configuration file is typically placed in

/data

so the Redis process has read/write access.

4. Prepare redis‑trib configuration

The

redis-trib.conf

file supplies parameters for cluster initialization:

<code>REPLICAS={{.REPLICAS_NUM}}
{{ $rs := service "redis" }}
NODES="{{range $i,$rc := $rs.Containers}} {{$rc.IPAddr}}:6379{{end}}"
</code>

REPLICAS defines the number of slaves per shard (commonly 1). NODES lists all master and slave node addresses.

Orchestrating the cluster

After building the images and preparing the configuration files, the following steps are performed in the cSphere UI (illustrated by screenshots):

Step 1 – Create a template

Step 2 – Add the Redis service

Step 3 – Set container parameters

Step 4 – Define health‑check policy

Step 5 – Set Redis deployment strategy

Add the redis‑trib initialization service

Step 1 – Choose the redis‑trib image

Step 2 – Set container parameters

Step 3 – Define deployment priority

The redis‑trib container must start after the Redis containers, so its priority is set lower.

Result

After the above steps, the Redis‑sharding application template is ready. Deploying the template creates a fully functional Redis Cluster.

Deployment screenshot

Cluster initialization log

Verification

Connecting to any node and running

redis-cli info

shows the cluster status.

The tutorial demonstrates a complete, container‑based, one‑click delivery of a Redis sharding cluster.