As a Docker Captain and Co-Founder of a Docker hosting company, I've seen a lot of people struggle and make mistakes with Docker.
Most developers "learn" Docker by copy-pasting a Dockerfile from Stack Overflow and calling it a day. But if you want to really understand containers, their limits, their quirks, and how to bend them to your will, you need to play. Here are 5 hands-on projects that will help you level up your Docker skills fast.
Are they something you will use day-to-day? No. Are they something that will save your butt in a very weird situation in 5 years time? Maybe, or at least thats what I hope for :D
1. Make the Smallest Docker Image You Can Without Breaking Everything
You already have a project. Maybe it is a Next.js frontend or a Flask API. Here is your challenge: strip the image down as far as it can possibly go. Do not just change the base image. Actually remove files and layers until the container stops working.
Then figure out why it broke. Try to work around it. Try again. Go smaller.
You will learn what your app truly needs, how layering works, and how dependencies silently sneak in.
You should look into tools like docker history or dive to see what is really inside.
2. Try to Dockerize Something That Should Not Be Dockerized
Pick something that feels wrong. Spotify. A graphical IDE. Your full Linux desktop environment. Even Windows.
Try to containerize it anyway. Most of it will fail.
That is the point. When it breaks, ask yourself why. Is it a Docker limitation? A kernel problem? A hardware dependency? An assumption about graphical output?
You do not fully understand Docker until you have tried something ridiculous and watched it collapse.
3. Build a Base Image From Scratch
Most people write Dockerfiles like this:
FROM node
FROM ubuntu
Now do it differently. Use this instead:
FROM scratch
And build your own base image that runs your app.
You will find out how files get into a container. You will learn what a working binary actually needs. You will see why some people use Alpine and others do not. You will discover what glibc is. You will understand how CMD and ENTRYPOINT really behave.
This is not practical for production but incredibly useful for understanding how containers work. (Please for the love of all that is holy, just use a normal image in production.)
4. Parameterize Your Docker Builds
Open source projects often publish many variations of Docker images. One is based on Debian. Another on Alpine. One is optimized for size. Another is made for debugging. Some support multiple CPU architectures.
Try building something similar. Learn how to use build arguments. Learn how to write conditional logic in Dockerfiles. Learn how to generate multiple outputs from a single pipeline.
Most importantly, figure out how to avoid writing the same lame logic over and over again.
5. Play the "What If I Ran Untrusted Code" Game
Imagine you want to run untrusted code inside Docker containers. A user uploads a script and your backend executes it. What would you need to do to make that secure?
Try it. Actually run untrusted code in a container and then start locking things down.
Explore seccomp profiles. Set containers to read-only. Use user namespaces. Drop capabilities. Attempt privilege escalation. Try to escape your own sandbox.
This is the edge where Docker ends and real sandboxing begins.
Bonus Project: Skip the Docker CLI Entirely
Docker is just a frontend. Behind it are other tools like BuildKit, containerd, and image specifications.
Try skipping Docker altogether.
Use buildctl directly. Create an OCI image manually. Push it to a registry without using docker push. Read the OCI image spec and try to replicate what Docker does.
Doing this will break your mental model of Docker and replace it with something much more accurate.
This is the final boss of container learning.
Is this list complete? Definitely not. There's always more to learn, but I hope this motivates you to go deeper :)
Cheers,
Jonas, Co-Founder of Sliplane
Top comments (13)
Awesome !
I ran a entire chome browser in a docker container next to a NextJS application (for web scrapping purposes). And was obliged to shrink down the size from 4GB to 2GB, still looking for shrinking it even further. Overall, it was a very fun experience filled with learning. Here is the app: link
This will be my project(s) for a month, I'll report back what happend in ~30days 👍(if i didnt ping me 😂). Great article!!
hi, how did it go ? :)
Hey, I missed the reply 😂... I did start and quickly ended up with my own projects until I was satisfied with the result. So I ended up only doing 1 & 2. Started setting up docker and then devcontainers stole my attention so I spent some days learning that and creating my own devcontainer "feature" (In VSCode thats an easy way to share a docker setup, in my case I just wanted to mimic a minimal development environment that I could use in different projects).
Then I went back to the post and tried minifying my dev container using dive and docker desktop. I didn't blindly delete stuff which I probably should have done cuz I believed the files to be important. Nonetheless got a try on distroless which is really minimal but didnt care too much since its not that far from alpine 5MB vs 2MB if I remember correctly. But since im adding other stuff like git, bash, node, ... I didnt care for these 3MB. Distroless is more for scalability of production environments where everything counts.
Then I tried setting up arch (btw) on docker on Windows 💀. I needed some server so docker could open windows on windows but the rest was pretty simple since there was an image for that already. However couldnt setup hyprland since it required direct access to the screen/gpu which docker didnt allow. At this point I felt that I've learned enough and it was time to go to the next project.
LFG this made my day! It’s always a good sign if you get sidetracked because you find stuff that you find more interesting:))
👀
Can you suggest or share some resources to learn such things ?
also notify me when u get one
Please don’t wait for some magical resource to get started!
I don't think you need anything else besides Google and a code editor:)
Great list!
Excellent read. Definitely going to my tinker to-do list. Looking forward to what I'm sure will be an adventure when it bubbles to the top. Well written.
awesome recommendations. I will try it out soon