Ansible Service Broker

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

Getting Started on Kubernetes

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.

Prerequisites:

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

Install

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 --kubernetes-version v1.9.3

# 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

Use

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

Getting Started on OpenShift

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.

Prerequisites

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.

Deploy an OpenShift Origin Cluster with the Ansible Service Broker

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

Versioning

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

Compatibility

APB Compatibility Matrix

ansible-service-broker	APB runtime 1	APB runtime 2
ansible-service-broker release-1.0, v3.7	✓	X
ansible-service-broker release-1.1, v3.9	✓	✓
ansible-service-broker HEAD	✓	✓

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 examime 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\" }}"

Contributing

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

License

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