Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about how to use Docker and Kubernetes to run MongoDB as a micro-service. The article is rich in content and analyzes and describes for you from a professional point of view. I hope you can get something after reading this article.

Want to try MongoDB on your laptop? Execute a command and then have a lightweight, independent sandbox; execute another command to remove all traces after you are done. Do you need an application that is the same as your application stack in multiple environments? Create your own container image, and then ask your development, testing, operation, and support team to build a clone exactly like your environment.

Containers are revolutionizing the entire software life cycle: from the earliest technical experiments to proof-of-concepts that run through development, testing, configuration, and version support.

Orchestration tools manage how multiple containers are created, upgraded, and highly available. Orchestration tools can also control the connections between multiple containers to achieve the effect of using multiple containers to build a complex application.

Complete features, simple tools and powerful API make container and orchestration functions a favorite of the operation and maintenance team, which integrates these functions into the continuous integration (CI) and continuous delivery (CD) workflows.

This post delves into the challenges you face when you try to run and program MongDB in a container, and then explains how to overcome these challenges.

Considerations for MongoDB

Running MongoDB with containers and orchestration tools introduces some additional considerations:

The MongoDB database is stateful. After the container fails to run and is rescheduled, data loss is not needed (data can be recovered from other nodes in the replica set, but it takes time). To solve this problem, the abstract function of data volumes in Kubernetes can be used to map the original MongoDB data directory in the container into a persistent data directory location, where the survival of the data is longer than the container failure and rescheduling.

The MongoDB database nodes in the replica collection must communicate with each other-- and after rescheduling. All nodes in the replica set must know all their peers, but when a container is rescheduled, it is likely to restart with a different IP address. For example, all containers in a Kubernentes pod share an IP address, and once the pod is rescheduled, the IP address will also change. With Kubernetes, this can be solved by associating each MongoDB with a Kubernetes Service, using Kubernetes DNS Service to provide hostname for the servi ce that remains unchanged by rescheduling.

Once the MongoDB nodes are running (each in its own container), the replica collection must be initialized and each node added. This probably requires some additional logic to provide ready-made programming tools. In particular, in the intended replica collection, a MongoDB node must be used to execute rs.initiate and rs.add commands.

If the orchestration framework provides automatic container rescheduling (like Kubernetes), this increases the resilience of MongoDB, because failed replica collection builds can be automatically recreated, thus restoring complete levels of redundancy control without any human intervention.

It is worth noting that while authoring tools may monitor the status of containers, they may also monitor applications running within containers or back up their data. This means that with powerful monitoring capabilities, it is impossible to back up solutions like MongoDB Cloud Manager, including the use of MongoDB Enterprise Advanced. Consider creating your own images, which can include versions that you like to include MongoDB and MongoDB automation agents.

Using Docker and Kubernetes to implement MongoDB replica collection

As mentioned in the previous section, distributed databases like MongoDB require some additional caveats when using an orchestration framework like Kubernetes. This section will go to the next level of detail and show how to implement it.

We start by creating an entire set of MongoDB replicas in a single Kubernetes cluster (which is normal, in a single data center-no geographic backup is provided). In fact, basically nothing will be changed to run on multiple clusters, and these steps will be covered later.

The artifacts of each replica collection will be run as its own pod, accompanied by services that expose external IP addresses and ports. This "fixed" IP address is important because external applications and other replica integration artifacts can remain the same when pod is rescheduled and continue to rely on it.

The following figure illustrates one of these pods and the associated Replication Controller and service.

Step by step through the resource configuration described, we have:

Starting from the core, there is a single container called mongo-node1, and mongo-node1 contains an image called mongo, which is the public MongoD B container image clustered on Docker Hub. The container exposes port 27107 in the cluster.

The Kubernetes data volume function is used in the map / data/db directory, when connecting to a persistent data element called mongo-persistent-storage1; these in turn are mapped to a disk called mongodb-disk1 created in Google Cloud. This is where MongoDB stores the data so that it is saved to the container and rescheduled.

The container is stored in a pod with a label marked with its own name mongo-node, and it also provides an instance named rod.

A Replication Controller named mongo-rc1 is configured to ensure that a single instance of mongo-node1pod is running all the time.

The LoadBalancerservice named mongo-svc-an exposes an IP address to the outside world, as well as 27017 excuses that this interface can be mapped to the interface number of the same container in the container. Service uses selectors to identify tags where the correct pod matches the pod. External IP addresses and interfaces are used for applications, as well as for communication between replica integrations. Each container has local IP addresses, but these IP addresses change when the container is moved or restarted, but not with replica collections.

The next figure shows the second component of the replica collection.

90% of the configurations are the same, and only these have changed:

Disk and volume names must be unique so that mongodb-disk2 and mongo-persistent-storage2 are used.

Pod is used to tag instance: jane and name:mongo-node2 so that the new service can distinguish it from the rodPod in figure 1 (through the selector).

Replication Controller is named mongo-rc2

Service is named mongo-svc-b and has a unique, external IP address (in this case, Kubernetes is assigned 104.1.4.5).

The third replica collection widget has the same pattern, and the following figure shows the complete replica collection:

Note that even if the configuration shown in figure 3 is run on a Kubernetes cluster with three or more nodes, Kubernetes may (usually) dispatch two or more MongoDB replica collection artifacts on the same host. This is because Kubernetes says that these three nodes are regarded as three separate service.

To increase redundancy (in zone), an additional headless service is created. The new service does not provide new performance to inform Kubernetes that the three MongoDB pods are from the same service, so KUbernetes tries to schedule them on different nodes.

Configuration files and command lines that really need to compile and open a collection of copies of MongoDB can be viewed here: click me. In particular, there are special steps that require combining three Mongo DB instances into a running, robust replica set, which is already covered in the paper.

Multiple availability zone MongoDB replica collections

Everything runs in the same GCE cluster, so the above things created by replica collections are also risky, and the same is true in the same availability zone. Suppose there is a major accident and the availability zone is offline, then the MongoDB replica collection is not available. If geo-backup is needed, then the three pods should operate in three different availability zones or zones.

Surprisingly, in order to create a similar set of replicas in each of the three regions, there is little need to change-- which requires three clusters. Each cluster needs its own KubernetesYAML file, which defines only pod,Replication Controller and service as a component of the replica collection. Then create a cluster, persistent data, and MongoDB for each region.

The above is how to use Docker and Kubernetes to run MongoDB as a micro-service. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.