By Version

Edit this Page

Servicios de desarrollo para RabbitMQ

Dev Services for RabbitMQ automatically starts a RabbitMQ broker in dev mode and when running tests. So, you don’t have to start a broker manually. The application is configured automatically.

Enabling / disabling Dev Services for RabbitMQ

Los servicios de desarrollo para RabbitMQ se activan automáticamente a menos que:

quarkus.rabbitmq.devservices.enabled se ajusta a false
el rabbitmq-host o rabbitmq-port está configurado
todos los canales de Reactive Messaging RabbitMQ tienen los atributos host o port establecidos

Dev Services for RabbitMQ relies on Docker to start the broker. If your environment does not support Docker, you must start the broker manually, or connect to an already running broker. You can configure the broker access by using the rabbitmq-host, rabbitmq-port, rabbitmq-username and rabbitmq-password properties.

Broker compartido

Most of the time you want to share the broker between applications. Dev Services for RabbitMQ implements a service discovery mechanism for your multiple Quarkus applications running in dev mode to share a single broker.

Dev Services for RabbitMQ starts the container with the quarkus-dev-service-rabbitmq label, which is used to identify the container.

If you need multiple (shared) brokers, you can configure the quarkus.rabbitmq.devservices.service-name attribute and indicate the broker name. It looks for a container with the same value, or starts a new one if none can be found. The default service name is rabbitmq.

Sharing is enabled by default in dev mode, but disabled in test mode. You can disable the sharing with quarkus.rabbitmq.devservices.shared=false.

Ajuste del puerto

By default, Dev Services for RabbitMQ picks a random port and configures the application. You can set the port by configuring the quarkus.rabbitmq.devservices.port property.

Configuración de la imagen

Dev Services for RabbitMQ uses official images available at https://hub.docker.com/_/rabbitmq. You can configure the image and version with the quarkus.rabbitmq.devservices.image-name property:

quarkus.rabbitmq.devservices.image-name=rabbitmq:latest

Access the management UI

By default, Dev Services for RabbitMQ use the official image with the management tag. This means you have the management plugin available. You can use the Dev UI to find the HTTP port randomly affected or configure a static one by using quarkus.rabbitmq.devservices.http-port.

Predefined topology

Dev Services for RabbitMQ supports defining topology upon broker start. You can define Virtual Hosts, Exchanges, Queues, and Bindings through standard Quarkus configuration.

Defining virtual hosts

RabbitMQ uses a default virtual host of /. To define additional RabbitMQ virtual hosts, provide the names of the virtual hosts in the quarkus.rabbitmq.devservices.vhosts key:

quarkus.rabbitmq.devservices.vhosts=my-vhost-1,my-vhost-2

Defining exchanges

To define a RabbitMQ exchange you provide the exchange’s name after the quarkus.rabbitmq.devservices.exchanges key, followed by one (or more) of the exchange’s properties:

quarkus.rabbitmq.devservices.exchanges.my-exchange.type=topic            # defaults to 'direct'
quarkus.rabbitmq.devservices.exchanges.my-exchange.auto-delete=false     # defaults to 'false'
quarkus.rabbitmq.devservices.exchanges.my-exchange.durable=true          # defaults to 'false'
quarkus.rabbitmq.devservices.exchanges.my-exchange.vhost=my-vhost        # defaults to '/'

Additionally, any additional arguments can be provided to the exchange’s definition by using the arguments key:

quarkus.rabbitmq.devservices.exchanges.my-exchange.arguments.alternate-exchange=another-exchange

Defining queues

To define a RabbitMQ queue you provide the queue’s name after the quarkus.rabbitmq.devservices.queues key, followed by one (or more) of the queue’s properties:

quarkus.rabbitmq.devservices.queues.my-queue.auto-delete=false          # defaults to 'false'
quarkus.rabbitmq.devservices.queues.my-queue.durable=true               # defaults to 'false'
quarkus.rabbitmq.devservices.queues.my-queue.vhost=my-vhost             # defaults to '/'

Additionally, any additional arguments can be provided to the queue’s definition by using the arguments key:

quarkus.rabbitmq.devservices.queues.my-queue.arguments.x-dead-letter-exchange=another-exchange

Defining bindings

To define a RabbitMQ binding you provide the binding’s name after the quarkus.rabbitmq.devservices.bindings key, followed by one (or more) of the binding’s properties:

quarkus.rabbitmq.devservices.bindings.a-binding.source=my-exchange      # defaults to name of binding
quarkus.rabbitmq.devservices.bindings.a-binding.routing-key=some-key    # defaults to '#'
quarkus.rabbitmq.devservices.bindings.a-binding.destination=my-queue    # defaults to name of binding
quarkus.rabbitmq.devservices.bindings.a-binding.destination-type=queue  # defaults to 'queue'
quarkus.rabbitmq.devservices.bindings.a-binding.vhost=my-vhost          # defaults to '/'

The name of the binding is only used for the purposes of the Dev Services configuration and is not part of the binding defined in RabbitMQ.

Additionally, any additional arguments can be provided to the binding’s definition by using the arguments key:

quarkus.rabbitmq.devservices.bindings.a-binding.arguments.non-std-option=value

Enabling / disabling Dev Services for RabbitMQ
Broker compartido
Ajuste del puerto
Configuración de la imagen
Access the management UI
Predefined topology