Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A decade of Docker containers

cacm.acm.org

Post reply on HN
Print view View original

191–200 of 275 posts

Re: A decade of Docker containers

#191

Post by BirAdam »

ahnick wrote: post #116
forrestthewoods wrote: post #97

I am so thoroughly convinced that Docker is a hacky-but-functional solution to an utterly failed userspace design. Linux user space decided to try and share dependencies. Docker obliterates this design goal by shipping dependencies, but stuffing them into the filesystem as-if they were shared. If you’re going to do this then a far far far simpler solution is to just link statically or ship dependencies adjacent to th…

Okay, so what's the best solution? What's even just a better solution than Docker? I mean really truly lay out all the details here or link to a blog post that describes in excruciating detail how they shipped a web application and maintained it for years and was less work than Docker containers. Just saying "a far far simpler solution is to just link statically or ship dependencies adjacent to the binary" is ignorin…

Given that distributions are the distributors of packages and not the upstream developers, I think static linking is fine as is dep-shipping. The now dead Clear Linux was great at handling package distribution.

Personally, I think docker is dumb, so is AppImage, so is FlatPak, so are VMs… honestly, it’s all dumb. We all like these various things because they solve problems, but they don’t actually solve anything. They work around issues instead. We end up with abstractions and orchestrations of docker, handling docker containers running inside of VMs, on top of hardware we cannot know, see, control, or inspect. The containers are now just a way to offer shared hosting at a price premium with complex and expensive software deployment methods. We are charged extortionate prices at every step, and we accept it because it’s convenient, because these methods make certain problems go away, and because if we want money, investors expect to see “industry standards.”

Re: A decade of Docker containers

#192

Post by a_t48 »

netrem wrote: post #175
a_t48 wrote: post #150

Earlier quoted context omitted.

I’ve seen images that accidentally install tensorflow twice, too. It wouldn’t be so bad if large files were shared between layers but they aren’t. It’s bad enough that I’m building an alternative registry and snapshotter with file level dedupe to deal with it.

Sounds like it would be useful. Many common dev workflows started falling apart when it's not just tiny code files they need to deal with. In the python world, uv has helped massively, with pip we were seeing 30+ min build times on fairly simple images with torch

uv is one of my inspirations. Take a familiar interface, do the same thing but better/faster.

Re: A decade of Docker containers

#193

Post by supriyo-biswas »

talkvoix wrote: post #22
avsm wrote: post #19

Earlier quoted context omitted.

(coauthor of the article here) Well, before Docker I used to work on Xen and that possible future of massive block devices assembled using Vagrant and Packer has thankfully been avoided... One thing that's hard to capture in the article -- but that permeated the early Dockercons -- is the (positive) disruption Docker had in how IT shops were run. Before that going to production was a giant effort, and 'shipping your…

Great point about coding agents! Back then, Docker gave us 'it works on my machine, let's ship the machine'. Now, AI agents are giving us 'I have no idea how this works, let's ship the prompt'. The early Docker community spirit really was legendary though—before every hyperscaler wrapped it in 7 layers of proprietary managed services. Thanks for the memories and the write-up!

It seems that your entire profile is LLM generated comments, would appreciate it if you'd stop. Thanks.

Re: A decade of Docker containers

#194

Post by ghthor »

hamandcheese wrote: post #167
stabbles wrote: post #119

Earlier quoted context omitted.

Does Nix do one layer per dependency? Does it run into >=128 layers issues? In Spack [1] we do one layer per package; it's appealing, but I never checked if besides the layer limit it's actually bad for performance when doing filesystem operations. [1] https://spack.readthedocs.io/en/latest/containers.html

This post has a great overview: https://grahamc.com/blog/nix-and-layered-docker-images/ tl;dr it will put one package per layer as much as possible, and compress everything else into the final layer. It uses the dependency graph to implement a reasonable heuristic for what is fine grained and what get combined.

That layering algorithm is also configurable, though I couldn’t really understand how to configure it and just wrote my own post processing to optimize layering for my internal use case. I believe I can open source this w/o much work.

The layer layout is just a json file so it can be post processed w/o issue before passing to the nix docker builders

Re: A decade of Docker containers

#195

Post by ghthor »

Spivak wrote: post #78
whateveracct wrote: post #65

Earlier quoted context omitted.

Nix is exceptionally good at making docker containers.

Yes but then you're committed to using Nix which doesn't work so well the moment you need some software not packaged by Nix. Want to throw a requirements.txt in there? No no, why would you even ask that? Meanwhile docker says yeah sure just run pip install, why should I care?

Packing software with nix is easier than any other system TBH and just seems to be just getting easier.

Re: A decade of Docker containers

#196

Post by ghthor »

jjmarr wrote: post #43
zbentley wrote: post #29

Earlier quoted context omitted.

But they’re roughly the same paradigm as docker, right? My understanding of the Nix approach is that it’s still reproducing most of a user land/filesystem in a captive/separate/sandbox environment. Like, docker is using namespaces for more stuff, Nix has a heavier emphasis on reproducibility/determinism, but … they’re both still throwing in the towel on deploying directly on the underlying OS’s userland (unless you g…

I daily drive NixOS. I don't have a global "userland". Packages are shipped from upstream and pull in the dependencies they need to function. That means unlike Gentoo, I've never dealt with a "slot conflict" where two packages want conflicting dependencies. And unlike Ubuntu, I have new versions of everything. Pick 2: share dependencies, be on the bleeding edge, or waste your time resolving conflicts.

Yeah nix is great for this. Also I can update infrequently and still package anything I want bleeding edge without any big issues other then maybe some build from sourcing.

Re: A decade of Docker containers

#197

Post by with »

docker is bloated. i'm almost certain half of every image is dead weight. unused apt packages, full distros for a single binary, shell configs nobody touches. but the incentive is to make things work, not make them small. so bloat wins.

still, i use it every day and i don't see what replaces it. every "docker killer" solves one problem while ignoring the 50 things docker does well enough.

Re: A decade of Docker containers

#198

Post by stephbook »

with wrote: post #197

docker is bloated. i'm almost certain half of every image is dead weight. unused apt packages, full distros for a single binary, shell configs nobody touches. but the incentive is to make things work, not make them small. so bloat wins. still, i use it every day and i don't see what replaces it. every "docker killer" solves one problem while ignoring the 50 things docker does well enough.

Docker released "Docker Hardened Images" last year and made them free. They contain less bloat.

Buying more RAM for your server or only touching a select few images that are run most often is also a way to make things work. It might not be the most elegant software engineering approach, but it just works.

Re: A decade of Docker containers

#199

Post by Zizizizz »

with wrote: post #197

docker is bloated. i'm almost certain half of every image is dead weight. unused apt packages, full distros for a single binary, shell configs nobody touches. but the incentive is to make things work, not make them small. so bloat wins. still, i use it every day and i don't see what replaces it. every "docker killer" solves one problem while ignoring the 50 things docker does well enough.

https://github.com/GoogleContainerTools/distroless

These are pretty handy to use

Post reply on HN