Okay, let's break down this Docker evolution. It's wild how things change. Remember when Docker felt like... wrestling a grumpy octopus? 🐙 So many commands, so many concepts. Build, run, push, pull, volumes, networks... my head was spinning. I used it, sure, because everyone said I should, but it always felt a bit clunky, a bit... friction-filled. My terminal history was just a mess of docker ps -a and desperately trying to remember that one command from last week. should docker ps -a one Then, slowly, things started clicking. Not one big eureka moment, but a series of small "aha!" discoveries. Little tricks, optimizations, workflow adjustments. Hacks, I guess? And honestly, they've seeped into my daily routine so much that I barely think about them anymore. They're just... how I do things. how I do things Here are the game-changers that stuck: 1. Terminal Aliases: The Sanity Savers ⌨️💨 Okay, first big win? Aliases. Seriously. 🤦‍♂️ Why did I spend months typing docker-compose up -d --build or docker ps over and over again? Setting up simple aliases in my .bashrc or .zshrc was a revelation. Aliases. docker-compose up -d --build docker ps .bashrc .zshrc # My sanity savers
alias dcu='docker-compose up -d'
alias dcd='docker-compose down'
alias dcb='docker-compose build'
alias dcr='docker-compose run --rm' # For running one-off commands
alias dps='docker ps'
alias dpa='docker ps -a'
alias di='docker images'
alias dip='docker image prune -f'  # Prune dangling images
alias dvp='docker volume prune -f' # Prune unused volumes
alias dsp='docker system prune -af' # The big cleanup! 💥 # My sanity savers
alias dcu='docker-compose up -d'
alias dcd='docker-compose down'
alias dcb='docker-compose build'
alias dcr='docker-compose run --rm' # For running one-off commands
alias dps='docker ps'
alias dpa='docker ps -a'
alias di='docker images'
alias dip='docker image prune -f'  # Prune dangling images
alias dvp='docker volume prune -f' # Prune unused volumes
alias dsp='docker system prune -af' # The big cleanup! 💥 Just typing dcu instead of the whole shebang? Oh, the milliseconds saved! It sounds trivial, but multiply that by dozens of times a day... it adds up. My fingers thank me. Less typing, fewer typos, more flow. Pure magic. ✨ dcu Get the ultimate cheatsheet of docker from here : Docker cheatsheet Docker cheatsheet 2. The Mighty .dockerignore File: Slimming Down Builds 🚫📦 .dockerignore Then came the .dockerignore file. Another "duh" moment. I knew about .gitignore, of course, but I didn't initially grasp how crucial .dockerignore is for build performance. My early Docker builds were so slow. Why? Because the build context was sending everything over to the Docker daemon. node_modules, logs, temporary files, local build artifacts... everything! 😱 .dockerignore .gitignore .dockerignore so slow everything node_modules Creating a proper .dockerignore file, listing out all the junk I didn't need inside the image build process? Suddenly, builds were faster. Images were smaller (sometimes dramatically so). It felt like putting blinders on Docker, telling it: "Just focus on this, ignore the rest." Less clutter, faster feedback loop. Chef's kiss! 👌 .dockerignore inside this 3. Multi-Stage Builds: Lean, Mean Production Machines 🌱➡️🌳 Multi-stage builds... okay, this one felt a bit more advanced initially. 🤯 The concept is brilliant, though. Multi-stage builds Stage 1: Use a base image with all the build tools, compilers, SDKs, and dependencies needed to create the application artifact (like a compiled binary or bundled JavaScript).
Stage 2: Start a new, clean, minimal base image (like alpine or distroless).
Copy: Only copy the final artifact from the first stage into this clean second stage. Stage 1: Use a base image with all the build tools, compilers, SDKs, and dependencies needed to create the application artifact (like a compiled binary or bundled JavaScript). Stage 1: create Stage 2: Start a new, clean, minimal base image (like alpine or distroless). Stage 2: new alpine distroless Copy: Only copy the final artifact from the first stage into this clean second stage. Copy: Only The result? Tiny production images! Instead of shipping images bloated with build tools and dev dependencies (which are also a security risk!), I ship lean images containing only what's needed to run the app. It took a bit to wrap my head around the syntax, but wow, the difference in image size and security posture is huge. Feels much more professional, more... tidy. 🛡️ only 4. Docker Compose Overrides: Taming Environments ⚙️🌿 Let's talk Docker Compose override files. Managing different environments used to be a pain. Dev needs volumes mounted for live code reloading, debug ports open. Prod needs different environment variables, maybe stricter resource limits, perhaps a different entrypoint. Trying to manage this with one docker-compose.yml was messy, involving commented-out sections or complex if conditions based on environment variables. Docker Compose override docker-compose.yml if Discovering docker-compose.override.yml was pure bliss. 😌 You have your base docker-compose.yml with the common configuration. Then, you create docker-compose.override.yml (which Git usually ignores via .gitignore) for your local development tweaks – mounting code directories, exposing different ports, adding debug tools. Docker Compose automatically merges them (override takes precedence). You can even have specific files like docker-compose.prod.yml and use the -f flag: docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d. Clean separation of concerns. No more accidental commits of dev settings! Hallelujah! 🙌 docker-compose.override.yml docker-compose.yml docker-compose.override.yml .gitignore override docker-compose.prod.yml -f docker-compose -f docker-compose.yml -f docker-compose.prod.yml up -d 5. Regular Cleanup: Keeping the System Tidy 🧹✨ And finally, the habit of regular cleanup. Docker can accumulate so much cruft over time if you're not careful. Dangling images (untagged layers from previous builds), unused volumes, stopped containers, old build caches... My disk space used to mysteriously vanish. 👻 regular cleanup so much Getting into the rhythm of periodically running docker system prune -af (the aggressive approach) or the more targeted docker image prune, docker volume prune, docker network prune, and docker builder prune feels like digital decluttering. It keeps things running smoothly, prevents weird caching issues ("why isn't my change showing up?!"), and frees up precious gigabytes. A clean workspace, a clean mind, right? 🧘‍♂️ Running dsp (my alias for docker system prune -af) is now a satisfying, almost therapeutic, routine. docker system prune -af docker image prune docker volume prune docker network prune docker builder prune dsp docker system prune -af So yeah, these aren't just 'hacks' anymore. They're ingrained. They're muscle memory. Aliases fly from my fingers without thought. .dockerignore is one of the first files I create. Multi-stage builds are the default for anything potentially going live. Compose overrides handle environment differences smoothly. Pruning happens regularly. .dockerignore Docker went from being that grumpy octopus 🐙 to a powerful, streamlined assistant. It gets out of my way now. Builds are faster, deployments are smoother, my disk space is happier, and honestly, I'm happier because there's less friction. It's not just about Docker itself; it's about how mastering these little details smoothed out my entire development and deployment workflow. It has definitely become part of my life, or at least, my digital life. And honestly? It's pretty great. 👍 I'm

It's 2025—Ditch the Bloat and Install These 20 Essential VS Code Extensions

I Tried Every Open Source Database and Found Only One That is Actually Useful

Read My Stories

View my website

Too Long; Didn't Read

Make resilience your competitive advantage

Here are Some Docker Hacks That Changed my Life

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

25+ Beginner Javascript Projects With Source Code on Github

105 Stories To Learn About K8s

10 Best Practices for Using Kubernetes Network Policies

1 Stories To Learn About Weekly Sponsor

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

25+ Beginner Javascript Projects With Source Code on Github

105 Stories To Learn About K8s

10 Best Practices for Using Kubernetes Network Policies

1 Stories To Learn About Weekly Sponsor

3 Free Ways to Learn Kubernetes and Red Hat OpenShift

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps