How to Install Cloud Foundry with BOSH

Introduction

Cloud Foundry is an open source platform as a service (PaaS) to deploy and operate stateless applications.

DIEGO is the new runtime used to stage and execute applications in Cloud Foundry. It provides some features that are not available in the "DEA" architecture, which is currently the default runtime in Cloud Foundry.

BOSH is the default system/tool to deploy and operate Cloud Foundry. BOSH itself is a distributed system and provides an API to deploy other distributed systems. The person who tels BOSH what system should be deployed and how it should be configred communicates with BOSH using a command line interfcace (the BOSH CLI). So BOSH is a client/service architecture where the server usually runs on a different machine than the client. BOSH must be configured with credentials of a supported IaaS layer. This allows BOSH to create and destroy virtual machines automatically.

This tutorial shows how to deploy Cloud Foundry release 238 and DIEGO version "0.1476.0" on BOSH version "1.3232.2.0". The tutorial uses the following BOSH features to simplify the deployment:

  • BOSH cloud config
  • BOSH global network
  • availability zones as first class BOSH citizen

To follow this tutorial a BOSH (with the warden CPI) must be in place, you must have access from your working station to this system and the BOSH CLI must be installed on this working station.

1. Connect to BOSH

To interact with BOSH and to deploy Cloud Foundry, first the "target" must be choosen using the BOSH CLI. The target is the API endpoint of the BOSH system that should deploy and operate the Cloud Foundry.

Once the target is set, the operator must provide an username and password in order to authorize on the BOSH system:

$ bosh target [BOSH director IP]
$ bosh login
Your username: admin
Enter password:
Logged in as `admin'

2. Upload a Stemcell and BOSH Release

Before we deploy a distributed system with BOSH (Cloud Foundry in this example) we must upload stemcells and BOSH releases to BOSH.

A stemcell in BOSH terminology is IaaS specific operation system image containing a BOSH agent.

A BOSH agent is a small programm that runs on each VM which was created by BOSH. BOSH communicates with its agents to send instructions and receive health informations.

A BOSH release is a description how BOSH should create executable files from source code, and how to configure and start processes from executable files.

$ bosh upload stemcell https://bosh.io/d/stemcells/bosh-warden-boshlite-ubuntu-trusty-go_agent
$ bosh upload release 'https://bosh.io/d/github.com/cloudfoundry/cf-release?v=238'

4. Setup a BOSH Cloud Config

A BOSH deployment manifest to deploy Cloud Foundry is usually complex since Cloud Foundry itself is a complex distributed system with a lot of configuration values. In this step an example deployment manifest is used.

The example manifest can be found on a repo on GitHub. Besides the example deployment manifest, there exists an example BOSH cloud config to configure the BOSH system to operate deployments. This example cloud config can be used to deploy the Cloud Foundry on BOSH lite (BOSH lite = BOSH with warden CPI).

In case you want to deploy Cloud Foundry to another IaaS (e.g. AWS) you just have to adjust the BOSH cloud config.

$ mkdir cf-deployment
$ cd cf-deployment
$ git clone https://github.com/wolfoo2931/cf-example-deployment-manifest.git
$ cd cf-example-deployment-manifest
$ bosh update cloud-config warden-cloud-config.yml

5. Trigger the Cloud Foundry Deployment

Execute the following commands from the "cf-deployment/cf-example-deployment-manifest" directory:

In the given deployment manifest there are a lot of credentials specified. For production purposes they have to be replaced in order to get a secure Cloud Foundry setup. For now we just choosing a custom password for the Cloud Foundry admin user by specifying the CF_ADMIN_PWD environment variable. Choose your own Cloud Foundry admin password here.

$ bosh deployment cf.yml
$ export SYSTEM_DOMAIN=[PUBLIC_IP_OF_YOUR_BOSH_LITE_INSTSANCE].xip.io
$ export CF_ADMIN_PWD=cfsecret
$ bosh deploy

6. Upload The Cloud Foundry DIEGO Releases

Performing the following steps is optional and will extend your Cloud Foundry setup with DIEGO. DIEGO is a newer engine to run applications in Cloud Foundry. With DIEGO you can use some addional features:

  • SSH Access into an application container
  • Deploying Docker container

$ bosh upload release 'https://bosh.io/d/github.com/cloudfoundry-incubator/diego-release?v=0.1476.0'
$ bosh upload release 'https://bosh.io/d/github.com/cloudfoundry/cflinuxfs2-rootfs-release?v=1.17.0'
$ bosh upload release 'https://bosh.io/d/github.com/cloudfoundry-incubator/etcd-release?v=58'
$ bosh upload release 'https://bosh.io/d/github.com/cloudfoundry-incubator/garden-linux-release?v=0.338.0'

7. Trigger the DIEGO Deployment

From the git repo you've checked out in step 4, execute the following commands:

$ export SYSTEM_DOMAIN=[PUBLIC_IP_OF_YOUR_BOSH_LITE_INSTSANCE].xip.io
$ bosh deployment diego.yml
$ bosh deploy

8. Verify Cloud Foundry Deployment

Login and create an organization and and application space:

$ cf api https://api.[REPLACE_WITH_PUBLIC_IP].xip.io --skip-ssl-validation
$ cf login -u admin -p cfsecret
$ cf create-org test-org
$ cf target -o test-org
$ cf create-space test-space
$ cf target -s test-space

Deploy a simple PHP app:

$ mkdir phptest
$ cd phptest
$ echo "<?php phpinfo() ?>" > index.php
$ cf push simple_php_app
Creating app simple_php_app in org test-org / space test-space as admin...
OK

Creating route simple_php_app.52.31.201.195.xip.io...
OK

Binding simple_php_app.52.31.201.195.xip.io to phptest...
OK

Uploading phptest...
Uploading app files from: /private/tmp/phptest
Uploading 151B, 1 files
Done uploading
OK

Starting app simple_php_app in org test-org / space test-space as admin...
Downloading binary_buildpack...
Downloading go_buildpack...
Downloading python_buildpack...
Downloading php_buildpack...
Downloading nodejs_buildpack...
Downloading ruby_buildpack...
Downloading staticfile_buildpack...
Downloaded php_buildpack
Downloaded go_buildpack
Downloaded ruby_buildpack
Downloaded binary_buildpack
Downloaded nodejs_buildpack
Downloaded python_buildpack
Downloaded staticfile_buildpack
Creating container
Successfully created container
Downloading app package...
Downloaded app package (187B)
Staging...
-------> Buildpack version 4.3.14
Installing HTTPD
Downloaded
[file:///tmp/buildpacks/f367ab2d18ec4ce70eb82204631e4217/dependencies/https___pivotal-buildpacks.s3.amazonaws.com_concourse-binaries_httpd_httpd-2.4.20-linux-x64.tgz] to [/tmp]
Installing PHP
PHP 5.5.36
Downloaded
[file:///tmp/buildpacks/f367ab2d18ec4ce70eb82204631e4217/dependencies/https___pivotal-buildpacks.s3.amazonaws.com_concourse-binaries_php_php-5.5.36-linux-x64-1464282808.tgz] to [/tmp]
Finished: [2016-07-10 19:02:27.603787]
Exit status 0
Staging complete
Uploading droplet, build artifacts cache...
Uploading build artifacts cache...
Uploading droplet...
Uploaded build artifacts cache (108B)
Uploaded droplet (46.4M)
Uploading complete

1 of 1 instances running

App started


OK

App simple_php_app was started using this command `$HOME/.bp/bin/start`

Showing health and status for app phptest in org test-org / space test-space as admin...
OK

requested state: started
instances: 1/1
usage: 1G x 1 instances
urls: simple_php_app.52.31.201.195.xip.io
last uploaded: Sun Jul 10 19:02:18 UTC 2016
stack: unknown
buildpack: php 4.3.14

     state     since                    cpu    memory    disk      details
#0   running   2016-07-10 09:02:46 PM   0.0%   0 of 1G   0 of 1G

In this example the test application is running under: simple_php_app.52.31.201.195.xip.io