In part 2 we looked at the 2 different ways Redis is setup in production, Cluster and Sentinel, and we started working towards configuring a Redis Sentinel Setup.
We’re going to continue with Configuring Redis Sentinel using our already running Redis1, Reds2, and Redis3 machines.
The next step in the process is to setup the Redis-Sentinel services in Docker. We are going to Pin our services to specific nodes to ensure we don’t ever schedule multiple Redis-Sentinel instances on the same node.
However this time we need to provide a configuration to our sentinel setup. There are several ways we could do that, however, the best solution in terms of future maintainability is to just go ahead and build your own Docker image with your configuration baked in. Once you have done that you can use Docker Hubs CI/CD pipeline to fully automate things. The contents of that thought could easily encompass a full post. So we’ll come back to that part.
For now using your favorite tool (I’m using VS Code) lets get a new project going. If you’re using VS Code create a directory where you like to store projects, open code and select Open Folder, selecting your new folder. I then like to “Save Workspace” into the same folder so I can easily launch Code back into this project.
Once you have the workspace setup create a new file called: Dockerfile
Next create another file called redis-sentinel.conf and give it these contents:
- The 1st line is the url for the sentinel docs so you can get all smart
- The 3rd line tells redis to start on port 26379
- The 4th line defines the master we want our sentinel to monitor, it has the Ip, port, and quorum configuration at the end. The Quorum is the number of sentinels that must agree to imitate a fail over.
- Next is how long a master must fail PING checks before being considered down
- Next is how long we’ll wait before Sentinel will try to fail over the same master again.
parallel-syncs
sets the number of slaves that can be reconfigured to use the new master after a failover at the same time. The lower the number, the more time it will take for the failover process to complete, however if the slaves are configured to serve old data, you may not want all the slaves to re-synchronize with the master at the same time
Now update your Dockerfile with these contents:
Notice a couple things here:
- I specify redis:5 – using a specific version instead of latest is a must for production
- We copy the configuration file to the container
- The CMD is for my reference later when we create the containers. We’ll eventually update the redis-server installation to use this custom image as well and I want to be able to use the same image for both.
Now that we have our Dockerfile built and our redis-sentinel.conf file ready we can build the image
This isnt a docker tutorial, but in short this command builds an image tagged as “wjdavis5/redis_sentinel_wordpress” based on the current directory “.”
Once it is built we can push it to Docker Hub
Now we can move back over to our Docker host and create our services.
Now we should be able to connect to an instance of redis sentinel, using the docker run command from before, only this time we need to specify the port -p 26379
Yeah mine says 4 sentinels b/c created an additional while testing this out, you should see 3. The next thing we want to do is test failover. To do that we first want to tail the logs for redis-sentinel. We can do that with the docker logs command:
Now from another window connect to the master (should be redis1) and issue the shutdown command:
Now if you watch the redis-sentinel log you should see the fail over initiate
When we issued the shutdown command it should have terminated the docker container that was running. Because we configured this as a Docker Service when the container terminates Docker is automagically going to reschedule the container to execute again. So at this point you should be able to reconnect to redis1, run an info command, and see that it is now a secondary (slave)
Congratulations, you now have created a Redis Sentinel deployment on Docker swarm. In the next post we’ll cover configuring Redis Cluster.