Using Visual Studio Team Services & Rancher for continuous deployment for your docker containers


Today I’m going to show you how you can leverage the combination of Visual Studio Team Services & Rancher to kickstart your continuous deployment of your docker containers. So every time we update our containers, we want a smooth upgrade process on our container setup. What do you think? Let’s see what this can look like?


The flow

The scenario of today will have the following flow ;

  • We’ll use a git(hub) repository to store our docker-compose & rancher-compose file that powers our solution.
  • Next up, we’ll be using VSTS as the orchestrator for your CI/CD-pipeline.
  • Rancher is our preferred container workflow / management tool, and we’ll be using the “rancher-compose” on our VSTS build agent.


Linux Build Agent

So the first thing you’ll need is a Linux based system that has been purposed as a Build Agent for your VSTS account. You can integrate that one like you would with any other build agent…


Though I create a separate pool for each platform ;


For this (Ubuntu) Linux hosts, I used “Default Linux”


Install Rancher Tools

There are two tools you want on your system ;

So what are the steps you need to do?


Demo Setup

For this example, we’ll be using a deployment of “Ghost” ; 

Here you can find a docker-compose.yml & rancher-compose.yml file, as needed for rancher-compose.

Looking for more information?



In order to be able to authenticate our rancher-compose statements, we’ll be needing an access key and secret key. So let’s go to the “API” ;


Then click on “Add Account API Key” ;


Give the name for the new API key ;


And note down the credential information ;


(Note : nice try… These keys have been revoked already!) 😀

Aside from that, be aware that API keys are related to your account! So if you want a “system” account, be sure to create that one and login with that persona when creating the API key!



So now for our CI/CD-pipeline. We’ll create a very simple build step. For this example, we’ll just package the file without doing any tests or whatever. Offcourse, you should add those… 😉


Towards the deployment, let’s extract that file, and then run rancher-compose ;


What settings did I use for the rancher-compose?

  • Tool : rancher-compose
  • Arguments : –url “http://hostname:port/v2-beta/projects/1a5/schemas” –access-key “my-access-key” –secret-key “my-secret-key” up –force-upgrade –confirm-upgrade -d
  • Working directory : $(System.DefaultWorkingDirectory)/artifactname/s/Ghost

Now why did I use certain parameters with the rancher-compose?

  • –force-upgrade ; cause I want the “up” to do an upgrade, even when it thinks it is not necessary.
  • –confirm-upgrade ; finish up the upgrade once done, otherwise we’ll need a manual interaction
  • -d ; to ensure that the command detaches after deployment
  • -url ; I noticed that this “hack” works best… normally you shouldn’t do it like this, but linking to the projects space works great every time


Demo Flow

So how does that look? The release phase runs as expected…


Rancher shows a running Ghost deployment (as deployed by an earlier release).


Now we see the upgrade process kicking in…


And the upgrade was done!



What does this all mean?

For those who are accustomed to docker hub, the CI (automated builds) work great there! But what about CD? Today I showed you a way that could kickstart that for you in combination with Rancher & VSTS.

In addition, you could also include the build phase in your CI-part, and then you have a nice CI/CD-pipeline for your containers!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.