pivotal-cf/cf-redis-release

Name: cf-redis-release

Owner: Pivotal Cloud Foundry

Description: null

Created: 2015-01-26 15:24:42.0

Updated: 2018-05-24 12:06:01.0

Pushed: 2018-05-24 12:05:59.0

Homepage: null

Size: 4918

Language: Ruby

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

Cloud Foundry Redis Release

This repository contains a BOSH release for a Cloud Foundry Redis service broker. It will support dedicated and shared-vm plans.

There is no active feature development for this repository. Please note that some features might change or get removed in future commits.

clone https://github.com/pivotal-cf/cf-redis-release ~/workspace/cf-redis-release
/workspace/cf-redis-release
submodule update --init --recursive

Deployment dependencies

1. BOSH CLI v2+ (you may use the old BOSH CLI but instructions will use the new one)
2. direnv (or set environment variables yourself)
3. a bosh director
4. a cloud foundry deployment

Setup

1. fill out the following environment variables of the .envrc.template file and save as .envrc or export them:
2. BOSH_ENVIRONMENT
3. BOSH_CA_CERT
4. BOSH_CLIENT
5. BOSH_CLIENT_SECRET
6. BOSH_DEPLOYMENT
7. in case you are using direnv

   nv allow
   

8. upload routing release

    upload-release http://bosh.io/d/github.com/cloudfoundry-incubator/cf-routing-release?v=0.161.0
   

9. upload syslog-migration release 11

    upload-release https://github.com/pivotal-cf/syslog-migration-release/releases/download/v8/syslog-migration-11.tgz
   

Deployment

Populate a vars file (using manifest/vars-lite.yml as a template), save it to secrets/vars.yml. You will need values from both your cloud-config and secrets from your cf-deployment.

To deploy:

 upload-stemcell https://s3.amazonaws.com/bosh-core-stemcells/warden/bosh-stemcell-3363.27-warden-boshlite-ubuntu-trusty-go_agent.tgz
 create-release
 upload-release
 deploy --vars-file secrets/vars.yml manifest/deployment.yml

 if you are deploying on GCP:
 deploy --vars-file secrets/vars.yml manifest/deployment.yml --ops-file manifest/ops-public-ip-gcp.yml
is ops-file adds a GCP specific vm_extension: `public_ip`, which is required to allow
stances to send outgoing public traffic. e.g. for the broker_registrar to register with the CF.

Network Configuration

The following ports and ranges are used in this service:

• broker vm, port 12350: access to the broker from the cloud controllers
• broker vm, ports 32768-61000: on the service broker from the Diego Cell and Diego Brain network(s). This is only required for the shared service plan
• dedicated node, port 6379: access to all dedicated nodes from the Diego Cell and Diego Brain network(s)

Testing

1. install gem requirements

   le install
   

2. run the tests

   le exec rspec spec`
   

Related Documentation

• BOSH
• Service Broker API
• Redis

Known Issues

Possible Data Leak when disabling Static IPs

In the past cf-redis-release expected to be deployed with static IPs for dedicated nodes specified in the manifest. It is often more desired to deploy without static IPs leaving BOSH to manage IP allocation.

There is a risk of data leak when transitioning from static to dynamic IPs. Consider the following scenario:

The operator:

1. has deployed cf-redis-release with static IPs
2. now decides to use dynamic IP allocation, and removes the static IPs from the manifest
3. then DOES NOT remove the static IPs from cloud config
4. re-deploys cf-redis-release with the new manifest

In the previous scenario BOSH will dynamically allocate IPs to the dedicated instances. BOSH will not try to re-use the previous IPs since those are still restricted in the cloud config. Since the IPs have changed, application bindings will break and the state in the broker will be out of sync with the new deployment. It is possible that previously allocated instances containing application data are erroneously re-allocated to another unrelated application, causing data to be leaked.

In order to avoid this scenario, the operator must remove the reserved static IPs in the cloud config at the same time as they are remove from the manifest. This will allow BOSH to keep the same IP addresses for the existing nodes.

To safely transition from static to dynamic IPs:

1. look up the static IPs that were specified in the manifest when deploying your dedicated nodes
2. ensure these IPs are no longer included in the static range of the network in your cloud config
3. remove the static IPs from the manifest
4. deploy using the manifest without static IPs