基于Docker搭建RabbitMQ集群(多台服务器)
前言:本文章这次主要是基于docker在多台服务器下搭建的普通集群环境,镜像集群以及集群搭建后通过nginx负载和keepalived实现HA会另出一篇文章进行详细介绍。
一:准备工作
集群所需要的虚拟机环境(根据自身的集群需要来准备),我这边测试的话用的是2台;机器准备好后,安装好docke环境等集群所需要的依赖
二:拉取RabbitMQ所需的镜像
在线拉取方式:
docker pull rabbitmq:3.9.5-management
离线方式:RabbitMQ官方网站下载对应版本的包
离线安装完毕后通过docker -load -i 加载镜像到docker里面
docker load -i xx.tar(xx.tar是rabbit的tar包)
#加载完毕后查看镜像
docker images
三:在集群的机器上进行部署
机器1:192.168.23.188
机器2:192.168.23.189
在两台机器上通过上诉操作安装好MQ的镜像;
操作机器1
docker run -d --hostname rabbitmq1 --add-host=rabbitmq2:192.168.23.189 --restart=unless-stopped --name rabbitmq1 --net host -p 15672:15672 -p 5672:5672 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin -e RABBITMQ_ERLANG_COOKIE='rabbit_mq' rabbitmq:management
参数解释:
-d 容器后台运行
--hostname rabbitmq1 容器的主机名为 rabbitmq1
--add-host="rabbitmq1":192.168.23.189 修改容器内部的hosts
--restart=unless-stopped docker 容器重启后重启MQ
--name rabbitmq1 容器名为rabbitma1，在宿主机上运行“docker ps”命令时显示的名称
-p "5672:5672" 消息通讯端口
-p "15672:15672" 后台管理端口
-e RABBITMQ_DEFAULT_USER=admin 设置rabbitmq默认用户为admin
-e RABBITMQ_DEFAULT_PASS=admin 设置rabbitmq默认密码为admin
-e RABBITMQ_ERLANG_COOKIE='rabbit_mq' 设置rabbitmq的cookie为“rabbit_mq”，可以自定义为其他文本，容器保持一致即可
启动完毕后,在网页打开192.168.23.188:15672访问看看是否正常
操作机器2
docker run -d --hostname rabbitmq2 --add-host=rabbitmq1:192.168.23.188 --restart=unless-stopped --name rabbitmq2 --net host -p 15672:15672 -p 5672:5672 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin -e RABBITMQ_ERLANG_COOKIE='rabbit_mq' rabbitmq:management
启动完毕后,在网页打开192.168.23.189:15672访问看看是否正常
这里注意一下:在操作机器1和机器2的时候 --add-host后面的参数一定要记得填写正确;abbitmq的cookie也要保持一致否则建立不了集群关系;两台机器分别部署完毕后,现在这两台MQ是不相干的我们需要使他们建立起集群关系
回到机器1
进入刚刚启动的rabbit容器
docker exec -it rabbitmq1 bash
进入容器后通过rabbitmqctl命令对MQ进行操作
#首先停止当前MQ
rabbitmqctl stop_app
#resetMQ
rabbitmqctl reset
#重新启动MQ
rabbitmqctl start_app
退出容器
exit
回到机器2
进入刚刚启动的rabbit容器
docker exec -it rabbitmq2 bash
进入容器后通过rabbitmqctl命令对MQ进行操作
#首先停止当前MQ
rabbitmqctl stop_app
#resetMQ
rabbitmqctl reset
#跟机器1的消息队列建立关系
rabbitmqctl join_cluster --ram rabbit@rabbitmq1
#重新启动MQ
rabbitmqctl start_app
退出容器
exit
这时候机器1和机器2的集群关系已经搭建好了,现在去看看管理地址上的情况:
四:通过nginx进行负载均衡
到这里测试用的两台集群已经搭建完毕,但是这时候还不能用,因为没有做负载。
这里可以另外找一台机器也可以再机器1或者机器2上进行部署nginx来进行负载;实际部署中是需要在另外一台机器进行部署的;测试的话就在机器1上进行部署nginx了
在机器1上面随便建立一个文件夹用来存放nginx的配置文件:/root/nginx/nginx_rabbitmq.conf
文件内容:
user nginx;
worker_processes 1;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
#tcp_nopush on;
keepalive_timeout 65;
#gzip on;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 5s;
proxy_send_timeout 5s;
proxy_read_timeout 5s;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
#rabbitmq管理界面
upstream rabbitManage {
server 192.168.23.188:15672;
server 192.168.23.185:15672;
}
server {
listen 15673;
server_name 192.168.23.188;
location / {
proxy_pass http://rabbitManage;
index index.html index.htm;
}
}
}
# rabbitmq通信
stream{
upstream rabbitTcp{
server 192.168.23.188:5672;
server 192.168.23.189:5672;
}
server {
listen 5673;
server_name 192.168.23.188;
location / {
proxy_pass http://rabbitTcp;
index index.html index.htm;
}
}
}
配置完毕后启动nginx:
docker run -it -d --name nginxMQ -v /root/nginx/nginx_rabbitmq.conf:/etc/nginx/nginx.conf --privileged --net=host nginx
启动完毕后通过负载的地址进行统一访问MQ
后台地址:192.168.23.188:15673
通讯地址:192.168.23.188:5673
五:结语
至此通过Docker 搭建普通版本RabbitMQ集群已经搭建完毕了,普通版本的集群对于一般公司的业务来说是够用的了,如果针对业务量比较大的公司还是有些弊端的;虽然搭建了nginx进行负载但是还是缺少高可用;这时候需要搭建镜像版的集群:
与普通集群模式区别 主要是消息实体会主动在镜像节点间同步数据，而不是只存储数据元信息。 普通通集群模式 一旦数据节点挂了,如果没有持久化数据,数据就会丢失,且这时候也不会进行消费,只能等待消息重新回到队列中才能再次消费;但镜像集群模式可以保证集群只要不全部挂掉，数据就不会丢失，当相对于性能来说，镜像集群模式会比普通集群模式多出消耗数据的传输。故取决于业务场景进行取舍;且镜像版集群不仅仅需要nginx来进行负载也需要keepaplived进行转发;对机器的要求相对更严格一点;后续会出一份关于镜像版本的集群