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…
A decade of Docker containers
231–240 of 275 posts
Re: A decade of Docker containers
#232Earlier 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?
Re: A decade of Docker containers
#233Back 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
#234Re: A decade of Docker containers
#235Didn't Vagrant/Vagrantfiles precede Docker? Unclear why that would be the key to its success if so.
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
#236Earlier 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…
Re: A decade of Docker containers
#237Earlier 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).
Re: A decade of Docker containers
#238Earlier 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.
Re: A decade of Docker containers
#239> 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 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
#240Earlier 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.