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

211–220 of 275 posts

Re: A decade of Docker containers

#211

Post by Ameo »

alex_dev42 wrote: post #190
bmitch3020 wrote: post #26

I've seen countless attempts to replace "docker build" and Dockerfile. They often want to give tighter control to the build, sometimes tightly binding to a package manager. But the Dockerfile has continued because of its flexibility. Starting from a known filesystem/distribution, copying some files in, and then running arbitrary commands within that filesystem mirrored so nicely what operations has been doing for a l…

[dead]

^ this account has posted nothing but AI generated spam since it was created 6 hours ago

Re: A decade of Docker containers

#212

Post by tripledry »

eudamoniac wrote: post #173

I've been a professional in the industry for over a decade and I've still not found any meaningful benefit for learning or using containerization in the real world. I just install my dependencies with good old fashioned version managers (asdf) and I develop the project. I ignore all docker documentation, and everything works fine. When I try to use containers to develop, it's seemingly two dozen gotchas that sum up t…

What's a good alternative if I want to self host and convenience?

I have some hobby sites I host on a VM and currently I use docker-compose mainly because it's so "easy" to just ssh into the machine and run something like "git pull && docker-compose up" and I can have whatever services + reverse proxy running.

If I were to sum up the requirements it would be to run one command, either it succeeds or fails in it's entirety, minimal to no risk of messing up the env during deployment.

Nix seems interesting but I don't know how it compares (yet to take a good look at it).

Re: A decade of Docker containers

#213

Post by jcgl »

cyberax wrote: post #135
jcgl wrote: post #122

Earlier quoted context omitted.

> I don't care about glibc or compatibility with /etc/nsswitch.conf. So what do you do when you need to resolve system users? I sure hope you don't parse /etc/passwd, since plenty of users (me included) use other user databases (e.g. sssd or systemd-userdbd).

Most software doesn't need to resolve users. You also can always shell out to `id` if you need an occasional bit of metadata.

That's a fair point, and shelling out to id is probably a good solution.

I guess what bothers me is the software authors who don't think this through, leaving applications non-functional in these situations.

At least with Go, if you do CGO_ENABLED=0, and you use the stdlib functions to resolve user information, you end up with parsed /etc/passwd instead of shelling out to id. The Go stdlib should maybe shell out to id instead, but it doesn't. And it's understandable that software developers use the stdlib functions without thinking all too much about it. But in the end, simply advocating for CGO_ENABLED=0 results in software that is broken around the edges.

Re: A decade of Docker containers

#214

Post by Sophira »

forrestthewoods wrote: post #170
matrss wrote: post #160

Earlier quoted context omitted.

> But they’re roughly the same paradigm as docker, right? Absolutely not. Nix and Guix are package managers that (very simplified) model the build process of software as pure functions mapping dependencies and source code as inputs to a resulting build as their output. Docker is something entirely different. > they’re both still throwing in the towel on deploying directly on the underlying OS’s userland The existence…

> This nuance is something that only the nix model started to capture at all. Unpopular opinion, loosely held: the whole attempt to share any dependencies at all is the source of evil. If you imagine the absolute worst case scenario that every program shipped all of its dependencies and nothing was shared then the end result would be… a few gigabytes of duplicated data? Which could plausible be deduped at the filesys…

> If you imagine the absolute worst case scenario that every program shipped all of its dependencies and nothing was shared then the end result would be… a few gigabytes of duplicated data?

Honestly, I've seen projects that do this. In fact, a lot of projects that do this, at the compilation level.

It feels like a lot of the projects that I would want to use from git pull in their own dependencies via submodules when I compile them, even when I already have the development libraries needed to compile it. It's honestly kind of frustrating.

I mean, I get it - it makes it easier to compile for people who don't actually do things like that regularly. And yeah, I can see why that's a good thing. But at the very least, please give me an option to opt out and to use my own installed libraries.

Re: A decade of Docker containers

#215

Post by matrss »

forrestthewoods wrote: post #170
matrss wrote: post #160

Earlier quoted context omitted.

> But they’re roughly the same paradigm as docker, right? Absolutely not. Nix and Guix are package managers that (very simplified) model the build process of software as pure functions mapping dependencies and source code as inputs to a resulting build as their output. Docker is something entirely different. > they’re both still throwing in the towel on deploying directly on the underlying OS’s userland The existence…

> This nuance is something that only the nix model started to capture at all. Unpopular opinion, loosely held: the whole attempt to share any dependencies at all is the source of evil. If you imagine the absolute worst case scenario that every program shipped all of its dependencies and nothing was shared then the end result would be… a few gigabytes of duplicated data? Which could plausible be deduped at the filesys…

I think the storage optimization aspect is secondary, it is more about keeping control over your distribution. You need processes to replace all occurrences of xz with an uncompromised version when necessary. When all packages in the distribution link against one and the same that's easy.

Nix and guix sort of move this into the source layer. Within their respective distributions you would update the package definition of xz and all packages depending on it would be rebuild to use the new version.

Using shared dependencies is a mostly irrelevant detail that falls out of this in the end. Nix can dedupe at the filesystem layer too, e.g. to reduce duplication between different versions of the same packages.

You can of course ship all dependencies for all packages separately, but you have to have a solution for security updates.

Re: A decade of Docker containers

#216

Post by Sophira »

skydhash wrote: post #51
vanviegen wrote: post #31

Earlier quoted context omitted.

It used to be, but only in cases where your distro doesn't just package whatever software you require. Nowadays I prefer Flatpak or AppImage over crappy custom Windows installers for those cases. They allow for sandboxing and reliable updating/deinstallation.

These days, I equate anything that ships via docker/flatpak first as built by someone that only care about their own computer, especially if the project is opensource. As soon as a library or a tool update, they usually rush to add a hard condition on it for no reason other than to be on the "bleeding edge".

I'm with you on this, but I do want to point out that a big reason that people will update bundled libraries like that is because they don't want to put the effort in to see whether their bundled library versions actually have any critical vulnerabilities that affect the project. It's easier to update everything and be sure that there are no critical vulnerabilities.

In other words, the Microsoft Windows update process as applied to software development.

Re: A decade of Docker containers

#217

Post by curt15 »

forrestthewoods wrote: post #133
ahnick wrote: post #116

Earlier quoted context omitted.

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…

The first half of my career was spent shipping video games. There is no such thing as shipping a game in Docker. Not even on Linux. You depend on minimum version of glibc and then ship your damn dependencies. The more recent half of my career has been more focused on ML and now robotics. Python ML is absolute clusterfuck. It is close to getting resolved with UV and Pixi. The trick there is to include your damn depend…

> The trick there is to include your damn dependencies… via symlink to a shared cache.

Isn't composefs[1] aiming to do basically just that?

[1] https://github.com/composefs/composefs

Re: A decade of Docker containers

#218

Post by brightbeige »

fittom wrote: post #139
anal_reactor wrote: post #126

Earlier quoted context omitted.

Link?

try searching for 'Rory Sutherland: What If Petrol Cars Were Invented In 2025'

Actual article was in the evening standard, but like all things Rory Sutherland, it’s worth to watch him tell the story: https://youtu.be/OTOKws45kCo?si=jbTdx3YCGkZv3Akb

For those who want more of him, check out his classic TED talk from decades ago: “Lessons from an ad man”

https://www.ted.com/talks/rory_sutherland_life_lessons_from_...

Re: A decade of Docker containers

#219

Post by codethief »

bmitch3020 wrote: post #137
__MatrixMan__ wrote: post #63

Earlier quoted context omitted.

There are some hurdles preventing that flow from achieving reproducible builds. As the bad guys get more sophisticated, it's going to become more and more important that one party can say "we trust this build hash" and a separate party to say "us too". That's not going to work if both parties get different hashes when they build the image, which won't happen as long as file modification timestamps (and other such haz…

Recent versions of buildkit have added support for SOURCE_DATE_EPOC. I've been making the images reproducible before that with my own tooling, regctl image mod [1] to backdate the timestamps. It's not just the timestamps you need to worry about. Tar needs to be consistent with the uid vs username, gzip compression depends on implementations and settings, and the json encoding can vary by implementation. And all this…

> I've been making the images reproducible before that with my own tooling

I've been doing the same, using https://github.com/reproducible-containers/repro-sources-lis... . It allows you to precisely pin the state of the distro package sources in your Docker image, using snapshot.ubuntu.com & friends, so that you can fearlessly do `apt-get update && apt-get install XYZ`.

Re: A decade of Docker containers

#220

Post by bongripper »

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!

[dead]
Post reply on HN