Documentation - Redise Pack

A guide to Redise Pack installation, operation and administration

open all | close all

Working with Redise Pack (RP) with Docker Containers

Redise Pack can be deployed using Docker Container on Windows, macOS and Linux-based systems. Redise Pack container represents a node in an RP Cluster. When deploying RP using Docker, there are a couple of common topologies:

Topology #1: The simplest topology is to run a single-node RP Cluster with a single container in a single host machine. This is best for local development or functional testing. Obviously, single-node clusters come with limited functionality in a few ways. For instance, in a single-node topology, RP can’t replicate to slave shards or provide any protection for failures. Simply follow the instruction in the Getting Started pages for Windows, macOS and Linux to build your development environment.
Topology #2: You may also run multi-node RP Cluster with multiple RP containers deployed to a single host machine. This topology is similar to the Topology #1 except that you run a multi-node cluster to develop and test against. The result is a system that is scale-minimized but similar to your production Redise Pack deployment. It is important to note that this topology isn’t ideal for performance-sensitive systems. In this topology, containers may interfere with each other under load. In addition, even though the RP cluster provides replication to protect against failures (as all nodes reside on the same physical host), the cluster cannot protect you against the failure of the single host. With all this, Topology #2 (or other hybrid deployment methods in which you put multiple RP nodes in containers on the same physical host) is not recommended if you are looking for predictable performance or high availability.
Docker Redis Enterprise Pack Cluster
Topology #3: You may also run multi-node RP Cluster with multiple RP containers each deployed to its own host machine. This topology minimizes interference between RP containers, so it performs more predictably than Topology #2.