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

131–140 of 275 posts

Re: A decade of Docker containers

#131

Post by cpuguy83 »

zbentley wrote: post #33
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…

> the Dockerfile has continued because of its flexibility I wish we had standardized on something other than shell commands, though. Puppet or terraform or something more declarative would have been such a better alternative to “everyone cargo cults ‘RUN apt-get upgrade’ onto the top of their dockerfiles”. Like, the layer/stage/caching behavior is fine. I just wish the actual execution parts had been standardized usi…

Give https://github.com/project-dalec/dalec a look. It is more declarative. Has explicit abstractions for packages, caching, language level integrations, hermetic builds, source packages, system packages, and minimal containers.

Its a Buildkit frontend, so you still use "docker build".

Re: A decade of Docker containers

#132

Post by Joe_Cool »

netrem wrote: 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 have an immutable Alpine Linux running from an ISO that includes a few docker containers (mostly ruby and php). All in about 750MB.

Re: A decade of Docker containers

#133

Post by forrestthewoods »

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…

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 dependencies… via symlink to a shared cache.

Any program or pipeline that relies on whatever arbitrary ass version of Python is installed on the system can die in a fire.

That’s mostly about deploying. We can also talk about build systems.

The one true build system path is a monorepo that contains your damn dependencies. Anything else is wrong and evil.

I’m also spicy and think that if your build system can’t crosscompile then it sucks. It’s trivial to crosscompile for Windows from Linux because Windows doesn’t suck (in this regard). It almost impossible to crosscompile to Linux from Windows because Linux userspace is a bad, broken, failed design. However Andrew Kelley is a patron saint and Zig makes it feasible.

Use a monorepo, pretend the system environment doesn’t exist, link statically/ship adjacent so/dll.

Docker clearly addresses a real problem (that Linux userspace has failed). But Docker is a bad hack. The concept of trying to share libraries at the system level has objectively failed. The correct thing to do is to not do that, and don’t fake a system to do it.

Windows may suck for a lot of reasons. But boy howdy is it a whole lot more reliable than Linux at running computer programs.

Re: A decade of Docker containers

#134

Post by Gigachad »

Hackbraten wrote: post #54
mihaelm wrote: post #23

Earlier quoted context omitted.

Maybe if you only look at it through the lens of building an app/service, but containers offer so much more than that. By standardizing their delivery through registries and management through runtimes, a lot of operational headaches just go away when using a container orchestrator. Not to mention better utilization of hardware since containers are more lightweight than VMs.

> Not to mention better utilization of hardware When compared to a VM, yes. But shipping a separate userspace for each small app is still bloat. You can reuse software packages and runtime environments across apps. From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular.

"bloat" has always been the last resort criticism from someone who has nothing valid. Containers are incredibly light, start very rapidly, and have such low overhead in general that the entire industry has been using them.

Docker containers also do reuse shared components, layers that are shared between containers are not redownloaded. The stuff that's unique at the bottom is basically just going to be the app you want to run.

Re: A decade of Docker containers

#135

Post by cyberax »

jcgl wrote: post #122
jfjasdfuw wrote: post #67

Earlier quoted context omitted.

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

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

Re: A decade of Docker containers

#136

Post by [deleted] »

pixelmonkey wrote: post #109

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…

[deleted]

Re: A decade of Docker containers

#137

Post by bmitch3020 »

__MatrixMan__ wrote: post #63
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…

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 assumes the commands being run are reproducible themselves. One issue I encountered there was how alpine tracks their package install state from apk, which is a tar file that includes timestamps. There are also timestamps in logs. Not to mention installing packages needs to pin those package versions.

All of this is hard, and the Dockerfile didn't make it easy, but it is possible. With the right tools installed, reproducing my own images has a documented process [2].

[1]: https://regclient.org/cli/regctl/image/mod/

[2]: https://regclient.org/install/#reproducible-builds

Re: A decade of Docker containers

#138

Post by FlyingSnake »

pixelmonkey wrote: post #109

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…

You’re right, it was 2014. I was there on HN when docker was announced by shykes. It was a godsend because I was getting bummed by the alternatives like LXC, juju charms or vagrant.

Here’s the announcement from 2013:

https://news.ycombinator.com/item?id=5408002

Re: A decade of Docker containers

#139

Post by fittom »

anal_reactor wrote: post #126
brightball wrote: post #121

Earlier quoted context omitted.

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?

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

Re: A decade of Docker containers

#140

Post by mberning »

I remember being pretty skeptical of “dockerizing” applications when it first becamee popular. But I’ve come around to it, if for no other reason than it provided an easily understandable concept which anyone could understand and more importantly use. The onramp to using docker is very gentle.
Post reply on HN