Live data from Hacker News

A decade of Docker containers

cacm.acm.org

141–150 of 275 posts

Re: A decade of Docker containers

#141
post #105

I've not done serious networking stuff for over two decades, and never in as complex an environment as that in the article, so the networking part of the article went pretty much over my head. What I want to do when running a Docker container on Mac is to be able to have the container have an IP address separate from the Mac's IP address that applications on the Mac see. No port mapping: if the container has a web se…

I don't have a Mac environment, but I have researched a bit for devex purposes, and I would go with the Colima project as a open source solution for containers on mac. Have you tried it?

Re: A decade of Docker containers

#142

The math of “a decade” seemed wrong to me, since I remembered Docker debuting in 2013 at PyCon US Santa Clara. Then I found an HN comment I wrote a few years ago that confirmed this: “[...] I remember that day pretty clearly because in the same lightning talk session, Solomon Hykes introduced the Python community to docker, while still working on dotCloud. This is what I think might have been the earliest public and…

From another comment below, it's just a nice short title to convey that we're going back in time and not one to set your watch by.

    We first submitted the article to the CACM a while ago.
    The review process takes some time and "Twelve years of
    Docker containers" didn't have quite the same vibe.
(The CACM reviewers helped improve our article quite a bit. The time spent there was worth it!)

Re: A decade of Docker containers

#143
> If you are a developer, our goal is to make Docker an invisible companion

I want it not to just be invisible but to be missing. If you have kubernetes, including locally with k3s or similar, it won't be used to run containers anyway. However it still often is used to build OCI images. Podman can fill that gap. It has a Containerfile format that is the same syntax but simpler than the Docker builds, which now provides build orchestration features similar to earthly.dev which I think are better kept separate.

Re: A decade of Docker containers

#145
post #105

I've not done serious networking stuff for over two decades, and never in as complex an environment as that in the article, so the networking part of the article went pretty much over my head. What I want to do when running a Docker container on Mac is to be able to have the container have an IP address separate from the Mac's IP address that applications on the Mac see. No port mapping: if the container has a web se…

I don't have a Mac environment, but I have researched a bit for devex purposes, and I would go with the Colima project as a open source solution for containers on mac. Have you tried it?

I'll look into that. Thanks.

Re: A decade of Docker containers

#146
post #128
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.

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…

Fundamentally speaking, the key point is really just hermeticity and reliable caching. Running arbitrary commands is never the problem anyways. What makes gcc a blessed command but the compiler for my own language an "arbitrary" command anyways?

And in languages with insufficient abstraction power like C and Go, you often need to invoke a code generation tool to generate the sources; that's an extremely arbitrary command. These are just non-problems if you have hermetic builds and reliable caching.

Re: A decade of Docker containers

#147
post #142

The math of “a decade” seemed wrong to me, since I remembered Docker debuting in 2013 at PyCon US Santa Clara. Then I found an HN comment I wrote a few years ago that confirmed this: “[...] I remember that day pretty clearly because in the same lightning talk session, Solomon Hykes introduced the Python community to docker, while still working on dotCloud. This is what I think might have been the earliest public and…

From another comment below, it's just a nice short title to convey that we're going back in time and not one to set your watch by. We first submitted the article to the CACM a while ago. The review process takes some time and "Twelve years of Docker containers" didn't have quite the same vibe. (The CACM reviewers helped improve our article quite a bit. The time spent there was worth it!)

Makes sense! Thanks for working on it -- truly a wonderful paper!

Re: A decade of Docker containers

#148
post #128
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.

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…

Well, arbitrary granularity is possible with Nix, but the build systems of today simply do not utilise it. I've for example written an experimental C build system for Nix which handles all compiler orchestration and it works great, you get minimal recompilations and free distributed builds. It would be awesome if something like this was actually available for major languages (Rust?). Let me know if you're working on or have seen anything like this!

Re: A decade of Docker containers

#150
post #125

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.

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.
Post reply on HN