RabbitMQ® for Pivotal Cloud Foundry Documentation
RabbitMQ is a fast and dependable open-source message server that 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 Pivotal Cloud Foundry (PCF) installer enables cloud operators to deploy a RabbitMQ service in PCF. You can deploy the service as a single node or a cluster.
The following table provides version and version-support information about RabbitMQ for PCF:
|Release date||March 31, 2017|
|Software component version||RabbitMQ OSS v3.6.9|
|Compatible Ops Manager version(s)||v1.8.x, v1.9.x, v1.10.x|
|Compatible Elastic Runtime version(s)||v1.8.x, v1.9.x, v1.10.x|
|IaaS support||AWS, Azure, GCP, OpenStack, and vSphere|
Upgrading to the Latest Version
Upgrades are normally a rolling deployment unless otherwise noted in the release notes.
Consider the following compatibility information before upgrading RabbitMQ for Pivotal Cloud Foundry.
Note: Any tile upgrading to RabbitMQ v3.6.9 or later will require downtime as the RabbitMQ cluster cannot run in mixed-mode with versions lower than v3.6.9.
Note: Any tile upgrading to RabbitMQ v3.6.6 or later will require downtime as the RabbitMQ cluster cannot run in mixed-mode with versions lower than v3.6.6.
Note: Pivotal recommends that customers always upgrade to the latest patch version of their minor line, and then only upgrade to the latest available new minor patch. This is to ensure that RabbitMQ or Erlang versions are not downgraded during the process.
Note: You can only upgrade this tile from v1.6.5 or later. This must be completed before upgrading from Ops Manager v1.7x to v1.8.x.
Note: Customers with v1.6.6 of the tile can upgrade to v1.7.0 or later.
Note: Customers with v1.6.7-9 of the tile should only upgrade to v1.7.4 or later.
Note: Customers with v1.6.10 or later of the tile should only upgrade to v1.7.7 or later.
Note: All customers upgrading from v1.6.x to v1.6.5 or later versions of the tile should read the Additional upgrade steps for customers going from v1.6.x to v1.6.5 document located with the release on https://network.pivotal.io/products/pivotal-rabbitmq-service.
For more information, see the full Product Compatibility Matrix.
|Ops Manager Version||Supported Upgrades from Imported RabbitMQ Installation|
|v1.6.x and v1.5.x||
- 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
Install via Pivotal Ops Manager
To install RabbitMQ for PCF, follow the procedure for installing Pivotal Ops Manager tiles:
- Download the product file from Pivotal Network.
- Upload the product file to your Ops Manager installation.
- Click Add next to the uploaded product description in the Ops Manager
Available Productsview to add this product to your staging area.
- Click the newly added tile to review any configurable options.
- Click Apply Changes to install the service.
This product requires Ops Manager v1.7.0 or later.
Using RabbitMQ in your application
RabbitMQ is shown in the services marketplace, either in the Apps Manager or
cf marketplace on the CLI.
Application developers can create an instance of the application with
cf create-service p-rabbitmq standard <your name>.
For this service an instance equals a Vhost on the RabbitMQ cluster.
Creating a binding gives the user permissions to access this Vhost and associated management dashboard.
Limitations with the current RabbitMQ for PCF product include:
- Availability Zone configuration cannot be changed once deployed.
- 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.
We hope to address all of these limitations in future releases.
- In versions
1.5.1, when performing a fresh installation or upgrade, if the Elastic Runtime system and application domains are different then the
Broker Registrarerrand will fail. To resolve this disable the errand and redeploy, then register the broker manually using the system domain route
pivotal-rabbitmq-broker.system.domain. For more information on registering brokers see the CloudFoundry documentation.
- In the
1.5.0, 1.5.1, 1.5.2, 1.5.3releases, when performing a fresh installation or upgrade, if you have the rabbitmq_jsonrpc_channel or rabbitmq_jsonrpc_channel_examples plugins selected then the RabbitMQ nodes will fail to start. The plugins are no longer distributed with RabbitMQ and plugin validation was introduced in RabbitMQ
3.5.7, causing the nodes to fail to start. To resolve this issue you should install or upgrade to version
1.5.4or later of the tile.
- In the
1.6.xtiles it is not possible to install the RabbitMQ tile in multiAZ with multi-subnet networks.
- It is not currently possible to set the HAproxy instance count to 0.
- IPsec is not required for the RabbitMQ tile since it can be secured via TLS, which will encrypt traffic from clients to the RabbitMQ cluster. RabbitMQ should be deployed in its own subnet outside the IPsec mesh. Refer to the documentation to set up TLS.
- In rare circumstances when manually stopping all RabbitMQ nodes in a cluster, it is possible for all queue masters to reside on the last node to be stopped. This is a known limitation in RabbitMQ and should you encounter it please contact support.
Please provide any bugs, feature requests, or questions to the Pivotal Cloud Foundry Feedback list.