Deployment

Deployment of the hubs is managed with continuous integration (TravisCI), rather than through use of the command-line kubernetes tools. Pull requests to the master branch trigger travis, as does merging a pull request. The Travis steps are scripted using python rather than calling kubectl and helm directly.

There are two protected branches in this repo - master and staging. Travis runs on both branches, and both branches are deployed to the same Google Cloud cluster.

  • master : This branch contains the production hubs - the ones we are using for courses. We use this branch through a pull request workflow, and deployment happens when a PR is merged.

  • staging : This branch is for testing, especially for testing changes to deployment (i.e. changes to .travis.yml or deploy.py that go beyond adding / removing hubs). You can safely test deployment changes here without affecting production hubs. We commit / push directly to this branch, and it never gets merged to master.

User workflow

When making changes to a hub (including both Deploying New Hubs and Manage, Modify or Remove a Hub), the expected workflow is:

  • change the required settings in this repo (e.g. the helm charts in hub-charts, or the Dockerfiles in user-images)

  • create a pull request with your changes - this will initiate a travis run that tests the builds of the docker image(s) and the docs. This does not push to Dockerhub, and does not deploy the hub. More specifically, this build skips the before_deploy and deploy sections in .travis.yml.

  • after the PR is merged, travis builds the docker image(s), pushes them to dockerhub, and deploys the hub(s). This build runs the before_deploy and deploy sections in .travis.yml.

Before making changes to a production hub (i.e. one being used for a course), try them out on a test hub on staging branch before creating a feature branch with the changes and pull requesting to master.

Deploy script

The deploy.py script at the top-level of this repo manages docker builds and deployments. The expectation is that this is only called by travis, not directly by the user (see the workflow, below). Changes to the deploy.py script should be thoroughly tested on staging before creating a feature branch and PR to master.

Basic usage is python deploy.py chartname. The following options are available:

  • --no-setup : run without setup procedures (authentication to GCloud and docker, helm / tiller status)

  • --build : build docker images; see Customize Your Hub for setting these up

  • --push : push images to dockerhub (option ignored if build==False)

  • --deploy : deploy the hub

These are the commands that deploy.py runs when deploying a hub :

helm dependency update <chartname>
helm upgrade --install --namespace <chartname> <chartname> <chart_dir> --force --wait --timeout 600 --cleanup-on-fail -f <secret>

Then, for each deployments found with kubectl -n <chartname> get deployments -o name:

kubectl rollout status --namespace <chartname> --watch <deployment>

Warning

If you do run deploy.py locally, use the --no-setup flag to avoid authenticating to gcloud as the travis user and borking your local access to the cluster. If that does happen, you can delete your .kube directory and re-authenticate to gcloud.

Manage, Modify or Remove a Hub Managing Storage for Your Hub