This example describes how to set up a sample microservices app for continuous deployment and release management in Weave Cloud. This example uses Travis CI and Quay, but you can use a continuous integration and container registry of your choice. All that Deploy needs to know is the repo that contains your manifests, and if you are using a private image repository, the credentials for that.

Before You Begin

  • Setup hosts
  • Install a Kubernetes Cluster
  • Download and fork the demo app Sock Shop

Setup Hosts and Stand up a Kubernetes Cluster

You can follow these instructions to set up three hosts in Digital Ocean and use kubeadm to quickly stand up a Kubernetes cluster:

Once you have a cluster running, return and continue on with this example.

Forking the Sock Shop

You will need a GitHub account for this step.

Before you can modify the Socks Shop, fork the following two repositories onto your host:

To fork the GitHub repositories click Fork from the top right hand corner. The repositories will appear in your own GitHub account.

Get a Container Registry Account

Sign up for a Quay.io account, and record the username that it gives you. When you log in, you’ll be able to see it under “Users and Organizations” on the right hand side of the Repositories page.

Create a new public repository called front-end. This is the Docker repository that will be used by Travis on which to push the newly built images.

Get a Continuous Integration Account

If you already have your own CI system, you can use that instead. Deploy needs a container image whenever you push a change to GitHub.

The example used here is Travis CI. Sign up for an account if you haven’t got one already, and then hook it up to your GitHub account. Click the + button next to My Repositories and toggle the button for <YOUR_GITHUB_USERNAME>/front-end so that Travis automatically runs builds for the repo.

Edit the travis.yml File

Replace the .travis.yml file in your fork of the front-end repo so that it contains only the following and replace <YOUR_QUAY_USERNAME> with your Quay.io username:

language: node_js

sudo: required

node_js:
  - "0.10.32"

services:
  - docker

before_install:
  - sudo apt-get install -y make
  - make test-image deps

env:
  - GROUP=quay.io/<YOUR_QUAY_USERNAME> COMMIT=$TRAVIS_COMMIT TAG=$TRAVIS_TAG REPO=front-end;

script:
  - make test

after_success:
  - set -e
  - if [ -z "$DOCKER_PASS" ]; then echo "Build triggered by external PR. Skipping docker push" && exit 0; fi
  - docker login quay.io -u $DOCKER_USER -p $DOCKER_PASS;
  - ./scripts/build.sh
  - ./test/container.sh
  - ./scripts/push.sh

Commit and push this change to your fork of the front-end repo.

git commit -m "Update .travis.yml to refer to my quay.io account." .travis.yml
git push

1. Log into Quay.io, and create a Robot Account called ci_push_pull by selecting the + from the header.

2. Ensure that the robot account has Admin permissions.

3. Configure the environment entries for DOCKER_USER and DOCKER_PASS using the credentials from the robot account in quay.io. Click the ci_push_pull repo and then Credentials and Settings. Select Robot Token from the top of this dialog. Copy the robot token from this dialog.

4. Go back to TravisCI, find the front-end repo and turn on the build switch next to it.

5. Add your Quay.io user name and robot account token to the front-end repo in Travis by selecting More Options and then Settings from the drop down menu on the upper right.

Add the following credentials from Quay.io:

DOCKER_USER=<"user-name+robot-account"> DOCKER_PASS=<"robot-key">

Where,

  • <"user-name+ci_push_pull"> is your user-name including the + sign and the name of the robot account.
  • <"robot-key"> is the key found and copied from the Robot Token dialog box.

Launching and Configuring Deploy

1. Launch all three cloud agents with:

kubectl apply -n kube-system -f \
  "https://cloud.weave.works/k8s.yaml?t=[cloud-token]&k8s-version=$(kubectl version | base64 | tr -d '
')"

Where,

2. Check Weave Cloud to ensure that the fluxd is running as a container. To simplify this, search for ‘flux’:

3. Use an Explore terminal to launch the forked version of the app onto the cluster. Select the Hosts view and click on the Master node, then open a terminal and enter the following to deploy the sock shop to the cluster.

You may have set the environment for Kubernetes before you can run kubectl commands:

  sudo cp /etc/kubernetes/admin.conf $HOME/
  sudo chown $(id -u):$(id -g) $HOME/admin.conf
  export KUBECONFIG=$HOME/admin.conf

and then run:

cd ~/microservices-demo/deploy/kubernetes
kubectl create namespace sock-shop
kubectl apply -f manifests

and check that the shop is running:

kubectl get pods --all-namespaces

Note that if you already have a Sock Shop running in your cluster, you will need to remove that from your Kubernetes cluster first before launching your forked version:

kubectl delete namespace sock-shop

The app should now appear in Explore where will see Pods view on the top of the screen. Select the Pods view and then enable the sock-shop filter from the left-hand corner:

4. Click on Deploy and then select Configuration.

Enter the path to your Github repo and the path to the Kubernetes manifests (optional) in the following format:

git@github.com:user/repo-name / [path to Kubernetes manifests]: [branch]

In this case, the manifests are kept in the microservices-demo.

5. Generate and push a set of SSH keys to the Github repo with your manifests that you specified above. Weave Cloud needs this access in order to write changes back to the repo.

Important! When pushing the keys to your repo, ensure that it is enabled to write.

Check that the keys are properly in Github by going to the forked microservices-demo repo and by clicking on Settings and then Deploy Keys to ensure that your keys have read/write enabled. Enabling write access ensures that Weave Cloud has push access to your repository. Weave Cloud should have done this for you.

6. Enter your credentials for the Quay robot account into the Container Image Credentials field. This is only necessary if the image repository is private, if you keep your images in a public repository, then Weave Cloud deploy detects those automatically.

Modify the Manifest file so it Points to Your Container Image

Begin by logging in to the Kubernetes master node. The rest of the demo will be run from the master Kubernetes node, but you could also run it from your laptop if you wish. Use ssh -A to enable the SSH agent so that you can use your GitHub SSH key from your workstation.

git clone https://github.com/<YOUR_GITHUB_USERNAME>/microservices-demo
cd microservices-demo/deploy/kubernetes

Modify the front-end manifest so that it refers to the container image that you’ll be using. Using an editor of your choice, open manifests/front-end-dep.yaml, and update the image line.

Change it from:

        image: weaveworksdemos/front-end

To:

        image: quay.io/$YOUR_QUAY_USERNAME/front-end:deploy-tag

Where,

  • $YOUR_QUAY_USERNAME is your Quay.io username.

You must specify a tag for the image. Flux will not recognize the image if there is no tag. Since Flux replaces tags with a specific version every time it does a release, it is best not to use :latest as a tag in this file.

Commit and push the change to your GitHub fork:

git commit -m "Update front-end to refer to my fork." manifests/front-end-dep.yaml
git push

Then go to Travis-CI and watch as the image is built, unit-tested and finally pushed to the Docker Registry, Quay.io.

Display the Sock Shop in a Browser

Find the NodePort by to launch in the Sock Shop in the browser by running:

kubectl describe svc front-end -n sock-shop

Display the Sock Shop in the browser using <master-node-IP>:<NodePort>.

Note that the active states of the Catalogue and the Cart buttons are blue. In the next section you will change those to red.

Make a Change to the Socks Shop and Deploy it to the Cluster

Suppose you want to change the colour of one of the buttons on the socks shop. On your workstation, or wherever you have front-end checked out (Note: You may need to clone it to your workstation, if you haven’t already done this):

cd front-end
sed -i s/#4993e4/red/ ./public/css/style.blue.css

You can also open up the file ./public/css/style.blue.css in a text editor and search and replace #4993e4 with red.

Now push the change to Github:

git commit -am "Change buttons to red."
git push

Deploying the Change to Kubernetes with Weave Cloud Deploy

1. Return to Travis and watch the change as it’s being built in a Docker image and then pushed to Quay.

2. Once the new image is ready in Quay.io, Weave Cloud deploy displays any new images available for deployment:

3. Deploy the new image with by clicking Release

Once the release is deployed, reload the Socks Shop in your browser and notice that the buttons in the catalogue and on the cart have all changed to red!

So that’s useful for manually gated changes, but it’s even better to do continuous delivery.

Enabling Continuous Delivery

Turn continuous delivery on by selecting the service (and in this example the front-end) and by enabling Automate.

Then change the front-end again, maybe green this time?

cd front-end
sed -i s/red/green/ ./public/css/style.blue.css

Of course, you can make any change you like. Now push the change:

git commit -am "Change button to blue."
git push

And watch Travis, and Quay.

Return to Weave Cloud to see your newly built image ready for deployment.

Further Reading