{"id":31904405,"url":"https://github.com/cloudfoundry-community/cf-boshworkspace","last_synced_at":"2026-03-06T05:34:13.302Z","repository":{"id":19365243,"uuid":"22605264","full_name":"cloudfoundry-community/cf-boshworkspace","owner":"cloudfoundry-community","description":"Deploy Cloud Foundry using bosh-workspace","archived":false,"fork":false,"pushed_at":"2015-11-26T09:24:23.000Z","size":364,"stargazers_count":7,"open_issues_count":2,"forks_count":18,"subscribers_count":19,"default_branch":"master","last_synced_at":"2024-04-14T22:47:38.803Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cloudfoundry-community.png","metadata":{"files":{"readme":"README.md","changelog":"ChangeLog.md","contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2014-08-04T13:33:51.000Z","updated_at":"2024-02-09T14:28:54.000Z","dependencies_parsed_at":"2022-07-27T00:16:16.168Z","dependency_job_id":null,"html_url":"https://github.com/cloudfoundry-community/cf-boshworkspace","commit_stats":null,"previous_names":[],"tags_count":19,"template":false,"template_full_name":null,"purl":"pkg:github/cloudfoundry-community/cf-boshworkspace","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudfoundry-community%2Fcf-boshworkspace","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudfoundry-community%2Fcf-boshworkspace/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudfoundry-community%2Fcf-boshworkspace/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudfoundry-community%2Fcf-boshworkspace/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cloudfoundry-community","download_url":"https://codeload.github.com/cloudfoundry-community/cf-boshworkspace/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloudfoundry-community%2Fcf-boshworkspace/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":279015347,"owners_count":26085686,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-13T02:00:06.723Z","response_time":61,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-10-13T13:48:57.753Z","updated_at":"2025-10-13T13:49:39.185Z","avatar_url":"https://github.com/cloudfoundry-community.png","language":"Ruby","funding_links":[],"categories":[],"sub_categories":[],"readme":"cf-boshworkspace\n================\n\nThis project's purpose is to help you easily deploy CloudFoundry in various\nconfigurations, small to large, in AWS (Openstack support coming soon). You will\nneed an extant microbosh instance - see [bosh-bootstrap](https://github.com/cloudfoundry-community/bosh-bootrap)\nfor an easy-to-use way to get microbosh running.\n\nYou may also want to look at [terraform-aws-cf-install](https://github.com/cloudfoundry-community/terraform-aws-cf-install)\nfor even more automation around this process.\n\n## Deploy Cloud Foundry\n\n__Create deployment file__\nJust as with the microbosh deployment file we need to fill in some information in our Cloud Foundry deployment file.\n\n```\nexport CF_DOMAIN=\u003cdomain, like prod.mycloudfoundry.domain or 1.2.3.4.xip.io\u003e\nexport CF_ADMIN_PASS=\u003cpassword to use for CF admin, like c1oudc0wc10udc0w\u003e\nexport CF_ELASTIC_IP=\u003cElastic IP that will be used as API endpoint, must be allocated but not assigned\u003e\nexport IPMASK=\u003cFirst two octects of IP range to use, set in 10.x, like 10.10\u003e\nexport CF_SUBNET1=\u003cID of first subnet to use for CF machines, like sg-deadbeef\u003e\nexport CF_SUBNET2=\u003cID of second subnet to use for CF machines, like sg-deadbeef\u003e\nexport LB_SUBNET1=\u003cID of subnet to use for loadbalancer, like sg-deadbeef\u003e\nexport CF_SG=\u003cName of the security group to use for Cloud Foundry machines, like cf or cf-security-group\u003e\nexport CF_SUBNET1_AZ=\u003cAvailability Zone of CF_SUBNET1\u003e\nexport CF_SUBNET2_AZ=\u003cAvailability Zone of CF_SUBNET2\u003e\nexport LB_SUBNET1_AZ=\u003cAvailability Zone of LB_SUBNET1\u003e\nexport DIRECTOR_UUID=$(bosh status | grep UUID | awk '{print $2}')\n```\n\nNow lets replace the placeholders in `cf-aws-tiny.yml` (you can replace that with `cf-aws-large.yml` in the loop below and get the bigger deployment)\n\n```bash\nfor VAR in CF_DOMAIN CF_ADMIN_PASS CF_ELASTIC_IP IPMASK CF_SUBNET1_AZ CF_SUBNET2_AZ LB_SUBNET1_AZ CF_SUBNET1 CF_SUBNET2 LB_SUBNET1 CF_SG DIRECTOR_UUID\ndo\n  eval REP=\\$$VAR\n  perl -pi -e \"s/$VAR/$REP/g\" deployments/cf-aws-tiny.yml\ndone\n```\n\n__Upload dependencies__\nOur Cloud Foundry deployment depends on the `cf-release` and on the `bosh-stemcell`, before we can deploy we will need to make sure those dependencies have been resolved. Luckily the bosh-workspace has built-in support for resolving those depedencies.\n```\nbosh deployment cf-aws-tiny\nbosh prepare deployment\n```\n\u003e Alternatively when not using an inception server, you can use a remote release: \n`bosh upload release https://community-shared-boshreleases.s3.amazonaws.com/boshrelease-cf-196.tgz`\n\n__Deploy__\nWith the dependencies resolved it's time to deploy Cloud Foundry version 196. The following changes have been made to the standard amazon templates:\n\n- [Use haproxy instead of elbs](https://github.com/starkandwayne/cf-boshworkspace/blob/master/templates/cf-use-haproxy.yml)\n- [Use postgresql instead of rds](https://github.com/starkandwayne/cf-boshworkspace/blob/master/templates/cf-use-postgresql.yml)\n- [Use nfs instead of an s3 bucket for blobs](https://github.com/starkandwayne/cf-boshworkspace/blob/master/templates/cf-use-nfs.yml)\n- [All secrets have been set to _c1oudc0w_](https://github.com/starkandwayne/cf-boshworkspace/blob/master/templates/cf-secrets.yml#L95)\n- [SSL has been disabled](https://github.com/starkandwayne/cf-boshworkspace/blob/master/templates/cf-no-ssl.yml)\n- [Single availability zone deployment](https://github.com/starkandwayne/cf-boshworkspace/blob/master/templates/cf-single-az.yml)\n\nWith the above changes __7 vms__ of different sizes will be deployed. If you use cf-aws-large.yml, it will be __19 vms__.\n\n```\nbosh deploy\n```\n\n## Scaling cf-aws-tiny\n\nTo achieve the VM savings over cf-aws-large.yml cf-aws-tiny.yml colocates a number of like jobs on the same VMs, allowing\nyou to scale groups of services with eachother. Here's a breakdown of what's running where, to help you decide which VMs to\nscale, based on your traffic patterns:\n\n| VM Name | Role | Jobs |\n|------|----|-------------|\n| data | Data Services | `postgres` `debian_nfs_server` `metron_agent` `consul_agent` |\n| haproxy_z1 | Optional LoadBalancer | `haproxy` `metron_agent` `consul_agent` |\n| api_z1 | Cloud Controller/Router | `routing-api` `gorouter` `cloud_controller_ng` `nfs_mounter` ` metron_agent` `consul_agent` |\n| api_z2 | Cloud Controller/Router | `routing-api` `gorouter` `cloud_controller_ng` `nfs_mounter` ` metron_agent` `consul_agent` |\n| backbone_z1 | Infrastructural Services | `nats` `nats_stream_forwarder` `doppler` `syslog_drain_binder` `etcd` `etcd_metrics_server` `metron_agent` `consul_agent` |\n| backbone_z2 | Infrastructural Services | `nats` `nats_stream_forwarder` `doppler` `syslog_drain_binder` `etcd` `etcd_metrics_server` `metron_agent` `consul_agent` |\n| health_z1 | Health Checking Services | `loggregator_trafficcontroller` `hm9000` `cloud_controller_clock` `collector` `metron_agent` `consul_agent` |\n| health_z2 | Health Checking Services | `loggregator_trafficcontroller` `hm9000` `cloud_controller_clock` `collector` `metron_agent` `consul_agent` |\n| services_z1 | Support Services | `uaa` `login` `cloud_controller_worker` `nfs_mounter` `metron_agent` `consul_agent` |\n| services_z2 | Support Services | `uaa` `login` `cloud_controller_worker` `nfs_mounter` `metron_agent` `consul_agent` |\n| runner_z1 | DEA nodes | `dea_next` `dea_logging_agent` `metron_agent` `consul_agent` |\n| runner_z2 | DEA nodes | `dea_next` `dea_logging_agent` `metron_agent` `consul_agent` |\n\nBy default, none of the \\*\\_z2 nodes are enabled in cf-aws-tiny.yml, to keep the basic deployment minimal.\nIf you wish to make your deployment more fault tolerant, deploy some \\*\\_z2 instances to run in your second availability zone.\n\n## Migrating from cf-tiny-dev to cf-tiny-scalable\n\nPreviously, a template called _cf-tiny-dev_ had been used to consolidate jobs into a small number of VMs. Recently, that\nhas been replaced with _cf-tiny-scalable_, allowing for multi-AZ scalable deployments of CloudFoundry on a smaller footprint\nthan the upstream deployment. However, it involved some job name changes, which requires some extra care when migrating from\none to the other. These steps are laid out below:\n\n1. Edit `templates/tiny/cf-tiny-dev.yml` to prepare the services machine for the migration (don't worry, this file won't be used\n   soon, so you dont need to worry about any future merge conflicts)\n   1. Remove the `etcd` template declaration from the `services` job definition\n    ```diff\ndiff --git a/templates/tiny/cf-tiny-dev.yml b/templates/tiny/cf-tiny-dev.yml\nindex 5ecfec9..2c2e9d5 100644\n--- a/templates/tiny/cf-tiny-dev.yml\n+++ b/templates/tiny/cf-tiny-dev.yml\n@@ -65,22 +65,20 @@ meta:\n \n   services_templates:\n   - name: uaa\n     release: (( meta.release.name ))\n   - name: login\n     release: (( meta.release.name ))\n   - name: cloud_controller_worker\n     release: (( meta.release.name ))\n   - name: metron_agent\n     release: (( meta.release.name ))\n-  - name: etcd\n-    release: (( meta.release.name ))\n   - name: nfs_mounter\n     release: (( meta.release.name ))\n \n   dea_templates:\n   - name: dea_next\n     release: (( meta.release.name ))\n   - name: dea_logging_agent\n     release: (( meta.release.name ))\n   - name: metron_agent\n     release: (( meta.release.name ))\n```\n    Removing the `etcd` job from the `services` VM up-front reduces the chance of errors during migration due to `etcd` failing\n    to start while the VM is being renamed.\n\n1. Deploy the above changes with `bosh deploy`.\n\n1. ```bosh ssh services``` to log into the services VM, and run ```sudo rm -rf /var/vcap/store/etcd``` to clean out the previous etcd data. This\nwill prevent etcd from having issues when migrating to cf-tiny-scalable, where etcd is *only* run on the services nodes.\n\n1. **CAUTION!** Do ***NOT*** run `bosh deploy` at any further point during the migration, unless the instructions indicate it. This will\n    erase your current deployment manifest, which you will have been manually updating to prepare the migration. You will\n    then have a large headache, and a mouth full of explitives.\n\n1.  Rename existing jobs:\n    ```bash\nfor job in health services api haproxy; do\n    # edit the instance names in your deployment\n    vi .deployments/cf-aws-tiny.yml  # NOTE: '.deployments', not 'deployments'\n\n    # rename the bosh job - takes about 1 min per job\n    bosh rename job $job ${job}_z1\ndone\n```\n    Beware of using `sed` for the above steps - bosh won't let you rename if you make any changes other than job name.\n\n    **NOTE:** If you happen to run into issues renaming a job, `bosh ssh` into the VM, find what service is failing, via\n    `/var/vcap/bosh/bin/monit summary`, and troubleshoot the service until it will start up normally. Then retry the `bosh rename job`\n    task.\n\n1.  Ensure all VMs are named correctly:\n   ```\n$ bosh vms\nDeployment 'cf-aws-tiny'\nDirector task 210\nTask 210 done\n+---------------+---------+---------------+-------------+\n| Job/index     | State   | Resource Pool | IPs         |\n+---------------+---------+---------------+-------------+\n| api_z1/0      | running | medium_z1     | 10.10.3.7   |\n| data/0        | running | large_z1      | 10.10.3.10  |\n| haproxy_z1/0  | running | small_z1      | 52.7.24.173 |\n|               |         |               | 10.10.2.6   |\n| health_z1/0   | running | medium_z1     | 10.10.3.9   |\n| runner_z1/0   | running | runner_z1     | 10.10.3.57  |\n| services_z1/0 | running | medium_z1     | 10.10.3.8   |\n+---------------+---------+---------------+-------------+\n```\n    Depending on your deployment, the IPs and resource pools may differ.\n\n1.  Update your deployment template (something like `deployments/cf-aws-tiny.yml`) to include the `tiny/cf-tiny-scalable.yml` template, instead of `tiny/cf-tiny-dev.yml`\n1.  Generate + deploy the new manifest via `bosh deploy`\n1.  Celebrate by cracking open a tasty beverage!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcloudfoundry-community%2Fcf-boshworkspace","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcloudfoundry-community%2Fcf-boshworkspace","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcloudfoundry-community%2Fcf-boshworkspace/lists"}