Running clustered solutions inside containers

MongoDB is a free and open source cross-platform, document-oriented database program that can run in cluster mode (using shards and ReplicaSets). In this example, we will run a three-node MongoDB ReplicaSet as that is much easier to configure than a full sharded cluster and is sufficient to demonstrate the principle of storing container state data persistently.

Our MongoDB ReplicaSet architecture will look as follows:

The primary node is responsible for managing all write operations, and there can only be one primary in a ReplicaSet. The secondary nodes are only replicating the primary's oplog and apply the data operations so that their datasets reflect the dataset of the primary. The main benefits of such a MongoDB deployment are as follows:

• Automatic failover: If the primary becomes unavailable, the rest of the secondary nodes will perform new leader election and resume cluster functionality.
• Possibility to use secondaries to read data: You can specify read preference so that clients offload the primary for read operations. However, you have to take note of the fact that asynchronous replication may result in secondaries being slightly off-sync with the primary node.

Now, let's create our MongoDB ReplicaSet!