 Thank you, Julie. Hi guys. So today you'll look at what should be the PLE one inside it. This is what I have. So the first few slides, I will try to use them to build and drive my point about what should be the PLE one inside it. And during this session, I will try to move towards some shell. I will try to execute some commands to show you some outputs. So let's begin. What do you want to understand by the term namespace? Anybody? So namespace, in a very simple way, it actually abstracts a global resource so that the processors within a namespace thinks that it has an isolated global resource. So it is just an abstract of a global resource. So here we are more concerned about the PLE namespace. So what's the PLE namespace? The PLE namespace is nothing but the process ID. So it actually abstracts the process ID in such a way that the containers, multiple containers, would have the same process ID. So it just abstracts the process ID of the host and then the process which are running inside the containers, they will have the same process ID. But from a host perspective, that process ID is actually mapped to a different actual process ID. So when you start your container, the first process which is started in that particular namespace gets the process ID as one. So if you start a process inside a container, that container would get the process ID as one. As a PLE one. So if a processor is a clone or created using the clone command with the flag clone new PLE, that particular process gets the PLE as one. So that's about the process ID namespace. Now let's look at how do we start, how do we control which process should have a process ID as one. So we have a Docker file and we actually use the CMD or the command. So we have three different ways to start a process and the process which is started can be the PLE ID one inside the container. So the first option that we have which is the most preferred way. So this is how we start a container for example here. So this is just an example of how we start an HTTP container. So this particular format is going to be the exit format. And the next option that we have is using the CMD we can actually pass some parameters to the entry point. So now what's the entry point in Docker or in a container? You're asking what is the entry point? Entry point. So that's the, in terms of other entry points it's HTTP here but is it V1? Yeah, so entry point is nothing but if you don't have a CMD or if you just start a container so that is what it executes for you. And so if you use the CMD parameter you can actually pass some variables to the entry point. And the third option is you can just start a script or you can actually do a shell exec. So if you just say CMD space echo. So first it starts a shell and then it runs the echo command. So this is the first example of a simple container that we are going to see. That is you're just basically installing HTTP and then you're just starting it. So when you run the container so this is the process that would start. And next we have a very simple example of using the third option of CMD. That is we're just starting a script. That is we're just starting a pass script and maybe you could write some ifs and buts and you could do some logits. You could actually find what is the environment variable that is being passed. Based on it you could take some action. So here we are just for the example sake we're just showing you a simple example of top command. So first container is about you're starting using the most widely used option of an exec format or a JSON format in which there is a way you actually want to call. So here we are just starting an HTTP process and the second container we are just starting a pass script and within the pass script we are actually calling our process which is top. So now let's see what happens. So when you start the container here the most important thing that you would see here is so when you use the option command so this particular process that is your first HTTP process gets the PAD as one. And when you start, when you use the second option of using a bash script so here what you see is bash becomes your first PAD and your actual process top is actually the style of the bash process. So this just again is to reiterate. So in the first option we actually use HTTP and we use this option of CMD. So here this particular process becomes the PAD one. So this is the most widely used format and this is what you would generally see if you take any Docker images from Docker Hub or from anywhere. So this is what you would see. And in some cases also you would also see like they start a bash script and within the script you would start your actual process. Now let's look at a simple example and see what if this is a really big thing that you should take care of like which process should be PAD one here. So here we can see this HTTP as a PAD one. Here you see the top of the bash as a PAD one. Now let's take a simple example and I will just show you some command outputs and then let's decide and think which process should be the PAD one. Does it really matter? So again very simple examples. So this may not be the right way or the best practices because I just want to use more space. So I just made it two more like two commands. So here what we're going to do is we have the same Python based web application. Here we are using the first option that is we will start doing the process directly. And the second container what we are going to do is we are going to start the shell script and then call our actual Python process. That's the only difference. So in the first container we are calling the Python based application directly. The second container we are starting a shell script and then we are calling the Python based process. So we will come to it a bit later what it means here. But at this particular point of time we are going to use the same application which we are going to build two containers. The second container is just that we are going to start a bash script and then the bash script is just going to start the Python program. So I already have a container built so it shouldn't take much time. So we will start the first container. So we have started two containers. Here you can see the command. Here we are starting the application directly and here we are starting a bash script and then we are calling the application. So now let's access the application. So we will just try it a couple of times and then change the IP to the second container. The output is the same because we are running the same application in port 8000 and we are getting the same output because the application is the same. It's just that we are just changing how it is running. So now the most important thing. So the first container where we are calling the application directly. So what do you see here? We have different processes. So here we have the PID1 as this particular application and we are seeing different processes. Now same application in a different container where we have the bash as the PID1 and here you see there is no different process. It's the same process. We are running the same process here. But when you access this particular application you are seeing some different processes. But on the second container where you are starting using bash and then you are starting the Python script you are not seeing any different processes. So now it is important for us to keep in mind we should actually decide which process inside the container has to be PID1. Because here the behavior is just different here. The Python process is PID1 but here the bash is PID1. So let's see. So now what's the role of PID1? So in a general Greek system or in a Fedora the PID1 is actually with system D. That's the innate deep process. So this particular process PID1 has many additional roles to take care of. So one of it is process reaping. That is if there is a different process it is the responsibility of PID1 to clean the process from the process table. So let's imagine if you have a container and that container has lot of different processes and at some point of time you would have multiple instances of the same container. And one point of time when the load goes high you would have more different processes on your host system. And what would happen? So let's go back to the... So let's imagine... So from the host system, when you execute the command PS you can actually see the different process. Because these processes in the host also take up a process ID. So this is the actual process ID. So when you have so many different processes at one point of time your PID's process table entries that is the maximum that you can have is 32768. But you can actually change it on the fly. But there's a limit that's being set by before this 32768. So if you have more processes which are in different state they actually take up one entry in your process table. And a process which is in a different state would still consume the ID. So when you have more different processes at one point of time there would be no more free process ID's which can be assigned to your process. So you may or may not be able to log into the system. Or your containers may not be possible to start a new process. So it would actually go into a hung state. So PID1 has an additional role of process ripping. So now what happened to the other container where you have the batch script as the PID1? Or the batch shell as the PID1? So this batch shell has an additional property where it can actually rip its different components. So just to go back and show you that. So here we are not seeing any different process because batch is the shell with the PID1. So it means that batch has an additional feature where it can actually rip different processes. So is batch the answer for this problem? Answer is an S and a No. Let's see why it is a No. The problem here is batch may not properly pass the signal to the process that is actually running. So the moment batch receives the signal it will kill itself. But it may not pass the exact signal to the processes that are running. So imagine if you have a DB application or an application which has a lot of memory in the cache which is not at sync. If such a process is there and if you try to stop the process the signal doesn't go directly to the actual process which is running. So it can leave your process in an inconsistent state. So you actually have one more work around. So this is what we are doing here. We are just making sure that we handle that signal. So here what we are trying to show you is the process should also register as signal handler. The process should also register as signal handler. And if I have the signal make sure that all the child processes are killed and then it exits. So I just have 5 minutes. So let's go back to the example and let's try to kill the process and see what's happening. So we will stop the first container. The first container is the container which actually has the different processes. And it is just a partial process. So I am doing a docker stop. So docker stop what happens when you execute a docker stop. So here you can see it is taking a lot of time. It took around 10 seconds. So when you execute docker stop it sends a sick term and waits for the process to kill itself and exit in a peaceful way. But that doesn't happen because you have some process which are in a different state. And then what docker does is after 10 second time out it sends a sick kill. Now let's stop the other container. So this was fast. Let's look at the exit status. Here you see 143 and 137. So it is 128 plus 15. So 15 is for sick term and 9 is for sick kill. So if you add 128 plus 9 or 128 plus 15 this is the value that you see here. So here we can actually say this particular, the first container was sick kill and the second was stop using the sick term. So it is important for you to have the sickness that you passed while doing a docker stop should be handled properly. So if you have a process inside a container that doesn't handle the child process as well, or if it doesn't handle the sick terms or the sick kills or the signal that you passed, then you have to make sure that the application that you write is written properly to handle them. Or you should register a signal handler. Let's go back. So what do we have as an answer? I mean you could find many such doctors in the internet like a dummy in it or minimal in it like tiny. So they actually have very less code. Just enough to start your process and handle the signals. So when you start using a dummy in it, this is what happens. So this is how the hierarchy would be. First you start a dummy in it and then the dummy in it starts the actual application. Since out of time, let's go to the next important point. Can you have system D inside a container? So with Docker 1.12, I believe it is possible to run system D inside a Docker container without using the privileged option. So you can have a system D inside a container without using the privileged option. And with the new features like the OCI hooks, you can actually register the system and take care of many other things because whatever is needed for a container to start in a non-privileged mode, that feature is actually provided by the OCI hooks. So the moment you start a system D inside a container, the OCI hooks actually takes that and mounts certain things for you. So that you can actually run a system D inside a container in a non-privileged mode. So now the additional benefits. I think I'm out of time, so let's open it up for questions. So I'll just show you quickly. So this is a system D container, this one. So this is system D container which is running. So if I execute machine CTL, so with the OCI hooks it actually registers your container to the machine CTL. Now the advantage as I showed you, I mean as I mentioned in my slide, that you actually get additional benefits of logging. So by default what happens when you execute Docker logs, it actually prints the output of an application if it writes to STD error or STD out. So what about application that actually writes to the SysLog? So when you put an application inside a container, you start thinking about how to handle the logging. So if you have system D inside, you can actually bypass that particular functionality back to the system D. And if you already have a system init file, let's say for Apache, you can just use it. So when you build the container, you just say system CTL enable the particular service. So this is the logging that you see. So from the host system service, you can actually see the logging using the general CTL command. So any application that writes to the SysLog can be taken back to the host system and you can actually see them. Okay, so any questions? I'm already out of time. Yeah, but you should always test, right? I mean that's the pretty much the answer. Shall the answer for solving the process mapping? Yes or no, because you have to test it. You have to make sure that the process signals are properly processed and it's stopped in a proper way. And if you have noticed in a Docker file, you can actually define the signal that has to be used using the stop signal directive. Let's say for any Linux, it doesn't really work well with the sync term. So you can actually define the signal that has to be sent. Using stop signals, right? In the Docker file. Or when you use Docker stop, also you can actually pass the sync term or sync kill whatever you want. Are you using default system re-installation in your container? Yes. Yeah, I'll just show you my default. I'll just show you the Docker file. So it's on Zell. So I'm just installing, I'm just using the system re-package that comes with the Zell 7 platform image or the container image. So the only line that I'm using here is, so I'm just adding my service and then saying system CTL enabled. Yeah, so last question. So right now, the example here that I'm showing you is actually on a Fedora 25 system. So on an upscale, I think you should be able to run because it is again part of 1C. Docker uses 1C now. Now all the OCA hoops makes use of the 1C. So you need not do anything else. Yeah, so thanks guys, so thanks.