cloudfoundry #185

Supports: trusty
Add to new model


This charm is capable of deploying and managing the CloudFoundry PaaS.

==================== CloudFoundry Bundle ====================

.. image:: :target:

.. image:: :target:

.. image:: :target:

A juju charm to deploy and manage a Cloud Foundry deployment.

If you are unfamiliar with CloudFoundry we suggest referring to their documentation.

Documenting CF is beyond the scope of this project. However once deployed using the system is a normal CF experience as described in the docs.

We provide a set of helper scripts (in bash) which can be used to assist in the deployment and management of CF.

You will need the cf command line client. This can easily be installed using the following:

wget dpkg -i cf-cli_amd64.deb


If you don't have a local copy of the charm obtaining it will give you access to helper scripts which can auto-configure the system. This is largely because of the way an orchestrator charm needs admin access to the running deployment.

To obtain the charm:

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

The deploy the system. This will create a cf.yaml file with the proper admin password automatically passed to the charm properly.

juju bootstrap --constraints instance-type=m3.medium
source trusty/cloudfoundry/

This will boot up the bundle orchestrator which will watch and manage a CF deployment using juju. (Note: the constraint is required to ensure the orchestrator has enough disk space for the build artifacts cache.)

Once the deployment is running you will see juju deploy all of the needed services. When this is going you will be able to: d cflogin

You can now push apps. A sample application we recommend to become familiar with the system is github high score website. This can be pushed with the following:

git clone
cd github-high-scores
cf push


For any given release we support (see cloudfoundry.releases) you should be able to generate an example of the bundle we'll deploy and manage by doing:

. .tox/py27/bin/activate
python charmgen.generator <release>

This will create a cloudfoundry-r directory with the bundle.yaml and a trusty repo will all the created charms.

There are currently two experimental tools included with the charm. These are designed to process a cf-release checkout and examine the differences in various tagged versions of cf-release.

. .tox/py27/bin/activate
# skip if you have a cf-release checkout
git clone ../cf-release
python develop
get_revisions -d ../cf-release 153..173
diff_revisions 153..173 | less

You can also use the following command on the cc unit to monitor the routes registered with NATS, which can be very helpful for debugging:

cd /var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1
/var/vcap/packages/ruby/bin/bundle exec bin/nats-sub -s `grep -o 'nats://.*' /var/vcap/jobs/cloud_controller_ng/config/cloud_controller_ng.yml` ">"

Operational Concerns

Scaling CloudFoundy: CF scales chiefly through expansion of its pool of compute nodes. This is the DEA (Droplet Execution Agents) Service. To scale this service you can simply do the following:

juju add-unit dea


[ forward looking statements ]

This CloudFoundry charm will automatically attempt to ensure that the deployment is in a healthy, functional form. However CloudFoundry itself has a large set of integration tests which can be triggered and run. Juju automatic charm testing framework will automatically run these tests to ensure the charm you use has passed theses test prior to deployment. However if you wish to run these tests yourself you can try the following:

. .tox/py27/bin/activate
python tests/

Which will produce a full report. As a caution some of these tests can be considered destructive and shouldn't be used on a live deployment. We intend to provide access to a recent non-destructive suite of smoke-tests in the near future. (These are the tests automatically run by this charm and reported on elsewhere.)


You get an exception with dig in the traceback: Expecting outbound connectivity the charm will attempt to find the domain name of its public IP in such a way that it will work with EC2 internal DNS system. To do this it asks an external DNS server (google's) for its public name. The workaround is to set the domain name on the service settings to the publicly reachable address of CF's haproxy server.

juju set cloudfoundy domain=xxx

Packages fail to download: Similar to the last possible error this is usually around outbound access to S3 where all the compiled CF artifacts live. A workaround is to mirror the archive to the internal network and then use our NFS implementation to share the assets among the CF units. Scripts for the mirror will be provided and the configuration is as follows:

    juju set cloudfoundry artifacts_url='' mirror_artifacts=true

This will attempt to mirror the artifacts from S3 to a single node (the
cloudfoundry/0 node) and share those over NFS to the whole deployment. Note
that the cloudfoundry node itself should still have outbound access to the
network for S3. The script to mirror the repository out of band and share
that will be documented in the future.

TODO: Full upgrade support coming soon.


(string) The admin password used to talk to the Juju REST API to do bundle orchestration. You will not be able to use Juju to deploy Cloud Foundry until this is properly set.
(string) The URL from which the artifacts can be retrieved. You will not be able to use Juju to deploy Cloud Foundry until this is properly set.
(string) The release of CF to switch the deployed bundle to. If set to "latest", it will use the most recent version supported by this charm.
(string) The namespace in the charmstore from which to install the dependent charms for the individual Cloud Foundry components. Set to an empty string to only install Recommended charms (may not be as up to date as the default ~cf-charmers namespace).
(string) The router domain, set to a address by default.
(boolean) Generate the dependent charms for the individual Cloud Foundry components on demand, instead of installing from the charm store. This option is intended only for testing and development purposes, and is not recommended for normal usage.
(boolean) Create and use a mirror of the artifacts on the orchestrator charm. This can reduce the number of requests to the upstream artifacts repository, but at the cost of significantly increasing the storage requirements on the deployed orchestrator charm.
(string) A value indicating a placement strategy. This can be "sparse", the default, which places each service on its own machine, "dense", which colocates some of the services to keep the number of machines down, "local", which is intended for deploying on the local provider and deployes all services to the same machine except the DEA, which is deployed to machine 0 (since it cannot be deployed to an LXC container), or "manual:" followed by YAML containing zones or raw bundle directives (e.g., "manual:zones: {a: [cc, cc-clock]}" or "manual:dea: {to: 0}").