Up until recently, BOSH has been pretty much the only tool chain for deployment of Cloud Foundry. We love BOSH for its visionary approach towards managing life cycle of clustered systems, flexibility and a distro-agnostic approach to Linux. Yet, it could be quite difficult to deploy BOSH/with BOSH. Yes, despite all its beauty, BOSH has a learning curve, and you certainly need to know its key concepts and internals to be productive. Bottom line, it takes quite a few manual steps to bring all Cloud Foundry components into a single working deployment using BOSH.

To grow the Cloud Foundry community, Altoros, Canonical, and Pivotal joined their efforts to deliver an alternative deployment tool, which would reduce complexity of Cloud Foundry deployment and decrease the number of steps. This solution is based on Juju, a service orchestration tool by Canonical.

What is Juju and Juju Charms?

Juju is an open-source tool, which automates configuration, deployment, management, scaling, and maintenance of services. You can push your services to all of the main IaaS solutions: AWS, OpenStack, Azure, etc. by typing one command in the console or clicking one button in the GUI. The charms can set relations between services and make necessary adjustments automatically. So, with Juju you can deploy such a complex bundle of services as OpenStack in one click.

Basically, Juju Charms contain configuration settings of an application. They define how services are deployed, connected to each other, and scaled. In this article, I will describe how to provision, run, scale, and destroy CF services using Juju charms.

You can write Juju Charms in pretty much any programming language. For the Cloud Foundry bundle of charms, we chose Python, since it has a good library, Charm Helpers, which simplifies service definition, working with templates, etc. In the course of the project, we added lots of enhancements to this library.

The first release of Charms consists of the following components:

go router

nats

cloud controller

uaa

dea

HM9000

etcd

MySQL and MySQL service broker

Below you can see a screenshot of the Juju GUI.

Cloud Foundry deployment using the Juju GUI

A Juju environment should be configured to use your credentials, endpoints, etc. Learn how to do it here.

To deploy a single CF component using Juju Charms, you should run a command:

$juju deploy cf-cloud-controller

Although you can deploy the Cloud Foundry components separately, to make a service work, you should set relations between the services. To avoid doing this manually, you should better use Juju Deployer to simplify deployment.

Automating Cloud Foundry installation with Juju Deployer

To reduce manual work needed to deploy Cloud Foundry, we gathered all Cloud Foundry charms into a single Cloud Foundry bundle file. It will help you to deploy all components, establish relations, and expose services by running a single command in the console or making a single mouse click in the GUI. If you would like to use the bundle, you need to install a Juju Deployer Package.

To deploy the entire Cloud Foundry platform, run:

$juju deployer -BWc bundle.yaml base

This command performs all the necessary installation operations, such as getting charms for the services, preparing a bootstrap machine (a VM is used to manage Juju), provisioning VMs for services, starting services, and adding relations between them. All these tasks are triggered by a single command. The only thing you will have to do is to specify a configuration file. It took about half an hour on my Ubuntu host to deploy the entire Cloud Foundry PaaS. I recorded the deployment process, so you can watch this video to get more details on installation.

Now, if we use BOSH, there are a few more steps we have to perform manually:

install Ruby

install BOSH gems

prepare BOSH manifest file

bootstrap micro BOSH

download a cf-release

upload a stemcell

configure cf-release

This video demonstrates how to push applications to Cloud Foundry using Juju.

Scaling services

With Juju, scaling is also simplified to a single command. For example, to add resources by increasing the number of running Droplet Execution Agents by 3, just run the following command:

$juju add-unit -n 3 cf-dea

It will add 3 more units to the deployment. To reduce resource utilization, execute:

$juju remove-unit cf-dea

It stops one virtual machine (or a container, if it is a local host).

Destroying services

To destroy the deployment completely and release all resources, run the following:

$juju destroy-environment local --force

This video demonstrates how it is done with Juju.

If you would like to delete services one by one, use the following command:

$juju destroy-service cf-uaa

Keep in mind that Juju is not an absolute solution and has some limitations. For example, it is impossible to deploy Juju to a VirtualBox VM. The DEA charm cannot run inside the LXC container, so we should use KVM instead. To run a KVM, a host should support nested virtualization, which VirtualBox does not. So, to deploy Cloud Foundry on a local machine inside a VM, you should use VMware Workstation or any other desktop hypervisor that supports nested virtualization.

Another drawback of Juju is that it does not support Cloud Foundry revisions. We are working on introducing this feature in the near future. For development purposes, we used Cloud Foundry version r153.

Juju: current state and future plans

Juju Charms simplified the whole Cloud Foundry deployment process to a single command and at the same time preserved the variety of deployment options. You can choose a local host, any public or private IaaS as a target deployment option. Juju Charms for Cloud Foundry complete Canonical’s set of tools provided for IaaS (MaaS, Juju, Charms for OpenStack) and PaaS deployment. Although lots has already been done, a great job is ahead. Currently, we are working on changing the whole concept of getting CF components to come up with quick CF updates. Very soon, we are going to extend the range of service brokers so users could quickly add such services as Hadoop, PostgreSQL, Cassandra, etc. to the Cloud Foundry PaaS deployed with Juju.

Should you try the Juju bundle of charms for Cloud Foundry (we certainly recommend it!), perhaps you can share your feedback!

What was your experience like? Did it work for you? What kind of capabilities would you like to add to the bundle?

Further reading

About the author: Aliaksandr Prysmakou is a Cloud Foundry DevOps Engineer at Altoros. He is an expert in cloud automation and virtualization. As a member of a joint team formed by Canonical, Pivotal, and Altoros, Alex worked on automating Cloud Foundry deployment with the Juju orchestration platform. He also contributed to extending BOSH to support new cloud providers. Previously, Alex designed templates to automate management of Microsoft solutions on the RightScale platform and provided fault tolerance for Microsoft SQL Server.

For more posts and tutorials, subscribe to our blog or follow @altoros.

To clarify “we certainly recommend it”, does Altoros now recommend using juju to deploy Cloud Foundry rather than BOSH?

Andrei Yurkevich

Nic, What we recommend is trying. Juju has advantages in adoption cycle and rich ecosystem of potential services. But it is still not the native tool designed specifically for deploying CF. A detailed comparison of BOSH and Juju deployments can be found in the video by the link below.

Subscribe to new posts

Subscribe to new posts

Get new posts right in your inbox!

Follow us

About Altoros

Altoros is a 300+ people strong consultancy that helps Global 2000 organizations with a methodology, training, technology building blocks, and end-to-end solution development. The company turns cloud-native app development, customer analytics, blockchain, and AI into products with a sustainable competitive advantage. Altoros assists enterprises on their way to digital transformation, standing behind some of the world's largest Cloud Foundry deployments.