Initialize RabbitMq Docker Container with preconfigured Queues

As we work with docker containers, it is often desired to initialize the containers with specific application needs. One of such requirements was to initialize RabbitMq container with predefined queue. To be more specific, the objective needs to be achieved using docker compose.

In this approach, we would use docker volume to map the configurations, which in turn defines our custom queues, to the docker container. Let us go ahead and define our docker compose file.

version: '3'
services:
  localRabbitMQ:
    image: "rabbitmq:3.10.6-management-alpine"
    ports:
      - 5672:5672
      - 15672:15672
    volumes:
      - type: bind
        source: ./rabbitmq-enabled-plugins
        target: /etc/rabbitmq/enabled_plugins
      - type: bind
        source: ./rabbitmq.config
        target: /etc/rabbitmq/rabbitmq.conf
      - type: bind
        source: ./rabbitmq-defs.json
        target: /etc/rabbitmq/definitions.json

There are 3 files which are adding to the container. Let us explore each of them in detail.

enabled_plugins

This file defines the plugins which we are interested in. In this case, we are interested in the RabbitMq Management plugin. The rabbitmq-enabled-plugins is defined as following.

[rabbitmq_management].

rabbitmq.conf

The second file, rabbitmq.conf is the primary RabbitMq configuration file. It this example, we have used the used the new INI-like/sysctl format. If you instead prefer the old classic erlang format, you need to rename the file as rabbitmq.config.

This provides all the high level configurations needed by RabbitMq. It also points to the detailed configuration of management plugin.

loopback_users.guest = false
log.console = true
load_definitions = /etc/rabbitmq/definitions.json

The key line to note in this example is the load_definitions. This points to the detailed configuration definition for our management plugin.

Do note that the load_definitions is prefered over the depreciated management.load_definitions now.

definitions.json

Finally the detailed definitions of our configuration, which is defined in the definitions.json as referred by the primary configuration file. This file is used to define the queues, exchanges and users which would be initialized in the container.

{
  "users": [
    {
     "name": "ntuser",
     "password_hash": "kI3GCqW5JLMJa4iX1lo7X4D6XbYqlLgxIs30+P6tENUV2POR", 
     "hashing_algorithm": "rabbit_password_hashing_sha256",
     "tags": "administrator"
    },
    {
     "name": "adminuser",
     "password_hash": "kI3GCqW5JLMJa4iX1lo7X4D6XbYqlLgxIs30+P6tENUV2POR",
     "hashing_algorithm": "rabbit_password_hashing_sha256",
     "tags": "administrator"
    }
   ],
    "exchanges": [
      {
        "name": "HelloQueue",
        "vhost": "/",
        "type": "fanout",
        "durable": true,
        "auto_delete": false,
        "internal": false,
        "arguments": {}
      }
    ],
    "vhosts":[
      {"name":"/"}
  ],
    "queues": [
      {
        "name": "HelloQueue",
        "vhost": "/",
        "durable": true,
        "auto_delete": false,
        "arguments": {}
      }
    ],
    "bindings": [
      {
        "source": "HelloQueue",
        "vhost": "/",
        "destination": "HelloQueue",
        "destination_type": "queue",
        "routing_key": "*",
        "arguments": {}
      }
    ]
  }

That’s all we would require. Now you cuold run the container using the compose command.

docker-compose -f docker-compose.yml up