Chapter 1. Introduction

You must prepare your APB’s directory structure and spec file before you can build and deploy it. The Getting Started topic provides a step by step tutorial on creating your first APB, while the following sections briefly cover this workflow.

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

version: 1.0
name: my-test-apb
description: This is a sample application generated by apb init
bindable: False
async: optional
metadata: 1
  displayName: my-test
plans:
  - name: default
    description: This default plan deploys my-test-apb
    free: True
    metadata: {}
    parameters: [] 2

The build step is responsible for building a container image from the named playbooks for distribution. Packaging combines a base image containing an Ansible runtime with Ansible artifacts and any dependencies required to run the playbooks.

The result is a container image with an ENTRYPOINT set to take in several arguments, one of which is the method to execute, such as provision and deprovision.

Figure 1.1. APB Build

Deploying an APB means invoking the container and passing in the name of the playbook to execute along with any required variables. It is possible to invoke the APB directly without going through the OAB. Each APB is packaged so its ENTRYPOINT will invoke Ansible when run. The container is intended to be short-lived, coming up to execute the Ansible playbook for managing the application then exiting.

In a typical APB deploy, the APB container will provision an application by running the provision.yml playbook, which executes an Ansible role. The role is responsible for creating the OpenShift Container Platform resources, perhaps through calling oc create commands or leveraging Ansible modules. The end result is that the APB runs Ansible to talk to OpenShift Container Platform to orchestrate the provisioning of the intended application.

The following diagrams illustrate this deployment flow in two phases: a user discovering a list of available APBs and then requesting their chosen APB be provisioned to their project:

Figure 1.2. Listing Available APBs

An OpenShift Container Platform user is interested in provisioning a service into their project, so they interact with the service catalog by accessing the OpenShift Container Platform UI (web console or CLI) to discover any APBs that are already available.

The service catalog requests a list of APBs from the OAB to show the user.

The OAB searches all configured container registries (the cluster’s OpenShift Container Registry or any other remote registry) for any APBs (images with a specific label, for example LABEL=apb-1.0).

The OAB returns the discovered list to the service catalog, to be viewed by the user in the OpenShift Container Platform UI.

Figure 1.3. Deploying a Chosen APB

The user now chooses an APB from the discovered list provided by the service catalog.

The service catalog communicates with the OAB that the user has requested use of the chosen APB.

The OAB initiates the image pull from the appropriate container image registry.

After the image is pulled, the OAB defers the logic for orchestrating the application to the APB. The service is deployed by running the APB container with a few parameters. To do so, the following command is issued against the OpenShift Container Platform cluster in a temporary namespace:

$ oc run $IMAGE $METHOD $VARS ansible-playbook ${METHOD}.yaml ${VARS}

To break this command down further:

As a result, the user views via the OpenShift Container Platform UI that their requested service has been successfully provisioned in their project.