DinD or DooD but not D&D

While surfing my usual waves at google I came across an article with some peculiar information. It does not directly relate to our current homework, which deals with the backend and API ties, but it is somewhat relevant. The article presents the argument of security in using DinD as a liability exposing the operating system to the container directly. Another important factor was the reliability of DinD and unintended consequences and conflicts with the use of it. I can’t think of possible bugs that docker in docker can cause, but I guess I can see how different operating systems with different file hierarchy and possibly arbitration can be a messy thing to untangle. Regardless, he shows a quite simple and cool way to have an important DinD capability without using DinD.

Why use docker in docker

while scouting for articles I came across this one https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ by Jérôme Petazzoni, it is interesting and tells the story of how DinD  was actually created to help develop docker itself. The use of DinD, as it appears to me, is mostly based on the need to run multiple images within docker to achieve continuous integration. Being able to test the entire system and making sure that integrity is maintained is what makes DinD so useful, or does it?

Why not use docker in docker

The author of the article mentioned tells the many headaches of developing DinD, some of which involves convoluted solutions that worked partially. The more I work and learn from this class, the more I determine that, if something is really complicated and requires too many hacks, it us not worth pursuing. I believe this was the case for early DinD. Some of the problems encountered were different security modules and many others that I am not quite familiar with, and can’t really discuss intelligently about. But DinD moved on, and a lot of improvements were made to improve on a lot of the issues, although I believe issues remain, partially because the article’s author involved with the development of it, asks you to use something else.

Do this instead, DooD docker out of docker

Thankfully, the article’s author gives a solution to the problem, and I didn’t even have to go back to the original google wave I surfed earlier to retrieve it. He mentions DinD works in some kind of quasi object-oriented principle of inheritance, where the containers have a family like hierarchy, this may cause some disturbance in the force. The solution he shows act squashing that inheritance down to a sibling relation, no one depends on anyone, we are all in the same level. The solution works by volume mount, mapping the docker socket. This is the solution for the running DooD in a project that requires continuous integration, “docker run -v /var/run/docker.sock:/var/run/docker.sock  -ti docker”, there are probably advantages as well as disadvantages to doing this but ill leave that for you to decide.

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 )

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

%d bloggers like this: