RabbitMQ Learning II: Managing single-node RabbitMQ

Environmental preparation:

[root@master ~]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
[root@master ~]# uname -a
Linux master 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@master ~]# ip addr
ens33:
inet 192.168.0.201/24 brd 192.168.0.255 scope global ens33

Current Erlang and RabbitMQ versions:

[root@master ~]# erl
Erlang/OTP 22 [erts-10.7.1] [source] [64-bit] [smp:1:1] [ds:1:1:10] [async-threads:1] [hipe]
[root@master ~]# rabbitmqctl version
3.8.3


1. Deploy single-node RabbitMQ

The RabbitMQ Node is actually the RabbitMQ application and its Erlang virtual machine.Similar to JAVA applications and JVM virtual machines.

Erlang allows applications to communicate with each other without having to know if they are on the same machine.

1.1. Configure repo:

[root@master ~]# cat /etc/yum.repos.d/erlang_solutions.repo 
[erlang-solutions]
name=Centos $releasever - $basearch - Erlang Solutions
baseurl=http://packages.erlang-solutions.com/rpm/centos/$releasever/$basearch
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/erlang_solutions.asc
enabled=1
[root@master ~]# cat /etc/yum.repos.d/rabbitmq.repo 
[rabbitmq_rabbitmq-server]
name=rabbitmq_rabbitmq-server
baseurl=https://packagecloud.io/rabbitmq/rabbitmq-server/el/7/$basearch
repo_gpgcheck=1
gpgcheck=0
enabled=1
gpgkey=https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300
[root@master ~]# wget -O /etc/pki/rpm-gpg/erlang_solutions.asc https://packages.erlang-solutions.com/ubuntu/erlang_solutions.asc

1.2. Perform installation:

[root@master ~]# yum clean all
[root@master ~]# yum makecache
[root@master ~]# yum -y install erlang
[root@master ~]# yum -y install rabbitmq-server

1.3. Configuration file:

 [root@master ~]# wget -O /etc/rabbitmq/rabbitmq.conf --no-check-certificate https://github.com/rabbitmq/rabbitmq-server/blob/master/docs/rabbitmq.conf.example


2. Start and Stop

2.1. Startup:

RabbitMQ installed via rpm can be started by simply executing a command:

[root@master ~]# rabbitmq-server

Put RabbitMQ in the background to start:

[root@master ~]# rabbitmq-server -detached

This starts the RabbitMQ application and the Erlang program.

If you execute the netstat command to view the port at this time, you will find three new ports (4369, 25672, 5672):

  • 4369 is used by the empd process, all known as Erlang Port Mapper Daemon.When a distributed Erlang node is started, it is registered with the empd process, providing the address and port assigned by the OS kernel;

  • 25672 is assigned by the OS to the Erlang VM running RabbitMQ;

  • 5672 is the port on which the AMQP client connects to RabbitMQ.

2.2. Stop:

[root@master ~]# rabbitmqctl stop
//perhaps
[root@master ~]# rabbitmqctl shutdown

You can also manage the start and stop of RabbitMQ through systemctl:

[root@master ~]# systemctl start rabbitmq-server.service
[root@master ~]# systemctl stop rabbitmq-server.service

The above commands apply to the entire RabbitMQ node (application and Erlang virtual machine).If you only want to restart the RabbitMQ application and keep the Erlang virtual machine running:

[root@master ~]# rabbitmqctl stop_app
[root@master ~]# rabbitmqctl start_app


3. Authority Management

Users are the basic unit of access control. For one or more vhost s, users can be given different levels of access.

Create users first, and then grant them permissions (configure, write, read).

3.1. User management:

Create a user and create a user named "user1" with a password of "passwd1":

[root@master ~]# rabbitmqctl add_user user1 passwd1

Modify the password for the specified user, such as changing the password for user "user1" to "newpasswd":

[root@master ~]# rabbitmqctl change_password user1 newpasswd

View existing users:

[root@master ~]# rabbitmqctl list_users

Delete users, such as user "user1":

[root@master ~]# rabbitmqctl delete_user user1

3.2. Permission system:

RabbitMQ implements an access control list (ACL)-style permission system that grants users configure, write, and read permissions:

  • Configure permissions: create and delete queues and switches;

  • Write: Publish a message;

  • Read: Any action on consumer messages, including "purging" the entire queue.

Access control entries cannot span vhosts. For example, if you want to give user user1 the same permissions on vhost1 and vhost2, you must create two identical access control entries.

The following table shows most AMQP commands and their corresponding permissions:

AMQP Command

Switch exchange

queue

exchange.declare

To configure


exchange.delete

To configure


queue.declare


To configure

queue.bind

read

write

basic.publish

write


basic.get


read

basic.consume


read

queue.puege


read

3.2.1And grant permissions:

Example 1 gives the user1 user full access (configuration, write, and read) to Vhost 1.

First create a vhost:

[root@master ~]# rabbitmqctl add_vhost vhost1

Give user1 permissions:

[root@master ~]# rabbitmqctl set_permissions -p vhost1 user1 ".*" ".*" ".*"
  • -p vhost1:set_The permissions entry should be applied to which vhost.If -p is not specified, the default'/'is used by default;

  • user1: the user granted permission;

  • ". *" ". *" ". *": Represents configuration, write, read permissions, respectively.'. *'means matching any queue or switch name.

Example 2 gives user1 permission on vhost1 to allow the user to read from any queue or switch, write only to queues or switches that start with logs-and block configuration operations altogether:

[root@master ~]# rabbitmqctl set_permissions -p vhost1 user1 "" "logs-.*" ".*"

As an example,''means that no queues or switches are matched.

3.2.2, view permissions:

View all permission entries on vhost1:

[root@master ~]# rabbitmqctl list_permissions -p vhost1

View permissions owned by user1:

[root@master ~]# rabbitmqctl list_user_permissions user1

3.2.3, Clear permissions:

Clear user1 permissions on vhost1:

[root@master ~]# rabbitmqctl clear_permissions -p vhost1 user1

clear_permissions clears all user permissions on the specified vhost.If you want to modify user permissions, just execute set_permissions sets new permissions.


IV. Check Statistics

4.1, View Queues and Number of Messages:

[root@master ~]# rabbitmqctl list_queues -p vhost1

View more information about the queue:

[root@master ~]# rabbitmqctl list_queues -p vhost1 name messages consumers memory durable auto_delete

This command returns the name of the queue on vhost1, the number of messages, the number of additional consumers, the memory used, the durable property (whether it is a persisted queue), and auto_delete attribute

4.2, view switches and bindings

4.2.1, View Switch:

[root@master ~]# rabbitmqctl list_exchanges -p vhost1
Listing exchanges for vhost vhost1 ...
name    type
amq.headers    headers
amq.match    headers
amq.topic    topic
    direct
amq.rabbitmq.trace    topic
amq.direct    direct
amq.fanout    fanout

By default, this command returns the name and type of the exchanger.When a vhost is created, several exchanges are already declared.There is one switch that only shows "type" as "direct", which is an "anonymous switch", where each new queue is bound by default.

4.2.2, View more about the switch:

[root@master ~]# rabbitmqctl list_exchanges -p vhost1 name type durable auto_delete

4.2.3. View information about binding s:

[root@master ~]# rabbitmqctl list_bindings


5. About Rabbit

5.1, Node name:

When the RabbitMQ node starts, it uses a node name such as rabbit@master."Rabbit" is usually fixed, and "master" is usually the local HOSTNAME.Node names are used in many places, such as when managing remote nodes through the rabbitmqctl command, they must match.There are also the Mnesia and log directories, as follows:

[root@master ~]# ls -dl /var/log/rabbitmq/rabbit@master.log
[root@master ~]# ls -dl /var/lib/rabbitmq/mnesia/rabbit@master

If you modify the native HOSTNAME, errors such as "nodedown" may occur when rabbitmqctl is executed, so keep the node name as long as possible.

5.2,Erlang cookie:

The Erlang node is authenticated by matching the Erlang cookie.When creating a RabbitMQ cluster, the Erlang cookies of each node need to be consistent in order for the nodes to communicate with each other.Cookies are typically stored in'~/.erlang.cookie'files,'~' usually refers to the rabbitmq user's home directory.

To find the location of the.erlang.cookie file, you can also execute:

[root@master ~]# find / -name .erlang.cookie

5.3,Mnesia:

RabbitMQ uses Mnesia to store information such as queues, switches, bindings, and so on.RabbitMQ starts the Mnesia database when it starts, and if Mnesia fails to start, RabbitMQ also fails to start.

Mnesia creates a database schema based on the machine's node name, so changing the host name can also cause problems with RabbitMQ.

5.4. Alternate RabbitMQ Log:

[root@master ~]# rabbitmqctl rotate_logs
[root@master ~]# ls /var/log/rabbitmq/*.log


More:

One of RabbitMQ Learning: Understanding RabbitMQ

https://blog.51cto.com/13568014/2495857

Tags: Operation & Maintenance RabbitMQ Erlang yum RPM

Posted on Mon, 18 May 2020 12:42:11 -0400 by NeoPuma