rubber docker

 Thousand different blogs and people rambling about docker, and whatnot, and years later of its boom, I slowly get the knowledge of wtf is docker and why it might be useful. 

I still think it's super complex and flexible, and that most people do not fully understand the nuances between the different situations you can get at with it.

Here I leave some links that in one way or another have made me "tick" something about docker.

• https://courses.cognitiveclass.ai/courses/course-v1:IBMDeveloperSkillsNetwork+CO0101EN+v1
• https://towardsdatascience.com/learn-enough-docker-to-be-useful-b7ba70caeb4b
• https://dockerbook.com/TheDockerBook_sample.pdf
• https://blog.sixeyed.com/windows-dockerfile-26/
• https://medium.com/@nagarwal/lifecycle-of-docker-container-d2da9f85959
• https://medium.com/the-code-review/docker-run-vs-exec-deep-dive-into-their-differences-19a1041735a3

One of the differences that were somehow harder to grasp was what exactly makes a container different than an image.

As of what I know today, a docker image has its read-only layers. A container that you spawn off this image will have a rw layer on top of that, and will point to the top layer of the image, that's why you can have 2 containers off the same image.

If you want to create an image out of a container (that means, start some image, fuck around manually as much as you want, and then store it to a runnable image), you can use docker commit.

Another option to create an image out of another image is to create a dockerfile and make that dockerfile start FROM the initial image. Then, in the dockerfile you fuck around, and after that you'll have an image where you can spawn off many containers.

The image doesn't have any state. You build it and that's it.  A container, apart from the filesystem itself is a bunch of processes that are running, and a network setting, and mounted volumes.

You can start a container from an image with different network settings, or exposed ports. That belongs to the container dimension.  And containers can be in multitude of states. halt,run,stop,pause,....

Another weird thing is what does it mean to run a command in a container.  If you have a container running, you can use 'docker exec' and you'll run a command inside that container. no new container will be created, and if this command changes some internal state, or creates a file, it will create a file in that already existing container.  If instead, you 'docker run', you should pass an image name, not a container name, and if the command you run is stateless, and just does something to the outer world (run migrations), you can run it either with run or with exec inside an already running container (if you have one)