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.

Last week reading took us through one design pattern the singleton pattern and a quasi-design pattern the simple factory technique. I was very impressed by both and took some time to analyze their delivery method –how they presented their arguments. On singleton the author presented the design as a conversation in an almost Zen tone. I was attracted to his way of explaining because I believe that a lot of times when studying we let the stress get the better of us and miss many important points. The step by step really show not just how but why. A lot of times we write a lot of code because we know how but not always know why we write it a certain way, which I believe makes the knowledge untransferable –although why is not always important.

The relaxed Zen mode of explaining is also something I appreciate because I am a strong believer that sometimes, some things should be explained like you would explain a 5-year-old, and I have no shame in listening like a 5-year-old. It is easy to have many years of experience on something and forget some of the things taken for granted are very important to the beginner(me). The Zen approach also reminds me of Buddhist monks drawing complex sand diagrams only to erased them and start over again. It is hard to erase bad habits and acquiring good ones, but by creating the habit of erasing habits the learning cycle can be increased considerably. That’s all I must really say on how the authors carried their message, but the interesting thing was the message itself.

The singleton pattern at first was not impressive if anything I always had a bad view of private or protected variables or methods. I never really understood the need to hide things in code maybe because I never really had to write code of considerable size. Once I started working with the pattern it was like a little light bulb flickered on top of my head and I suddenly started seeing the coolness of obfuscation in this case just preventing object overcrowding. I really thought it was pretty cool and I think that in the way the idea was explained the structure will be in my head for quite some time, and I am a very forgetful person.

The simple factory technique was also well explained in just the right number of words. It was very clear that by consolidating actions or delegating the creation of objects helped to minimize how much one class was doing. Uncle bob always say doing too many things is bad, so I think this applies in this case. I was afraid at first that to implement this was to substitute the singleton pattern that I’ve gotten so fond of, but that was not the case. After implementing it I saw that there were other areas that could be greatly improved by consolidating further. My only fear is to know when to stop –how much is too much consolidation.

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