RabbitMQ for PCF
RabbitMQ for PCF enables PCF app developers to provision and use the RabbitMQ message broker with a single command.
RabbitMQ for PCF v1.8 supports two types of service, an on-demand service and a pre-provisioned service. This table summarizes the main differences between the two:
|Available Since||VMs it Runs On||How VMs are Created||Metrics Name Prefix|
|On-Demand Service||New for v1.8||Dedicated VM that serves a single service instance||PCF creates each VM on-demand when app developer creates service instance||
|Pre-Provisioned Service||v1.2||Multi-tenant VMs shared by apps across PCF deployment||PCF creates all VMs when operator deploys or updates service||
This RabbitMQ for PCF v1.8 documentation describes both service types. Documentation for RabbitMQ for PCF v1.7 and earlier only describes a pre-provisioned service.
For PCF RabbitMQ versions before v1.8.0, the RabbitMQ Service instances correspond to a unique RabbitMQ Vhost on the multi-tenant RabbitMQ cluster. RabbitMQ for PCF v1.8.0 introduced On-Demand Broker (ODB) support. That means that a new, single-tenant, cluster can be created and dedicated to a single app.
RabbitMQ is a fast and dependable open-source message server, which supports a wide range of use cases including reliable integration, content-based routing and global data delivery, and high-volume monitoring and data ingestion.
Emerging as the de facto standard for cloud messaging, RabbitMQ is used for efficient communication between servers, applications and devices, and creates lasting value by enabling rapid development of modern decentralized application and data architectures that can scale with your business needs.
The following table provides version and version-support information about RabbitMQ for PCF.
|Release date||February 26, 2018|
|Software component version||RabbitMQ OSS v3.6.15|
|Compatible Ops Manager version(s)||v1.9.x, 1.10.x|
|Compatible Elastic Runtime version(s)||v1.9.x, 1.10.x|
|IaaS support||AWS, Azure, GCP, OpenStack, and vSphere|
- Provision on-demand single node dedicated instances of RabbitMQ
- Emit metrics for Dedicated Instances
- Provision an instance of the RabbitMQ service, which corresponds to a unique RabbitMQ Vhost (virtual host)
- Bind applications to an instance of the plan, providing unique credentials for each binding
- Management dashboard access to PCF Operators and application developers
- Deployment across multiple availability zones, with nodes striped across the AZs automatically
- Enable SSL (Secure Sockets Layer) for the AMQP, MQTT, STOMP protocols
- HAProxy load balancer across all nodes to balance connections
- Plugin configuration can be easily changed at any time and the cluster redeployed and updated
- The cluster topology can be changed and easily scaled out
- Automated upgrades of RabbitMQ for major, minor and patch releases (see release notes for downtime requirements)
- Configure the end point for the RabbitMQ Syslog
- RabbitMQ and HAProxy metrics are exposed on the firehose
- Enable operators to select
- Metrics are not emitted if RabbitMQ for PCF v1.8.x is installed on Ops Manager v1.11.0. or later.
- Smoke tests fail if SSL/TLS is configured for your RabbitMQ cluster.
nameis namespaced with
/p-rabbitmq(this should be
- Cluster scaling or changing Erlang Cookie require downtime in deployments.
- IPsec does not work with this version of the tile, and it must be installed into a non-IPsec subnet or by excluding the deployment IPs following the steps in the documentation.
- As of Ops Manager v10.0.0, errands set to the When Changed rule do not always run when the tile has relevant changes. For more information, see Errands. One-time rules should be set when using Ops Manager 1.10.7 or earlier to ensure that Update All Service Instances is run.
- Changing networks an/or IP addresses for the
RabbitMQ Serverjob results in a failed upgrade deployment. For details, see this page.
- RabbitMQ for PCF v1.8.12 and earlier has a bug that does not delete management users,
mu-*, when a service is deleted. To automate deletion of these users, contact Pivotal Support.
Some PCF services offer on-demand service plans. These plans let developers provision service instances when they want.
These contrast with the more common pre-provisioned service plans, which require operators to provision the service instances during installation and configuration through the service tile UI.
The following PCF services offer on-demand service plans:
MySQL for PCF v2.0 and later
RabbitMQ for PCF
Redis for PCF
Pivotal Cloud Cache (PCC)
These services package and deliver their on-demand service offerings differently. For example, some services, like Redis for PCF, have one tile, and you configure the tile differently depending on whether you want on-demand service plans or pre-provisioned service plans.
For other services, like PCC, you install one tile for on-demand service plans and a different tile for pre-provisioned service plans.
The following table lists and contrasts the different ways that PCF services package on-demand and pre-provisioned service offerings.
|PCF service tile||Standalone product related to the service||Versions supporting on demand||Versions supporting pre-provisioned|
|RabbitMQ for PCF||Pivotal RabbitMQ||v1.8 and later||All versions|
|Redis for PCF||Redis||v1.8 and later||All versions|
|MySQL for PCF||MySQL||v2.x
(based on Percona Server)
(based on MariaDB and Galera)
|PCC||Pivotal GemFire||All versions||NA|
|GemFire for PCF||Pivotal GemFire||NA||All versions|
Please provide any bugs, feature requests, or questions to the PCF Feedback list.