RabbitMQ

Warning

The above example uses secrets as plain strings. It is recommended to use a secret store for the secrets as described .

Spec metadata fields

To configure communication using TLS, ensure that the RabbitMQ nodes have TLS enabled and provide the caCert, clientCert, clientKey metadata in the component configuration. For example:

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Component
  3. metadata:
  4.   name: rabbitmq-pubsub
  5. spec:
  6.   type: pubsub.rabbitmq
  7.   version: v1
  8.   metadata:
  9.   - name: host
  10.     value: "amqps://localhost:5671"
  11.   - name: consumerID
  12.     value: myapp
  13.     value: false
  14.   - name: deletedWhenUnused
  15.     value: false
  16.   - name: autoAck
  17.     value: false
  18.   - name: deliveryMode
  19.     value: 0
  20.   - name: requeueInFailure
  21.     value: false
  22.   - name: prefetchCount
  23.     value: 0
  24.   - name: reconnectWait
  25.     value: 0
  26.   - name: concurrencyMode
  27.     value: parallel
  28.   - name: publisherConfirm
  29.     value: false
  30.   - name: enableDeadLetter # Optional enable dead Letter or not
  31.     value: true
  32.   - name: maxLen # Optional max message count in a queue
  34.     value: 10485760
  35.   - name: exchangeKind
  36.     value: fanout
  37.   - name: caCert
  38.     value: ${{ myLoadedCACert }}
  39.   - name: clientCert
  40.     value: ${{ myLoadedClientCert }}
  41.   - name: clientKey
  42.     secretKeyRef:
  43.       name: myRabbitMQClientKey
  44.       key: myRabbitMQClientKey

Note that while the caCert and clientCert values may not be secrets, they can be referenced from a Dapr secret store as well for convenience.

The RabbitMQ pub/sub component has no built-in support for retry strategies. This means that the sidecar sends a message to the service only once. When the service returns a result, the message will be marked as consumed regardless of whether it was processed correctly or not. Note that this is common among all Dapr PubSub components and not just RabbitMQ. Dapr can try redelivering a message a second time, when autoAck is set to false and requeueInFailure is set to true.

To make Dapr use more sophisticated retry policies, you can apply a to the RabbitMQ pub/sub component.

  1. When using autoAck = false and requeueInFailure = true, RabbitMQ is the one responsible for re-delivering messages and any subscriber can get the redelivered message. If you have more than one instance of your consumer, then it’s possible that another consumer will get it. This is usually the better approach because if there’s a transient failure, it’s more likely that a different worker will be in a better position to successfully process the message.
  2. Using Resiliency makes the same Dapr sidecar retry redelivering the messages. So it will be the same Dapr sidecar and the same app receiving the same message.

Create a RabbitMQ server

You can run a RabbitMQ server locally using Docker:

You can then interact with the server using the client port: localhost:5672.

The easiest way to install RabbitMQ on Kubernetes is by using the :

  1. helm install rabbitmq stable/rabbitmq

Look at the chart output and get the username and password.

This will install RabbitMQ into the default namespace. To interact with RabbitMQ, find the service with: kubectl get svc rabbitmq.

rabbitmq.default.svc.cluster.local:5672

Setting exchangeKind to "topic" uses the topic exchanges, which are commonly used for the multicast routing of messages. Messages with a routing key will be routed to one or many queues based on the routing key defined in the metadata when subscribing. The routing key is defined by the routingKey metadata. For example, if an app is configured with a routing key keyA:

It will receive messages with routing key keyA, and messages with other routing keys are not received.

  1. // publish messages with routing key `keyA`, and these will be received by the above example.
  2. client.PublishEvent(context.Background(), "pubsub", "B", []byte("this is a message"), dapr.PublishEventWithMetadata(map[string]string{"routingKey": "keyA"}))
  3. // publish messages with routing key `keyB`, and these will not be received by the above example.
  4. client.PublishEvent(context.Background(), "pubsub", "B", []byte("this is another message"), dapr.PublishEventWithMetadata(map[string]string{"routingKey": "keyB"}))

Bind multiple routingKey

Multiple routing keys can be separated by commas.
The example below binds three routingKey: keyA, keyB, and "". Note the binding method of empty keys.

For more information see rabbitmq exchanges.