Live data from Hacker News

A decade of Docker containers

cacm.acm.org

231–240 of 275 posts

Re: A decade of Docker containers

#231

Back in the day when it came out, I gotta admit, Docker sort of got my my nerves as yet another thing coming to 'disrupt' how things are done. (Half assed NOSQL 'databases' with poorly thought out storage models, everything having to be a microservice, turning every function call into a fallible RPC call etc...) But I've come to appreciate it more, and i use it regularly now. I appreciate its relative simplicity. But…

Having been on way too many middle-of-the-night Zoom calls watching my company's DevOps and development teams aimlessly troubleshoot issues with containers and similar cloud first technologies, I am convinced that nobody really understands what's happening.

Re: A decade of Docker containers

#232
post #103

Earlier quoted context omitted.

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.

> You can pretty much replace "docker build" with "go build". Interesting. How does go build my python app?

It obviously means you dont use a scripting language, instead use a real langauge with a compiler.

Re: A decade of Docker containers

#233

Back in the day when it came out, I gotta admit, Docker sort of got my my nerves as yet another thing coming to 'disrupt' how things are done. (Half assed NOSQL 'databases' with poorly thought out storage models, everything having to be a microservice, turning every function call into a fallible RPC call etc...) But I've come to appreciate it more, and i use it regularly now. I appreciate its relative simplicity. But…

Having been on way too many middle-of-the-night Zoom calls watching my company's DevOps and development teams aimlessly troubleshoot issues with containers and similar cloud first technologies, I am convinced that nobody really understands what's happening.

I have read the setns() manpage. I'm feeling very special and unique :D :D

Re: A decade of Docker containers

#235

Didn't Vagrant/Vagrantfiles precede Docker? Unclear why that would be the key to its success if so.

Vagrant was a layer over virtualization, with hypervisors like virtualbox, kvm or vmware. The article mention virtualization and virtual machines several times, e.g. "unlike the virtual machine experience (which involved installing an entire operating system)".

For instance, deploying a complex Python application was hell, for lack of proper packaging. Using Vagrant was easy, but the image was huge (full system) and the software slow (full virtualization), among other problems. Containers like LXC and Docker were a bit easier to setup, much smaller, almost as performant as native packaging, and with a larger spectrum of features for sharing things with the host (e.g. overlay mounts).

Re: A decade of Docker containers

#236
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…

What's your take on WASM/WASI?

Re: A decade of Docker containers

#237
post #62

Earlier quoted context omitted.

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

There's also the part where you have a much easier time building alpine packages inside a container rather than a VM. There is no docker run equivalent that lets you quickly run a shell script inside the deployment Linux distribution to build the package.

Re: A decade of Docker containers

#238
post #96

Earlier quoted context omitted.

Just pull a tarball from a signed URL, install deps, and run from systemd. Rolls out in 30 seconds, remarkably stable. Initial bootstrap of deps/paths is maybe 5 minutes.

So is it 5 minutes or 30 seconds then? And yes, you're missing out. Docker images come in layers, which may or may not change depending on your release, and may or may not be shared across services.

Read what I wrote. The answer to your question is there.

Re: A decade of Docker containers

#239
post #60

> 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…

SLIP not PPP. Those are two very different protocols. Otherwise your comment is fairly accurate. There were dial-in terminals, whether more expensive or not, that could be repurposed for generic Internet access.

I don't recall whether you could technically open listening ports, at least for a single connection, using slirp, but many, if not all systems, limited opening ports under 1024 to superusers, which (would have?) made running servers on standard ports more difficult.

In any case, I'm glad that you pointed out ACM's apparent revisionist history. They should know better.

Re: A decade of Docker containers

#240

Earlier quoted context omitted.

I am trying to decipher the meaning of your comment, to no avail.

So you’ve never improvised an air conditioning system from a spare bilge pump, a propane tank and a cast iron radiator? Sir, this is a hacker news.

Facts! That would've been covered on Hackaday not here.
Post reply on HN