Makes blue-green app deployments on Cloud Foundry.
docker build -t europeana/cf-blue-green-deploy .
docker pull europeana/cf-blue-green-deploy
Configuration of Cloud Foundry settings is by environment variable on the Docker container. All are required at run time.
CF_API
: API endpointCF_USERNAME
: usernameCF_PASSWORD
: passwordCF_ORG
: orgCF_SPACE
: spaceCF_ROUTES
: route(s) for the app, separated by spaceCF_APP_NAME
: app name, to which the-blue
or-green
suffix will be added
It is suggested to copy the supplied .env.example to .env,
populate for your CF provider and app, and pass to Docker when running the
image, with --env-file .env
. All following examples assume such configuration.
No arguments are set by default on the cf push
command, but should instead
be supplied as the docker run
command, following deploy
.
For example:
docker run --env-file .env \
europeana/cf-blue-green-deploy \
deploy -f manifest.yml --vars-file vars.yml
This is equivalent to running: cf push ${BLUE_GREEN_APP_NAME} -f manifest.yml --vars-file vars.yml
If the app needs to push local data (which will generally be the case unless using
a Docker image), then mount the local data directory into the container as
/deploy
.
For example:
docker run --env-file .env --mount type=bind,source=/path/to/app,target=/deploy \
europeana/cf-blue-green-deploy \
deploy -f manifest.yml
To deploy with a Docker image instead of a buildpack, set the env var CF_APP_TYPE=docker
.
For example:
docker run --env-file .env \
-e CF_APP_TYPE=docker \
europeana/cf-blue-green-deploy \
deploy --docker-image nginx -m 32M
This blue-green deployment agent operates based on routing. It is given a single primary route for the application, and whichever colour is presently mapped to that route is the active one.
The other colour will be deployed with the code changes, then the route remapped to point to it.
- Given an app named
myapp
, a domainexample.org
and a hostnamewww
, the entrypoint will use the CF CLI to look for the routewww.example.org
, then:- If one exists, and the first mapped app is named
myapp-blue
, then the blue colour is active and green will be deployed; vice versa if it is namedmyapp-green
. - If one exists but the first mapped app is not named either
myapp-blue
ormyapp-green
then it will exit. - If one does not exist, this is assumed to be the first deployment and blue will be deployed.
- If one exists, and the first mapped app is named
- The new colour is pushed as
myapp-blue
ormyapp-green
- The route
www.example.org
is mapped to the new colour - The route
www.example.org
is unmapped from the old colour (if there is one) - The old colour is stopped (if there is one)
If an autoscaling policy is supplied at /autoscaling-policy.json
, it will be
applied to the new app colour. If none is supplied, but the old colour has one,
that will be copied to the new.
In addition, the old app colour will be inspected for the number of instances it is running at the time of deployment, and the new app colour started with that number of instances, within the bounds of the autoscaling policy min/max thresholds.
A number of hooks are available to run custom commands during the blue-green deployment lifecycle:
pre-login
: before logging in to CF; no argumentspost-login
: after logging in to CF; no argumentspre-push
: before pushing the new app to CF; arguments are old and new app namespost-push
: after pushing the new app to CF; arguments are old and new app namespost-routing
: after remapping the routes from old to new; arguments are old and new app namespost-deploy
: after stopping the old app and deployment is complete; arguments are old and new app names
To use these hooks, provide executable files in /hooks named after the hook. For example: /hooks/post-login:
#!/bin/sh
cf apps
/hooks/post-deploy:
#!/bin/sh
new_app_name=$2
cf app ${new_app_name}
See LICENSE.md.