How you should think about docker containers if you understand linux.
Introduction and Purpose:
I took a deep dive into linux to try to understand my computer. It took a long time, and I had worked hard too. I worked my a** off to get arch installed on my laptop, which I still use to this day. I never thought I would be building up the most difficult part, in my opinion, of understanding how Docker works. I decided that I wanted to write this article because I could not believe how easy containers are to create, and that during my installation of arch linux, I had essentially done just that. If you have experience with linux and you are looking to work with kubernetes or docker swarm, but you can’t say that you definitively understand what a container is. This article might be able to help you out. One thing I like to tell people that have just gotten started with containters that you are always in a container. Your computer is essentially a container. It’s just an unlimited container. It’s not even exactly unlimited either. It’s limited by your hardware specification, and not only that, but most of the time your machine is limited to some extent by the machine. You tell each partition how much data it is allowed to use. These are just automatically set up for you, so you don’t think about it when you are using your computer, so even when you don’t think you are using a container… you kinda are.
Docker:
You may have heard people say docker is essentially a lightweight vm or you might hear them say it’s a basically the code and everything you need to run it. I don’t like that thinking, and I will show you why. System adminstrators bless them. Have had the tools to work with containers for years. In fact, Docker isn’t anything new. Ok that’s great but still if you don’t subscribe to light weight vm, what is Docker?Docker’s website says, ”A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, run time, system tools, system libraries and settings,” but what does that mean? The first time I asked a senior developer to explain how docker works under the hood he said, “Well, there is a hypervisor which is the operating system on the server, then you create an artificial root access that only allows you to see the operating system that you specified, all configuration options you need are set up, and then your code is ported over.” At that point he had scared me, how would I ever be able to create ingenious code like that… The coolest thing I had done up to that point was put my resume on Alexa. I plan to break up what that senior engineer was trying to tell me into a few simple and easy to understand concepts. Not only that, but I am going to rewrite Docker, part of it and just for the concept, in bash scripting so that we can get a better understanding of what a container is, and why I believe if you have ever installed Arch Linux and understood what you are doing, you should definitely understand how this works.
The Interesting bit: WARNING SOME CODE AHEAD
So the best way I can come up with to explain containers is 3 basic things, control groups, namespaces, and chroot. These are the tools that a system administrator could use to set up a container on their personal machine. Now this will not be something that is scale-able, but you will begin to get an understanding of what a container is.
Let’s start with control groups.
Control groups are pretty straight forward. It’s the amount of resources you want someone to be able to control. It allows for resources to be shared and managed. This is pretty straight forward in Docker. You would use the -m or — memory= both of those are ways to limit how much ram you have access to. I am personally running arch linux. I have my resources managed by a file in /etc/security/limits.conf. You can control how much ram they get, their storage, their access to gpus and a ton more. I could write an entire other article that talks about just the beginner things you can do with cgroups. I mean they are powerful. If you know where your cgroups files are, you can actually see docker create those.
Namespaces-
Cool. So now we were able to limit how much resources someone has access to in your container, but I didn’t really go into the bulk because there is too much. I just wanted to make you aware, so you can understand what is going on. Now, I want to talk about something a little bit different. If cgroups are what control what you can use, namespaces are what you can see. This is where you can control access to processes, mounts, networking and all sorts of other things basically everything you see. The idea is what you can’t see, you can’t access either. We mainly want to focus on processes and networking though. These are important because if you look at the processes on a container, they are different than the processes on your machines. That way you are only in control of the process on that container. You may be looking at everything I am saying, and you might start to think… well we are managing all of these things… That’s what my /dev does in my filesystem… or that’s what /mnt does. These are all essentially root level functions… you’re on to something, and I want to bring it all together.
Lets focus on processes for a second.
is I use the ps command. If I don’t change the namespace to make it so that I can’t see the host machine’s processes you might get something like this
[lucas@krusty-krab pycker]$ ps
PID TTY TIME CMD
9837 pts/1 00:00:00 bash
10978 pts/1 00:00:00 ps
root@container:/# /bin/ps
PID TTY TIME CMD
10995 ? 00:00:00 sudo
10997 ? 00:00:00 bash
10999 ? 00:00:00 ps
Do you see how the processes are high in the container? That’s not what you would expect. You have to set a new namespace in order to fix this issue. You are also going to need to unmount the systems proc and mount it onto /proc on the file system you are using.
root@container:/# /bin/ps
PID TTY TIME CMD
1 ? 00:00:00 bash
2 ? 00:00:00 ps
# things got moved over because of Mediums space limitations. However you can see how this works and we are happy.
chroot-
when you are creating a docker container, you might notice that you have to specify a image. Now, you might see the whole connection. Chroot allows you to change the apparent root directory. So, if we use everything we have talked about until now, and we have a file system; we can control how much memory, storage, gpus and all sorts of other hardware options using cgroups; and, we can control what processes, mounts, and all sorts of networking using namespaces, and now we can change the apparent root to be any linux filesystem whether it be ubuntu, opensuse, redhat or otherwise using chroot. Doesn’t that sound like a container. Now, I realize there are a lot of other things you can do, but the point is, it’s not magic. It’s not wizard jizz. It’s a lot of blood sweat and tears of some brilliant people who created an amazing tool to make it so that we don’t have to fuss with cgroups, namespaces or chroot. We can let docker handle all of those details, and we can code.
Using chroot is pretty simple if you never have before. All you have to do is say:
chroot /path/to/file/you/want/to/be/the/apparent/root
Docker is an amazing tool. It can teach you so much more than you would think possible, and it will take the stress of worrying about all the things I just talked about and throw them out the window. It will show you that everything you learned in linux isn’t a waste. Not that you do though ;). I suggest every team start using Docker because it is truly remarkable.
