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

Today, I will talk to you about how to use containers to achieve one-click delivery of production-level MongoDB sharding clusters. Many people may not know much about it. In order to make you understand better, the editor summarized the following for you. I hope you can get something from this article.

Introduction to the author

CTO, co-founder of Wei Shijiang Xiyun, is responsible for the back-end research and development of Docker-based automated service management platform. Good at Docker related technology, PasS platform architecture and enterprise automation operation and maintenance system design and development. Before starting a business, he worked as a technical manager on Sina SAE platform. For more than four years from the establishment of the SAE project in 2009 to the second half of 13 years, he has been responsible for the design and development of various Web-based service management systems on SAEPasS platform, and has accumulated rich experience in DevOps. Docker engine code contributor ranks about 50 in the world in terms of code contribution in Docker open source projects.

The beginning

Mongo supports replication set and sharding clusters a long time ago. After so many years of precipitation, the maturity of Mongo cluster has been very stable and has been used by a large number of companies in their own production environment. How to use container technology to achieve one-click delivery and deployment of Mongo clusters and shield the details of the underlying implementation is a topic of concern to many people.

This article will introduce the process-based container technology to achieve one-click deployment of Mongo sharding clusters, which fully demonstrates the powerful power of containers.

What is a Mongo sharding cluster

As a popular document database, Mongo (mongodb.com) has many interesting features, such as built-in failover, support for file storage, support for mapreduce and the ability to run js scripts directly on the server side. Of course, what we are most concerned about today is its built-in sharding function. The design of distributed system has always been a high challenge. In recent years, with the development of the Internet, distributed practice has been gradually promoted and valued.

For an in-depth understanding of the principles of Mongo sharding, refer to:

Https://docs.mongodb.com/manual/sharding

Cluster planning

Mongo cluster involves a number of services, including:

Configdb, the central configuration of sharding cluster, is a replicaset cluster, listening on port 27019

Mongos, as the access and management entry of sharding cluster, listens on port 27017

Mongo slices, data sharding node

Mongo replicaset, each data shard is a replicaset cluster, which ensures that there is no single point and provides automatic failover capability.

Mongo express, the management dashboard of mongodb

Topological graph

In this deployment, there are 3 configdbs and 12 mongo data nodes, which are divided into 4 shards, each with one master and two slaves.

First prepare the mongo image

Mongo has officially provided an image of Mongo 3.2, which can be used as a mirror of a Mongo cluster. In order to reduce the subsequent maintenance work, we try not to build our own image as much as possible.

Let's arrange the cluster step by step according to the official deployment documentation of mongo sharding.

Https://docs.mongodb.com/manual/tutorial/deploy-shard-cluster/

The order of deployment is: configdb-> mongos-> mongo-replicaset/mongo-slices-> mongo-express

Deploy the configuration file # cat mongo-config.confsystemLog: verbosity: 0 operationProfiling: slowOpThresholdMs: 3000processManagement: fork: falsestorage: dbPath: / data/db journal: enabled: true engine: wiredTigerreplication: replSetName: {{.ReplSetName}} sharding: clusterRole: configsvr net: port: 27019 prepare the configdb cluster initialization js script # cat configdb-init.js {{$s: = service "mongo-configsvr"} config = { _ id: "{{.ReplSetName}}" Members: [{{range $c: = $s.Containers}} {_ id: {{$c.Seq}}, host: "{{$c.Domain}}: 27019"}, {{end}}]} rs.initiate (config) rs.status () begins to orchestrate the first step of configdb service creation template

The second step is to select mongo image and specify cmd

The third step is to set container parameters and associate the configuration file

Step 4 Health check-up Strategy

Step 5: set the deployment policy. The default number of deployment containers

Initialize configdb to replicaset cluster

By adding an one-off service configsvr-init, the service will exit automatically after performing the initialization action

The first step is to select mongo image and specify cmd

The second step is to set the container parameters and associate the js script

The third step is to set the deployment policy, with the priority number set to 11 (configdb priority 10)

At this point, the choreography of configdb is complete. Let's next orchestrate the mongos service

Prepare mongos configuration file # cat mongos.confreplication: localPingThresholdMs: 2000 {{$port: = .CfgPort}} {{$s: = service "mongo-configsvr"}} sharding: configDB: {{.ReplSetName}} / {{range $iReplSetName: = $s.Containers}} {{if ne $I 0}}, {end} {{$c.Domain}: {{$port} {{end}

We usually put the configuration file of mongo under / etc/

The first step in arranging the mongos template is to select the image and specify the cmd parameter

Notice that mongos is executed in cmd

The second step is to set container parameters and associate mongos configuration.

The third step of health check-up

Step 4: set the deployment strategy and pay attention to the priority.

Mongos must run after the configdb cluster is initialized, and then we begin to orchestrate the data node service of mongo, which is the most complex part of the cluster.

Prepare the configuration file cat mongo-shard.confsystemLog: verbosity: 0 operationProfiling: slowOpThresholdMs: 3000 processManagement: fork: false storage: dbPath: / data/db journal: enabled: true engine: wiredTiger {{$num: = (parseInt .REPLICA _ NUM) | add 1} {{$cn: = (parseInt .Container.Seq) | subtract 1}} {{$rsn: = $cn | divide $num} replication: replSetName: RS {{$rsn}}

The variable REPLICA_NUM indicates that each master has several slaves. The default is 2. Here 123 containers are compiled as RS0456, RS1789, RS2,10,11,12, RS3.

The first step in orchestrating mongo shard service is to add mongo image and specify the cmd parameter

The second step is to set parameters and associate configuration

The third step of health check-up

Step 4 set up deployment

With the above data node, we find that the replset has not been initialized and every replset has not been added to the sharding. Let's do the shard initialization work.

Initialize sharding cluster #! / bin/bashset-e {{$s: = service "mongo"}} {{$n: = (parseInt .REPLICA _ NUM) | add 1}} {{$slices: = $s.ContainerNum | divide $n}} {{$port: = .Port}} echo begin to init replica set... for i in {0.. {{$slices | subtract 1} Do bn=$ (($I * {{$n}} + 1)) en=$ (($bn + {{. REPLICA_NUM}})) RS_NODE= RS_NODE_CONFIG= ii=$bn while [$ii-le $en] Do RS_NODE=$RS_NODE$ii.mongo. {{.Instance.Name}} .csphere.local: {{$port}}, RS_NODE_CONFIG=$RS_NODE_CONFIG "{_ id:$ii, host:\" $ii.mongo. {{.Instance.Name}} .csphere.local: {{$port}}\ "}," ii=$ ($ii + 1)) done RS_NODES=$ (echo $RS_NODE | sed's hint) RS_NODES_CONFIG=$ (echo $RS_NODE_CONFIG | sed's /) $/') cat > / tmp/RS$i.js

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.