Deploying Services to Cloud Foundry Using Kubernetes: Less BOSH, More Freedom

by Alexey Zakharov and Carlo GutierrezJune 6, 2018

Using Kubernetes to host services, developers can deploy services on Cloud Foundry without the need for BOSH releases.

Table of Contents

A common way to deploy services on Cloud Foundry

In Cloud Foundry environments, services are commonly deployed as BOSH releases. Service brokers can then be implemented either on top of BOSH or on top of Cloud Foundry. While this is a common method for deploying services in Cloud Foundry, what happens when a BOSH release for a particular service isn’t available? In this case, a developer will have to create his or her own BOSH release.

User applications are bound to services through service brokers (Image credit)

This is not necessarily a problem, and the process is well documented. However, it requires an understanding of BOSH fundamentals, such as what jobs and packages are, how Monit works, etc. Naturally, learning all of these takes time.

At KubeCon 2018, we introduced attendees with an alternative method of deploying services to Cloud Foundry using Kubernetes. The demonstrated approach aims at saving both time and effort as it doesn’t entail BOSH-specific expertise.

Using Kubernetes to host services

So, one may deploy services to Kubernetes as a ReplicaSet. Additionally, a service broker can also be developed and deployed. This enables developers to register the service broker to the Cloud Foundry marketplace, create a service instance, and then bind a user application to this service instance.

Using Kubernetes to deploy services to Cloud Foundry (Image credit)

Below, you will find the approach illustrated step by step.

Step 1.

First, one needs to clone a sample application.

$ git clone https://github.com/cloudfoundry-samples/cf-sample-app-nodejs.git
$ cd cf-sample-app-nodejs 
$ cf push

Step 2.

To deploy a service to Kubernetes, one may use Helm. In this instance, MariaDB has been chosen, since it didn’t have a working BOSH release yet.

$ helm search mariadb
$ helm install \
--name mariadb \
--namespace mariadb \
--set service.type=LoadBalancer \
stable/mariadb

Step 3.

After that, it’s time to clone the service broker. The service broker shown below was forked from the CF MySQL Broker. It now includes a Docker file.

$ git clone https://github.com/axelaris/cf-mysql-broker.git
$ cd cf-mysql-broker

Step 4.

Next, a Docker image is created and run in a container locally. Then, the container is pushed into a repository.

$ docker build . -t baber/cf-mysql-broker:latest
$ docker run --rm -d -p 8080:8080 \
-e VAR_HOST=$MARIADB_IP \
-e VAR_PASS=$MARIADB_ROOT_PASSWORD \
 baber/cf-mysql-broker:latest
$ docker push baber/cf-mysql-broker:latest

Step 5.

The repository is used to deploy the service broker on Kubernetes. Its IP address is also exposed to make it available externally.

$ kubectl run broker --image=baber/cf-mysql-broker:latest --port=8080 \
--env="VAR_PASS=$MARIADB_ROOT_PASSWORD" \
--env="VAR_HOST=$MARIADB_IP"
$ kubectl expose deployment broker --type="LoadBalancer"

Step 6.

Finally, a service broker is created and is granted access in Cloud Foundry. Afterwards, a service instance is created and used to bind the sample application. On restaging, the application is bound to the service and deployed on Kubernetes.

$ cf csb mariadb cc secret http://IP:8080
$ cf enable-service-access p-mysql-local
$ cf create-service p-mysql-local 5mb my-maria
$ cf bind-service cf-nodejs my-maria
$ cf restage cf-nodejs

Relying on this method, developers not familiar with BOSH can still deploy services to Cloud Foundry even if there is no available BOSH release.

Want details? Visit our upcoming training!