Getting started with Ansible Playbook Bundles on CDK

Install Ansible Service Broker addon into your CDK installation

Start your CDK environment with registration (important as yum get’s used during addon installation)

export MINISHIFT_ENABLE_EXPERIMENTAL=y
minishift start --service-catalog

Clone the addon repository and install Ansible Service Broker addon:

git clone https://github.com/minishift/minishift-addons.git
cd minishift-addons/add-ons/
minishift addon install ansible-service-broker
minishift addon apply ansible-service-broker

When logging in to your CDK console you should already see the preinstalled APB’s:

Install the ABP command line on your client machine

Configure your shell to use the minishift Docker daemon

eval $(minishift docker-env)

Fetch the APB command line script and make it available in your PATH

wget https://raw.githubusercontent.com/ansibleplaybookbundle/ansible-playbook-bundle/master/scripts/apb-docker-run.sh && mv apb-docker-run.sh apb && chmod +x apb

Verify that your installation works

apb --help

If everything went well you should see something like this:

Test the connection between ABP CLI and CDK

You will need special permissions to work with the broker on your CDK installation. Therefore we need to execute the following:

oc login -u system:admin
oc adm policy add-cluster-role-to-user cluster-admin developer
oc login -u developer

Now let’s see if we can list the preinstalled APB’s:

apb list

Configure Ansible Service Broker to pull images from local registry

In the default config of our Ansible Service Broker the APB’s are pulled from “https://registry.hub.docker.com/”. We need to change this to our local registry running within CDK.

registry:
  - type: local_openshift
    name: lo
    namespaces:
      - openshift
    white_list:
      - ".*-apb$"

The Ansible Service Broker pod now needs to be restarted in order to pull in the new configuration.

Create your first APB

Firstly we use the CLI to scaffold our new service:

apb init sample-service-apb
cd sample-service-apb

Now we locally build our APB. After the process has completed, the newly build APB docker image should appear in your local docker registry:

apb build

Finally we need to push the Docker image to our Service Broker inside CDK:

apb push

Now you should be able to see your first APB in your CDK’s service catalog.

Reference Information

Ansible Playbook Documentation

Getting started with APB development

Minishift Addon – Ansible Service Broker

Ansible Service Broker Configuration

How to set up wordpress on OpenShift in 10 minutes

What this is about?

A lot of customers would like to give the brave new container world (based on Docker technology) a try with real life workload. The WordPress content management system (yes, it has become more than a simple blog) seems to be an application that many customers know and use (and that I’ve been asked for numerous times). From a technical point of view the WordPress use case is rather simple, since we only need a PHP runtime and a database such as MySQL. Therefore it is a perfect candidate to pilot container aspects on OpenShift Container Platform.

Preparation

Install Container Development Kit

I highly recommend to install the freely available Red Hat Container Development Kit (shortly CDK). It will give you a ready to use installation of OpenShift Container Platform based on a Vagrant image. So you’re up to speed in absolutely no time:

Please follow the installation instructions here: https://developers.redhat.com/products/cdk/get-started/

Setup resources on OpenShift

Spin up your CDK environment and ssh into the system:

vagrant up
vagrant ssh

Create a new project and import the template for an ephemeral MySQL (since this is not included in the CDK V2.3 distribution by default). If you prefer to use another database or even one with persistent storage, then you can find additional templates here.

oc new-project wordpress
oc create -f https://raw.githubusercontent.com/openshift/openshift-ansible/master/roles/openshift_examples/files/examples/v1.3/db-templates/mysql-ephemeral-template.json

Now we create one pod for our MySQL database and create our WordPress application based on the source code. OpenShift will automatically determine that it is based on PHP and will therefore choose the PHP builder image to create a Docker image from our WordPress source code.

oc new-app mysql-ephemeral
oc new-app https://github.com/wordpress/wordpress
oc expose service wordpress

Now let’s login to the OpenShift management console and see what has happened:

We now have a pod that runs our WordPress application (web server, PHP, source code) and one pod running our ready to use ephemeral (= non-persistent) MySQL database.

Install wordpress

Before we need to note down the connection settings for our MySQL database. Firstly we look up the cluster IP of our mysql service; secondly we look up the database name, username & password. Have a look at the following screenshots:

Now it is time to setup and configure wordpress. Simply click on the route that has been created for your wordpress pod (in my case the hostname is “http://wordpress-wordpress.rhel-cdk.10.1.2.2.xip.io/wp-admin/setup-config.php”).

Congratulations for installing WordPress on OpenShift!

What’s next

For now we’ve created all the resources manually in a not yet reusable fashion. Therefore one of the next steps could be to create a template from our resources, import it into the OpenShift namespace and make it available for our users as a service catalog item. So our users could provision a fully installed WordPress with the click of a button.

OpenShift Quicktip: Testdriving persistent storage with NFS

Creating a persistent volume for NFS storage plugin

The administrator is responsible for creating volumes (PV). The administrator assigns some external thing (partition, entire device, NFS volume, whatever) to a PV.

Login to OpenShift with an admin user
Create persistent volume:

oc create -f persistent-volume-nfs.yaml

Check status of persistent volume:

oc get pv

Creating a persistent volume claim

The end-user/developer/user/whatever is responsible for making a request for a volume (PVC). They get assigned some volume, and they don’t really know what it is. Keep in mind that there is a 1:1 mapping between PV and PVCs.

Login to OpenShift
Create persistent volume claim:

oc create -f persistent-volume-claim.yaml

The source code can be found on my Github page: https://github.com/sebastianfaulhaber/openshift-v3-showcase/tree/master/openshift-resources

OpenShift Quicktip: Limiting resource consumption for users

A. Resource limits

Resource limits allow you to set boundaries (max/min & default) for the compute resources a developer can define on pod/container level (see https://docs.openshift.com/enterprise/3.1/dev_guide/compute_resources.html).

Login to OpenShift with an admin user
Change to target project with

oc project <my-project>

Import limit range (see https://docs.openshift.com/enterprise/3.1/dev_guide/limits.html on what options are available)

oc create -f limit-range.json

Browse to OpenShift admin console, select the project and then “Settings”.

B. Quotas

A quota allows you to set hard limits on the overall resource consumption on project level. This is in particular useful to create a t-shirt size based accounting model (small, medium, large) for OpenShift. See also https://docs.openshift.com/enterprise/3.1/dev_guide/quota.html.

Login to OpenShift with an admin user
Change to target project with

oc project <my-project>

Create quota for project:

oc create -f resource-quota.json

Browse to OpenShift admin console, select the project and then “Settings”.

The source code can be found on my Github page: https://github.com/sebastianfaulhaber/openshift-v3-showcase/tree/master/openshift-resources