Rancher : Docker Lifecycle Management – Or how to upgrade containers?

Introduction

It’s all fun & games to create & deploy containers. And the “pets vs cattle” thingie is also cool… Though what about the lifecycle management? That’s something we’ll be handling today!

What will we be doing today?

  • Create a small dummy container
  • Setup a source respository (at BitBucket) for that dummy container
  • Setup an automated build (linked to the source repository) on your docker hub respository
  • Deploy a service on rancher
  • Update the source
  • Upgrade the service to the latest version
  • Enjoy life even more!

What will already need to be setup?

My little dummy container

So let’s start with creating our Docker file & some basic “hello world”-scripts.

root@docker01:/data/BitBucket/docker-blogtest# ls -la
total 24
drwxr-xr-x  2 root root 4096 Jan  4 17:14 .
drwxr-xr-x 11 root root 4096 Jan  4 17:10 ..
-rw-r–r–  1 root root  691 Jan  4 17:14 Dockerfile
-rw-r–r–  1 root root  108 Jan  4 17:12 startcron.sh
-rw-r–r–  1 root root   68 Jan  4 17:13 testblogcron
-rwxr-xr-x  1 root root   37 Jan  4 17:13 testblog.sh

What is in there?

  • Dockerfile : This is your “recipe” for your container. It will contain a step by step action list of what docker should do to build the system.
  • startcron.sh : The script that will run in your container. Once your run script is terminated, your container will be stopped!
  • testblogcron : The entry for cron.
  • testblog.sh : The command that will be executed by cron

Dockerfile

root@docker01:/data/BitBucket/docker-blogtest# cat Dockerfile
#
# BlogTest Dockerfile
#
# Source : https://bitbucket.org/kvaes/docker-testblog/
# Author : Karim Vaes
#

# Use Ubuntu 10.04 as a base
FROM ubuntu:10.04

# First let’s do some updates!
RUN apt-get update && apt-get -y upgrade

# Install cron
RUN apt-get -y install cron

# Let’s prep the directory
RUN mkdir -p /data/bin

# Pull the latest batch script
ENV HOME /root
COPY testblog.sh /data/bin/
COPY testblogcron /data/bin/
COPY startcron.sh /data/bin/

# Setup 755 on the scripts
RUN chmod 755 /data/bin/*.sh

# Setup Cron Job
RUN cat /data/bin/testblogcron >> /etc/crontab

# Setup Cron Log
RUN touch /var/log/testblog.log

# Define default command.
CMD [“/data/bin/startcron.sh”]

Synopsis

The above will create a container based on Ubuntu. We’ll install cron, which will run a “hello world” bash script every minute. The output of that script will be prompted to the logs, which will be echoed to the shell. Sounds simple doesn’t it? 😉

Source Control

I’ve just created a respository in my BitBucket account ; https://bitbucket.org/kvaes/docker-testblog

And now I’ll be adding the created files to this repository ;

root@docker01:/data/BitBucket/docker-blogtest# git init
Initialized empty Git repository in /data/BitBucket/docker-blogtest/.git/
root@docker01:/data/BitBucket/docker-blogtest# git remote add origin https://username@bitbucket.org/kvaes/docker-testblog.git
root@docker01:/data/BitBucket/docker-blogtest# git add *
root@docker01:/data/BitBucket/docker-blogtest# git commit -m “first commit”
[master (root-commit) bfba6f7] first commit
4 files changed, 49 insertions(+)
create mode 100644 Dockerfile
create mode 100644 startcron.sh
create mode 100755 testblog.sh
create mode 100644 testblogcron

root@docker01:/data/BitBucket/docker-blogtest# git push origin master
Password for ‘https://username@bitbucket.org’:
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (6/6), 888 bytes | 0 bytes/s, done.
Total 6 (delta 0), reused 0 (delta 0)
To https://kvaes@bitbucket.org/kvaes/docker-testblog.git
* [new branch]      master -> master

And that went pretty good…

2016-01-04 17_34_38-Action center

Automated Builds

Now let us link our BitBucket repository with our Docker Hub repository to achieve automated builds… Be aware, this is really simple! 🙂

First step is to link your BitBucket account with your Docker Hub account

Now let’s link the repository! Click on “Create” and then “Create Repository”.

2016-01-04 17_36_10-Foto's

Select your BitBucket repository.

2016-01-04 17_36_31-Foto's

Enter the namespace/name & description. Now press “Create”.

2016-01-04 17_37_05-Foto's

The automated build has been setup. Though it has not been triggered… Let’s go to “Build Settings”.

2016-01-04 17_37_22-New notification

Press “Trigger”. (Please note that in the future, once you do a commit, an automatic trigger will occur!)

2016-01-04 17_37_34-New notification

2016-01-04 17_37_46-Foto's

Now let’s go to “Build Details” and “wait for it“…

2016-01-04 17_37_57-Foto's

2016-01-04 17_40_21-Foto's

2016-01-04 17_43_01-Foto's

Done! Docker image build!

Rancher Service

We could now deploy the image as a standalone container. Though we’ll be using the “Rancher Server” to enjoy (as one of) the “Upgrade” feature(s).

First check your docker hub, and note the pull command. We’ll need to enter the repository name that is right after “docker pull”, being “kvaes/docker-testblog” when adding the service later on…

2016-01-04 17_55_17-New notification

Fire up “Rancher” and press “Add Stack”.

2016-01-04 17_50_17-Foto's

We’ll give it a stupid name… like “BlogTest”.

2016-01-04 17_50_37-Start

Once done, we’ll add a service…

2016-01-04 17_50_49-Start

Enter the details and at “Select Image”, you enter the image string as we noted down just earlier.

2016-01-04 17_55_38-Rancher

Once created, start the service.

2016-01-04 17_58_27-Rancher

You’ll notice it’ll be “Activating”. At this point, it is probably downloading the latest image from Docker Hub.

2016-01-04 17_51_42-Start

And suddenly… Our container is running!

2016-01-04 17_56_52-Rancher

Click on the “Name” of the service.

2016-01-04 18_02_07-Search

You’ll see the service details, and the container we just deployed. Go the the commands and select “View Logs”.2016-01-04 18_02_20-New notification

And you’ll see that our little “hello world” is working!2016-01-04 18_02_29-Rancher

Life is great, isn’t it…

Now let’s make a change!

root@docker01:/data/BitBucket/docker-blogtest# git commit -m “version 2”
[master b39c497] version 2
1 file changed, 1 insertion(+), 1 deletion(-)
root@docker01:/data/BitBucket/docker-blogtest# git push origin master
Password for ‘https://kvaes@bitbucket.org’:
Counting objects: 5, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 291 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://kvaes@bitbucket.org/kvaes/docker-testblog.git
bfba6f7..b39c497  master -> master
root@docker01:/data/BitBucket/docker-blogtest# cat testblog.sh
#!/bin/bash

date
echo “hello world – v2”

So the changes are off to our source control.

2016-01-04 19_37_01-Docker Hub

And let’s wait for it…

2016-01-04 19_40_09-Docker Hub

Legendary!

And finally, let’s upgrade!

Go to the commands for our “blogtest” service and select “Upgrade”.

2016-01-04 19_40_27-Rancher

Maybe change some settings if needed (not for this Proof-of-Concept) and press “Upgrade.

2016-01-04 19_40_38-Rancher

You’ll see the status changing to “Upgrading”

2016-01-04 19_40_53-Rancher

The original container will be stopped, and a new container will be deployed with the latest pulled image.

2016-01-04 19_41_13-Rancher

Let’s check the logs for our original container…

2016-01-04 19_41_30-Program Manager

It’s showing “hello world”, as it was with our first commit.

2016-01-04 19_41_47-Rancher

Now let’s check the logs of the new container…

2016-01-04 19_42_02-Rancher

That shows the “v2” version!

2016-01-04 19_42_11-Rancher

As we have validated the upgrade, let’s finish off… Select “Finish Upgrade” and the old container will be removed.

2016-01-04 19_42_23-Rancher

And the service goes back to the original / good status.

2016-01-04 19_43_34-Rancher

If we would have done “Rollback”, then the new service would be removed and the old service would be put back into service.

Enjoy life

I hope this blog post was interesting for you… It outlined the full lifecycle of a container. Or almost… you could have also deleted (and purged) the container to have the full lifecycle from birth to death. 🙂

7 thoughts on “Rancher : Docker Lifecycle Management – Or how to upgrade containers?

  1. Karim, excellent post (as some other posts of yours)! I plan to use a similar approach (Docker + Rancher) to implement ALM for the current development project (pretty large system) I’m working on. I wanted to suggest you to fix the date on your site (like “it’s not April yet”), but then realized that it’s in Euro format… – been for quite a while in US :-). Do you think that using Docker + Rancher on bare-metal would be similarly good in terms of ALM vs. using OpenStack? Basically, I’m not sure what additional benefits OpenStack would offer. I also looked at the recently released as open source Walmart’s OneOps platform, but I felt it’s overly complicated for my needs.

  2. As a true consultancy answer… It depends on what you want to realize. Rancher is an orchestration tooling utlizing Docker. You can run docker on hosts running within OpenStack. If “docker” sufficiently covers your needs, then I would say you do not need OpenStack.

    Though typically, stacks like OpenStack / Azure Stack / etc make it more easy to manage the “fabric” (underlying platform). If you have a rather static environment with a modest size, then I could imaging that you do not need the “overhead”.

    1. I appreciate your fast feedback. It basically confirms my impression that “heavier” infrastructural platforms, like OpenStack, is likely an overkill for our current and relatively fuzzy needs. Essentially, I want to dockerize components of the underlying application framework, consisting of PHP code (back-end), JavaScript, etc. (front-end), MySQL DB, OpenVZ containers for scientific computing sessions and other pieces of the puzzle. In addition, I want to dockerize all new features that we will be developing. There are a lot of moving parts in the current foundational system and will be many more in the future. Current components are deployed as Debian packages, but I think it would be beneficial to base current and future deployment on Docker containers. I think that Rancher would help in making application provisioning and management easier (including scalability aspects – clustering, autoscaling, etc.). The target platform is bare-metal, so we cannot use AWS or Azure autoscaling features. From a brief review of Rancher documentation and some blogs (including yours), I have an impression that it is possible to set up such infrastructure in bare-metal environment. If you have any comments on the above, please let me know. We have already set up a pretty solid CI/CD development process (based on GitHub Enterprise, Phabricator and Jenkins), but now we are thinking about the deployment and ALM parts… (hence my interest in Docker and Rancher).

      1. Definitely check out Rancher. From what I read it will probably make your life easier. 🙂
        Do not underestimate the design work in regards to persistent storage… Read up on that matter.

Leave a Reply

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

WordPress.com Logo

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

Google photo

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

Twitter picture

You are commenting using your Twitter 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.