These instructions allow you to:
- Provision an AWS account with preliminary resources and secrets,
- Deploy BOSH to AWS via
bosh-init
, and - Deploy CF and Diego via the deployed BOSH.
- Setting Up the Local Environment
- Creating the AWS Environment
- Deploying Cloud Foundry
- Deploying Diego
As part of the deployment process, you must install the following dependencies:
You must also clone the following git repositories from GitHub:
The deployment process requires that you create a directory for each deployment which will hold the necessary configuration to deploy BOSH, cf-release, and diego-release.
Before proceeding with setup, select a domain name you intend to use for your CF deployment. This domain name will be the base domain for all apps deployed to your Cloud Foundry instance, as well as the base domain for the Cloud Foundry system components. You will later create a Route 53 Hosted Zone for this domain to set up DNS entries for the deployment, so you should make sure you have access at your domain registrar to integrate these DNS settings into your domain.
Change into the directory you just created for the deployment and run the following to produce the deployment-env
file:
cat <<"EOF" > deployment-env
export DEPLOYMENT_DIR="$(cd $(dirname "$BASH_SOURCE[0]") && pwd)"
export CF_RELEASE_DIR="$HOME/workspace/cf-release"
export DIEGO_RELEASE_DIR="$HOME/workspace/diego-release"
export CF_DOMAIN=REPLACE_WITH_DEPLOYMENT_DOMAIN
echo "DEPLOYMENT_DIR set to '$DEPLOYMENT_DIR'"
echo "CF_RELEASE_DIR set to '$CF_RELEASE_DIR'"
echo "DIEGO_RELEASE_DIR set to '$DIEGO_RELEASE_DIR'"
echo "CF_DOMAIN set to '$CF_DOMAIN'"
EOF
Edit the deployment-env
file to replace REPLACE_WITH_DEPLOYMENT_DOMAIN
with the domain selected above. If you have not checked out cf-release and diego-release as subdirectories of ~/workspace
, also replace those default locations.
Run source deployment-env
to export these variables to your environment. They will be used extensively as $DEPLOYMENT_DIR
, $CF_RELEASE_DIR
, $DIEGO_RELEASE_DIR
, and $CF_DOMAIN
in commands and references below.
Before deploying the BOSH director, you must create the following resources in your AWS account through the AWS console:
- From the AWS console homepage, click on
Identity & Access Management
. - Click on the
Policies
link. - Click on the
Create Policy
button. - Select
Create Your Own Policy
. - Enter
bosh-aws-policy
as thePolicy Name
. - Enter the following as the
Policy Document
and click on theCreate Policy
button:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:DeleteServerCertificate",
"iam:UploadServerCertificate",
"iam:ListServerCertificates",
"iam:GetServerCertificate",
"cloudformation:*",
"ec2:*",
"s3:*",
"vpc:*",
"elasticloadbalancing:*",
"route53:*"
],
"Resource": "*"
}
]
}
- From the AWS console homepage, click on
Identity & Access Management
. - Click on
Users
link. - Click on the
Create New Users
button. - Fill in only one user name.
- Make sure that the
Generate an access key for each user
checkbox is checked and clickCreate
. - Click
Download Credentials
at the bottom of the screen. - Copy the downloaded
credentials.csv
file to$DEPLOYMENT_DIR
. - Click on the
Close
link to return to the IAM Users page. - Click on the user that you created.
- Click on the
Permissions
tab. - Click on the
Attach Policy
button. - Filter for
bosh-aws-policy
in the filter box - Select
bosh-aws-policy
and click on theAttach Policy
button
- From the AWS console homepage, click on
EC2
. - Click on the
Key Pairs
link in the sidebar, in theNetwork & Security
group. - Click the
Create Key Pair
button at the top of the page. - When prompted for the key name, enter a name that can be easily referred to later, for example:
bosh_keypair
. - Make the directory
$DEPLOYMENT_DIR/keypair
and move the downloadedbosh_keypair.pem
key to$DEPLOYMENT_DIR/keypair/id_rsa_bosh
. - Change the permissions on the new key file to
600
(rw-------
):chmod 600 $DEPLOYMENT_DIR/keypair/id_rsa_bosh
.
- From the AWS console homepage, click on
Route 53
. - Select
Hosted zones
from the left sidebar. - Click the
Create Hosted Zone
button. - Fill in the
$CF_DOMAIN
domain name you chose above for your Cloud Foundry deployment.
If you host this domain at another domain registrar, set the nameservers at that registrar to the DNS servers listed in the NS record in the AWS Hosted Zone.
After creating the necessary resources in AWS, you must populate
$DEPLOYMENT_DIR
in the following format. Each of the files is explained further
below.
DEPLOYMENT_DIR
|-(bootstrap_environment)
|-keypair
| |-(id_rsa_bosh)
|-certs
| |-(elb-cfrouter.key)
| |-(elb-cfrouter.pem)
|-stubs
| |-(domain.yml)
| |-infrastructure
| | |-(availablity_zones.yml)
| |-bosh-init
| |-(keypair.yml)
| |-(releases.yml)
| |-(users.yml)
| |-(stemcell.yml)
To create the directories, run the following commands:
cd $DEPLOYMENT_DIR
mkdir -p keypair
mkdir -p certs
mkdir -p stubs/infrastructure
mkdir -p stubs/bosh-init
This script exports your AWS default region and the access and secret keys of your IAM user as environment variables.
Run the following to create a new ``
Copy the template below into a new bootstrap_environment
file in `$DEPLOYMENT_DIR`
cat <<EOF > $DEPLOYMENT_DIR/bootstrap_environment
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=REPLACE_WITH_AKI
export AWS_SECRET_ACCESS_KEY='REPLACE_WITH_SECRET_ACCESS_KEY'
EOF
Next, replace the values prefixed with REPLACE_WITH_
as follows from the values in the credentials.csv
file downloaded during creation of the IAM user:
- For the
AWS_ACCESS_KEY_ID
variable, replaceREPLACE_WITH_AKI
with the access key id. - For the
AWS_SECRET_ACCESS_KEY
variable, replaceREPLACE_WITH_SECRET_ACCESS_KEY
with the secret access key.
Replace the value of AWS_DEFAULT_REGION
if you are deploying to a different AWS region.
This file is the private key pair generated as the AWS keypair for the BOSH director.
#### certs/elb-cfrouter.key
and certs/elb-cfrouter.pem
An SSL certificate for the domain where Cloud Foundry will be accessible is required. If you do not already provide a certificate, you can generate a self-signed certificate following the commands below.
cd $DEPLOYMENT_DIR/certs
openssl genrsa -out elb-cfrouter.key 2048
When prompted for the 'Common Name' in the next command, enter *.$CF_DOMAIN
, where $CF_DOMAIN
is the value you entered in the hosted zone setup. The other fields can be left blank.
openssl req -new -key elb-cfrouter.key -out elb-cfrouter.csr
openssl x509 -req -in elb-cfrouter.csr -signkey elb-cfrouter.key -out elb-cfrouter.pem
Run the following command to produce the stubs/domain.yml
stub file with the domain you selected above:
cat <<EOF > $DEPLOYMENT_DIR/stubs/domain.yml
---
domain: $CF_DOMAIN
EOF
Run the following to produce the stubs/infrastructure/availability_zones.yml
file, which defines the three availability zones to host your Cloud Foundry deployment.
cat <<EOF > $DEPLOYMENT_DIR/stubs/infrastructure/availability_zones.yml
---
meta:
availability_zones:
- us-east-1a
- us-east-1c
- us-east-1d
EOF
If you wish to use different availability zones, or to assign them a different order, edit this file to replace them. Note that these availability zones must be located in the AWS region specified in the bootstrap_environment
file.
Note: These zones could become restricted by AWS. If at some point during the deploy_aws_cli
script and you see an error
similar to the following message:
Value (us-east-1b) for parameter availabilityZone is invalid Subnets can currently only be created in the following availability zones: us-east-1d, us-east-1c, us-east-1a, us-east-1e
then update this file with acceptable availability zone values.
Run the following to create the stubs/bosh-init/keypair.yml
file:
cat <<EOF > $DEPLOYMENT_DIR/stubs/bosh-init/keypair.yml
---
BoshKeypairName: REPLACE_WITH_BOSH_KEYPAIR_NAME
EOF
Next, edit this file to replace REPLACE_WITH_BOSH_KEYPAIR_NAME
with the name of the keypair created on AWS keypair for the
BOSH director. For example:
---
BoshKeypairName: bosh_keypair
Run the following to create the stubs/bosh-init/releases.yml
file, which specifies the bosh
and bosh-aws-cpi
releases for bosh-init
to use to deploy the BOSH VM.
cat <<EOF > $DEPLOYMENT_DIR/stubs/bosh-init/releases.yml
---
releases:
- name: bosh
url: REPLACE_WITH_URL_TO_LATEST_BOSH_BOSH_RELEASE
sha1: REPLACE_WITH_SHA1_OF_LATEST_BOSH_BOSH_RELEASE
- name: bosh-aws-cpi
url: REPLACE_WITH_URL_TO_LATEST_BOSH_AWS_CPI_BOSH_RELEASE
sha1: REPLACE_WITH_SHA1_OF_LATEST_BOSH_AWS_CPI_BOSH_RELEASE
EOF
Next, replace the values in this file with the URLs and SHA1 checksums of the bosh
and bosh-aws-cpi
releases.
Releases for bosh
can be found here, and
releases for bosh-aws-cpi
can be found here.
For example:
releases:
- name: bosh
url: https://bosh.io/d/github.com/cloudfoundry/bosh?v=255
sha1: 923dfb8c26fab7041c0a3e591f0e92f3c4bca29e
- name: bosh-aws-cpi
url: https://bosh.io/d/github.com/cloudfoundry-incubator/bosh-aws-cpi-release?v=44
sha1: a1fe03071e8b9bf1fa97a4022151081bf144c8bc
Run the following to create the stubs/bosh-init/users.yml
file, which defines the admin users for the BOSH director.
cat <<EOF > $DEPLOYMENT_DIR/stubs/bosh-init/users.yml
---
BoshInitUsers:
- name: admin
password: REPLACE_WITH_BOSH_ADMIN_PASSWORD
EOF
Next, edit this file to replace the REPLACE_WITH_BOSH_ADMIN_PASSWORD
with the password you intend to use for the 'admin' BOSH user.
Run the following to create the stubs/bosh-init/stemcell.yml
file, which defines the stemcell to use to create the BOSH director.
cat <<EOF > $DEPLOYMENT_DIR/stubs/bosh-init/stemcell.yml
---
BoshInitStemcell:
url: REPLACE_WITH_URL_TO_LATEST_BOSH_AWS_HVM_STEMCELL
sha1: REPLACE_WITH_URL_TO_LATEST_BOSH_AWS_HVM_STEMCELL
EOF
Next, select an AWS Xen-HVM Light stemcell and edit the file to replace the url
and sha1
fields for that stemcell. For example:
---
BoshInitStemcell:
url: https://bosh.io/d/stemcells/bosh-aws-xen-hvm-ubuntu-trusty-go_agent?v=3232.6
sha1: 971e869bd825eb0a7bee36a02fe2f61e930aaf29
The bosh.io site does not currently provide the SHA1 hash of stemcells. You must download the stemcell locally and calcuate the SHA1 hash manually. On Mac OS X, this can be done by running:
shasum /path/to/downloaded/stemcell
In order to secure your Cloud Foundry deployment properly, you must generate SSL certificates and keys to secure traffic between components.
The CF and Diego release repositories provide scripts to generate the necessary SSL certificates.
- To generate certificates for consul, run:
cd $DEPLOYMENT_DIR/certs
$CF_RELEASE_DIR/scripts/generate-consul-certs
- To generate certificates for the etcd and BBS servers in the Diego deployment, run:
$DIEGO_RELEASE_DIR/scripts/generate-diego-certs
mv $DIEGO_RELEASE_DIR/diego-certs/* $DEPLOYMENT_DIR/certs
After running these scripts, you should see the following files in $DEPLOYMENT_DIR/certs
:
DEPLOYMENT_DIR/certs
|- diego-ca.crt
|- diego-ca.key
|- etcd-peer-ca.crt
|- etcd-peer-ca.key
|-bbs-certs # generated via diego-release/scripts/generate-diego-certs
| |- client.crt
| |- client.key
| |- server.crt
| |- server.key
|-consul-certs # generated via cf-release/scripts/generate-consul-certs
| |- agent.crt
| |- agent.key
| |- server-ca.crt
| |- server-ca.key
| |- server.crt
| |- server.key
|-etcd-certs # generated via diego-release/scripts/generate-diego-certs
| |- client.crt
| |- client.key
| |- server.crt
| |- server.key
| |- peer.crt
| |- peer.key
You can ignore any files with a crl
or csr
extension.
The certificates in consul-certs
are used to set SSL properties for the consul VMs, and the certificates in bbs-certs
and etcd-certs
are used to set SSL properties on the Diego etcd cluster and BBS API servers.
####Generating SSH Proxy Host Key and Fingerprint
To enable SSH access to CF instances running on Diego, generate a host key and fingerprint for the SSH proxy as follows, entering an empty string for the passphrase when prompted:
ssh-keygen -f $DEPLOYMENT_DIR/keypair/ssh-proxy-host-key.pem
If the local ssh-keygen
supports the -E
flag, as it does on OS X 10.11 El Capitan or Ubuntu 16.04 Xenial Xerus, generate the MD5 fingerprint of the public host key as follows:
ssh-keygen -lf $DEPLOYMENT_DIR/keypair/ssh-proxy-host-key.pem.pub -E md5 | cut -d ' ' -f2 | sed 's/MD5://g' > $DEPLOYMENT_DIR/keypair/ssh-proxy-host-key-fingerprint
Otherwise, generate the MD5 fingerprint as follows:
ssh-keygen -lf $DEPLOYMENT_DIR/keypair/ssh-proxy-host-key.pem.pub | cut -d ' ' -f2 > $DEPLOYMENT_DIR/keypair/ssh-proxy-host-key-fingerprint
The ssh-proxy-host-key.pem
file contains the PEM-encoded private host key for the Diego manifest, and the ssh-proxy-host-key-fingerprint
file contains the MD5 fingerprint of the public host key. You will later copy these values into stubs for generating the CF and Diego manifests.
UAA requires an RSA keypair for its configuration. Generate one as follows, entering an empty string for the passphrase when prompted:
ssh-keygen -t rsa -b 4096 -f $DEPLOYMENT_DIR/keypair/uaa
openssl rsa -in $DEPLOYMENT_DIR/keypair/uaa -pubout > $DEPLOYMENT_DIR/keypair/uaa.pub
To create the AWS environment and two VMs essential to the Cloud Foundry infrastructure,
run ./deploy_aws_environment create "$CF_RELEASE_DIR" "$DEPLOYMENT_DIR"
from the directory containing these instructions ($DIEGO_RELEASE_DIR/examples/aws
).
This process may take up to 30 minutes.
cd "$DIEGO_RELEASE_DIR/examples/aws"
./deploy_aws_environment create "$CF_RELEASE_DIR" "$DEPLOYMENT_DIR"
The ./deploy_aws_environment
script takes three required arguments and a fourth, optional argument:
-
The first argument is one of three directives, which you'll need if our script doesn't succeed the first time:
create
creates an AWS CloudFormation stack based off of the stubs filled out above.update
updates the CloudFormation stack. Run the script with this command after changing the stubs in$DEPLOYMENT_DIR/stubs/infrastructure
, or after an update to this example directory. If there are no changes to the stack, instead run theskip
command below, as otherwise the script will fail.skip
upgrades the BOSH director without affecting the CloudFormation stack.
-
The second argument is the absolute path to
$CF_RELEASE_DIR
. -
The third argument is the absolute path to
$DEPLOYMENT_DIR
, which must be structured as defined above. -
The fourth (optional) argument is the stack name for the deployment environment which, if provided, overrides the default environment name
cf-diego-stack
.
The deployment process generates a collection of stubs, in the following directory structure. Some of the stubs start with the line GENERATED: NO TOUCHING
, and are not intended for hand-editing.
DEPLOYMENT_DIR
|-stubs
| |- director-uuid.yml # the unique id of the BOSH directory
| |- aws-resources.yml # general metadata about the CloudFormation stack
| |-cf
| | |- stub.yml # networks, zones, s3 buckets for the Cloud Foundry deployment
| | |- properties.yml # consul configuration and shared secrets
| | |- domain.yml # domain
| |-diego
| | |- property-overrides.yml # stub to parametrize with Diego manifest property overrides
| | |- iaas-settings.yml # networks, zones for the Diego deployment
| |-infrastructure
| |- certificates.yml # certificates for the cfrouter ELB
| |- cloudformation.json # CloudFormation JSON deployed to AWS
|-deployments
| |-bosh-init
| |- bosh-init.yml # bosh director deployment
The ./deploy_aws_environment
script generates a partial stub for your
Cloud Foundry deployment. It is a generated stub that contains information specific to the AWS CloudFormation stack and should not be edited manually.
The ./deploy_aws_environment
script copies another partial stub for your
Cloud Foundry deployment. This stub is intended to be editied, as describes in more detail in the
Manifest Generation section.
This stub will be used as part of Diego manifest generation and was constructed from your deployed AWS infrastructure, as well as our default template. This stub provides the skeleton for the certificates generated in the Configuring Security section, as well as for setting the log levels of components.
This stub is during Diego manifest generation. It contains settings specific to your AWS environment.
For your BOSH director to be accessible on the Internet via DNS using the Route 53 hosted zone created above, perform the following steps:
- From the EC2 dashboard, obtain the public IP address of the
bosh/0
BOSH director instance. - Click on the
Route53
link on the AWS console. - Click the
Hosted Zones
link. - Click on the hosted zone created earlier.
- Click the
Create Record Set
button. - Enter
bosh
for theName
. - Change the
Type
toA - IPv4 address
if it is not already set to that type. - Enter the public IP address of the BOSH director for the value.
- Click the
Create
button.
If using RDS MySQL, follow the directions in Setup AWS RDS MySQL to configure and create the RDS instance. You can also deploy a CF-MySQL cluster if you so choose, but that should be done after deploying your initial CF deployment below.
To deploy Cloud Foundry, you need a stub similar to the one from the Cloud Foundry Documentation.
The generated stub $DEPLOYMENT_DIR/stubs/cf/stub.yml
already has some of these properties filled out for you.
The stub $DEPLOYMENT_DIR/stubs/cf/properties.yml
contains some additional placeholder properties that you must specify.
For more information on stubs for Cloud Foundry manifest generation, please refer to the documentation here.
The default deployment configuration from the manifest-generation scripts in cf-release omits some instances and properties that Diego depends on.
It also includes some instances and properties that are unnecessary for a deployment with Diego as the only container runtime. Including $DIEGO_RELEASE_DIR/examples/aws/stubs/cf/diego.yml
in the list of stubs when generating the Cloud Foundry manifest will configure these instance counts and properties correctly.
In order to correctly generate a manifest for the Cloud Foundry deployment, you must
replace certain values in the provided $DEPLOYMENT_DIR/stubs/cf/properties.yml
.
Replace all the values that are prefixed with REPLACE_WITH_
.
Note: If you did not generate a self-signed certificate for the
CF Router ELB and are instead using a certificate signed by a
trusted certificate authority, change the value of properties.ssl.skip_cert_verify
from true
to false
.
If you also wish to change the instance counts for the jobs in the CF deployment, add those different counts to this stub. These counts will override the counts set in the $DIEGO_RELEASE_DIR/examples/aws/stubs/cf/diego.yml
if using the command below to generate the manifest.
If you wish to enable volume services add the following property to the cc
section of $DEPLOYMENT_DIR/stubs/cf/properties.yml
:
cc:
...
volume_services_enabled: true
After following the instructions to fill out the placeholder values
in the DEPLOYMENT_DIR/stubs/cf/stub.yml
stub, run the following to generate the Cloud Foundry manifest:
cd $CF_RELEASE_DIR
./scripts/generate_deployment_manifest aws \
$DEPLOYMENT_DIR/stubs/director-uuid.yml \
$DIEGO_RELEASE_DIR/examples/aws/stubs/cf/diego.yml \
$DEPLOYMENT_DIR/stubs/cf/properties.yml \
$DEPLOYMENT_DIR/stubs/cf/stub.yml \
> $DEPLOYMENT_DIR/deployments/cf.yml
Target the BOSH director using either the public IP address or the Route53 record created earlier.
The public IP address can be obtained from either the $DEPLOYMENT_DIR/stubs/aws-resources.yml
under Resources.EIP.BoshInit
or from the EC2 dashboard in the AWS console.
bosh target bosh.$CF_DOMAIN
When prompted for the username and password, provide the credentials set in the $DEPLOYMENT_DIR/stubs/bosh-init/users.yml
stub.
Upload the lastest BOSH stemcell for AWS to the bosh director. You can find the latest stemcell here.
bosh upload stemcell /path/to/stemcell
In order to deploy CF, create and upload the release to the director using the following commands:
cd $CF_RELEASE_DIR
bosh --parallel 10 create release
bosh upload release
Set the CF deployment manifest and deploy with the following commands:
bosh deployment $DEPLOYMENT_DIR/deployments/cf.yml
bosh deploy
From here, follow the documentation on deploying a Cloud Foundry with BOSH. Depending on the size of the deployment and the time required for package compilation, the initial deploy can take many minutes or hours.
To use a CF-MySQL deployment as the Diego data store, follow the directions in Setup CF-MySQL to configure and create the CF-MySQL cluster.
If you enabled volume services, create and upload your Driver's bosh release.
If you would like to use the cephdriver
that we use for testing and development then you may use this repo.
After deploying Cloud Foundry, you can now deploy Diego.
To generate a manifest for the Diego deployment, replace the properties in the
$DEPLOYMENT_DIR/stubs/diego/property-overrides.yml
file that are prefixed with REPLACE_WITH_
.
Here is a summary of the properties that must be changed:
- Replace all instances of
REPLACE_WITH_ACTIVE_KEY_LABEL
with the desired key name (for example,key-a
). - Replace
REPLACE_WITH_A_SECURE_PASSPHRASE
with a unique passphrase associated with the active key label.
Component log levels and other deployment properties may also be overridden in this stub file.
This stub file also contains the contents of the BBS, etcd, and SSH-Proxy certificates and keys generated above. If those files are regenerated, the deploy_aws_environment
script will update the property-overrides stub with their new contents.
Copy the example stub to $DEPLOYMENT_DIR/stubs/diego/instance-count-overrides.yml
:
cp $DIEGO_RELEASE_DIR/examples/aws/stubs/diego/instance-count-overrides-example.yml $DEPLOYMENT_DIR/stubs/diego/instance-count-overrides.yml
Edit that file to change the instance counts of the deployed Diego VMs.
Copy the example release-versions stub to the correct location:
cp $DIEGO_RELEASE_DIR/examples/aws/stubs/diego/release-versions.yml $DEPLOYMENT_DIR/stubs/diego/release-versions.yml
Edit it to fix the versions of the Diego, Garden-Linux, and etcd releases in the Diego deployment, instead of using the latest versions uploaded to the BOSH director.
For example, to use version 22 of etcd-release and version 0.331.0 of garden-linux-release, edit the stub to read:
release-versions:
diego: latest
etcd: 22
garden_linux: 0.331.0
cflinuxfs2_rootfs: 0.2.0
If using a SQL store for the BBS, follow the directions to fill in the Diego-SQL Stub with the SQL database configuration.
If you enabled volume services, follow these directions to fill in the drivers Stub with your driver configuration.
See the full manifest generation documentation for more generation instructions.
Remember that the -n
instance-count-overrides flag and the -v
release-versions flags are optional. If using a non-standard deployment (SQL, Volume Drivers, Garden-RunC, etc) follow the generate the Diego manifest optional instructions.
cd $DIEGO_RELEASE_DIR
./scripts/generate-deployment-manifest \
-c $DEPLOYMENT_DIR/deployments/cf.yml \
-i $DEPLOYMENT_DIR/stubs/diego/iaas-settings.yml \
-p $DEPLOYMENT_DIR/stubs/diego/property-overrides.yml \
-n $DEPLOYMENT_DIR/stubs/diego/instance-count-overrides.yml \
-v $DEPLOYMENT_DIR/stubs/diego/release-versions.yml \
> $DEPLOYMENT_DIR/deployments/diego.yml
-
Upload the latest garden-linux-release:
bosh upload release https://bosh.io/d/github.com/cloudfoundry-incubator/garden-linux-release
To upload a specific version of garden-linux-release, or to download the release locally before uploading it, please consult directions at bosh.io.
-
Upload the latest etcd-release:
bosh upload release https://bosh.io/d/github.com/cloudfoundry-incubator/etcd-release
To upload a specific version of etcd-release, or to download the release locally before uploading it, please consult directions at bosh.io.
-
Upload the latest cflinuxfs2-rootfs-release:
bosh upload release https://bosh.io/d/github.com/cloudfoundry/cflinuxfs2-rootfs-release
To upload a specific version of cflinuxfs2-rootfs-release, or to download the release locally before uploading it, please consult directions at bosh.io.
As with the Cloud Foundry deployment, once the Diego manifest is generated, you need to create the Diego release, upload it to the BOSH director, and deploy Diego:
bosh deployment $DEPLOYMENT_DIR/deployments/diego.yml
cd $DIEGO_RELEASE_DIR
bosh --parallel 10 create release --force
bosh upload release
bosh deploy