Skip to main content
Ask Question
OpenStack
Asked a question 2 months ago

How can I deploy Cloud Foundry on Bright Openstack 7.3?

Where am I?

In Bright Computing, Inc. you can ask and answer questions and share your experience with others!

This guide is based on the Cloud Foundry documentation in http://docs.cloudfoundry.org/deploying/openstack/index.html4, and walk trough the installation process in a Bright Openstack 7.3 deployment.

When not specified, the commands mentioned in this article must be run on the head node.

Prerequisites

Bright Openstack already deployed

We assume BOSH is not already installed, so we will install it first over Bright OpenStack.

Openstack credentials are already configured and the command line utilities can access the Openstack API. This is configured by Bright by default, for the root user the ~/.openstackrc stores credentials for the admin user and the bright tenant. In case of deploying CloudFoundry for another user and tenant, these values would need to be changed.

There are other prerequisites that the Openstack deployment must conform to, and they are described in http://docs.cloudfoundry.org/deploying/openstack/validate_openstack.html4. A typical installation of Bright Openstack meets most of these requirements out of the box.

1 - Configure Openstack environment

1.1 - Verify that Nova and Cinder use the same default availability zones

A tool which will be used in this article (BOSH) creates a virtual machine in the default availability zone and then tries to create a Cinder volume in the same zone in which it created the virtual machine. This will not work if the mentioned availability zone is not known to Cinder.

To verify what is the default availability zone, run the following command:
# cmsh -c "openstack; settings; compute; get defaultavailabilityzone"

To verify what availability zones are available for creating cinder volumes, run the following command:
# cinder availability-zone-list

If the zones are different it will be necessary to change Cinder’s availability zones. The following is an example on how to change Cinder’s availability zone to “default”:
# cmsh -c "configurationoverlay; use openstackcontrollers; customizations; add INI /etc/cinder/cinder.conf; entries; add [DEFAULT]storage_availability_zone=default; commit"

The controller nodes need to be rebooted after this change.

1.2 - Configure security groups for Cloud Foundry

Run the following commands on the head node:
# openstack security group create cf
# openstack security group rule create --proto udp --dst-port 68:68 cf
# openstack security group rule create --proto udp --dst-port 3457:3457 cf
# openstack security group rule create --proto icmp cf
# openstack security group rule create --proto tcp --dst-port 22:22 cf
# openstack security group rule create --proto tcp --dst-port 80:80 cf
# openstack security group rule create --proto tcp --dst-port 443:443 cf
# openstack security group rule create --proto tcp --dst-port 4443:4443 cf
# openstack security group rule create --proto tcp --dst-port 1:65535 --src-group $(openstack security group show cf | grep id | head -n 1 | cut -d"|" -f3) cf

This is the minimum required configuration, according to http://docs.cloudfoundry.org/deploying/openstack/security_group.html4. For a production environment it can require some modifications.

1.3 - Verify quota of tenant

The last time we tested this procedure in May 2017, with the configuration templates included with Cloud Foundry, a total of 21 instances had to be deployed (1 for the BOSH director, 6 for compilation and 14 for Cloud Foundry)

This could be a problem, if the current tenant has a limit on how many instances can be created which is lower than that.

To verify how many instances can be deployed in the bright tenant, run the following command on the head node:
# openstack quota show bright

If the values shown by this command are less than what it's needed, then they can be increased. For example, to increase the quota for instances and cores to 50, the following command can be used:
# openstack quota set --instances 50 --cores 50 bright

2 - Install BOSH

In order to deploy Cloud Foundry, we will first deploy BOSH (https://bosh.cloudfoundry.org/2) a tool used to deploy applications.

The steps in this section are based on the procedure described in https://bosh.io/docs/init-openstack.html5

2.1 - Install RVM and Ruby 2.3.0

For running the bosh client (which will be installed later) Ruby is required. Here is a brief description on how to install Ruby in a rvm (https://rvm.io/) environment.

Run the following commands on the head node:
# gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
# curl -sSL https://get.rvm.io5 | bash -s stable --ruby=2.3.0
# source /usr/local/rvm/scripts/rvm

2.3 - Create a manifest to deploy BOSH

Create a directory which will be used for placing the BOSH manifests.
# mkdir /cm/shared/manifests

Create the manifest for deploying bosh in /cm/shared/manifests/microbosh.yml, with the following content:
name: bosh

releases:
- name: bosh
 url: https://bosh.io/d/github.com/cloudfoundry/bosh?v=2593
 sha1: 94cd3ade8549fbc6a02fcca349794ac40045c22c
- name: bosh-openstack-cpi
 url: https://bosh.io/d/github.com/cloudfoundry-incubator/bosh-openstack-cpi-release?v=271
 sha1: 85e6244978f775c888bbd303b874a2c158eb43c4

resource_pools:
- name: vms
 network: private
 stemcell:
   url: https://bosh.io/d/stemcells/bosh-openstack-kvm-ubuntu-trusty-go_agent?v=3263.101
   sha1: abbf1686c486570393c75d865772bf1b3e8dfbfd
 cloud_properties:
   instance_type: m1.xlarge

disk_pools:
- name: disks
 disk_size: 20_000

networks:
- name: private
 type: manual
 subnets:
 - range: PRIVATE-CIDR # <--- Replace with a private subnet CIDR
   gateway: PRIVATE-GATEWAY-IP # <--- Replace with a private subnet's gateway
   dns: [DNS-IP] # <--- Replace with your DNS
   cloud_properties: {net_id: NETWORK-UUID} # <--- # Replace with private network UUID
- name: public
 type: vip

jobs:
- name: bosh
 instances: 1

 templates:
 - {name: nats, release: bosh}
 - {name: postgres, release: bosh}
 - {name: blobstore, release: bosh}
 - {name: director, release: bosh}
 - {name: health_monitor, release: bosh}
 - {name: registry, release: bosh}
 - {name: openstack_cpi, release: bosh-openstack-cpi}

 resource_pool: vms
 persistent_disk_pool: disks

 networks:
 - name: private
   static_ips: [PRIVATE-IP] # <--- Replace with a private IP
   default: [dns, gateway]
 - name: public
   static_ips: [FLOATING-IP] # <--- Replace with a floating IP

 properties:
   nats:
     address: 127.0.0.1
     user: nats
     password: nats-password

   postgres: &db
     listen_address: 127.0.0.1
     host: 127.0.0.1
     user: postgres
     password: postgres-password
     database: bosh
     adapter: postgres

   registry:
     address: PRIVATE-IP # <--- Replace with a private IP
     host: PRIVATE-IP # <--- Replace with a private IP
     db: *db
     http: {user: admin, password: admin, port: 25777}
     username: admin
     password: admin
     port: 25777

   blobstore:
     address: PRIVATE-IP # <--- Replace with a private IP
     port: 25250
     provider: dav
     director: {user: director, password: director-password}
     agent: {user: agent, password: agent-password}

   director:
     address: 127.0.0.1
     name: my-bosh
     db: *db
     cpi_job: openstack_cpi
     max_threads: 3
     user_management:
       provider: local
       local:
         users:
         - {name: admin, password: admin}
         - {name: hm, password: hm-password}

   hm:
     director_account: {user: hm, password: hm-password}
     resurrector_enabled: true

   openstack: &openstack
     auth_url: IDENTITY-API-ENDPOINT # <--- Replace with OpenStack Identity API endpoint
     project: OPENSTACK-PROJECT # <--- Replace with OpenStack project name
     domain: OPENSTACK-DOMAIN # <--- Replace with OpenStack domain name
     username: OPENSTACK-USERNAME # <--- Replace with OpenStack username
     api_key: OPENSTACK-PASSWORD # <--- Replace with OpenStack password
     default_key_name: bosh
     default_security_groups: [bosh]

   agent: {mbus: "nats://nats:nats-password@PRIVATE-IP:4222"} # <--- Replace with a private IP

   ntp: &ntp [0.pool.ntp.org3, 1.pool.ntp.org3]

cloud_provider:
 template: {name: openstack_cpi, release: bosh-openstack-cpi}

 ssh_tunnel:
   host: FLOATING-IP # <--- Replace with a floating IP
   port: 22
   user: vcap
   private_key: ./bosh # Path relative to this manifest file

 mbus: "https://mbus:mbus-password@FLOATING-IP:68684" # <--- Replace with a floating IP

 properties:
   openstack: *openstack
   agent: {mbus: "https://mbus:mbus-password@0.0.0.0:68683"}
   blobstore: {provider: local, path: /var/vcap/micro_bosh/data/cache}
   ntp: *ntp

 



 

2.4 - Create an Openstack keypair for BOSH

 

Create a SSH keypair and place it in the /cm/shared/manifests directory

 

# ssh-keygen -f /cm/shared/manifests/bosh

 

Add the keypair to Openstack.

 

# openstack keypair create --public-key /cm/shared/manifests/bosh.pub3 bosh

 

2.5 - Configure a security group for BOSH

Run the following commands on the head node:

 

# openstack security group create bosh

# openstack security group rule create --proto tcp --dst-port 22:22 bosh

# openstack security group rule create --proto tcp --dst-port 6868:6868 bosh

# openstack security group rule create --proto tcp --dst-port 25555:25555 bosh

# openstack security group rule create --proto tcp --dst-port 1:65535 --src-group $(openstack security group show bosh | grep id | head -n 1 | cut -d"|" -f3) bosh

 

The previous rules are mentioned in the BOSH documentation. In order to allow communication between the BOSH director and the Cloud Foundry instances, the following rules have to be added also:

 

# openstack security group rule create --proto tcp --dst-port 1:65535 --src-group $(openstack security group show cf | grep id | head -n 1 | cut -d"|" -f3) bosh

# openstack security group rule create --proto tcp --dst-port 1:65535 --src-group $(openstack security group show bosh | grep id | head -n 1 | cut -d"|" -f3) cf

2.6 - Allocate a floating IP

 

Allocate a floating IP in the external network by running this command:

 

# openstack ip floating create bright-external-flat-externalnet

 

Take note of the generated IP, as it will be used in the following steps.

 

2.7 - Create an internal network to be used by Cloud Foundry

 

In case there isn’t already an internal network defined for use by Cloud Foundry, create one by following these steps.

 

#  openstack network create cloudfoundry-net

# neutron subnet-create --enable-dhcp --gateway 192.168.0.254 --name cloudfoundry-subnet cloudfoundry-net 192.168.0.0/24

 

2.8 - Verify that the external network can be reached from the internal network

 

If it’s not already defined, a router connecting the internal Cloud Foundry network and the external network must be defined (that will allow Openstack to assign the floating IP to a VM inside the Cloud Foundry internal network)

 

# openstack router create cloudfoundry-router

# neutron router-gateway-set cloudfoundry-router bright-external-flat-externalnet

# neutron router-interface-add cloudfoundry-router cloudfoundry-subnet

 

When configuring this, it’s also very important to verify that from inside the internal network it will be possible to reach the OpenStack public endpoints. The public endpoints’s URLs are the ones returned by running this command in the head node:

 

# openstack endpoint list | grep public

2.9 - Edit the BOSH manifest

 

Edit the  /cm/shared/manifests/microbosh.yml and replace the following values:

 

NETWORK-UUID -> replace for the UUID of the network defined in 2.7. To get the UUIDs of the networks run this command: openstack network list

PRIVATE-IP -> replace for an unused IP of the network defined in 2.7.

PRIVATE-CIDR -> replace with the CIDR of the network defined in 2.7. For example: 192.168.0.0/16

PRIVATE-GATEWAY-IP -> replace for the gateway of the network defined in 2.7. This should be the same as the internal network IP of the router defined in 2.8. For example: 192.168.0.254

DNS-IP -> replace by the IP of a DNS server.

FLOATING-IP -> replace for the floating IP allocated in step 2.5

OPENSTACK-PASSWORD→ replace for the value of OS_PASSWORD in /root/.openstackrc

IDENTITY-API-ENDPOINT -> replace for the URL of the public Identity API endpoint. The URL can be found by running the “openstack endpoint list” command.

OPENSTACK-PROJECT → replace for the value of OS_TENANT_NAME in /root/.openstackrc

OPENSTACK-USERNAME → replace for the value of OS_USERNAME in /root/.openstackrc

OPENSTACK-DOMAIN -> replace for the Openstack domain name of the user. For example: ‘default’

 

You must also verify that the flavor specified in “instance_type” can be deployed in your Openstack Hypervisors.

 

2.10 - Install bosh-init

 

Run the following commands in the head node:

 

# wget https://s3.amazonaws.com/bosh-init-artifacts/bosh-init-0.0.102-linux-amd643

# chmod +x bosh-init-0.0.102-linux-amd64

# mv bosh-init-0.0.102-linux-amd64 /root/bin/bosh-init

 

Verify it’s installed correctly by running this command:

 

# bosh-init -v

 

2.11 - Deploy BOSH

 

Run the following command on the head node:

 

# bosh-init deploy /cm/shared/manifests/microbosh.yml

 

2.12 - Install the BOSH command line client

 

Run the following command on the head node:

 

# gem install bosh_cli --no-ri --no-rdoc

 

Test by logging in to the BOSH director:

 

# bosh target FLOATING_IP

 

And use the username and password specified in the “director” section of the manifest.



 

3 - Deploy Cloud Foundry

 

We will now use BOSH to deploy Cloud Foundry.

 

3.1 - Install Git

 

If not already installed run the following command

 

# yum install git

 

3.2 - Install Go

 

An installation of GO will be required for some of the next steps. The following commands can be run to install and configure it.

 

# yum install golang

# export GOPATH=/usr/share/gocode

# export PATH=$PATH:/usr/share/gocode/bin

3.3 - Retrieve the BOSH director UUID

 

Log into the BOSH director

 

# bosh target FLOATING_IP

 

After logging in, run the following command:

 

# bosh status --uuid

 

The value returned here will be required in step 3.5.

 

3.4 - Allocate a floating IP

 

Allocate a floating IP in the external network by running this command:

 

# openstack ip floating create bright-external-flat-externalnet

 

Take note of the generated IP, as it will be used in the following steps.

 

3.5 - Clone the cf-release project

 

Run the following commands in the head node.

 

# git clone https://github.com/cloudfoundry/cf-release.git4

# cd cf-release

# ./scripts/update

 

3.6 - Create a stub manifest for Cloud Foundry

 

Create a stub manifest for deploying Cloud Foundry in /cm/shared/manifests/cf-stub.yml. Use the cf-release/spec/fixtures/openstack/cf-stub.yml as a template. In the following sections we describe how the stub has to be filled.

3.7 - Generate certificates and keys.

 

In some sections of the manifest stub it will be necessary to generate SSL certificates and keys. Running the scripts under cf-release/scripts can be used to generate them in case they don’t exist already.

 

For example, to generate the certificates for the consul section, the following command can be used:

 

# cf-release/scripts/generate-consul-certs

 

The certificates should be generated under /root/consul-certs

 

3.8 - Edit the stub manifest

 

Edit the manifest according to the instructions in http://docs.cloudfoundry.org/deploying/openstack/cf-stub.html#editing5, keeping in mind the following:

 

DIRECTOR_UUID has to be replaced by the uuid obtained in step 3.1

 

ENVIRONMENT has to be replaced by an arbitrary value, for example openstack-prod

 

In floating_static_ips the floating ip allocated in step 3.3 must be set.

 

In the networks section,the net_id value must be the network id of the network defined in 2.7, this can be obtained with the following command:

 

# openstack network show cloudfoundry-net

 

In the networks section, the range and gateway values in subnets must correspond to the subnet of the internal network defined in 2.7, this can be obtained with the following command:

 

# openstack subnet show cloudfoundry-subnet

 

In the networks section, in static it’s required to specify a range of at least 26 IP addresses inside the range.

 

In the networks section, in reserved it’s necessary to specify IP addresses inside the range that are already being used and can’t be assigned to instances. Typically those addresses are the DHCP server of the internal network, the BOSH director and the router. To verify which IP addresses are already being used in the internal network, the following command can be used:

 

# neutron port-list | grep $(openstack subnet list | grep cloudfoundry-subnet | cut -d" " -f2)

 

In security_groups for the cf1 network, the security group defined in step 1.2 must be specified.

Where certificates and keys are required, the scripts mentioned in 3.3 can be used to generate them.

 

Editing Instructions Table, from that URL

Deployment Manifest Stub ContentsEditing Instructions
director_uuid: DIRECTOR_UUID
  
Replace DIRECTOR_UUID with the BOSH Director UUID. Run the BOSH CLI bosh status --uuid command to view the BOSH Director UUID.
meta:
 environment: ENVIRONMENT
  
Replace ENVIRONMENT with an arbitrary name describing your environment, for example openstack-prod.
 floating_static_ips:
 - 198.51.100.1
  
Replace 198.51.100.1 with an existing static IP address for your OpenStack floating network. This is assigned to the ha_proxy job to receive incoming traffic.
networks:
 - name: floating
   type: vip
   cloud_properties:
     net_id: NET_ID
     security_groups: []
 - name: cf1
   type: manual
   subnets:
   - range: 10.10.0.0/24
     gateway: 10.10.0.1
     reserved:
     - 10.10.0.2 - 10.10.0.100
     - 10.10.0.200 - 10.10.0.254
     dns:
     - 8.8.8.8
     static:
     - 10.10.0.125 - 10.10.0.175
     cloud_properties:
       net_id: NET_ID
       security_groups: ["cf"]
  

Update the values for range, reserved, static, and gateway to reflect the available networks and IP addresses in your OpenStack network. Replace NET_ID with the network ID of your OpenStack network.

This also assumes that you have a security group cf suitable for your Cloud Foundry VMs. Change this to the name of your security group if necessary.

properties:
 system_domain: SYSTEM_DOMAIN
 system_domain_organization: SYSTEM_DOMAIN_ORGANIZATION
 app_domains:
  - APP_DOMAIN
  

Replace SYSTEM_DOMAIN and APP_DOMAIN with the full domain you want associated with applications pushed to your Cloud Foundry installation, for example cloud-09.cf-app.com1. You must have already acquired these domains and configured their DNS records so that these domains resolve to your load balancer.

Choose a name for the SYSTEM_DOMAIN_ORGANIZATION. This organization will be created and configured to own the SYSTEM_DOMAIN.

 cc:
   staging_upload_user: STAGING_UPLOAD_USER
   staging_upload_password: STAGING_UPLOAD_PASSWORD
   bulk_api_password: BULK_API_PASSWORD
   db_encryption_key: CCDB_ENCRYPTION_KEY
  

The Cloud Controller API endpoint requires basic authentication. Replace STAGING_UPLOAD_USER and STAGING_UPLOAD_PASSWORD with a username and password of your choosing.

Replace BULK_API_PASSWORD with a password of your choosing. Health Manager uses this password to access the Cloud Controller bulk API.

Replace CCDB_ENCRYPTION_KEY with a secure key that you generate to encrypt sensitive values in the Cloud Controller database. You can use any random string. For example, run the following command from a command line to generate a 32-character random string: LC_ALL=C tr -dc 'A-Za-z0-9' < /dev/urandom | head -c 32 ; echo

 blobstore:
   admin_users:
     - username: blobstore-username
       password: blobstore-password
   secure_link:
       secret: blobstore-secret
   tls:
       port: 443
       cert: BLOBSTORE_TLS_CERT
       private_key: BLOBSTORE_PRIVATE_KEY
       ca_cert: BLOBSTORE_CA_CERT
  

Replace blobstore-username and blobstore-password with a username and password of your choosing.

Replace blobstore-secret with a secure secret of your choosing.

Replace BLOBSTORE_TLS_CERT, BLOBSTORE_PRIVATE_KEY, and BLOBSTORE_CA_CERT with the blobstore TLS certificate, private key, and CA certificate.

 consul:
   encrypt_keys:
     - CONSUL_ENCRYPT_KEY
   ca_cert: CONSUL_CA_CERT
   server_cert: CONSUL_SERVER_CERT
   server_key: CONSUL_SERVER_KEY
   agent_cert: CONSUL_AGENT_CERT
   agent_key: CONSUL_AGENT_KEY
  
See theSecurity Configuration for Consul7 topic.
 loggregator_endpoint:
   shared_secret: LOGGREGATOR_ENDPOINT_SHARED_SECRET
  
Replace LOGGREGATOR_ENDPOINT_SHARED_SECRET with a secure string that you generate.
 nats:
   user: NATS_USER
   password: NATS_PASSWORD
  
Replace NATS_USER and NATS_PASSWORD with a username and secure password of your choosing. Cloud Foundry components use these credentials to communicate with each other over the NATS message bus.
 router:
   status:
     user: ROUTER_USER
     password: ROUTER_PASSWORD
  
Replace ROUTER_USER and ROUTER_PASSWORD with a username and secure password of your choosing.
 uaa:
   admin:
     client_secret: ADMIN_SECRET
   cc:
     client_secret: CC_CLIENT_SECRET
   clients:
     cc-service-dashboards:
       secret: CC_SERVICE_DASHBOARDS_SECRET
     cc_routing:
       secret: CC_ROUTING_SECRET
     cloud_controller_username_lookup:
       secret: CLOUD_CONTROLLER_USERNAME_LOOKUP_SECRET
     doppler:
       secret: DOPPLER_SECRET
     gorouter:
       secret: GOROUTER_SECRET
     tcp_emitter:
       secret: TCP-EMITTER-SECRET
     tcp_router:
       secret: TCP-ROUTER-SECRET
     login:
       secret: LOGIN_CLIENT_SECRET
     notifications:
       secret: NOTIFICATIONS_CLIENT_SECRET
  
Replace the values for all secret keys with secure secrets that you generate.
   jwt:
     verification_key: JWT_VERIFICATION_KEY
     -----BEGIN PUBLIC KEY-----
     PUBLIC_KEY
     -----END PUBLIC KEY-----
     signing_key: JWT_SIGNING_KEY
     -----BEGIN RSA PRIVATE KEY-----
     RSA_PRIVATE_KEY
     -----END RSA PRIVATE KEY-----
  

Generate a PEM-encoded RSA key pair, and replace JWT_SIGNING_KEY with the private key, and JWT_VERIFICATION_KEY with the corresponding public key. You can generate a key pair by running the following command:

openssl genrsa -des3 -out jwt-key.pem 2048 && openssl rsa -in jwt-key.pem -pubout > key.pub2

This command creates the jwt-key.pem.pub6 file, which contains your public key, and the jwt-key.pem file, which contains your private key. If you were prompted for a passphrase, you must strip it from the private key with the following command:

openssl rsa -in jwt-key.pem -out jwt-key.pem

Copy in the full keys, including the BEGIN and END delimiter lines.

   scim:
     users:
     - name: admin
       password: ADMIN_PASSWORD
  
Generate a secure password and replace ADMIN_PASSWORD with that value to set the password for the Admin user of your Cloud Foundry installation.
 ccdb:
   roles:
   - name: ccadmin
     password: CCDB_PASSWORD
 uaadb:
   roles:
     - name: uaaadmin
       password: UAADB_PASSWORD
 databases:
   roles:
   - name: ccadmin
     password: CCDB_PASSWORD
   - name: uaaadmin
     password: UAADB_PASSWORD
  
Replace CCDB_PASSWORD and UAADB_PASSWORD with secure passwords of your choosing.
 hm9000:
   ca_cert: HM9000_CA_CERT
   server_cert: HM9000_SERVER_CERT
   server_key: HM9000_SERVER_KEY
   agent_cert: HM9000_AGENT_CERT
   agent_key: HM9000_AGENT_KEY
  
Generate SSL certificates for HM9000 and replace these values. You can use the scripts/generate-hm9000-certs script in the cf-release repository to generate self signed certificates.
jobs:
 - name: ha_proxy_z1
   networks:
     - name: cf1
       default:
       - dns
       - gateway
   properties:
     ha_proxy:
       ssl_pem: |
         -----BEGIN RSA PRIVATE KEY-----
         RSA_PRIVATE_KEY
         -----END RSA PRIVATE KEY-----
         -----BEGIN CERTIFICATE-----
         SSL_CERTIFICATE_SIGNED_BY_PRIVATE_KEY
         -----END CERTIFICATE-----
  
Replace RSA_PRIVATE_KEY and SSL_CERTIFICATE_SIGNED_BY_PRIVATE_KEY with the PEM-encoded private key and certificate associated with the system domain and apps domains that you configured to terminate at the floating IP address associated with the ha_proxy job.

Note: You can configure blacklists of IP address ranges to prevent future apps deployed to your Cloud Foundry installation from attempting to drain syslogs to internal Cloud Foundry components. See theLog Drain Blacklist Configuration6 topic for more information.

 

3.9 - Install Spiff

To generate the Cloud Foundry manifest from the stub, the Spiff tool will be used. It can be installed following this procedure:

 

# wget https://github.com/cloudfoundry-incubator/spiff/releases/download/v1.0.8/spiff_linux_amd64.zip6

# unzip spiff_linux_amd64.zip

# mv spiff /root/bin

# export PATH=$PATH:/root/bin

 

3.10 - Generate the Cloud Foundry manifest

 

Generate the manifest by running the following command:

 

# cf-release/scripts/generate_deployment_manifest openstack /cm/shared/manifests/cf-stub.yml > /cm/shared/manifests/cf-deployment.yml

 

3.11 - Deploy the Cloud Foundry manifest

 

Set the generated manifest as the current deployment.

 

# bosh deployment /cm/shared/manifests/cf-deployment.yml

 

Download an Openstack stemcell from https://bosh.io/stemcells5, for example:

 

# wget https://s3.amazonaws.com/bosh-core-stemcells/openstack/bosh-stemcell-3363.14-openstack-kvm-ubuntu-trusty-go_agent.tgz4

 

Upload the stemcell to the BOSH director.

 

# bosh upload stemcell bosh-stemcell-3363.14-openstack-kvm-ubuntu-trusty-go_agent.tgz

 

Create the release.

 

# cd /root/cf-release

# bosh create release

 

Upload the release.

 

# bosh upload release

 

Deploy Cloud Foundry by running the following command:

 

# bosh deploy