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

61–70 of 275 posts

Re: A decade of Docker containers

#61

Post by avsm »

curt15 wrote: post #44
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').

>'then we'll just ship your machine production' Minus the kernel of course. What is one to do for workloads requiring special kernel features or modules?

Those are global to the machine; generally not an issue and seccomp rules can filter out undesirable syscalls to other containers. But GPU kernel/userspace driver matching has been a huge headache; see https://cacm.acm.org/research/a-decade-of-docker-containers/... in the article for how the CDI is (sort of) helping standardise this.

Re: A decade of Docker containers

#62

Post by avsm »

throwawaypath wrote: post #50
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…

>massive block devices assembled using Vagrant and Packer has thankfully been avoided... Funny comment considering lightweight/micro-VMs built with tools like Packer are what some in the industry are moving towards.

And those lightweight VM base images are possible because Docker applied a downward pressure on OS base image sizes! Alpine Linux doesn't get enough credit for this; in addition to being a great base image, it was also the first distro to prioritise fast and small image creation (Gentoo and Arch were small, but not fast to create).

Re: A decade of Docker containers

#63

Post by __MatrixMan__ »

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 hazards) are part of what gets hashed.

Re: A decade of Docker containers

#64

Post by esseph »

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…

The more you try and abstract from the OS, the more problems you're going to run into.

Re: A decade of Docker containers

#65

Post by whateveracct »

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…

Nix is exceptionally good at making docker containers.

Re: A decade of Docker containers

#66

Post by phplovesong »

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…

You can pretty much replace "docker build" with "go build".

But as long as people want to use scripting languages (like php, python etc) i guess docker is the neccessary evil.

Re: A decade of Docker containers

#67

Post by jfjasdfuw »

blackcatsec wrote: post #48
chuckadams wrote: post #17

Earlier quoted context omitted.

It's the ultimate in static linking. Perhaps a question that should be asked is why that approach is so compelling?

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)

Re: A decade of Docker containers

#69

Post by avsm »

toast0 wrote: post #60
mrbluecoat wrote: post #4

> Docker repurposed SLIRP, a 1990s dial-up tool originally for Palm Pilots, to avoid triggering corporate firewall restrictions by translating container network traffic through host system calls instead of network bridging. Genuinely fascinating and clever solution!

I don't think SLIRP was originally for palm pilots, given it was released two years before. SLIRP was useful when you had a dial up shell, and they wouldn't give you slip or ppp; or it would cost extra. SLIRP is just a userspace program that uses the socket apis, so as long as you could run your own programs and make connections to arbitrary destinations, you could make a dial script to connect your computer up like…

> I don't think SLIRP was originally for palm pilots, given it was released two years before.

That's a mistake indeed; "popularised by" might have been better. Before my beloved Palmpilot arrived one Christmas, I was only using SLIRP to ninja in Netscape and MUD sessions onto a dialup connection which wasn't a very mainstream use.

Re: A decade of Docker containers

#70

Post by speedgoose »

phplovesong wrote: post #66
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…

You can pretty much replace "docker build" with "go build". But as long as people want to use scripting languages (like php, python etc) i guess docker is the neccessary evil.

It doesn't sound like Golang is going to dominate and replace everything else, so Docker is there to stay.
Post reply on HN