Juju Charms for Cloud Foundry: How to Deploy, Customize, and Upgrade

by Siarhei MatsiukevichDecember 5, 2014

Overviewing the features of the new Juju charm for Cloud Foundry, this blog post demonstrates how to automate deployment or do it manually via a config file.

Table of Contents

A new charm for Cloud Foundry

A lot has changed in the Juju orchestration tool and the Cloud Foundry Juju Charm, since our latest blog post about them. In this new post, I will overview the new features and provide two guides on installing Cloud Foundry, taking into account these updates. You will learn about:

The new Cloud Foundry Juju charm implementation and some of its features
How to deploy Cloud Foundry automatically with the latest Cloud Foundry Juju charm
How to deploy Cloud Foundry manually using the config file
How to customize your Cloud Foundry deployment by editing the config file
How to upgrade Cloud Foundry with Juju

Recently, a lot of new components have been added to the Cloud Foundry charm. You can see all of them above, on the screenshot from the Juju GUI tool.

However, the most important change was in the way you deploy Cloud Foundry with Juju. Now you need to use a separate charm instead of the Juju deployer. The new Cloud Foundry Juju charm works like an orchestrator responsible for installing all other charms and setting all the necessary relations. Still, its main responsibility is helping you to configure different deployment options.

The diagram below demonstrates how this process works:

This charm differs from the regular charms, because it uses Juju to deploy all other Cloud Foundry charms. So, it cannot work without access to the admin-secret key from your Juju configuration.

You still can deploy all the charms and set all the relations manually, but it is much easier to use the Cloud Foundry charm. I will describe both ways of deploying Cloud Foundry below.

Automated deployment with the Cloud Foundry charm

So, lets go through the basic Cloud Foundry deployment scenario:

First of all, you need to install the Bazaar version control system, if you do not have it already.

The second step is getting a local copy of the Cloud Foundry charm from the launchpad.

mkdir trusty
bzr branch lp:~cf-charmers/charms/trusty/cloudfoundry/trunk trusty/cloudfoundry

It is possible to use the version of this charm available from the charm store. If you do, you will not need to install Bazaar or obtain a local version of the charm. However, then you also will not get access to the useful Python helpers that come with the charm and you will have to create the config file for the charm manually. (See the second tutorial below.)

Once you have obtained a local version of the charm, execute the cfdeploy script:
```
cd trusty/cloudfoundry/
./cfdeploy 
```

This script will take care of generating the charm config file, bootstrapping your environment (if necessary), and actually deploying the Cloud Foundry charm. Optionally, you can also specify the Cloud Foundry version using the -v switch. The latest supported version will be installed by default. At the time this was written, this was revision 180, but the new architecture of the Cloud Foundry charm makes it very easy to add support for new versions. So, we expect new ones to become available soon.

The cfdeploy command is asynchronous, so it will be blocked until the deployment is fully up and running. When that happens, it will create a Cloud Foundry “admin” user with the specified password, leaving you logged in and ready to push a Cloud Foundry app. Note that while this can take quite some time, the whole process is automated.

In addition, if you do not have the cf command line client on your machine, the latest one will be installed from a .deb package to your local system as part of cfdeploy.

Manual deployment using the config file

As you know, the Cloud Foundry charm cannot be deployed without the IaaS provider’s admin-secret (see the table below). This and some other options are stored in the config file. To install Cloud Foudnry, the cfdeploy script, described in the previous section, generates a minimal config file and executes a command similar to this one:

juju deploy --repository=. --config=<path to the generated config> local:<path to the Cloud Foundry charm root folder>

You can also easily deploy Cloud Foundry using a manually created config file. This is done via the -config switch:

juju deploy cs:~cf-charmers/trusty/cloudfoundry --config=<path to the config file>

When using this command, we do not have to obtain a local version of the Cloud Foundry charm and can use the version from the Charm Store. This approach will also work with the local version.

Customizing a Cloud Foundry deployment

Your Cloud Foundry deployment can be customized by editing the config file before installation. The table below lists some of the most useful options you can adjust:

`admin_password`	The password for the default admin user in Cloud Foundry. This value is passed to the `cfdeploy` script.
`admin_secret`	The admin password for the Juju REST API used in bundle orchestration. The `cfdeploy` script gets this value from the `~/.juju/environments/<provider_name>.jenv` file.
`cf_version`	The Cloud Foundry release the deployed bundle is switched to. If set to `latest`, it will use the most recent version supported by this charm. You can set this with the `-v` script when executing `cfdeploy`.
`domain`	The router domain (set to the `xip.io` address by default).
`placement`	This value indicates the placement strategy. It is set to `sparse` by default, which places each service on its own machine. When placement is set to `dense`, some of the the services are collocated to keep the number of machines down. The `local` option is intended for deploying on a local provider—it installs all services on the same machine except for the DEA, which is deployed to machine 0 since it cannot be installed in an LXC container. The `manual` placement option needs to be followed by YAML containing zones or raw bundle directives (e.g., `manual:zones: {a: [cc, cc-clock]}` or `manual:dea: {to: 0}`).
`admin_ui`	This deploys and configures the Administration UI from the Cloud Foundry Incubator.

To view all the available options with full descriptions, open the config.yaml file located in the root of the Cloud Foundry charm folder.

Upgrading Cloud Foundry with Juju (upcoming features)

One of the obvious drawbacks of installing Cloud Foundry via Juju—as compared to BOSH—is that you cannot upgrade without re-deploying the entire system. Luckily, the Cloud Foundry Juju charm team have been working on a tool called Reconciler that helps to resolve this issue. When you use cfdeploy to install Cloud Foundry, Reconciler is deployed and started automatically.

The tool is responsible for upgrading and monitoring the health of all installed Cloud Foundry components. The screenshot below is the UI of Reconciler.

Reconciler lists all the deployed charms along with information about their status and relations. It can also grab and display all charm logs. At the time this was written, Reconciler was in active development, so I will not describe it in many details as they may change. However, keep it in mind that soon this tool will become standard.

As you can see, deploying Cloud Foundry with Juju is probably not the perfect solution that suits everyone’s needs. You still do not have as much flexibility in configuring individual components of your deployment as when you are using BOSH. In addition, not all the planned features have been fully implemented yet. Despite that, the development team have definitely made a big step forward in developing this charm, adding automation of deployment with a separate charm, Cloud Foundry revisions support, support for upgrades, and a variety of new services.