OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Ansible Service Broker

Overview

Enabling the Ansible service broker is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

For more information on Red Hat Technology Preview features support scope, see https://access.redhat.com/support/offerings/techpreview/.

To opt-in during installation, see Advanced Installation.

The Ansible service broker (ASB) is an implementation of the OSB API that manages applications defined by Ansible playbook bundles (APBs). APBs provide a new method for defining and distributing container applications in OpenShift Container Platform, consisting of a bundle of Ansible playbooks built into a container image with an Ansible runtime. APBs leverage Ansible to create a standard mechanism for automating complex deployments.

The design of the ASB follows this basic workflow:

  1. A user requests list of available applications from the service catalog using the OpenShift Container Platform web console.

  2. The service catalog requests the ASB for available applications.

  3. The ASB communicates with a defined container registry to learn which APBs are available.

  4. The user issues a request to provision a specific APB.

  5. The provision request makes its way to the ASB, which fulfills the user’s request by invoking the provision method on the APB.

Ansible Playbook Bundles

An Ansible playbook bundle (APB) is a lightweight application definition that allows you to leverage existing investment in Ansible roles and playbooks.

APBs use a simple directory with named playbooks to perform OSB API actions, such as provision and bind. Metadata defined in apb.yml spec file contains a list of required and optional parameters for use during deployment.

Directory Structure

The following shows an example directory structure of an APB:

example-apb/
├── Dockerfile
├── apb.yml
└── roles/
│   └── example-apb-openshift
│       ├── defaults
│       │   └── main.yml
│       └── tasks
│           └── main.yml
└── playbooks/
    └── provision.yml
    └── deprovision.yml
    └── bind.yml
    └── unbind.yml

Spec File

An APB spec file (apb.yml) must be edited for your specific application. For example, the etherpad-apb spec file looks as follows:

name: fusor/etherpad-apb
description: Note taking web application
bindable: true
async: optional
parameters:
  - name: hostport
    description: The host TCP port as the external endpoint
    type: int
    default: 9001
  - name: db_user
    description: Database User
    type: string

For an APB that does not have any parameters, the parameters field should be blank:

parameters: []

Actions

The following are the actions for an APB. At a minimum, an APB must implement the provision and deprovision actions.

provision.yml

Playbook called to handle installing application to the cluster.

deprovision.yml

Playbook called to handle uninstalling.

bind.yml

Playbook to grant access to another service to use this service. For example, generating credentials.

unbind.yml

Playbook to revoke access to this service.

The required named playbooks correspond to methods defined by the OSB API. For example, when the ASB needs to provision an APB, it will execute the provision.yml.

After the required named playbooks have been generated, the files can be used directly to test management of the application. A developer may want to work with this directory of files, make changes, run, and repeat until they are satisfied with the behavior. They can test the playbooks by invoking Ansible directly with the playbook and any required variables.