LATEST VERSION: 0.16.0 - CHANGELOG

Creating an On-Demand Service Tile

This documents the process for deploying an on-demand broker (ODB) with a service in a single tile, on a AWS installation of Ops Manager 1.8. We have built a reference Kafka tile.

Requirements

Before ODB, Ops Manager controlled the IP allocation of the private networks. So when using the ODB in a tile, you will need at least two private networks:

  • a network where Ops Manager will deploy the on-demand broker VM
  • a different network where the on-demand broker will deploy service instance VMs

The network for service instances should be flagged as a Service Network in Ops Manager.

Deploying Ops Manager to AWS

  1. Follow the default Ops Manager deployment docs, but with these modifications:
    1. Create a self-signed wildcard SSL certificate for a domain you control: This will usually be *.some-subdomain.cf-app.com, and upload it (along with the associated private key) to AWS. Instructions here.
    2. Download the CloudFormation JSON and save it in the Ops Manager directory.
    3. Run the CloudFormation stack, saving any pertinent inputs (e.g BOSH DB credentials) you type into the web console into the Ops Manager directory for safe keeping (e.g. in info.txt).
    4. Launch an instance of the AMI. If possible, use an elastic IP so that we can always keep the same DNS record even if we recreate the VM. Failing that, auto-assign a public IP.
    5. Create a DNS record for pcf.<the domain you made a wildcard cert for earlier>. To use the earlier example, the record will be for pcf.some-subdomain.cf-app.com. It should point to the public IP of the Ops Manager VM.
  2. Keep following the docs to log into Ops Manager (save the credentials).
  3. Configure the Ops Manager director (BOSH) tile.
  4. Click “Apply Changes”, and steal the BOSH init manifest for future reference. scp -i private_key.pem ubuntu@opsmanIP:/var/tempest/workspaces/default/deployments/bosh.yml bosh.yml

Notes:

  1. The ELBs created by CloudFormation are both for CF, not Ops Manager. One of them will be configured with your wildcard certificate. This takes the place of HAProxy in AWS PCF deployments, and is therefore not used until you deploy the ERT tile.
  2. To target the bosh director from the Ops Manager VM: bosh --ca-cert /var/tempest/workspaces/default/root_ca_certificate target 10.0.16.10

Build a Tile

Follow the default build your own Product tile documentation, enhance the handcraft.yml with the accessors listed below. To access the $self accessors, the service-broker flag must be true in the handcraft.

Non-Exhaustive Accessors Reference

director

Used to provide fields relating to the BOSH director installation present.

Accessor Description
$director.hostname The director’s hostname or IP address
$director.ca_public_key The director’s root ca certificate. Related: how to configure SSL certificates for the ODB.

For example

bosh:
  url: https://(( $director.hostname )):25555
  root_ca_cert: (( $director.ca_public_key ))

self

Used to provide fields that belong to the specific tile (in this case, the broker tile).

Accessor Description
$self.uaa_client_name UAA client name, that can authenticate with the BOSH director
$self.uaa_client_secret UAA client secret, that can authenticate with the BOSH director
$self.service_network Service network configured for the on-demand instances

The service network has to be created manually. Create a subnet on AWS and then add it to the director. In the director tile, under Create Networks > ADD network > fill in the subnet/vpc details.

$self accessors are enabled by setting service_broker: true at the top level of handcraft.yml. Please note that, at the time of writing this, setting service_broker: true will cause a redeployment of the BOSH director when installing or uninstalling the tile.

For example

bosh:
  authentication:
    uaa:
      url: https://(( $director.hostname )):8443
      client_id: (( $self.uaa_client_name ))
      client_secret: (( $self.uaa_client_secret ))

cf

Used to provide fields from the Elastic Runtime Tile (i.e. Cloud Foundry) present in the Ops Manager installation.

Accessor Description
..cf.ha_proxy.skip_cert_verify.value Flag to skip SSL certificate verification for connections to the CF API
..cf.cloud_controller.apps_domain.value The application domain configured in the CF installation
..cf.cloud_controller.system_domain.value The system domain configured in the CF installation
..cf.uaa.system_services_credentials.identity Username of a CF user in the cloud_controller.admin group, to be used by services
..cf.uaa.system_services_credentials.password Password of a CF user in the cloud_controller.admin group, to be used by services

For example

disable_ssl_cert_verification: (( ..cf.ha_proxy.skip_cert_verify.value ))
cf:
  url: https://api.(( ..cf.cloud_controller.system_domain.value ))
  authentication:
    url: https://uaa.(( ..cf.cloud_controller.system_domain.value ))
    user_credentials:
      username: (( ..cf.uaa.system_services_credentials.identity ))
      password: (( ..cf.uaa.system_services_credentials.password ))

Reference

For more accessors you can see the ops-manager-example product

Public IP address for on-demand service instance groups

Ops Manager 1.9 RC1+ provides a VM extension called public_ip in the BOSH Director’s cloud config. This can be used in the on-demand service broker’s manifest to give instance groups a public IP address. This IP is only used for outgoing traffic to the internet from VMs with the public_ip extension. All internal traffic / incoming connections need to go over the private IP.

Here is an example showing how to allow operators to assign a public IP address to an on-demand service instance group in the tile handcraft:

form_types:
- name: example_form
  property_inputs:
  - reference: .broker.example_vm_extensions
    label: VM options
    description: List of VM options for Service Instances

job_types:
- name: broker
  templates:
  - name: broker
    release: on-demand-service-broker
    manifest: |
      service_catalog:
        plans:
        - name: example-plan
          instance_groups:
          - name: example-instance-group
            vm_extensions: (( .broker.example_vm_extensions.value ))
  property_blueprints:
  - name: example_vm_extensions
    type: multi_select_options
    configurable: true
    optional: true
    options:
    - name: "public_ip"
      label: "Internet Connected VMs (on supported IaaS providers)"

On-Demand Broker errands

In the reference Kafka tile we have demonstrated how the errands in the on-demand broker release can be used.

The errands should be specified in the following order, as shown in the example Kafka tile:

Post-deploy:

  • register-broker
  • upgrade-all-service-instances

Pre-delete:

  • delete-all-service-instances
  • deregister-broker

These errands are documented in the operating section.

Create a pull request or raise an issue on the source for this page in GitHub