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

121–130 of 275 posts

Re: A decade of Docker containers

#121

Post by brightball »

kccqzy wrote: post #120
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…

> But the Dockerfile has continued because of its flexibility. The flip side is that the world still hasn’t settled on a language-neutral build tool that works for all languages. Therefore we resort to running arbitrary commands to invoke language-specific package managers. In an alternate timeline where everyone uses Nix or Bazel or some such, docker build would be laughed out of the window.

Reminds me of the “Electric cars in reverse” video where the guy envisions a world where all vehicles are electric and tries to make the argument for gas engines.

Re: A decade of Docker containers

#122

Post by jcgl »

jfjasdfuw wrote: post #67
blackcatsec wrote: post #48

Earlier quoted context omitted.

I question that as well, it's also why Go is extremely popular. Could it just be a pendulum swing back towards static linking? Wonder when some enterprising OSS dev will rebrand dynamic linking in the future...

CGO_ENABLED=0 is sigma tier. I don't care about glibc or compatibility with /etc/nsswitch.conf. look at the hack rust does because it uses libc: > pub unsafe fn set_var , V: AsRef >(key: K, value: V)

> 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).

Re: A decade of Docker containers

#123

Post by gnull »

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?

Packaging for nix is exceptionally easy once you learn it. And once something is packaged, it's solved for all, it's not going to randomly break.

If you care about getting it to work with minimal effort right now more thar about it being sustainable later, then sure.

Re: A decade of Docker containers

#125

Post by netrem »

With ML and AI now being pushed into everything, images have ballooned in size. Just having torch as a dependency is some multiple gigabytes. I miss the times of aiming for 30MB images.

Have others found this to be the case? Perhaps we're doing something wrong.

Re: A decade of Docker containers

#126

Post by anal_reactor »

brightball wrote: post #121
kccqzy wrote: post #120

Earlier quoted context omitted.

> But the Dockerfile has continued because of its flexibility. The flip side is that the world still hasn’t settled on a language-neutral build tool that works for all languages. Therefore we resort to running arbitrary commands to invoke language-specific package managers. In an alternate timeline where everyone uses Nix or Bazel or some such, docker build would be laughed out of the window.

Reminds me of the “Electric cars in reverse” video where the guy envisions a world where all vehicles are electric and tries to make the argument for gas engines.

Link?

Re: A decade of Docker containers

#127

Post by hwhshs »

talkvoix wrote: post #5

A full decade since we took the 'it works on my machine' excuse and turned it into the industry standard architecture ('then we'll just ship your machine to production').

In 2002 I used to think why cant they package a website. These .doc installation instructions are insane! What a waste of someones time.

I sort of had the problem in mind. Docker is the answer. Not clever enough to have inventer it.

If I did I would probably have invented octopus deploy as I was a Microsoft/.NET guy.

Re: A decade of Docker containers

#128

Post by muvlon »

kccqzy wrote: post #120
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…

> But the Dockerfile has continued because of its flexibility. The flip side is that the world still hasn’t settled on a language-neutral build tool that works for all languages. Therefore we resort to running arbitrary commands to invoke language-specific package managers. In an alternate timeline where everyone uses Nix or Bazel or some such, docker build would be laughed out of the window.

As a Nix evangelist, I have to say: Nix is really not capable of replacing languag-specific package managers.

> running arbitrary commands to invoke language-specific package managers.

This is exactly what we do in Nix. You see this everywhere in nixpkgs.

What sets apart Nix from docker is not that it works well at a finer granularity, i.e. source-file-level, but that it has real hermeticity and thus reliable caching. That is, we also run arbitrary commands, but they don't get to talk to the internet and thus don't get to e.g. `apt update`.

In a Dockerfile, you can `apt update` all you want, and this makes the build layer cache a very leaky abstraction. This is merely an annoyance when working on an individual container build but would be a complete dealbreaker at linux-distro-scale, which is what Nix operates at.

Re: A decade of Docker containers

#130

Post by Gigachad »

lioeters wrote: post #95
syncsynchalt wrote: post #83

Earlier quoted context omitted.

I see this take a lot but I'd argue what Docker did was to entice everyone to capture their build into a repeatable process (via a Dockerfile). "Ship your machine to production" isn't so bad when you have a ten-line script to recreate the machine at the push of a button.

Exactly my feeling. Docker is "works on this machine" with an executable recipe to build the machine and the application. Newer better solutions like OCI-compliant tools will gradually replace Docker, but the paradigm shift has provided a lot of lasting value.

Yeah docker codifies what the process to convert a base linux distro in to a working platform for the app actually is. Every company I've worked at that didn't use docker just has this tribal knowledge or an outdated wiki page on the steps you need to take to get something to work. Vs a dockerfile that exactly documents the process.
Post reply on HN