Skip to content

RabbitMQ Shovel Transport

Shovels are RabbitMQ implementation of the Message Transfer concept described earlier. It allows to connect two endpoints in different brokers and route messages through them.

Shovels are enabled with the shovel plugin for rabbitmq and configured by Replication via its exposed rest API.

  1. The shovel plugins runs on the hub only, not on satellites.
  2. Shovels are created only on the hub, two shovels per satellite
    1. A shovel hub to satellite
    2. A Shovel satellite to hub

Networking

  1. The Hub's rabbitmq instance must be able to reach all satellites on AMQPS protocol port 5671, bidirectional.

  2. A DNS record is usually used (instead of IP addresses) so that a certificate, signed by a wellknown authority, can be issued for that domain name.

  3. The shovel plugin (running only on the hub) will send/receive traffic from/to the hub's rabbitmq instance locally, in-cluster traffic.

    1. No AMQPS is enabled on the hub's broker.
    2. The satellites do not need to reach the hub's rabbitmq instance; it is the hub who sends/receives all packets.
  4. The shovel plugin (running only on the hub) will send/receive traffic from/to each satellite's rabbitmq instance using each satellite's AMQPS listener. This is traffic is encrypted.

TLS Configuration

To enable TLS for the shovels, first we need to enable TLS on each satellite's rabbitmq instance. Usually, internal cluster traffic uses the AMQP listener, and external (aka shovels) use the AMQPS listener.

Only the satellites needs to have TLS enabled on the broker, hence certificates are only required for the satellites.

  1. A certificate is required for each satellite's Rabbitmq instance to enable the AMQPS listener
    1. A single certificate can be used for all satellites using multiple SANs
  2. The hub must have access to the certificates of all satellites, public and private keys.
    1. The hub's rabbitmq instance needs to have these certificates mounted.
  3. The hub must have the CA certificate (public key) used to sign the satellite's certificates.
    1. The hub's rabbitmq instance needs to have the CA mounted.

TLS Shovel URIs

Once TLS is in place for the satellites, the Replication Shovel URIs on the hub need to be updated to reference the satellite's certificates and enable peer verification.

Text Only
1
2
3
4
5
amqps://user:password@server-name
?cacertfile=/path/to/cacert.pem
&certfile=/path/to/cert.pem
&keyfile=/path/to/key.pem
&verify=verify_peer

For example, using break lines to clean it up:

Text Only
1
2
3
4
5
amqps://default_user:__RabbitMqPassword__@cdu-ship.dev.suite.itsynch.com
?cacertfile=/home/itsynch/secrets/replication/ca.crt
&certfile=/home/itsynch/secrets/replication/cdu-satellite.crt
&keyfile=/home/itsynch/secrets/replication/cdu-satellite.key
&verify=verify_peer