Skip to main content

Rancher for Microservices : Upgrades and Rollback.

So far we've checked how easy it is to get up and running with Rancher. We also deployed a very simple HTTP service on our Rancher Cluster, attached an L7 Load balancer and successfully scaled up containers running this service.

In this post, I'll use the same service with a slight modification which is version number now return as  2.0 in HTTP response. So far our service is on v1.0, let's say we've worked very hard and released a new version with latest features. We want to release it to our users while ensuring there is no downtime during deployment. At this stage, our docker image of service 2.0 is pushed to docker repository (ravirdv/app:2.0).

In the world without container orchestration platforms, we'd have to write scripts to spawn up compute resource (EC2, VM etc) and then use something like Ansible/Chef/Farbic scripts to provision required services and dependencies. Once that is done, we'd push our package and hope there is no dependency/version mismatch and our service starts up. After new version of service is up, we'd slowly migrate our traffic to new version of service and clean up compute resources of old version or may be keep it running as standby. Now there might be variations of how this is done, but roughly this is how normally people did it in past.

Enough of history lesson 🙂, let's get back to how we can achieve similar result with more predictability and fault tolerance using Rancher. Rancher likes to call collection of containers a "Workload", in this case, our HTTP service containers are part of same workload. So when we ask Rancher to upgrade the Workload, it will spin up new set of containers with specified revision of docker image and instruct our L7 load balancer to gradually redirect traffic to new set of containers. Rancher does all of this for you, without breaking a sweat! awesome isn't it? 🤩

Upgrading a workload is very simple. You just have to click on Edit, update image version and hit "Upgrade" button, Rancher will instantly fetch the docker image from registry and provision a set of containers using that image.

Demo time! let's try to upgrade our service from v1.0 to v2.0 and see how our curl script handles it.

Looking at "App Version" value, we can see that it curl slowly starts receiving v2.0 as response.

It takes few more seconds to switch all containers to new version, below screen capture shows all responses are now from 2.0

As our service is now upgraded, "App Version" value is 2.0 in response, also container host are now different.
I was completely blown away by this feature, this "nuke and pave" approach give me much more confidence than modifying existing server configuration. However, things may go wrong. May be there is a last minute bug which impact a set of users or a top secret feature which shouldn't have been part of this release or anything else really where you'd wish your infrastructure had an "undo" button.

And you guessed it! while not really an undo button, Rancher makes it very easy to rollback to previous version. Process for rollback is same as upgrade. Let's say we found an issue in our cutting edge 2.0 release and now we've decided to rollback to 1.0 version ASAP 🔥. Let's see how Rancher handles it:



As you can see from HTTP response, we can see service 2.0 containers are replaced with version 1.0 containers. Although, this will be much more messy if services are not stateless, I'll write more about this when covering persistent storage topic. If you're new to containerization and its ecosystem then I highly recommend to start with services which are stateless. Running your app on local machine with Docker-Compose is easiest way to start in my opinion.

I hope this series of posts give you enough ammunition to start playing with Rancher. In next series of posts, I'll write about how you can use this platform to perform service discovery, handle configuration changes, store secrets, and most importantly debug and monitor services.

If you found this interesting or if there is something that I can improve then please let me know via comments.






Comments

Popular posts from this blog

Getting Started with Rancher & Kubernetes

During my time working at Azoi (a startup), I was responsible for maintaining Gitlab for my team along with various other self-hosted internal services. When I first setup Gitlab in 2013, it was quite a task, as setting it up would involve configuring various services using provided scripts and a lot of luck. Fortunately, I found Bitnami Gitlab package to make that process easier. However initial setup is one thing and keeping up with the latest releases was a nightmare.

Fast forward to 2016, I joined eInfochips as Solutions Consultant. Where one of my responsibilities was to modernize development workflow and encourage DevOps culture. It made sense to use Gitlab specially for Gitlab-runner and since this was a fresh setup, I explored few options to setup Gitlab, I found that Gitlab monthly releases were now published as Docker images. So I decided to use Gitlab docker image to host gitlab-ce internally. This time around, the experience was very different, initial setup and upgrading…

Rancher for Microservices : Load Balancing and Scaling Containers.

In my previous post, we saw how easy it is to set up Kubernetes cluster using Rancher. Once you have a cluster up and running, next step is to deploy your microservices on the cluster. In this post, we’ll look at how to deploy, run and scale a docker image on your cluster. We’ll also look at setting up an L7 load balancer to distribute traffic between multiple instances of your app.

Let’s create a simple HTTP service which returns server hostname & current version of the binary (hardcoded). I’ve used go-lang for this, below is code snippet which returns hostname and service version.

All it does is, returns a string "App Version 2.0 running on host: <hostname>", once deployed it will return container hostname.

Next step is to dockerize our service by generating a docker image and push it to DockerHub (or your private Docker registry), below is Dockerfile I used to dockerize this service.


Running this will compile our service and generate a docker image on local mac…

Ubuntu Touch SDK, Core Apps & Mac OSX

I have started working on Ubuntu Touch core apps, this involves using Ubuntu UI Toolkit which is basically QML Components designed for Ubuntu Touch OS. Unfortunately Ubuntu UI Toolkit is not available for Mac OS. In order to develop Ubuntu Touch core apps I have to get Ubuntu UI components running on Mac.

So this has shifted my focus from Ubuntu Touch core apps to ubuntu ui sdk. Once I get it, I can start working on Ubuntu Touch core apps.


Coming back to the SDK, it is a straightforward package which contains QML building block for application developers. Now compiling this on Mac should not be diffcult.

I have identified following dependencies causing compilation to fail.


QtDbus:

This is the first error message i got when trying to compile Ubuntu UI Toolkit.
it says Unknown Module : dbus  when I run QMake.

I have no clue why this is coming, as I think I have qtdbus installed. will come back to this point once I have a solution

libintl includes:

Ubuntu Touch SDK seems to be using lib…