RabbitMQ

This guide allows you to configure the mandatory RabbitMQ server deployed with your Regards swarm stack.

RabbitMQ Configuration

Edit your inventory file inventories/<your inventory>/group_vars/regards_nodes/main.yml to override RabbitMQ information

Format used

The REGARDS playbooks generates a definition file that is imported by the RabbitMQ service. Click here to get more info about this format.

Cluster configuration

To deploy a cluster of RabbitMQ nodes, you need to set global_service to true:

group_docker_cots:
  rabbitmq:
    global_service: true

If you don't want all your Swarm nodes to receive a RabbitMQ replica, use Swarm label node placement constraint:

group_docker_cots:
  rabbitmq:
    global_service: true
    node_label_placement_constraint:
      key: type
      value: cots

This example tells Swarm to deploy a replica of RabbitMQ on every node having a property type valued to cots.

Client port configuration

Client configuration allows external programs to contact the RabbitMQ server deployed.

No TLS (unsafe)

group_docker_cots:
  rabbitmq:
    # Port to connect to RabbitMQ server
    client: 5672

With TLS

To enable ssl on your RabbitMQ server, you need define the port (using client_ssl property):

group_docker_cots:
  rabbitmq:
    # Port to connect to RabbitMQ server
    client: 5672
    # Port to connect to RabbitMQ server with ssl
    client_ssl: 5671

And you need to provide SSL certificates names inside your inventory:

Certificates used by RabbitMQ

group_docker_cots_configuration:
  rabbitmq:
    ssl:
      crt: certificate.crt
      key: certificate.key
      ca: certificate.ca.crt

Certificates location

Certificate files must be located inside <my-inventory>/static/ssl/ folder in your inventory.
In upper example, it means the file <my-inventory>/static/ssl/certificate.crt exists.

Admin port configuration

Our playbook let you configure the port used to administrate RabbitMQ using a browser.

No TLS (unsafe)

group_docker_cots:
  rabbitmq:
    # Port to connect to RabbitMQ admin dashboard
    http: 15672

With TLS

On REGARDS Swarm deployment, it's the rs-front service that provides the RabbitMQ Admin UI through TLS.

group_docker_mservices:
  front:
    rabbitmq_admin: 15672


group_docker_cots:
  rabbitmq:
  # rabbitmq admin HMI is open through rs-front, no property used here

Configure admin

group_docker_cots:
  rabbitmq:
    # Administrator user name for RabbitMQ Server
    user: my-admin
    # Administrator user password for RabbitMQ Server 
    password: XXXXX

group_config_mservices:
  amqp:
    # Administrator user name for RabbitMQ Server
    user: my-admin
    # Administrator user password for RabbitMQ Server 
    password: XXXXX

note

If you do not override this property, admin will be the default RabbitMQ administrator guest.
If you override the administrator name, user guest is not allowed

Configure users

group_docker_cots:
  rabbitmq:
    # RabbitMQ configuration to automatically create users
    additional_users:
      - name: exemple-user
        password: XXXXX
        tags: ''
    # RabbitMQ configuration to automatically create users permissions 
    user_permissions:
      - user: exemple-user
        vhost: regards.multitenant.manager
        configure: ''
        write: ''
        read: ''

Configure shovels

Our playbook provides following configuration to automatically create shovels

group_docker_cots:
  rabbitmq:
    additional_parameters:
      - component: shovel
        name: Exemple shovel
        vhost: regards.multitenant.manager
        value:
          ack-mode: on-confirm
          dest-add-forward-headers: false
          dest-protocol: amqp091
          dest-exchange: exemple.exchange
          dest-uri: amqp:///regards.multitenant.manager
          src-delete-after: never
          src-protocol: amqp091
          src-queue: source.queue
          src-uri: amqp://user:password@other-amqp-server-adress:5672/vhost

Shovels

Most of the time, a shovel takes messages from a distant queue and put them in a local exchange

Create queues, exchanges and bindings

Our playbook provides three different properties to automatically create RabbitMQ queues, exchanges and bindings:

• additional_queues property to manage queues
• additional_exchanges property to manage exchanges
• additional_bindings property to manage bindings

group_docker_cots:
  rabbitmq:
    additional_exchanges:
      - name: exemple.exchange
        vhost: regards.multitenant.manager
        # type can be Direct / Fanout / Topic
        type: fanout
        durable: true
        internal: false
    additional_queues:
      - name: exemple.queue
        vhost: regards.multitenant.manager
        durable: true
        auto_delete: false
        arguments:
          x-dead-letter-exchange: regards.DLX
          x-dead-letter-routing-key: regards.DLQ
          x-max-priority: 255
    additional_bindings:
      - source: exemple.exchange
        vhost: regards.multitenant.manager
        destination: exemple.queue
        destination_type: queue
        routing_key: 'exemple'

Consumer timeout

Our playbook provides following configuration to override default consumer timeout, which is by default 30 min.

group_docker_cots:
  rabbitmq:
    consumer_timeout_in_ms: 3600000
    # set to 1h

Mutualised RabbitMQ

If you prefer to use a mutualised instance of RabbitMQ, ensure it uses the right version of RabbitMQ and plugin rabbitmq_delayed_message_exchange is active