Of course containers are not the same as processes you find in operating systems, but at a conceptual level there are many similarities. In this fortnightly article series I aim to explore this notion at the expense of getting your hands a little dirty. Let’s dive in,
A process is an atomic component of a program(or a complete program) in execution, in Linux, each process has its own unique id(PID) and is capable of creating child processes(forking), this in turn makes a process’s PID into a PPID(parent PID). The PID’s allow the operating system to get hold of the process and run it through its various process states as need be.
The concept of the containers derives from the wonderful world of Docker, where a bunch of super smart geeks figured out ways of extending and building up on a few process isolation, packaging mechanisms/concepts present in Linux, they should also be credited for building an awesome product range out of their advancements and making them available to the masses. A container is an image of a dockerized application in execution(well technically the images stay immutable and it is a completely new layer called the container layer that provides access to the immutable content but for simplicity sake, lets say a container is an image in execution).
Note: to try out the examples in this article you will need to have docker configured in a linux distribution(i’m using ubuntu trusty with docker 17.06.0-ce), have internet access and be logged in with a user that has permissions to use docker and the other commands listed(you may also require root access for some of the commands listed).
Let’s get an OS process and a container going. Open up three terminal sessions.
In one terminal type in the command found below. The command will start printing its message on the terminal you typed in, every two seconds, indefinitely!
Command Block 1
Output Block 1
In the second terminal type in the command found below, assuming you have not used the tomcat:8.0 on your box before, docker will pull the required image(a layer at a time) from docker hub and perform the predefined run sequence for the container. Bam you got a container running.
Command Block 2
Output Bloack 2
Let’s turn to the third terminal to peer into the mannerisms of these two creators. Run the following two commands to get a few top level details about the process and the container.
Command Block 3
Output Block 3
In the output of the two commands pay attention to the PID of the processtestscript.sh and the Container ID of the tomcat:8.0 container. These two identifiers serve the same purpose, which is to uniquely identify these in execution entities.
Of Process states and Container states
A linux process is birthed when a parent process forks a child process into being, this new process may then be transitioned into various different states as need be. from these the most common states are, running, sleeping and stopped.
A parent process typically goes into a sleep state when it forks a child process, these processes wait for signals to move along their execution paths. Keeping with the topic of discussion of this article, we will concentrate on the two states and the transition between these two states that are similar in concept to that what’s found in the world of containers.
As mentioned earlier on, a container is a collection of immutable layers with a mutable layer put on top to provide access to the contents of these immutable layers. There are various strategies of providing access to the contents of the immutable layer, which we will not get into in this article. A crude symbolic state representation of this state transfer would look much like that of a process going from stopped to running.
Let’s switch back to the first terminal running the processes and change the process state to stopped and then back to running.
Go back to the output you received in Command Block 3 and find the PID for the processtestscript.sh process. Switch to the third terminal and run the next command block with the PID you just extracted. To me its,
Command Block 4
Output Block 4
Now, send a CONT signal(18) to the stopped process, to resume it.
Command Block 5
You will notice that the process resumes and starts printing its message again. Back from the dead, picking up from where it left off.
Now let’s do something similar with our container and observe how it behaves. To make sure, it has preserved its state when it transitions from Stopped to Running, let’s go into the container and add a new file. Take the Container ID from Output Block 3 and run Command Block 6 to go into the container. Once inside the container run the echo command to create a new file.
Command Block 6
Now switch to back to the third terminal and run command block 7 to stop the container, observe that the container has stopped.
Command Block 7
Output Block 7
Finally let’s start the stopped container, go into it and check if the file we created is still there,
Command Block 8
Output Block 8
In this article we looked at two ways in which linux processes and docker containers are similar. These being,
- Containers and processes are both atomic computational resource representations.
- Containers and processes both can be stopped and then be resumed to carry on from where they left off.
In the next article in this series, Let’s expand this analogy further and see where it leads..