Ansible Service Broker is an implementation of the Open Service Broker API that manages applications defined in Ansible Playbook Bundles. Ansible Playbook Bundles (APB) are a method of defining applications via a collection of Ansible Playbooks built into a container with an Ansible runtime with the playbooks corresponding to a type of request specified in the Open Service Broker API Specification.

Check out the Keynote Demo from Red Hat Summit 2017

Features

• Easily define, distribute, and provision microservice(s), like RocketChat and PostgreSQL, via ansible playbooks packaged in Ansible Playbook Bundles.
• Easily bind microservice(s) provisioned through Ansible Playbook Bundles, for example: Using the Service Catalog to Bind a PostgreSQL APB to a Python Web App.

Learn More:

• Documentation
• Our Trello Board
• Chat with us on IRC (Freenode): #asbroker
• Email us at [email protected] and subscribe to the Ansible Service Broker's mailing list
• Our YouTube Channel

Important Links

• Check out the ansible playbook bundle project and our library of example APBs
• catasb gives you more control over your development environment
• Amazon Web Services deployed into OpenShift via Ansible Service Broker
• Presentation Open Service Broker API + Ansible Service Broker/Ansible Playbook Bundles

Minikube makes it easy to get started with Kubernetes. Run the commands below individually or as a script to start a minikube VM that includes the service catalog and the broker. If you already have a Kubernetes cluster, skip the minikube command and proceed with the remaining ones as applicable.

• Install minikube and kubectl. Make sure minikube start and minikube delete are working.
• Install the helm binary.
• Clone the broker's GitHub repository

Run the following from the root of the cloned git repository.

#!/bin/env bash

# Adjust the version to your liking. Follow installation docs
# at https://github.com/kubernetes/minikube.
minikube start --bootstrapper kubeadm --kubernetes-version v1.9.4

# Install helm and tiller. See documentation for obtaining the helm
# binary. https://docs.helm.sh/using_helm/#install-helm
helm init

# Wait until tiller is ready before moving on
until kubectl get pods -n kube-system -l name=tiller | grep 1/1; do sleep 1; done

kubectl create clusterrolebinding tiller-cluster-admin --clusterrole=cluster-admin --serviceaccount=kube-system:default

# Adds the chart repository for the service catalog
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com

# Installs the service catalog
helm install svc-cat/catalog --name catalog --namespace catalog

# Wait until the catalog is ready before moving on
until kubectl get pods -n catalog -l app=catalog-catalog-apiserver | grep 2/2; do sleep 1; done
until kubectl get pods -n catalog -l app=catalog-catalog-controller-manager | grep 1/1; do sleep 1; done

./scripts/run_latest_k8s_build.sh

Once everything is installed, you can interact with the service catalog using the svcat command. Learn how to install and use it here.

There are a few different ways to quickly get up and running with a cluster + ansible-service-broker:

• oc cluster up
• Alternatively, you can use minishift and install the broker with our addon, documented here.

Let's walk through an oc cluster up based setup.

1. You will need a system setup for local OpenShift Origin Cluster Management

   • Your OpenShift Client binary (oc) must be >= v3.7.0-rc.0

2. If you are using minishift you should look at the minishift documentation to get the ansible service broker deployed and running.

• Starting with Origin v3.10 it's as simple as running oc cluster up --enable=service-catalog,automation-service-broker.
  • Running oc cluster up --enable will give you a full list of features. You may find it helpful to also add persistent-volumes, registry, rhel-imagestreams, router, etc.
  • You might also want to add a public-hostname and routing-suffix to make it easier to access your provisioned applications as well.
  • Complete example would look like oc cluster up --routing-suffix=172.17.0.1.nip.io --public-hostname=172.17.0.1.nip.io --enable=service-catalog,router,registry,web-console,persistent-volumes,rhel-imagestreams,automation-service-broker
  • An in depth demo is available at https://youtu.be/IY1RINVsO40

1. Download and execute our run_latest_build.sh script

   Origin Version 3.7:

   wget https://raw.githubusercontent.com/openshift/ansible-service-broker/master/scripts/run_latest_build.sh
   chmod +x run_latest_build.sh
   ./run_latest_build.sh
   

2. At this point you should have a running cluster with the service-catalog and the Ansible Service Broker running.

Provision an instance of MediaWiki and PostgreSQL

1. Log into OpenShift Web Console
2. Create a new project 'apb-demo'
3. Provision MediaWiki APB
   • Select the 'apb-demo' project
   • Enter a 'MediaWiki Admin User Password': 's3curepw'
   • Click 'Create'
4. Provision PostgreSQL APB
   • Select the 'apb-demo' project
   • Leave 'PostgreSQL Password' blank, a random password will be generated
   • Choose a 'PostgreSQL Version'; either version will work.
   • Click 'Next'
   • Select 'Do not bind at this time' and then 'Create'
5. Wait until both APBs have finished deploying, and you see pods running for MediaWiki and PostgreSQL

Bind MediaWiki to PostgreSQL

1. Bind MediaWiki to PostgreSQL
   • Click on kebab menu for PostgreSQL
   • Select 'Create Binding' and then 'Bind'
   • Click on the link to the created secret
   • Click 'Add to Application'
   • Select 'mediawiki123' and 'Environment variables'
   • Click 'Save'
2. View the route for MediaWiki and verify the wiki is up and running.
   • Observe that mediawiki123 is on deployment '#2', having been automatically redeployed

Our release versions align with openshift/origin. For more detailed information see our version document.

Key:

• ✓ Supported.
• X Will not work. Not supported.

Ansible Playbook Bundle images are built on the apb-base image. Starting with apb-base 1.1, a new APB runtime was introduced and captured in the label com.redhat.apb.runtime. Currently, there are two APB runtime versions:

• APB runtime 1 - all APBs tagged release-1.0 as well as APBs with no "com.redhat.apb.runtime" label.
• APB runtime 2 - all APBs tagged release-1.1 as well as APBs with label "com.redhat.apb.runtime"="2".

You can examine the runtime of a particular APB with docker inspect $APB --format "{{ index .Config.Labels \"com.redhat.apb.runtime\" }}". An APB without a "com.redhat.apb.runtime" label is APB runtime 1. For example:

$ docker inspect docker.io/ansibleplaybookbundle/mediawiki-apb:latest --format "{{ index .Config.Labels \"com.redhat.apb.runtime\" }}"
2

# No label on release-1.0
$ docker inspect docker.io/ansibleplaybookbundle/mediawiki-apb:release-1.0 --format "{{ index .Config.Labels \"com.redhat.apb.runtime\" }}"

First, start with the Contributing Guide.

Contributions are welcome. Open issues for any bugs or problems you may run into, ask us questions on IRC (Freenode): #asbroker, or see what we are working on at our Trello Board.

If you want to run the test suite, when you are ready to submit a PR for example, make sure you have your development environment setup, and from the root of the project run:

# Check your go source files (gofmt, go vet, golint), build the broker, and run unit tests
make check

# Get helpful information about our make targets
make help

Ansible Service Broker is licensed under the Apache License, Version 2.0.