RabbitMQ for PCF v1.9.16

Installing and Configuring RabbitMQ for PCF as an On-Demand Service

This topic provides instructions to Pivotal Cloud Foundry (PCF) operators about how to install, configure, and deploy the RabbitMQ for PCF tile to provide on-demand service.

Note: For instructions on how to install, configure, and deploy the RabbitMQ for PCF tile as a pre-provisioned service, see the documentation for pre-provisioned RabbitMQ for PCF.

Prerequisites for Deploying the On-Demand Service

Before deploying RabbitMQ for PCF as an on-demand service, you must ensure that the required network rules are in place to allow various components to communicate.

See Required Networking Rules for On-Demand Services for details on the network connections that must be open to enable the on-demand service.

For information on the on-demand service architecture, see this page.

Download and Install RabbitMQ for PCF

  1. Download the product file from Pivotal Network.

  2. Navigate to the Ops Manager Installation Dashboard and click Import a Product to upload the product file.

  3. Under the Import a Product button, click + next to the version number of RabbitMQ for PCF. This adds the tile to your staging area.

  4. Click the newly added RabbitMQ for PCF tile to configure the service.

Configure RabbitMQ for PCF

The configuration screen appears when you click the RabbitMQ for PCF tile in Ops Manager:

Configuring Errand Run Rules

Configure AZs and Networks

Follow the steps below to configure the AZs and networks.

  1. Click Assign AZs and Networks.

    Important: You cannot change the regions or networks after you have clicked Apply Changes in the final step below.

  2. Configure the fields on the Assign AZs and Networks as follows:

    Place singleton jobs in Select the region that you want for singleton VMs. PCF creates the RabbitMQ broker in this AZ.
    Balance other jobs in Select additional region. This selection does not affect the on-demand RabbitMQ for PCF service.
    Network Select a network for the RabbitMQ On-Demand Broker.

    This should be a separate network from the one you select for Service Network. This network is represented by the Default Network in this picture. Typically, you select the network used for the Pivotal Elastic Runtime components.
    Service Network Select a separate network that the on-demand service instances run on.

    A typical practice is to put all on-demand services on a single network, separate from the network that ERT and the On-Demand Broker run on.
    This network is represented by the Services Network in this picture.

    This field is also required for the pre-provisioned service, though in that case, it doesn’t matter which network you select.

    WARNING: Changing the Network or Service Network, or changing their IP configurations, results in a failed deployment. For more information, see Changing Network or IP Addresses Results in a Failed Deployment.

  3. Click Save.

Configure Global Settings

Follow the steps below to configure global settings.

  1. Click Dedicated Instance: Global Settings and configure the following:

    • Service instance quota min: 0, max: 50 set the total number of dedicated service instances which can be deployed.

    • VM options:

      Allow outbound internet access (IaaS-dependent). This checkbox must be ticked to allow external log forwarding, sending backup artifacts to external destinations, and communicating with an external BOSH blob store.
  2. Click Save.

Configure the Service Plan

In order to enable the on-demand service plan, you must configure the Dedicated Instance: Single Node Plan. The default name of this plan is Solo.

This plan deploys a single RabbitMQ node on a single virtual machine.

Note: If the on demand plans are not enabled, the RabbitMQ On Demand Broker VM is deployed alongside the RabbitMQ installation, but the plans will not be available in the Marketplace.

  1. Click Dedicated Instance: Single Node Plan.


  2. Configure the fields on the Dedicated Instance: Single Node Plan as follows:

    Enable this plan Select the checkbox.
    Service instance quota Enter the maximum number of dedicated service instances that can be available at one time.
    Plan name Accept the default or enter a name. This is the name that appears in the Marketplace.
    Plan description Accept the default or enter a description.
    Plan features Accept the default or enter information about the plan to help your app developers.
    RabbitMQ VM Type Select a large VM type.
    The plan will create a service instance of this size.
    Persistent disk type This is where RabbitMQ will page messages to disk. See Disk Size Concerns for more details.
    AZ placement This field is available after you complete the Assign AZs and Networks page.
    Select one AZ for the single node. The plan creates all the on-demand service instance VMs in this AZ.

  3. Click Save.

Resource Types and Disk Size Concerns

It is possible to configure the VM type for RabbitMQ and the size of the persistent disk that is going to be attached to the RabbitMQ instances.

Vm ram disk example

RabbitMQ raises alarms when disk space drops below the configured limit. Incorrect disk sizes may cause the deployed instance not to start. RabbitMQ declines to start if there is not enough space available according to the threshold.

Dedicated instances are configured with a threshold set to the 40% of the memory (RAM) of the VM. Operators can take the following table as an example when selecting the size of the persistent disk.

The following table shows an example of possible RAM values, absolute minimal value below which RabbitMQ declines to start, and the disk size suggested for an average use case.

RAM Free disk alarm threshold (0.4xRAM) Suggested disk size (2xRAM)
10 GB 4 GB 20 GB
16 GB 6.4 GB 32 GB
32 GB 12.8 GB 64 GB

For more information, see the following documentation links:

Verify the Stemcell

  1. Click Stemcell.

  2. Verify and, if necessary, import a new stemcell version.
    For more information, see the information about importing the stemcell for your IaaS: AWS, Azure, GCP, or vSphere.

Apply Changes from your Configuration

Your installation is not complete until you apply your configuration changes. Follow the steps below:

  1. Return to the Ops Manager Installation Dashboard.

  2. Click Apply Changes.

Configure Logging to Monitor RabbitMQ for PCF

Pivotal recommends that you configure logging to monitor the health of RabbitMQ for PCF. Follow this procedure to configure logging.


When deploying or updating RabbitMQ for PCF, Ops Manager can optionally run a series of post-deploy errands. An example is the Smoke Tests errand, which checks the health of the RabbitMQ cluster after a deploy or upgrade.

You can decide whether to run errands by toggling them on or off before an update. This is a one-time setting on the installation dashboard:

Configuring One-time Errands

IMPORTANT: As of RabbitMQ for PCF v1.9.0, all post-deploy errands are on by default. Pivotal recommends keeping these defaults, because the smoke tests can encounter unexpected issues, and dedicated instances of RabbitMQ for PCF may fall behind if the Upgrade All Service Instances errand is not on by default.

However, if necessary, you can change these defaults by clicking Errands in the RabbitMQ for PCF Settings tab.

For more information on errand run rules, see the Ops Manager documentation.

Post-Deploy Errands

Errand Description
Broker Registrar Makes the pre-provisioned RabbitMQ service plans available in the Marketplace
Smoke Tests Checks that a pre-provisioned RabbitMQ service instance can be bound to a Cloud Foundry app, and that the app can publish and subscribe to a RabbitMQ cluster (details below)
Register On-Demand Service Broker Makes the on-demand RabbitMQ service plans available in the Marketplace. If you change the Service Plan Configuration, you must run this errand in order for the changes to be reflected in the Marketplace.
Upgrade All Service Instances On-demand instances are updated and redeployed if there are changes to the Dedicated Instance settings or the tile is upgraded. If this errand is set to “Off” or “When Changed”, updates to Dedicated Instance settings will not be applied to existing service instances. Pivotal strongly recommends that this errand is configured to always run.

Pre-Delete Errands

Errand Description
Broker Deregistrar Removes the pre-provisioned RabbitMQ service from the Marketplace and deletes all associated service instances and bindings
Delete All Service Instances Unbinds and deletes existing dedicated service instances. The duration of this errand depends on the number of deployed dedicated instances.
Deregister On-Demand Service Broker Removes the on-demand RabbitMQ service from the Marketplace

Dedicated Instance Smoke Test Process

The smoke tests perform the following for each enabled service plan:

  1. Create and target the org smoke-test-org and the space smoke-test-space to run the tests.
  2. Deploy an instance of the CF RabbitMQ Example App in this cf space.
  3. Create the RabbitMQ cluster and bind it to the CF RabbitMQ Example App.
  4. Check that the CF RabbitMQ Example App can write to, and read from, the RabbitMQ service instance.
  5. Clean up the deployed Example App and all its service bindings.
  6. Delete the cf org and space created for the tests.

Create an Admin User for a Service Instance

If you want to give app developers admin privileges to the RabbitMQ Management UI, you can create an admin user for a service instance and share the user credentials with app developers.

Both operators and app developers can use this procedure.

To create an admin user on a RabbitMQ instance do the following:

  1. Run this command to create a service key:

    cf create-service-key SERVICE_INSTANCE SERVICE_KEY -c '{"tags": "administrator"}'


    SERVICE_INSTANCE is the name you supplied when you ran cf create-service
    SERVICE_KEY is a name you choose to identify the service key.

    For example:

    $ cf create-service-key my-instance my-admin-key -c '{"tags":"administrator"}'
    Creating service key my-admin-key for service instance my-instance as OK
  2. Run this command to get the admin user credentials:

    cf service-key SERVICE_INSTANCE SERVICE_KEY where the variables are the same as above.

    This returns a Dashboard URL containing the admin credentials, which can be used to access the management UI. For example:

    $ cf service-key my-instance my-admin-key
    Getting key my-admin-key for service instance my-instance as { "dashboard_url": "", "username": "admin-username", "password": "admin-password", ... }
Create a pull request or raise an issue on the source for this page in GitHub