1 00:00:00,001 --> 00:00:01,501 [No Audio] 2 00:00:01,501 --> 00:00:05,234 Let's start our demo where we have ended the previous one. 3 00:00:05,434 --> 00:00:07,901 The list of containers is still the same, 4 00:00:08,034 --> 00:00:10,267 just the time duration has updated. 5 00:00:10,267 --> 00:00:13,800 In previous demo, we had created the container called 6 00:00:13,800 --> 00:00:17,234 cc_busybox-A, but we did not run it. 7 00:00:17,234 --> 00:00:21,720 Now, to send it into running state, let's use docker container 8 00:00:21,720 --> 00:00:24,967 start command followed by the name of the container. 9 00:00:25,101 --> 00:00:28,167 We don't have to provide flags like itd, 10 00:00:28,167 --> 00:00:30,450 since they have already been passed during 11 00:00:30,450 --> 00:00:32,701 the create command, let's run it. 12 00:00:32,701 --> 00:00:34,334 [No Audio] 13 00:00:34,334 --> 00:00:39,150 We won't even get a container id here, since, that too had been 14 00:00:39,150 --> 00:00:42,780 generated previously, all we will get is the name 15 00:00:42,780 --> 00:00:45,720 of the container as a nod to success of the 16 00:00:45,720 --> 00:00:48,234 command in typical Docker CLI style. 17 00:00:48,234 --> 00:00:52,080 Time to get repetitive, and list out the containers again, 18 00:00:52,080 --> 00:00:56,070 using 'docker ps -a', and we have an update 19 00:00:56,070 --> 00:01:01,020 our created container 'cc_busybox -A' is now finally 20 00:01:01,020 --> 00:01:04,290 in running state. Just like start, we also have a 21 00:01:04,290 --> 00:01:07,620 command to stop the containers, since a has just 22 00:01:07,620 --> 00:01:11,234 started running, let's stop cc_busybox_B. 23 00:01:11,867 --> 00:01:15,767 Again, a confirmation signal is the name of the container. 24 00:01:16,367 --> 00:01:22,367 And if you want to verify it, let's list our containers again and wait. 25 00:01:22,501 --> 00:01:25,067 Where's our cc_busybox_B? 26 00:01:25,767 --> 00:01:29,767 Does that mean there is an error? Well, no. 27 00:01:30,134 --> 00:01:34,201 If you remember, we had applied a flag called rm 28 00:01:34,201 --> 00:01:37,401 in our last demo with docker run command on 29 00:01:37,401 --> 00:01:40,920 cc_busybox_B container, which meant that the 30 00:01:40,920 --> 00:01:45,301 container will be deleted once it has stopped running. 31 00:01:46,067 --> 00:01:48,120 The use is simple. If you want to 32 00:01:48,120 --> 00:01:50,820 reuse the container, keep it, if you don't want to 33 00:01:50,820 --> 00:01:53,640 reuse it, remove it and free up some resources. 34 00:01:54,467 --> 00:01:57,780 Next, we have the restart command. Let's restart 35 00:01:57,780 --> 00:02:00,001 our cc_busybox-A container. 36 00:02:00,734 --> 00:02:03,734 We will also give it a buffer of 5 seconds 37 00:02:04,303 --> 00:02:06,401 and when we verify it, 38 00:02:06,401 --> 00:02:10,101 what we get is a fresh restarted container up and running. 39 00:02:10,101 --> 00:02:12,900 Finally, I think all of us would agree 40 00:02:12,901 --> 00:02:17,634 that cc_bbusybox-A was not that great of a naming convention to follow. 41 00:02:18,401 --> 00:02:22,001 Its just lengthy, over complicated and bland. 42 00:02:22,867 --> 00:02:25,434 If you encounter such thoughts with your containers, 43 00:02:25,434 --> 00:02:27,901 we have a command to rename them. 44 00:02:28,467 --> 00:02:30,930 Let's be a bit more casual and 45 00:02:30,930 --> 00:02:36,601 rename cc_bbusybox-A as my-busybox. 46 00:02:37,734 --> 00:02:41,101 And when we list them, we can see the changes reflected. 47 00:02:41,101 --> 00:02:43,140 By the way, notice that the 48 00:02:43,140 --> 00:02:46,620 container has just been renamed, not restarted, 49 00:02:46,734 --> 00:02:50,100 which means, we can rename them almost whenever we 50 00:02:50,100 --> 00:02:53,001 want unless they affect some other containers. 51 00:02:53,001 --> 00:02:55,680 In next lecture, we will do something more 52 00:02:55,680 --> 00:02:58,080 application related with our containers.