←back to thread

I ditched Docker for Podman

(codesmash.dev)
1101 points codesmash | 3 comments | 05 Sep 25 11:56 UTC | HN request time: 0.001s | source
Show context
ttul ◴[05 Sep 25 19:09 UTC] No.45142410[source]▶
Back in 2001/2002, I was charged with building a WiFi hotspot box. I was a fan of OpenBSD and wanted to slim down our deployment, which was running on Python, to avoid having to copy a ton of unnecessary files to the destination systems. I also wanted to avoid dependency-hell. Naturally, I turned to `chroot` and the jails concept.

My deployment code worked by running the software outside of the jail environment and monitoring the running processes using `ptrace` to see what files it was trying to open. The `ptrace` output generated a list of dependencies, which could then be copied to create a deployment package.

This worked brilliantly and kept our deployments small and immutable and somewhat immune to attack -- not that being attacked was a huge concern in 2001 as it is today. When Docker came along, I couldn't help but recall that early work and wonder whether anyone has done a similar thing to monitor file usage within Docker containers and trim them down to size after observing actual use.

replies(5): >>45142674 #>>45142868 #>>45143085 #>>45144228 #>>45149147 #
sroerick ◴[05 Sep 25 19:32 UTC] No.45142674[source]▶
The best CI/CD pipeline I ever used was my first freelance deployment using Django. I didn't have a clue what I was doing and had to phone a friend.

We set up a git post receive hook which built static files and restarted httpd on a git receive. Deployment was just 'git push live master'.

While I've used Docker a lot since then, that remains the single easiest deployment I've ever had.

I genuinely don't understand what docker brings to the table. I mean, I get the value prop. But it's really not that hard to set up http on vanilla Ubuntu (or God forbid, OpenBSD) and not really have issues.

Is the reproducibility of docker really worth the added overhead of managing containers, docker compose, and running daemons on your devbox 24/7?

replies(15): >>45142780 #>>45143044 #>>45143149 #>>45143733 #>>45143788 #>>45144390 #>>45146716 #>>45147245 #>>45147489 #>>45147573 #>>45147740 #>>45148831 #>>45149230 #>>45149460 #>>45165839 #
Shog9 ◴[05 Sep 25 19:42 UTC] No.45142780[source]▶
Reproducibility? No.

Not having to regularly rebuild the whole dev environment because I need to work on one particular Python app once a quarter and its build chain reliably breaks other stuff? Priceless.

replies(3): >>45143131 #>>45144404 #>>45145715 #
janjongboom ◴[05 Sep 25 20:17 UTC] No.45143131[source]▶
This false sense of reproducability is why I funded https://docs.stablebuild.com/ some years ago. It lets you pin stuff in dockerfiles that are normally unpinnable like OS package repos, docker hub tags and random files on the internet. So you can go back to a project a year from now and actually get the same container back again.
replies(1): >>45143337 #
jselysianeagle ◴[05 Sep 25 20:40 UTC] No.45143337[source]▶
Isn't this problem usually solved by building an actual image for your specific application, tagging that and pushing to some docker repo? At least that's how it's been at placec I've worked at that used docker. What am I missing?
replies(3): >>45143852 #>>45144454 #>>45145885 #
lmm ◴[06 Sep 25 01:55 UTC] No.45145885[source]▶
What do you do when you then actually need to make a change to your application (e.g. a 1-liner fix)? Edit the binary image?
replies(3): >>45146857 #>>45147338 #>>45149200 #
1. xylophile ◴[06 Sep 25 05:27 UTC] No.45146857{3}[source]▶
You can always edit the file in the container and re-upload it with a different tag. That's not best practice, but it's not exactly sorcery.
replies(1): >>45148150 #
2. lmm ◴[06 Sep 25 10:40 UTC] No.45148150[source]▶
It's not, but at that point you're giving up on most of the things Docker was supposed to get you. What about when you need to upgrade a library dependency (but not all of them, just that one)?
replies(1): >>45160683 #
3. jselysianeagle ◴[07 Sep 25 18:08 UTC] No.45160683[source]▶
I'm not sure what the complication here is. If application code changes, or some dependency changes, you build a new docker image as needed, possibly with an updated Dockerfile as well if that's required. The Dockerfile is part of the application repo and versioned just like everything else in the repo. CICD helps build and push a new image during PRs, or tag creation, just like you would with any application package / artifact. Frequent building and pushing of docker images can over time start taking up space of course but you can take care of that by maybe cleaning out old images from time to time if you can determine they're no longer needed.