This repository contains a BOSH release for a Cloud Foundry Redis service broker. It supports shared-vm plans. Dedicated-vm plans are being deprecated.
There is no active feature development for this repository. The repository will be supported until July 31st 2019, after which we will continue to support open source Redis deployments in the shared-redis-release repo.
Note: Breaking change > version 434.3.6 - the redis.limits.maxclients
property is now redis.maxclients
git clone https://github.com/pivotal-cf/cf-redis-release ~/workspace/cf-redis-release
cd ~/workspace/cf-redis-release
git submodule update --init --recursive
Run the following steps:
.envrc.template
file
and save as .envrc or export them. All or almost all the variables are required for tests but these are the minimum required for deploy:
.envrc
file
direnv allow
bosh upload-release http://bosh.io/d/github.com/cloudfoundry-incubator/cf-routing-release
bosh upload-release http://bosh.io/d/github.com/cloudfoundry/syslog-release
bosh upload-release http://bosh.io/d/github.com/cloudfoundry-incubator/bpm-release # required for routing 180+
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:
bosh upload-stemcell https://s3.amazonaws.com/bosh-core-stemcells/warden/bosh-stemcell-97.3-warden-boshlite-ubuntu-xenial-go_agent.tgz
bosh create-release
bosh upload-release
bosh deploy --vars-file secrets/vars.yml manifest/deployment.yml
The following ports and ranges are used in this service:
bundle install
bundle exec rspec spec
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:
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:
The Cf-Redis Service Broker offers the following BOSH errands:
Communicates to the CloudFoundry Cloud Controller which maintains the database for the CF Marketplace. This enables the service plans on the CF Marketplace so that App Developers can create and delete service instances of those plans.
Note: As of v434.0.13, the broker-registrar will disable service access to the dedicated-vm service plan as the service plan is being deprecated.
Communicates with the CF Cloud Controller to remove the cf-redis broker and service plans from the CF Marketplace as well as delete the broker deployment from BOSH.
Note: If any service instances exist, the errand will fail. This is to prevent orphan deployments which the CF Cloud Controller will lose record of but will continue to live as a BOSH deployment which would continue to incur costs.
If you wish to remove the service broker, perform a
cf delete-service SERVICE_INSTANCE
and remove all service instances associated with the broker and run the errand after all service instances have been removed.
Runs smoke tests which tests the lifecycle and functionality of the both the dedicated-vm and shared-vm services. See the Redis documentation for more information.
Available as of v434.0.13. Communicates with the CF Cloud Controller to disable service access to the dedicated-vm service plan. This allows operators to remove the dedicated-vm service plan from the marketplace in order to prevent App Developers from creating new service instances in preparation for the deprecation of the dedicated-vm plan.
Available as of v434.0.15. Communicates with the CF Cloud Controller to purge references to dedicated-vm service instances if no dedicated-vms have been provisioned. The purpose for this errand is to provide a smoother experience for migrating to On-Demand Instances given the Ops Manager tile deployment flow. Intended as a temporary errand during deprecation of dedicated-vms.