-Step 1:
+Step 1 **Let’s begin by containerizing a simple ping process on your node:** @@ -102,9 +99,10 @@ PING 8 .8.8.8 ( 8 .8.8.8): 56 data bytes Press CTRL+C to kill the process. ``` -```text -Step 2: List all of the containers on your node host: -``` ++Step 2
+**List all of the containers on your node host:** + ```shell [ubuntu@node ~]$ docker container ls -a @@ -115,16 +113,17 @@ CONTAINER ID IMAGE COMMAND ... STATUS ... 81484551f69b alpine "ping 8.8.8.8" ... Exited ( 0 ) 50 seconds ago ... ``` -```text + We can see our container and its status. Sending a CTRL+C to the ping process that was attached to our terminal killed the ping, and since ping was the primary process in our container, it caused the container itself to exit. -``` -```text -Step 3: Let’s run the same container again, this time with the -d flag to detach the ping process -from our shell so it can run in the background: -``` + ++Step 3
+**Let’s run the same container again, this time with the -d flag to detach the ping process +from our shell so it can run in the background:** + 1. The Container Lifecycle @@ -137,10 +136,10 @@ from our shell so it can run in the background: 4bf570c09043c0094fef87e9cad7e94e20b2b2c8bd1029bb49def581cdcb ``` -```text + This time we just get the container ID back (4bf5... in my case, yours will be different), but the ping output isn’t streaming to the terminal this time. -``` + ```text List your running containers: @@ -154,68 +153,87 @@ List your running containers: CONTAINER ID IMAGE COMMAND STATUS ... 4bf570c09043 alpine "ping 8.8.8.8" Up About a minute ... ``` -``` + By omitting the -a flag, we get only our running containers - so only the one we just started and which is still running in the background. -``` -Step 4: Stop your running container: -``` + ++Step 4
+**Stop your running container:** + +```shell [ubuntu@node ~]$ docker container stop+Step 5
+**Run the docker container ls again, and you’ll see nothing; there are no running +containers. To see our stopped containers, again use:** + +```shell [ubuntu@node ~]$ docker container ls -a ``` -``` + +```shell CONTAINER ID IMAGE COMMAND CREATED STATUS 4bf570c09043 alpine "ping 8.8.8.8" 4 minutes ago Exited ( 137 ) a minute ago 81484551f69b alpine "ping 8.8.8.8" 8 minutes ago Exited ( 0 ) 8 minutes ago ``` -``` + The exit codes presented (137 and 0) are the exit codes of the ping process when it was terminated. -``` -Step 6: Restart the container you just exited (it should be the one more recently created, with the -137 exit code), and list containers one more time: -``` + ++Step 6
+**Restart the container you just exited (it should be the one more recently created, with the +137 exit code), and list containers one more time:** + +```shell [ubuntu@node ~]$ docker container start+Step 1
+**Retrieve your state and config information about your running container:** + + + +```shell [ubuntu@node ~]$ docker container inspect+Step 2
+**Retrieve your resource consumption stats about your container:** + + +```shell [ubuntu@node ~]$ docker container stats+Step 3
+**Retrieve the same information as the previous step, formatted as JSON and only +instantaneously, without streaming:** + + +```shell [ubuntu@node ~]$ docker container stats --no-stream \ --format '{{json .}}'+Step 6
+**Retrieve the logs from your containerized process:** + 1. The Container Lifecycle -``` +```shell [ubuntu@node ~]$ docker container logs+Step 5
+**Get a list of processes running in your container:** + +```shell [ubuntu@node ~]$ docker container top+Step 1
+**Restart your ping container, exactly as you did before:** 1. The Container Lifecycle -``` +```shell [ubuntu@node ~]$ docker container start+Step 2
+**Look at the PID tree of your container from the container’s perspective by running ps +inside your container:** + +```shell [ubuntu@node ~]$ docker container exec+Step 3
+***Launch an interactive shell inside your running container:*** + +```shell [ubuntu@node ~]$ docker container exec -it+Step 1
+**List all of your containers one more time:** -``` +```shell [ubuntu@node ~]$ docker container ls -a CONTAINER ID IMAGE COMMAND CREATED STATUS 4bf570c09043 alpine "ping 8.8.8.8" 37 minutes ago Up 10 minutes 81484551f69b alpine "ping 8.8.8.8" 41 minutes ago Exited ( 0 ) 41 minutes ago ``` -Step 2: Remove the exited container: -``` ++Step 2
+**Remove the exited container:** + +```shell [ubuntu@node ~]$ docker container rm+Step 3
+**Attempt to remove the running container:** + +```shell [ubuntu@node ~]$ docker container rm+Step 1
-``` +**Create a container using the centos:7 image and connect to its bash shell in interactive +mode:** + +```shell [ubuntu@node ~]$ docker container run -it centos:7 bash ``` -Step 2: Explore your container’s filesystem with ls, and then create a new file. Use ls again to + ++Step 2
+**Explore your container’s filesystem with ls, and then create a new file. Use ls again to confirm you have successfully created your file. Use the -l option with ls to list the files and -directories in a long list format. +directories in a long list format.** -``` +```shell [root@2b8de2ffdf85 /]# ls -l [root@2b8de2ffdf85 /]# echo 'Hello there...' > test.txt [root@2b8de2ffdf85 /]# ls -l ``` -Step 3: Exit the connection to the container: -``` ++Step 3
+**Exit the connection to the container:** + +```shell [root@2b8de2ffdf85 /]# exit ``` -Step 4: Run the same command as before to start a container using the centos:7 image: + ++Step 4
+**Run the same command as before to start a container using the centos:7 image:** 1. The Container Lifecycle -``` +```shell [ubuntu@node ~]$ docker container run -it centos:7 bash ``` -``` -Step 5: Use ls to explore your container. You will see that your previously created test.txt is + ++Step 5
+**Use ls to explore your container. You will see that your previously created test.txt is nowhere to be found in your new container; while both containers were based on the same centos:7 image, changes made to the filesystem inside a container (like adding test.txt) are -local only to the container that made the change, preserving independence between containers. -Step 6: Challenge: Using the commands you learned previously, restart the container you -created test.txt in, connect to it, and prove that that file is still present in that container. -Step 7: Remember to clean up by deleting the containers created in this section. -``` +local only to the container that made the change, preserving independence between containers.** + ++Step 6
+**Challenge: Using the commands you learned previously, restart the container you +created test.txt in, connect to it, and prove that that file is still present in that container.** + ++Step 7
+**Remember to clean up by deleting the containers created in this section.** + ### 1.6. Conclusion -``` In this exercise we learned the basic commands to start, stop, restart and investigate a container. But beyond basic syntax, we learned some examples of the importance of the primary, PID 1 process inside a container. The state of this process determines the liveness of our container, the STDOUT and STDERR of this process is what’s logged by container logs, and this process’ response to SIGTERM determines how our container behaves during a controlled shutdown. -``` - -1. The Container Lifecycle ``` @@ -562,79 +646,101 @@ By the end of this exercise, you should be able to: ### 2.1. Modifying a Container -Step 1: Start a bash terminal in a CentOS container: ++Step 1
+**Start a bash terminal in a CentOS container:** -``` +```shell [ubuntu@node ~]$ docker container run -it centos:7 bash ``` -Step 2: Install a couple pieces of software in this container - there’s nothing special about wget, -any changes to the filesystem will do. Afterwards, exit the container: -``` ++Step 2
+**Install a couple pieces of software in this container - there’s nothing special about wget, +any changes to the filesystem will do. Afterwards, exit the container:** + +```shell [root@dfe86ed42be9 /]# yum install -y which wget [root@dfe86ed42be9 /]# exit ``` -Step 3: Finally, try docker container diff to see what’s changed about a container relative -to its image; you’ll need to get the container ID via docker container ls -a first: -``` ++Step 3
+**Finally, try docker container diff to see what’s changed about a container relative +to its image; you’ll need to get the container ID via docker container `ls -a` first:** + +```shell [ubuntu@node ~]$ docker container ls -a [ubuntu@node ~]$ docker container diff+Step 1
+**Installing which and wget in the last step wrote information to the container’s read/write layer; now let’s save that read/write layer as a new read-only image layer in order to create a new -image that reflects our additions, via the docker container commit: +image that reflects our additions, via the docker container commit:** -``` +```shell [ubuntu@node ~]$ docker container commit+Step 2
+**Check that you can see your new image by listing all your images:** + +```shell [ubuntu@node ~]$ docker image ls ``` -``` + + +```shell REPOSITORY TAG IMAGE ID CREATED SIZE myapp 1 .0 34f97e0b087b 8 seconds ago 300MB centos 7 5182e96772bf 44 hours ago 200MB ``` -Step 3: Create a container running bash using your new image, and check that which and wget -are installed: + ++Step 3
+**Create a container running bash using your new image, and check that which and wget +are installed:** 2. Interactive Image Creation -``` +```shell [ubuntu@node ~]$ docker container run -it myapp:1.0 bash [root@2ecb80c76853 /]# which wget ``` -``` + + The which commands should show the path to the specified executable, indicating they have been installed in the image. Exit your container when done by typing exit. -``` + + ### 2.3. Conclusion -``` + In this exercise, you learned how to inspect the contents of a container’s read / write layer with docker container diff, and then commit those changes to a new image layer with docker container commit. Committing a container as an image in this fashion can be useful when developing an environment inside a container, when you want to capture that environment for reproduction elsewhere. -``` -2. Interactive Image Creation ## 3. Creating Images with Dockerfiles (1/2) @@ -1582,7 +1688,6 @@ allocating and managing disk space for logs; while we can’t provision an unlim on each of our nodes for logs, the more logs we’re able to keep, the further back in history we can look when troubleshooting our deployments. ``` -7. Managing Container Logs ## 8. Sharing and Streaming Logs @@ -1676,4 +1781,5 @@ you’re running, because you’ll want a standardized way of consuming logs fro processes. Once all relevant logs are available via the container logging API, it becomes relatively straightforward to integrate these logs with whichever logging aggregator you prefer. ``` -8. Sharing and Streaming Logs + +