1 00:00:00,401 --> 00:00:03,167 A container's lifecycle is pretty much similar to a 2 00:00:03,167 --> 00:00:06,967 process's lifecycle in Linux. Because after all, 3 00:00:06,967 --> 00:00:11,001 a container is just a running process instance of a Docker Image. 4 00:00:11,701 --> 00:00:14,134 We start with the Created stage, 5 00:00:14,134 --> 00:00:17,334 which can be a part of docker run command, or can 6 00:00:17,334 --> 00:00:20,467 be explicitly caused by docker create command. 7 00:00:20,534 --> 00:00:23,767 If it is a part of run command, it will automatically 8 00:00:23,767 --> 00:00:27,101 lead to the next stage, which is Running stage. 9 00:00:27,101 --> 00:00:30,601 It means that the created container or the sheduled 10 00:00:30,601 --> 00:00:33,767 process is running and resources are being 11 00:00:33,767 --> 00:00:37,401 actively used by it. Alternatively, if a container 12 00:00:37,401 --> 00:00:41,067 is explicitly in Created stage, it can be sent to 13 00:00:41,067 --> 00:00:45,967 running state with Start command. Next is Paused stage 14 00:00:45,967 --> 00:00:49,067 which won't occur on its own for the most part, 15 00:00:49,067 --> 00:00:51,401 you can strategically cause it with Docker 16 00:00:51,401 --> 00:00:54,267 container Pause command and resume it similarly 17 00:00:54,267 --> 00:00:57,134 with Unpause command. The container process will 18 00:00:57,134 --> 00:01:00,234 go to Pending stage and once resumed, it will be 19 00:01:00,234 --> 00:01:04,266 back to being up and running. Next is Stopped stage, 20 00:01:04,266 --> 00:01:06,566 which means the process of the container is 21 00:01:06,566 --> 00:01:10,267 terminated, but the container id still exists. 22 00:01:10,267 --> 00:01:13,467 So it can be rescheduled without creating another 23 00:01:13,467 --> 00:01:15,734 container and registering its id. 24 00:01:15,734 --> 00:01:19,601 This can be due to multiple reason, it can be caused by an error, 25 00:01:19,867 --> 00:01:22,734 restart policy, or simply container having 26 00:01:22,734 --> 00:01:25,301 finished its run to completion task. 27 00:01:25,301 --> 00:01:28,201 We can manually stop and restart containers with docker 28 00:01:28,201 --> 00:01:30,834 container stop and restart commands respectively. 29 00:01:30,834 --> 00:01:34,034 Finally, we have Deleted stage where the 30 00:01:34,034 --> 00:01:38,201 terminated container is removed and its id is freed up, 31 00:01:38,634 --> 00:01:41,701 it will stop appearing in the list of containers. 32 00:01:42,467 --> 00:01:44,367 To expand further on multiple 33 00:01:44,367 --> 00:01:47,834 containers from single image, consider this diagram. 34 00:01:47,834 --> 00:01:51,034 The read only layer is common and the 35 00:01:51,034 --> 00:01:53,734 read/write layers are fetching data from it. 36 00:01:53,967 --> 00:01:57,434 This does not cause any data corruption since the data 37 00:01:57,434 --> 00:02:00,367 of Read only layer is not going to be modified in 38 00:02:00,367 --> 00:02:03,034 the first place. And the system just has to 39 00:02:03,034 --> 00:02:06,101 perform multiple read operation on the same data. 40 00:02:06,434 --> 00:02:09,633 This optimizes storage of Docker host whereas the 41 00:02:09,633 --> 00:02:12,267 number of running containers from the same or 42 00:02:12,267 --> 00:02:15,067 different image on a single host will always 43 00:02:15,067 --> 00:02:17,634 depend on host architecture limitations like 44 00:02:17,634 --> 00:02:19,701 memory and processing speed. 45 00:02:19,934 --> 00:02:24,667 Another important aspect of containers is their Copy-on-Write mechanism. 46 00:02:24,667 --> 00:02:27,767 What's that? Well, it's pretty simple. 47 00:02:27,901 --> 00:02:30,367 Till now we have seen that writable layer of 48 00:02:30,367 --> 00:02:34,001 container is mounted to the readwrite layer of Docker Image. 49 00:02:34,201 --> 00:02:36,267 Well that was true, but it has a 50 00:02:36,267 --> 00:02:39,734 little secret to it. The Read only layers file 51 00:02:39,734 --> 00:02:42,867 themselves are untouched. A copy of them is 52 00:02:42,867 --> 00:02:45,967 created and read/write layer is mounted on that 53 00:02:45,967 --> 00:02:49,434 copy, which makes it easier to recover the layers, 54 00:02:49,567 --> 00:02:54,334 in case any unauthorized host file system access or content damage