In my last post, we talked about what Docker is and why it’s more than just a buzzword. But knowing the "why" doesn't help when you're staring at a terminal screen wondering how to actually get a container to do something.
Now, let's look at where Docker lives in the real world and the specific needed for the day to day work.
The "Day-to-Day" Command Handbook 📝
If you’re going to work with Docker, these are the commands you'll find yourself typing over and over again.
1. docker build -t <name> .
Before you can run a container, you need an Image. Think of this as the "factory" step. You’re taking your code and your Dockerfile and baking them into a single package.
-
Pro Tip: Don't forget the
.at the end—it tells Docker to look for the Dockerfile in your current folder!
2. docker run <image>
This is the "Let there be light" command. It takes that image you just built, pulls any missing pieces from the cloud, and starts the container.
-
Example:
docker run nginx(Starts a web server immediately).
3. docker run -d <image>
The -d stands for Detached mode. Without this, your terminal is "stuck" inside the container process—if you close the window, the app dies. With -d, the container runs in the background like a silent ninja. 🥷
4. docker ps
Ever wonder, "Wait, is my database actually running?" docker ps is your status report. It shows you every container that is currently active, their IDs, and which ports they are using. Use docker ps -a if you want to see the ones that crashed or stopped, too.
5. docker exec -it <container_id> bash
Ever needed to "go inside" the container to check a config file or run a manual database migration? This is how you do it. exec stands for execute, and -it makes it interactive so you can actually type things inside.
- Think of it as: SSHing into your container.
6. docker logs <container_id>
Is your app crashing? Did the database fail to start? docker logs is your first line of defense. It shows you everything the application has printed to the console (STDOUT).
-
Handy flag: Use
docker logs -fto "follow" the logs in real-time as they happen. It’s like watching a live heart monitor for your code.
7. docker stop <container_id>
The polite way to tell a container, "Okay, shift's over. Go home." It gives the processes inside a chance to shut down gracefully.
-
Pro Tip: If a container is being stubborn and won't close, you can use
docker kill, but it’s like pulling the power plug—use it sparingly!
8. docker rm <container_id>
Just because you stopped a container doesn't mean it's gone. It’s still sitting on your disk like a parked car. docker rm actually deletes the container instance.
-
Shortcut: Use
docker rm -f $(docker ps -aq)to delete every container on your machine. (Use with caution!)
9. docker rmi <image_id>
If a container is a "running car," the Image is the "blueprints." Over time, you’ll end up with dozens of old versions of images taking up gigabytes of space. rmi (Remove Image) deletes those blueprints.
10. docker system prune
The Nuclear Option. ☢️
This is the single most useful command for when your Mac/PC screams "Disk Full." It deletes:
- All stopped containers.
- All networks not used by at least one container.
- All "dangling" images (the ones that didn't get a proper name).
- All build cache.
- Warning: It’s a fresh start. You’ll have to re-download/re-build things next time you need them, but it usually saves me about 20GB of space every month.
Wrapping Up
Docker might seem like magic at first, but it’s really just about packaging your environment so you can stop worrying about "it works on my machine" and start focusing on writing code.
Now that you've mastered the single-container life, things get even more interesting when you have 5 or 10 containers talking to each other.
After firm grisp on manging single container, we can dive into the world of docker compose for using multiple container & networking between them so how can they talk to each other.
Please leave a comment below, if you've liked this article or have any kind of queries or suggestions for me.
Top comments (0)