A key aspect of Cloud Foundry open PaaS is the ability to run everywhere using open-source tools that developers and operations can review and modify to suit their needs. Today we are releasing a simplified scheme for provisioning Cloud Foundry multi-node environments. By combing the ease-of-use of Chef recipes and the open architecture of Cloud Foundry, developers, admins and “DevOps” are now able to easily and consistently provision a customized multi-node Cloud Foundry environment that will suit their particular requirements.
Chef is a well-known open-source configuration manager that is used to install and configure software packages in a repeatable way.
By rewriting much of the open source Cloud Foundry’s (VCAP) provisioning scripts in Chef recipes, we can leverage the instant familiarity of the tooling with a large community of users and contributors to make customizing Cloud Foundry deployments more accessible. Being able to customize the Cloud Foundry environment is necessary if you are trying to design a multiple node or host environment to suit your particular requirements.
The set of deployment tools released today, are in “alpha” stage. We wanted to get them out to the community as quickly as possible to invite users to experiment, validate, and contribute to this effort. Everything you need is located in the Git hub repository under vcap/dev_setup (https://github.com/cloudfoundry/vcap/tree/master/dev_setup). The tools assume that they are running a clean Ubuntu 10.04 server, which means that they will work no matter if your servers are running in a cloud, virtualized environment, or physical datacenter. They also allow you to deploy and setup Cloud Foundry in single or multiple node environments.
In this blog post we will walk through some of the steps involved in this deployment process. Please note that we are only highlighting the major steps. To get detailed instructions and a step-by-step guide, you should read the KB article located on our support site: Single/Multi Node VCAP Deployment using Chef. Additionally, the source code repository also has a README that has some quick start steps.
To get started, you will need a copy of the setup tools from the source repository: https://github.com/cloudfoundry/vcap/tree/master/dev_setup. We currently only support the Chef Solo scheme, so you will need to have a copy of these scripts on every server used in your Cloud Foundry environment. One important note here is that since you are only starting with the cookbooks, part of the process will involve an automatic downloading of the full Cloud Foundry source code repository and that certain components will be compiled during this time. The benefit of this model is that you are guaranteed to be up-to-date on the latest Cloud Foundry source. There are options to deploy existing source code that you have previously downloaded or modified.
The installer executable is vcap_dev_setup in the bin directory. By running the script with default values, it will provision everything on the current server, creating a single node installation. To see this in action, simply run the script:
$ bin/vcap_dev_setup
However, vcap_dev_setup has a number of options, you can type ‘-h’ as a parameter and see the following help text:
OPTIONS:
-h Show this message
-a Answer yes to all questions
-p http proxy i.e. -p http://username:password@host:port
-c deployment config
-d cloudfoundry home
-r cloud foundry repo
The most interesting option is the deployment config, which allows you to specify a config file to pass into vcap_dev_setup. The config files are written in yml, so they are simple to decipher. For example, the default config, deployments/devbox.yml, to install everything is as follows:
---
deployment:
name: "devbox"
jobs:
install:
- all
The content is fairly obvious. This config file names the node, devbox, and specifies an installation job that installs all components. This creates a single node installation of Cloud Foundry. To specify this installation, type the following:
$ bin/vcap_dev_setup -c deployments/devbox.yml
Once Cloud Foundry has finished installing, then you can start this node with the vcap_dev script using the node name.
$ bin/vcap_dev -n devbox start
The script supports start, stop, and other commands. Again, please reference the KB article for details on the specific commands you can run.
There are other sample config files that can be found in the repository under deployments/sample directory. Each directory has a set of config files that comprise of the environment named, such as customized runtimes or multi-node services. For example, in the multihost_redis directory, there are four config files:
- dea.yml
- redis0.yml
- redis1.yml
- rest.yml
In a multi-node setup, there should be a unique config file to be deployed on a host. In this case, we are setting up a multi-node environment with two dedicated Redis nodes. Two of these files are named redisN.yml. Each of these files is expected to be used on a node intended to be a redundant Redis service provider for the Cloud Foundry environment. Here is the content of redis0.yml.
---
deployment:
name: "redis0"
jobs:
install:
- redis:
index: "0"
installed:
- nats_server:
host: "172.31.4.13"
Under ‘install’, you can see that the config file specifies Redis as the only component to be installed. The ‘installed’ section is specifying a previously installed component, the NATS server in this case, which allows the nodes to communicate via a message bus. Compare this with rest.yml, which is the main host in the environment running the Cloud Controller and NATS server.
---
deployment:
name: "rest"
jobs:
install:
- nats_server
- cloud_controller:
builtin_services:
- redis
- mongodb
- mysql
- router
- health_manager
- redis_gateway
- ccdb
- mysql:
index: "0"
- mysql_gateway
- mongodb_gateway
- mongodb:
index: "0"
As we can see here, many more components are being installed on the node named ‘rest’. This config file shows a majority of the available install jobs. However, to see more details regarding what to specify in a config file, take a look at the README file at deployments/README.
There are some caveats here. The following components must run on the same node and limited to only a single instance:
- Cloud Controller
- Health Manager
- Service Gateways
However, the following components support multiple instances:
- DEA
- Service Nodes (i.e. MySQL, Redis and MongoDB)
To learn more about the functionality of the above Cloud Foundry components, please refer to the following blog post: How Cloud Foundry works when a new Application is Deployed.
Once the nodes have been provisioned, then you can start the Cloud Foundry services on each of the nodes using vcap_dev. There are other examples. The easiest way to get started on your multi-host setup is to start customizing the various example config files that exist in the samples directory.
While the Chef cookbooks are incomplete with respect to complete support for all Cloud Foundry components (Rabbit and Postgres services are not currently available), we would like to encourage you to put the deployment scheme through its paces and provide us with feedback. Over time, we intend on standardizing on the Chef cookbooks as the default scheme for customizing Cloud Foundry instances for single and multiple hosts.
- The Cloud Foundry Team
