Doing an initial Cloud Foundry deployment can be hard, keeping it up to date with the weekly releases can be even harder. So together with Swisscom we have developed the bosh-workspace gem to simplify this process.
What better way to introduce a new tool then by having a step by step tutorial. The objective today will be to deploy Cloud Foundry v175 on AWS, with some custom settings and then show how we can use the bosh-workspace to update to v176 (current latest version).
Setup Workspace
git clone https://github.com/starkandwayne/cf-boshworkspace.git
cd cf-boshworkspace
bundle install
AWS Setup
Create Keypair
Create a keypair via the aws console. Move the downloaded key into cf-workspace/ssh/ and name it bosh.
ls -l ssh
total 8
[email protected] 1 vcap vcap 1692 Jul 31 10:44 bosh
Allocate Elastic IPs
Allocate 2 elastic ips, one for the microbosh and the other for Cloud Foundry.
Create Security Groups
Create a security group named bosh.
| Protocol | Port Range | Source |
| TCP | 22 | 0.0.0.0/0 |
| TCP | 4222 – 25777 | 0.0.0.0/0 |
Create a security group named cf.
| Protocol | Port Range | Source |
| TCP | 80 | 0.0.0.0/0 |
| TCP | 443 | 0.0.0.0/0 |
| TCP | 4443 | 0.0.0.0/0 |
| ALL | ALL | 172.31.0.0/16 |
Deploy microbosh
Create deployment file
With AWS all setup it’s time to fill in the blank spots in our microbosh deployment file.
export MICROBOSH_ELASTIC_IP=<first_elastic_ip>
export SUBNET_ID=<default_vpc_subnet_id>
export ACCESS_KEY_ID=<access_key_id>
export SECRET_ACCESS_KEY=<secret_access_key>
Now lets replace the placehorders in micro_bosh.yml
for VAR in MICROBOSH_ELASTIC_IP SUBNET_ID ACCESS_KEY_ID SECRET_ACCESS_KEY
do
eval REP=\$$VAR
perl -pi -e "s/$VAR/$REP/g" microbosh/firstbosh/micro_bosh.yml
done
Download stemcell
We will be using the light-stemcell which references a public AMI. This way we don’t have to up/download the whole stemcell.
mkdir .stemcells
curl https://bosh-jenkins-artifacts.s3.amazonaws.com/bosh-stemcell/aws/light-bosh-stemcell-2669-aws-xen-ubuntu-lucid-go_agent.tgz \
-o .stemcells/bosh-stemcell-2669-aws-xen-ubuntu-lucid-go_agent.tgz
Deploy
After setting the deployment we will deploy our microbosh with the stemcell stemcell from the previous step.
cd microbosh
bosh micro deployment firstbosh
bosh micro deploy ../.stemcells/bosh-stemcell-2669-aws-xen-ubuntu-lucid-go_agent.tgz
cd ..
Target director
When the deployment has finished it’s time to target the bosh director and login as the default user.
bosh target $MICROBOSH_ELASTIC_IP
bosh login admin admin
Deploy Cloud Foundry
Create deployment file
Just as with the microbosh deployment file we need to fill in some information in our Cloud Foundry deployment file.
export CF_ELASTIC_IP=<second_elastic_ip>
export SUBNET_ID=<default_vpc_subnet_id>
export DIRECTOR_UUID=$(bosh status | grep UUID | awk '{print $2}')
Now lets replace the placehorders in cf-aws-vpc.yml
for VAR in CF_ELASTIC_IP SUBNET_ID DIRECTOR_UUID
do
eval REP=\$$VAR
perl -pi -e "s/$VAR/$REP/g" deployments/cf-aws-vpc.yml
done
Upload dependencies
Our Cloud Foundry deployment depends on the cf-release and on the bosh-stemcell, before we can deploy we will need to make sure those dependencies have been resolved. Luckily the bosh-workspace has build in support for resolving those depedencies.
bosh deployment cf-aws-vpc
bosh prepare deployment
Alternatively when not using an inception server, you can use a remote release:
bosh upload release goo.gl/ptAhNw
Deploy
With the dependencies resolved it’s time to deploy Cloud Foundry version 175. The following changes have been made to the standard amazon templates:
- Use haproxy instead of elbs
- Use postgresql instead of rds
- Use nfs instead of an s3 bucket for blobs
- All secrets have been set to c1oudc0w
- SSL has been disabled
- Single availability zone deployment
With the above changes 20 vms of different sizes will be deployed.
bosh deploy
Upgrade Cloud Foundry
We have just deployed Cloud Foundry version 175. Now it’s time to upgrade this deployment to version 176.
Update deployment file
First the version reference needs to be changed.
perl -pi -e "s/175/176/g" deployments/cf-aws-vpc.yml
Upload dependencies
We will need to upload release 176.
bosh prepare deployment
Deploy
bosh deploy
The above step will fail because of a spiff merge error. The cf-properties template requires properties.uaa.clients.notifications.secret since version 176.
To solve this merge issue make the following changes to cf-secrets.yml:
- add after line 23:
notifications: (( merge || meta.secret ))
- add after line 61:
notifications:
secret: (( meta.secrets.uaa_secrets.notifications ))
Now we can deploy again.
bosh deploy
Spread the word
