Welcome back to our series covering all things Docker. In our previous article, Docker Advanced: Deploying with Docker-Compose, we covered the basics of Docker-Compose, how to create a docker-compose.yaml file, and the structure of commands within Docker-Compose. In this article, we’ll cover a selection of basic Docker commands which are essential for any systemadmin managing containers within Docker.
Looking for information on a specific command? Use the table of contents below to jump to any section you’re specifically looking for or read on for a general covering of the 6 commands you most need to know.
docker ps Command
So let’s say you’ve built a container or two in Docker. First things first, how can we tell which containers are actively running? We can get this information by using the command docker ps which will display a list of running containers. This is the Docker counterpart to the ps command in Linux.
Running the command in our terminal we see:
1 [hivelocity@fedora Docker-Article]$ docker ps
2 CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
3 dccb3084edee ghost:latest "docker-entrypoint.s…" 4 hours ago Up 4 hours 0.0.0.0:8080->2368/tcp, :::8080->2368/tcp docker-article_ghost_1
4 3532dab3e08f mysql:8.0 "docker-entrypoint.s…" 4 hours ago Up 4 hours 3306/tcp, 33060/tcp docker-article_db_1
5 [hivelocity@fedora Docker-Article]$
This shows us a plethora of useful information on the running state of our containers. This command is useful for checking if a container deployed correctly, verifying container/host ports, and much more.
docker logs Command
So now that we know our containers are running, we can use the docker logs command to display the logging output of any running container. Entering this command with the -n option will tail the logs to a certain number of lines.
But when would this command be useful?
Well, there are many instances where an application will refuse to deploy correctly or the network may be nonfunctional. It may not be apparent what the problem is at a glance, but thankfully, Docker makes logs very easy with just a single command.
For instance, I wonder what our ghost container will say if I kill the db container?
1 [hivelocity@fedora Docker-Article]$ docker kill db
2 db
3 [hivelocity@fedora Docker-Article]$ docker logs ghost
4 [2022-11-30 05:45:33] INFO Ghost is running in production...
5 [2022-11-30 05:45:33] INFO Your site is now available on http://localhost:8080/
6 [2022-11-30 05:45:33] INFO Ctrl+C to shut down
7 [2022-11-30 05:45:33] INFO Ghost server started in 2.63s
8 [2022-11-30 05:45:34] INFO Database is in a ready state.
9 [2022-11-30 05:45:34] INFO Ghost database ready in 3.601s
10 [2022-11-30 05:45:41] INFO Ghost URL Service Ready in 10.157s
11 [2022-11-30 05:45:41] INFO Adding offloaded job to the queue
12 [2022-11-30 05:45:41] INFO Scheduling job clean-expired-comped at 59 5 0 * * *. Next run on: Thu Dec 01 2022 00:05:59 GMT+0000 (Coordinated Universal Time)
13 [2022-11-30 05:45:41] INFO Ghost booted in 10.353s
14 [2022-11-30 05:45:41] INFO Adding offloaded job to the queue
15 [2022-11-30 05:45:41] INFO Scheduling job update-check at 44 19 0 * * *. Next run on: Thu Dec 01 2022 00:19:44 GMT+0000 (Coordinated Universal Time)
16 Connection Error: Error: Connection lost: The server closed the connection.
17 Connection Error: Error: Connection lost: The server closed the connection.
18 [2022-11-30 05:50:01] ERROR Unhandled rejection: getaddrinfo EAI_AGAIN db
19
20 getaddrinfo EAI_AGAIN db
21 Error Code:
22 EAI_AGAIN
23 ----------------------------------------
24 Error: getaddrinfo EAI_AGAIN db
25 at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:109:26)
26
27 [2022-11-30 05:50:38] WARN Ghost is shutting down
28
As you can see above, thanks to the Docker logs, we can see exactly what the problem is. If we want to investigate the db further (say we didn’t already know we killed it), we can run docker logs db for logs on the database container too.
docker restart Command
This next command, docker restart, is rather straightforward. It restarts a Docker container. This command is useful when changes are made to configuration files, or for troubleshooting purposes.
docker network ls Command
The command docker network ls lists out all available networks within Docker. For example, running this command, we get the following output:
1 [hivelocity@fedora Docker-Article]$ docker network ls
2 NETWORK ID NAME DRIVER SCOPE
3 0ccfeda06a30 bridge bridge local
4 ddc14603bb6e docker-article_ghost-net bridge local
5 5e9387d96b95 host host local
6 902ca789121a none null local
Here we can see that we have four networks. Three are created by default by Docker, and the docker-article_ghost-net is the one we defined in our Docker-Compose file from the previous article. There isn’t much to be done with the three networks created by default, as most administration is done with the networks we define with our containers.
docker network inspect Command
The docker network inspect command allows us to inspect networks and view the gateway, subnet, and containers inside a network.
1 [hivelocity@fedora Docker-Article]$ docker network inspect docker-article_ghost-net
2 [
3 {
4 "Name": "docker-article_ghost-net",
5 "Id": "ddc14603bb6ec254607379bd97fd712eafe93ffc9dee63025a70a03d42c08efb",
6 "Created": "2022-11-29T19:42:28.49966953-06:00",
7 "Scope": "local",
8 "Driver": "bridge",
9 "EnableIPv6": false,
10 "IPAM": {
11 "Driver": "default",
12 "Options": null,
13 "Config": [
14 {
15 "Subnet": "172.20.0.0/16",
16 "Gateway": "172.20.0.1"
17 }
18 ]
19 },
20 "Internal": false,
21 "Attachable": true,
22 "Ingress": false,
23 "ConfigFrom": {
24 "Network": ""
25 },
26 "ConfigOnly": false,
27 "Containers": {
28 "6933100da8ea8d61f64f19dc283fb2bda800adf3ece6c623a66c8b9e9629b3fa": {
29 "Name": "ghost",
30 "EndpointID": "dd4c19f1c658a51c8e97e3d59986c07838ecb5354ce70b9ff6d73dca39517816",
31 "MacAddress": "02:42:ac:14:00:03",
32 "IPv4Address": "172.20.0.3/16",
33 "IPv6Address": ""
34 }
35 },
36 "Options": {},
37 "Labels": {
38 "com.docker.compose.network": "ghost-net",
39 "com.docker.compose.project": "docker-article",
40 "com.docker.compose.version": "1.29.2"
41 }
42 }
43 ]
Here we can see some useful metadata along with the IP addresses for our individual containers. These IP addresses exist within Docker, so they will not be accessible outside the host machine. All Docker network addresses exist within private IP address space, which can be customized within Docker.
docker exec Command
The docker exec command allows us to run new commands within containers. Most commonly this command is called with the -it flags. The i flag stands for interactive, and -t for tty. These flags allow for a terminal within the container.
For instance we can run docker exec -it ghost bash to start a bash shell within our Ghost container.
1 [hivelocity@fedora Docker-Article]$ docker exec -it ghost bash
2 root@6933100da8ea:/var/lib/ghost# ls
3 config.development.json config.production.json content content.orig current versions
This command is extremely useful for debugging containers or for learning more about how they work.
A Visual Demonstration Using Docker-Compose
Other Common Docker Commands
Although this article only covers 6 of the most essential Docker commands, there are many many more useful commands available for working with containers. Thankfully, all of these commands can be found whenever needed in the official Docker CLI reference.
So, there you have it. We’ve learned what Docker is, how containers run, how to make Docker-Compose files, and some examples of commonly used Docker commands.
Now what?
Time to Have Fun with It
From here the best way to learn Docker better is to deploy containers for yourself! This can be by hosting services with containers, deploying containers for test use as a lightweight alternative to VM’s, and much, much more.
Once you become familiar with containers, I highly doubt you will go back to traditional deployments. Docker makes everything simpler, allowing organizations to focus on growing their business instead of worrying about the operational overhead of their deployments. If you find that Docker is improving development for your organization, look into Kubernetes as well. In the end, the best solution is whichever one gives the best results for your specific use case, and the only way to find out which tools will serve you best is to try them and see.
We hope that you now have a better understanding of Docker and how it can revolutionize the way your digital infrastructure develops and grows. Thanks for reading, and be sure to check out our blog and knowledge base for all the latest content and industry insights from the hosting experts at Hivelocity.
– written by Eric Lewellen