Using Docker to manage and replicate test environments

About 5 years back I started this business, Test Collab, ever since then I was fortunate enough to work with so many developers, managers and testers. From micro-ISVs to Fortune 500 companies, I just loved how different people can give you so many diverse ideas.

So today I’m going to talk about an idea, or let’s call it a solution, if you will.

The problem

When you are manually testing an app, you have to deploy it again and again. To save time, some teams use shared testing environments, i.e. one app instance is used across whole team for testing (Not good – as it increases false bug reports).

Some teams I’ve worked with teach their testers the whole set of linux commands to compile the app from source (Not good – testers may or may not be as technical as developers)

Others rely on their developers to setup test instances for testers (Not good either – developers are expensive)

Solution

Why not have automated test environments?

But that’s too difficult, right? Well not anymore… thanks to wonderful team at Docker.

Wait, but isn’t that just like virtualization?

Yes and no. Traditional virtualization is too bulky and slow. Docker is way too fast.

I don’t intend this article to be on this topic as there are already tons of articles available about this.

Rather what I’m interested in is showing how to utilize Docker for testing…

Docker lets you build containers. Think of container as your pre-configured, ready to use, super-fast, clone-able application runtime environment.

So I’ll just have to configure my container once and I can use it to launch tens or hundreds of my application copies. And they’ll live separately. You might be thinking that that’s same as virtualization or launching a new VM from image, except it’s not. It’s fast, it provides better control over your running machine and it’s way too easy on CPU.

Getting Started

So first you need to setup Docker

Now you don’t need to go through every feature or every page of their documentation to learn it. I’ll just explain docker commands below which are actually useful to us as developers/testers (Although I do recommend reading it once to to get all sorts of crazy innovative ideas):

1. Creating your first image / test environment

Each image / container you’re going to create must be created from a base image of OS. Say you’re app runs on Ubuntu 14, so my base image is Ubuntu 14.

There are hundreds of images available at Docker hub but for now we’ll stick to Ubuntu 14 image.

To create an image we’re going to run Ubuntu 14 first:

docker run -t -i ubuntu:14.04

This will automatically download image from Docker hub and run it.

-t tells docker to run a terminal and –i to make it interactive, so we can setup our apps.

You’ll see the command prompt change, which means that you’ve entered into the container.

Now let’s install an application. I’ll just install Apache2/PHP5 and deploy a ‘hello world’ PHP script for now.

apt-get update

apt-get install apache2 php5 nano curl

nano /var/www/html/index.php

rm /var/www/html/index.html

service apache2 start

Now to verify

‍
curl http://localhost

OK, Now my running container has my dummy app running. Let’s save it.

First we exit from the container to host.

exit

‍

Then we save the running container:

‍
docker commit <containerID> myapp

The container ID is visible all the time you’re inside the container after ‘root@’…

Let’s verify that our image is saved…

docker images

This will bring out all list of images you have.

It shows two, one is our configured app, and another Ubuntu which was automatically downloaded.

2. Replicating test environments

You’ve already seen that our clean test app lies as an image, which is ready for launch any moment. You can launch more than one instances in seconds.

Let’s launch our very first test instance:
‍

docker run -t -i myapp

‍

Interesting thing to note here is that when this runs as a container, you are actually creating an isolated clean setup of your app, which can be used for all crazy testing without getting worried about.

It has its own filesystem and network.

Once inside the container you can run/test your app. For now:
‍

service apache2 start

curl http://localhost

At the same time, you can open another terminal and launch parallel containers. Since each container runs in isolation, so does your application instance, which makes it testing heaven. No interaction with system or with each other.

3. Going further

Practically speaking you can do a lot more like, sharing deployed apps (docker images) with teams. Run instances for different testing purposes etc.

Some of these operations will require you to learn port forwarding functions etc. which cannot all be covered here at this time, but feel free to ask me or post a comment below.

Benefits

I’ll admit that I’ve just started scratching surface here. Docker is really powerful, especially for testing.

So let’s see how teams can really benefit from it:

Sharing

Instead of sharing the repository URL and credentials, imagine how cool would be sharing running apps. You send your testing team just name of the image

And all they do is:
‍

docker run –t –i yourapp

You can have several images for versions or branches or experimental features. You never have to worry about installation docs or system configuration.

Replication

The greatest benefit it offers in testing world is replication of testing environment. When you have one image created, you can launch 10 or even 100 of instances for your testers.

In short you never have to worry about ports being used by one instance of app, just launch it inside docker. You can even get one EC2 instance and use that as a central hub for running test apps for whole team.

Compartmentalization

If your testers are installing apps on a their physical machine again and again, they are likely to run into dependencies issues over time.

Have you ever ran into this issue in an old machine? You try installing a ruby gem and it just doesn’t work. Then you try fixing dependencies and one hour just flies by and you still cannot get that gem installed. You’ll never have to worry about these.

Sounds familiar? Unfortunately it’s common for developers to have this attitude – that’s why you need a bulletproof quality control process in place. Test Collab is a test management solution that solves all problems around QA. Check us out with quick tour!

‍