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.

From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho and used with permission of the author. All other rights reserved by the author.

Hi everyone, or one, however many, hope all is well. These last few weeks have been hard for all of us, and it is tuff to keep a captain’s log when the sea is turbulent and requires careful navigation. This is the reason I decided to try something new, something I suppose I should have been doing all along. Instead of studying the subject and writing the experience, I will try to combine writing, while, getting acquainted with the subject. Disclaimer, this is a test, it is a discussion from following the tutorial not instructions. Feel free to follow the tutorial –the link is at the end.

The beginning of this tutorial has us creating a folder in cmd and opening that folder, I tried to follow it to the letter.  Windows users tend to get lazy with all the easy click visual aids and underestimate the power of the shell (pun intended).  While playing through a python file, I decided to write the script on the shell and forgot to use “”.  Many lines later I realize the time I wasted with the useless typing effort. Echo “import time” > app.py was all that I needed, sometimes we go through the extra effort without realizing there is no extra reward. The focus of this tutorial is not the python script [ctrl c, ctrl v is my best friend/enemy].

The second part of the tutorial has us setting up a Dockerfile. I wasted some time trying to find the [.extension] for Dockerfile, which shows how sometimes is easy to go around chasing our tails in tutorials. The tutorial has a very good set of explanations on what every line is doing. I really like the RUN pip install -r requirements.txt, which saves space and compartmentalize things, all we must do is write the txt for the requirements in that one file and we never have to touch the Dockerfile for petty things such as these.

Step 3 has us creating a [.yml] file for the compose json like statements. As mentioned in the tutorial this compose file defines a [web] and [redis] services, I assume the version is not linked to anything or it is set at the developer’s discretion giving the condition of some actual project. The [web] service just points to the port that have been exposed from the Dockerfile, I suppose. The other service [redis] is an image to run parallel to the image already running from Dockerfile.

The final step was to just run [docker-compose up] and I must say there is nothing more pleasing than blue text and no errors at the end. It then asks you to use the keyword [volumes] in the [.yml] file to bind the current directory on the host to /code, I must say I got an error for missing a space on [-.:/code] instead of [- .:/code], see the difference.  We’ve done this in class, but any good guitar player could tell you –repetition is the name of the game.

https://docs.docker.com/compose/gettingstarted/

From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho and used with permission of the author. All other rights reserved by the author.