Detailed operations of building RabbitMq's common cluster and mirror cluster with Docker

Ordinary cluster: An ordinary cluster composed of multiple nodes. Messages are randomly sent to the queue of one of the nodes. Other nodes only retain metadata. Each node has only the same metadata, namely queue structure, switch structure, vhost, etc. When consumers consume messages, they pull messages from various nodes. If the node that stores the message fails, the message cannot be consumed. If the message is persisted, it must wait for the node to recover before it can be consumed. If it is not persisted, the message will be lost.

Mirror cluster: Based on the normal mode, the required queues are made into mirror queues and exist on multiple nodes to achieve high availability (HA). This mode solves the above problems. Broker will actively synchronize message entities among mirror nodes, and there is no need to temporarily pull data when consumers retrieve data. The side effects of this mode are also obvious. In addition to reducing system performance, if there are too many mirror queues and a large number of messages enter, the network bandwidth within the cluster will be consumed a lot. Generally, mirroring mode is recommended for scenarios with high reliability requirements.

1. Build the operating environment of RabbitMq

My computer is window10, and I built two rabbitmq nodes through docker.

1. Query the rabbitmq image through search

docker search rabbitmq

2. Pull the latest official image of rabbitmq through pull

It is best to bring the version with the tag management here. Otherwise, when you pull the latest version, the web management page cannot display the entire version and will prompt overview: management only mode

docker pull rabbitmq:3.8.25-management

3. Create a container

docker run -d --name rabbitmq1 -p 5672:5672 -p 15672:15672 --hostname myRabbit1 -e RABBITMQ_DEFAULT_VHOST=my_vhost1 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin a4eb038c2ecb

--name: container name

-p: endpoint mapping

--hostname: rabbitmq node name

-e RABBITMQ_DEFAULT_VHOST: Virtual host name

-e RABBITMQ_DEFAULT_USER: login account

-e RABBITMQ_DEFAULT_PASS: login password

a4eb038c2ecb is the image ID, replace it according to your own situation.

4. Start the management page

Our image does not have the web management page enabled by default, so we use the exec command to enter the container and start it. The environment of this image is Ubuntu.

PS C:\> docker exec -it 639a151c5440 /bin/bash
root@myRabbit:/# rabbitmq-plugins enable rabbitmq_management

Visit http://localhost:15672/ in the browser to open it. Do the same for the other rabbitmq. The difference is that the ports are changed to 5673 and 15673, etc., and --link is used to connect to the first rabbitmq node when creating the container (you can also create a bridge network connection), as follows

docker run -d --name rabbitmq2 -p 5673:5672 -p 15673:15672 --hostname myRabbit2 -e RABBITMQ_DEFAULT_VHOST=my_vhost2 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin --link rabbitmq1:myRabbit1 a4eb038c2ecb

5. Set Erlang cookies

The erlang cookie could originally be set by setting the parameter -e RABBITMQ_ERLANG_COOKIE when running the container, but it is now deprecated.

We first use the docker logs command to view the running log of the container and find the home dir parameter as follows

PS D:\> docker logs rabbitmq1
//.....Starting broker is omitted here...2021-11-17 02:19:55.859245+00:00 [info] <0.222.0>
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> node : rabbit@myRabbit1
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> home dir : /var/lib/rabbitmq
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> config file(s) : /etc/rabbitmq/conf.d/10-default-guest-user.conf
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> : /etc/rabbitmq/conf.d/management_agent.disable_metrics_collector.conf
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> cookie hash : Aed9pjd9vYWw3hng7Gjmkg==
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> log(s) : /var/log/rabbitmq/rabbit@myRabbit1_upgrade.log
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> : <stdout>
2021-11-17 02:19:55.859245+00:00 [info] <0.222.0> database dir : /var/lib/rabbitmq/mnesia/rabbit@myRabbit1

So the .erlang.cookie file is in this path, and we can see this file when we enter the container

root@myRabbit1:~# ls -a /var/lib/rabbitmq
. .. .bash_history .erlang.cookie mnesia

We then set the permissions for the Erlang cookie and run the following code in the container. If the permissions are insufficient, subsequent operations will report an error.

chmod 600 /var/lib/rabbitmq/.erlang.cookie

We then use the docker cp command to copy the .erlang.cookie file in rabbitmq1 to the physical machine and then copy it to the rabbitmq2 container. The copy command between the physical machine and the container is as follows:

• Container copies files to the physical machine: docker cp container name: container directory
• Physical machine directory Physical machine copies files to container: docker cp Physical machine directory Container name: container directory

The specific code is as follows:

docker cp rabbitmq1:/var/lib/rabbitmq/ d:\workspace\
docker cp d:\workspace\rabbitmq\.erlang.cookie rabbitmq2:/var/lib/rabbitmq/

After copying, you need to restart the rabbitmq2 container, otherwise the following error will be reported when executing the rabbitmqctl command:

[error] Cookie file /var/lib/rabbitmq/.erlang.cookie must be accessible by owner only

2. Normal Mode

After restarting, enter the container and add the rabbitmq2 node to rabbitmq1 to create a normal cluster. Execute the following codes respectively:

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster --ram rabbit@myRabbit1 //myRabbitmq1 is the hostname of rabbitmq in the rabbitmq1 container
rabbitmqctl start_app

After that, we can see two nodes on the web management page.

If you create a queue on any node, the same queue will be generated on the other node. And it can be found that the vhost of rabbitmq2 has changed from my_vhost2 to my_vhost1, which is the same as rabbitmq.

3. Mirror Mode

The mirror mode is to enter the rabbitmq1 container based on the normal mode and enter the following command:

rabbitmqctl set_policy -p my_vhost1 ha-all "^" '{"ha-mode":"all"}' --apply-to all

The specific format is

rabbitmqctl set_policy [-p Vhost] Name Pattern Definition [Priority]
-p Vhost: Optional parameter, set for the queue under the specified vhost Name: policy name Pattern: queue matching pattern (regular expression)
Definition: image definition, including three parts: ha-mode, ha-params, ha-sync-mode
        ha-mode: specifies the mirror queue mode. Valid values ​​are all/exactly/nodes
            all: indicates mirroring on all nodes in the cluster exactly: indicates mirroring on a specified number of nodes, the number of nodes is specified by ha-params nodes: indicates mirroring on specified nodes, the node name is specified by ha-params ha-params: as a parameter, it is a supplement to ha-mode ha-sync-mode: the synchronization mode of messages in the queue, the valid values ​​are automatic and manual
priority: optional parameter, policy priority rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}' --apply-to all

Or log in to the rabbitmq management page -> Admin -> Policies -> Add / update a policy

name: policy name

Pattern: ^ matching character, only one ^ means match all. ^message refers to the queue name starting with "message"

Definition: ha-mode=all is the matching type, which is divided into 3 modes: all (indicates all queues)

Priority: First, sort by priority . The larger the value, the higher the priority. For the same priority , sort by creation time. The later the creation, the higher the priority.

Briefly explain the difference between Operator Policy and User Policy:

• Operator Policy is used by service providers or corporate infrastructure departments to set certain general rules that need to be enforced.
• User Policy is used to set rules for business applications

Operator Policy and User Policy will be combined and applied to the queue. To prevent Operator Policy from overwriting certain key attributes of the queue, such as the Dead Letter Exchange Exchange, which may cause unexpected results in business applications, Operator Policy only supports four parameters: expire , message-ttl , max-length , and max-length-bytes .

Reference learning:

https://www.cnblogs.com/knowledgesea/p/6535766.html

https://blog.csdn.net/belonghuang157405/article/details/83540148

This is the end of this article about building RabbitMq's ordinary cluster and mirror cluster with Docker. For more information about building RabbitMq cluster with Docker, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!