Skip to content

Latest commit

 

History

History
95 lines (58 loc) · 4.63 KB

deploy-alongside-existing-cf.md

File metadata and controls

95 lines (58 loc) · 4.63 KB

Deploying Diego Alongside an Existing CF Deployment

This document describes a high-level overview for deploying a new Diego deployment to integrate with an existing CF deployment.

Table of Contents

  1. Configure Additional Infrastructure
  2. Configure CF Manifest for Diego
  3. Generate Diego Deployment Manifest
  4. Upload Additional Releases
  5. Deploy Relational Datastore
  6. Create and Upload Diego Release
  7. Deploy Diego

Configure Additional Infrastructure

Diego Subnets

Create the required subnets in your IaaS for Diego. If you are using multiple availability zones, create one subnet per zone.

Load Balancer

If not using the HAProxy job in the CF release for load balancing, create a load balancer for the Diego SSH proxy instances.

Configure CF Manifest for Diego

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.

See the cf/diego.yml stub from the AWS documentation example for one example of these configuration changes.

Required Changes

  • Change the instance counts on the consul_z1 and consul_z2 jobs so that at least one instance is running. At least three instances total are recommended for a highly available deployment.

Optional Changes

  • If you no longer wish to deploy DEAs at all any more:
    • Set the hm9000_z1 and hm9000_z2 instance counts to 0.
    • Set the runner_z1 and runner_z2 instance counts to 0.
  • For SSH access to instances, configure the app_ssh property section and add an appropriately configured ssh-proxy client to the list of UAA clients.
  • To make Diego the default container runtime for CF, enable the cc.default_to_diego_backend property.

After these changes have been made, redeploy CF.

Generate Diego Deployment Manifest

The Diego deployment integrates with services in the CF deployment, and so the generation of the manifest requires data in the CF deployment manifest. The generate-deployment-manifest script takes that CF manifest as the input to its -c flag. For example:

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 \
  > $DEPLOYMENT_DIR/deployments/diego.yml

The cf.yml file specified is the CF manifest as updated above.

See the manifest-generation script documentation for more information about the script arguments. For examples of these input stubs, see the BOSH-Lite deployment stubs or the full AWS documentation.

Upload Additional Releases

The Diego deployment requires several additional BOSH releases to be uploaded to the BOSH director, as they are referenced in the Diego manifest.

The releases to upload can be found at bosh.io/releases and include the following:

Deploy Relational Datastore

See documentation on data stores to select and deploy a relational data store to be used by BBS

Create and Upload Diego Release

Official release tarballs for Diego can be found on bosh.io.

Alternatively, clone the diego-release repository and create and upload a development release to the BOSH director using the following commands:

cd $DIEGO_RELEASE_DIR
bosh create release && bosh upload release

Deploy Diego

Once all the dependencies have been uploaded to the bosh director, deploy Diego to your environment:

bosh -d <path-to-diego-manifest-yml> deploy