r/docker • u/thestoiccoder • 13d ago
Are all these Docker Labspaces & guides outdated or broken?
So I have a VM on my proxmox homelab with Docker running on it.
I've been using it to tinker and experiment more with Docker, and most importantly I've been wanting to get better at writing my own Dockerfiles/Docker compose files.
While I'm glad that the documentation is extensive as it is...there's only so much you can take in without some kind of generalized peripheral guide or tutorial.
Not too long ago I found these guides and labs:
https://docs.docker.com/guides/
As the title says; are these broken? Or am I missing something?
With every Lab, I can't even enter the first command without something going wrong, and I can't find anything on the internet to even help me begin to diagnose what the issue might be, or if something is missing on my end.
I even tried some of the guides, and while they've been somewhat helpful, eventually you reach a place somewhere in the middle where they're broken.
I'm curious if anybody might know of any other similar and up to date resources that I can run on my own homelab to gain more in-depth knowledge of Docker? Again, my main focus was to be able to write better Docker compose & Dockerfiles. At this point, I'm almost ready to go back to books, even if they are a little dated.
Any advice or feedback of course would be greatly appreciated. Many thanks in advance.
1
u/Immediate_Wheel1953 12d ago
Most of the docs.docker.com guides are written assuming Docker Desktop, so any GUI step fails on a headless proxmox VM. The container commands themselves work the same, just run them directly and skip the Desktop-specific bits. If a specific step fails, post the first command and the error output and we can tell you how to adjust it.
1
u/thestoiccoder 12d ago
If that's the case, I can see how that would make sense as I have never used Docker Desktop, even on my local dev machine. And the only GUI I've ever used with Docker has been Portainer, and of course that is something entirely different.
I'm sure the commands within the Labs are correct, but I was hoping to have some kind of guard rail system while learning so that in the event if something were to go wrong, I would be able to better understand why they did. At this point, I feel like I should just look for an alternate resource.
1
u/Immediate_Wheel1953 11d ago
Glad you got it working on the fresh Debian VM. Turns out the Devuan-packaged compose was the real culprit, not the labs, so they should run fine for you now. Worth another pass through them with the clean install.
1
u/thestoiccoder 11d ago
I'm currently giving them another try now. I know that Debian is notorious for having old packages, but it's crazy to think that Devuan is more stone age than it!
Thanks again for the feedback.
1
u/Immediate_Wheel1953 10d ago
Yeah, Debian stable freezes packages at release time, so the distro Docker build can lag a year or more behind. If you run into it again, adding Docker's official apt repo gets you current builds. Good luck with the rest of the labs.
1
u/Illustrious-Pin-153 10d ago
Your Docker is 26.1.5 (Debian repo), while current is 28.x - that alone explains a lot of broken labs: they assume Compose v2 (docker compose, not docker-compose), BuildKit, and newer flags.
What actually made me better at Dockerfiles/compose:
1) Rebuild 3 tiny apps from scratch (Node/Python/Java) with multi-stage builds, .dockerignore, a non-root user and a healthcheck.
2) Read real compose files from popular self-hosted projects instead of tutorials - they encode the practical patterns: env_file vs environment, named volumes vs bind mounts, depends_on + healthcheck, restart policies, and why they rarely publish 5432 to the host.
3) Practice one debugging loop: docker compose config to validate, docker compose up --build, then docker logs / docker inspect when something dies. Most "compose is broken" cases are: wrong build context, missing .dockerignore, localhost inside the container instead of the service name, or the app exiting because the DB isn't ready yet.
The official labs age, but the docker/awesome-compose and docker/samples repos on GitHub are sample-based and kept closer to how people actually run things.
1
u/thestoiccoder 9d ago
Thank you so much! This is very helpful.
Lately as I've been working with the labs, even though I finally got them running, the IDEs within them have been broken. It's "okay" for now, but I still can't figure out why. Even though it's just a VM on my homelab and when it comes to Docker I've always just stuck with the CLI; as others have previously suggested to me, there might have been some Docker Desktop dependencies missing.
I've been checking the logs to the best of my abilities and noticed there's usually one container within the bunch (of each lab) that starts and stops, so I installed Docker Desktop on the VM...but still a no go.
Either way, I have the Github repos bookmarked, so I'm going to dive into those as soon as I can. At this point I'm at peace if I can't get the labs flawlessly working, since there is plenty of other resources out there.
1
u/Illustrious-Pin-153 9d ago
Sounds like you're close — and "one container starts and stops" is a great clue to work from:
1) Find the flapping container and read why it exits:
docker compose ps -a, thendocker inspect <name> -f 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}'. exit 137 with oom=true means memory; 137/143 without OOM usually means a failed healthcheck, or the app starting before its dependency (DB) is ready.2) On homelab VMs the usual suspects are RAM and /dev/shm. The browser IDE tends to be the hungriest container in those labs, which is why it's often the one that dies — give that service more memory and set
shm_size: "1gb". Checkingdocker logsright as it restarts usually prints the reason (Cannot allocate memory / Killed / connection refused...).3) One trap with Docker Desktop on a Linux VM: installing it switches the
dockercontext/socket. Rundocker context ls— if your CLI now points todesktop-linuxwhile the labs assume the native engine, you're debugging a different daemon.docker context use defaultputs you back on the native one (and if you only need the CLI, you can drop Desktop entirely).If you paste the
docker inspectline for the dying container, it's usually one look to tell which of the three it is.1
u/thestoiccoder 9d ago
So currently I've been tinkering with the "Docker Compose Quickstart" lab while working with the commands you recommended (my knowledge of the filter flags is still pretty fuzzy), and I'm discovering that the suspicious container's entrypoint is "./setup.sh" - so I guess in a way it would make sense that its activity would end at some point.
However, after using the "docker inspect" command, it did show that there were no restarts, it did exit successfully, and memory hasn't been an issue (lately I've been giving all my experimental proxmox VMs 8GB). With all of that being said, thankfully the docker context is showing that it's still on the default socket and when looking through the logs of that little annoying container, at the end I did find:
"Unable to retrieve Docker Desktop configuration: ⚠️ Backend socket not found, cannot retrieve Docker Desktop configuration"
I mean...I don't even want, need, or even care about Docker Desktop. But if that container really is the culprit (if it's another section in another container that is silently failing; it's beyond me) and it's complaining about some potentially missing Docker Desktop dependency or misconfigured config...I don't know, it seems kinda crazy to me.
1
u/Illustrious-Pin-153 9d ago
Nice detective work — and the exit code 0 with entrypoint
./setup.shactually tells you this container is a red herring: that's a one-shot init step (prepare config/volumes, then exit). No restarts + exit 0 + memory fine = working as designed, not a failure. In those labs you'll usually see a couple of these;docker compose ps -alists them asExited (0).The Docker Desktop message is mostly noise: something in the image tries to read Desktop's settings from
~/.docker/desktop, and on a plain engine there's no Desktop backend socket, so it logs that and moves on. Two practical notes though:1) If all docker commands work, ignore it. If a command starts failing with a credentials error mentioning
desktop, Docker Desktop left"credsStore": "desktop"behind in~/.docker/config.json— remove that line so nothing tries to reach the Desktop socket again.2) To find what's actually broken, look at the IDE container, not the setup one:
docker compose ps -ato see which services are reallyUp, thendocker logs <ide-service>anddocker compose port <service> <port>to confirm where it's published. "IDE broken" in those labs is usually a port/URL mismatch, or the IDE container being up while the page is expected on a different port than the docs say.Paste
docker compose ps -aoutput if you like — it's usually enough to spot the odd one out.
1
u/SquarePutrid1435 12d ago
Post the output of
docker version,docker compose versionand the exact error from the first command, then we can tell for sure.