Date
1 - 6 of 6
Recipe to install Diego?
|
Lev Berman <lev.berman@...>
Hi,
toggle quoted message
Show quoted text
I can share my experience on installing Diego on AWS. I followed the instructions for BOSH Lite deployment <https://github.com/cloudfoundry-incubator/diego-release#deploying-diego-to-a-local-bosh-lite-instance>except for the fact I replaced 3 templates with the ones you can find in the attachment. Note that in my case instance-count-overrides.yml leads to a one-AZ deployment. Prerequisites include creating a separate AWS subnet for Diego. Also, you need to configure routes and security groups in the same manner you did it for Cloud Foundry. On Sat, May 9, 2015 at 2:57 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:
Hi, --
Lev Berman Altoros - Cloud Foundry deployment, training and integration Github *: https://github.com/ldmberman <https://github.com/ldmberman>* |
|
|
|
Ken Ojiri
Hi,
toggle quoted message
Show quoted text
I have posted a sample BOSH deployment manifest to Gist. https://gist.github.com/ozzozz/4c08c37863b703a75afc I could deploy cf-release v207 and diego-release 0.1099.0 to AWS Tokyo region by MicroBOSH. I could also deploy cf-release and diego-release to OpenStack(Juno). The manifests differs only in 'networks', 'cloud_properties' and 'stemcell'. Regards, Ken --- <ozzozz(a)gmail.com> Mitaka, Tokyo Japan On Sat, May 9, 2015 at 8:57 PM, Tom Sherrod <tom.sherrod(a)gmail.com> wrote:
Hi, |
|
|
|
王天青 <wang.tianqing.cn at gmail.com...>
Hi Ken,
toggle quoted message
Show quoted text
How do you generate the manifest file? Thanks Best Regards~! Grissom On Mon, May 11, 2015 at 9:17 PM OzzOzz <ozzozz(a)gmail.com> wrote:
Hi, |
|
|
|
Ken Ojiri
Hi,
toggle quoted message
Show quoted text
I use spiff manifest templates included by cf-release and diego-release, and generate manifests by spiff, but I usually use the manifests as reference materials. I finally adjust my own manifests by refering to spiff generated manifests, job definitions of cf-release and/or diego-release, and do try-and-error... Now, setting parameters of diego components are changing with every version, so job definitions of diego-release are essential reference. Regards, Ken Ojiri --- Ken Ojiri <ozzozz(a)gmail.com> Mitaka, Tokyo Japan On Tue, May 12, 2015 at 5:56 PM, 王天青 <wang.tianqing.cn(a)gmail.com> wrote:
Hi Ken, |
|
|
|
Eric Malm <emalm@...>
Hi, Tom,
toggle quoted message
Show quoted text
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 <https://github.com/cloudfoundry-incubator/diego-release/blob/develop/scripts/ci/deploy_diego>, 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. Thanks, Eric Malm, CF Runtime Diego PM On Tue, May 12, 2015 at 8:48 AM, Ken Ojiri <ozzozz(a)gmail.com> wrote:
Hi, |
|
|
|
Xianfeng Ye
Thanks all!
toggle quoted message
Show quoted text
Xianfeng Ye On Mon, May 11, 2015 at 9:17 PM, OzzOzz <ozzozz(a)gmail.com> wrote:
Hi, |
|
|