The Diego team does deploy Diego to AWS as part of our testing pipeline. We haven't fully published our tooling for doing so, but you can see some of our process in the deploy_diego CI script in diego-release
, which uses diego-release's generate-deployment-manifest script. This script is set up differently from the generate_deployment_manifest script in cf-release, in that it takes a fixed sequence of stubs and a deployment directory as arguments instead of an infrastructure type and an arbitrary list of stubs to merge in. The full list of stubs is described in the usage message for the script, but here are the parts that should be most relevant for you to deploy Diego to AWS or OpenStack:
- IaaS settings (arg #5): This is a stub that should contain an "iaas_settings" hash with several expected subfields (compilation_cloud_properties, resource_pool_cloud_properties, stemcell, subnet_configs). The manifest generation script takes these values and uses them to populate certain fields in the diego manifest's resource_pools, networks, and compilation sections. This will likely be the stub you need to customize the most for an AWS or OpenStack deployment, as this will contain all the information about the network and security group configuration for that environment.
- Deployments directory (arg #7): This is a directory that should contain your CF deployment manifest as the file 'cf.yml'. The manifest generation script will extract certain values from the CF manifest so the Diego deployment can integrate correctly with various services in CF (for example, NATS and consul).
- Director UUID (arg #1): This is a stub containing "director_uuid: <your-director-uuid>"; you may already have such a stub for generating your CF manifest.
- Instance count overrides (arg #3): This is a stub containing any instance-count changes for the diego jobs. Depending on the size of your desired cluster, you'll want to change these values from the defaults that the manifest-generation/diego.yml template provides in the jobs section.
Depending on how you wish to configure the Diego deployment, there may be some additional properties you want to add to the property-overrides stub (arg #2). I doubt you'll need to change anything in the persistent-disk overrides or additional-jobs stubs (args #4 and #6), unless you're customizing your deployment extensively. In any case, the stubs under manifest-generation/bosh-lite-stubs should give you examples to customize for your own deployment, and the manifest-generation/diego.yml template will show you which values from those stubs are consumed in manifest generation.
Also, as Diego matures and becomes the principal backend for running application instances in CF, these manifest-generation patterns may change substantially.
Eric Malm, CF Runtime Diego PM