Sunday, 16 July 2017

Virtualizing The Containerization King - Docker itself!!

 
                                 Docker

Oh yes, I hear you! Its a totally crazy thought to attempt something like virtualizing Docker components. There are many articles saying how Docker's containerization is challenging the virtualization technology. So why on earth did I get this thought of making a virtual docker client? Its simply an engineer's curiosity, stuff which fascinates me. I don't know if something useful will come out of my experiments, but that's the unknown I want to explore. Here is how I set myself upon this new adventure.


Being a die-hard Linux fan since college days, I've spent most of my career admiring Linux. Naturally, I get inclined towards anything coming from that world. I started diving into Docker internals to know more about this de facto containerzation engine. Honestly, I am still at a beginner level when it comes to Docker knowledge.

My Experiment

One day during my innovation time (20% of my working hours at Cloudhouse), I thought of running a Cloudhouse container within a Docker image. So, I setup a win 2016 VM, created a Cloudhouse container and was all set to run it on the docker image. When I tried to connect to docker daemon it wasn't able to connect. I could see that the daemon is running, still the client terminal hanged (neither connecting nor returning an error). In this situation I should have troubleshooted it to see whats misconfigured, but instead of that a different thought struck me

Why not virtualize docker client itself; after all it is just like any other software running on an OS.

So I started virtualizing the docker client using our virtualization engine.

And It Worked!!

To my surprise the virtualized docker client was able to connect to the daemon while the natively installed client was still hanged. I tried it multiple times, but every time the native one was hanging while virtualized one connected perfectly fine. This totally went over my head as both were using exactly the same version of binaries, running on exactly the same environment, trying to connect to the same daemon. I recorded a video (link available in the widget on blog's home page) of the natively installed vs virtualized docker client and saved this VM to experiment later. Then moved on to create another VM to continue my original task of running legacy apps within Docker image on Win 2016 using our virtualization engine. I was able to run Cloudhouse containers (with redirection engine) within Docker's restricted filesystem. I will soon upload a demo video showing legacy (win XP) app on docker.

But The Mystery Remains..

I didn't get time to figure out what is it that got fixed by virtualizing the docker client? May be something misconfigured on my VM which makes native docker client hang, but how could virtualizing it make it connect?

It was late in the evening, so I had to leave my experiment at that stage. It might turn out to be a simple thing, but I am curious to explore more on that as it might open up whole set of features our virtualization could provide for docker itself using redirection engine (such as network isolation, improved security, pre-configured docker images, non-admin management of client console, different versions running simultaneously, etc.).

Feel free to leave your suggestions and watch this space as I continue my crazy experiment of "Virtualizing the Containerization King - Virtual Docker".

 

Priya Saxena

No comments:

Post a comment