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…

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”.

Select your BitBucket repository.

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

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

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

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

…

…

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…

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

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

Once done, we’ll add a service…

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

Once created, start the service.

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

And suddenly… Our container is running!

Click on the “Name” of the service.

You’ll see the service details, and the container we just deployed. Go the the commands and select “View Logs”.

And you’ll see that our little “hello world” is working!

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.

And let’s wait for it…

Legendary!

And finally, let’s upgrade!

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

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

You’ll see the status changing to “Upgrading”

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

Let’s check the logs for our original container…

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

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

That shows the “v2” version!

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

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

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. 🙂