13 ms·

A decade of Docker containers

366 points by zacwest 7mo ago

zacwest 7mo ago
The historic information in here was really interesting, and a great example of an article rapidly expanding in scope and detail. How they combatted corporate IT “security” software by pretending to be a VPN is quite unexpected.
the__alchemist 7mo ago
I'm optimistic we will succeed in efforts to simplify linux application / dependency compatibility instead of relying on abstractions that which work around them.
- Joker_vD 7mo ago
  I am also optimistic we will succeed in efforts to properly annotate the data on the Internet with useful and accurate meta-data and achieve the semantic web vision instead of relying on search engines and LLMs.
- __MatrixMan__ 7mo ago
  Agreed. I've recently switched from docker compose to process compose and it's super nice not to have to map ports or mount volumes. What I actually needed from docker had to do less with containers and more with images, and nix solves that problem better without getting in the way at runtime.
  - onei 7mo ago
    Assuming I've found the right process-compose [1], it struck me as having much overlap with the features of systemd. Or at least, I would tend to reach for systemd if I wanted something to run arbitrary processes. Is there something additional/better that process-compose does for you? [1]: https://github.com/F1bonacc1/process-compose https://github.com/F1bonacc1/process-compose
    - __MatrixMan__ 7mo ago
      That's the one, although I tend to reference it through https://github.com/juspay/services-flake https://github.com/juspay/services-flake because that way I end up using the community-maintained configs for whatever well-known services I've enabled (I'll use postgres as an example below, but there are many: https://community.flake.parts/services-flake/services https://community.flake.parts/services-flake/services) What process-compose gives me is a single parent with all of that project's processes as children, and a nice TUI/CLI for scrolling through them to see who is happy/unhappy and interrogating their logs, and when I shut it down all of that project's dependencies shut down. Pretty much the same flow as docker-compose. It's all self-contained so I can run it on MacOS and it'll behave just the same as on Linux (I don't think systemd does this, could be wrong), and without requiring me to solve the docker/podman/rancher/orbstack problem (these are dependencies that are hard to bundle in nix, so while everything else comes for free, they come at the cost of complicating my readme with a bunch of requests that the user set things up beforehand). As a bonus, since it's a single parent process, if I decide to invoke it through libfaketime, the time inherited by subprocess so it's consistently faked in the database and the services and in observability tools... My feeling for systemd is that it's more for system-level stuff and less for project-level dependencies. Like, if I have separate projects which need different versions of postgres, systemd commands aren't going to give me a natural way to keep track of which project's postgres I'm talking about. process-compose, however, will show me logs for the correct postgres (or whatever service) in these cases: ~/src/projA$ process-compose process logs postgres ~/src/projB$ process-compose process logs postgres This is especially helpful because AI agents tend to be scoped to working directory. So if I have one instance of claude code on each monitor and in each directory, which ever one tries to look at postgres logs will end up looking at the correct postgres's logs without having to even know that there are separate ones running. Basically, I'm alergic to configuring my system at all. All dependencies besides nix, my text editor, and my shell are project level dependencies. This makes it easy to hop between machines and not really care about how they're set up. Even on production systems, I'd rather just clone the repo `nix run` in that dir (it then launches process compose which makes everything just like it was in my dev environment). I am however not in charge of any production systems, so perhaps I'm a bit out of touch there.
- mihaelm 7mo ago
  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.
  - the__alchemist 7mo ago
    Hah indeed that's my perspective. I'm used to being able to compile program, distribute executable, "just works", across win, Linux, MacOs. (With appropriate compile targets set)
  - Hackbraten 7mo ago
    > 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.
    - esseph 7mo ago
      > From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular. Why? It's not virtualization, it's containerization. It's using the host kennel. Containers are fast.
      - Hackbraten 7mo ago
        I was referring to the userspace runtime stack, not the kernel. What I criticize is that multiple containers that share a single host usually overdo it with filesystem isolation. Hundreds of MBs of libraries and tools needlessly duplicated, even though they could just as well have used distro packages and deployed their apps as system-level packages and systemd unit files with `DynamicUser=`. You can hardly call this efficient hardware utilization.
- Bratmon 7mo ago
  I'm curious why. To me "We updated our library to change some things in a way that's an improvement on net but only mostly backwards compatible" seems like an extremely common instinct in software development. But in an environment where people are doing that all the time, the only way to reliably deploy software is to completely freeze all your direct and indirect dependencies at an exact version. And Docker is way better at handling that than traditional Linux package managers are. Why do you think other tools will make a comeback?
  - the__alchemist 7mo ago
    You can write any software you want without worrying about depending on a specific set of system dependencies. I like software that "just works", and making something that will give you inscrutable linking or dependency errors if the OS isn't set up just so is a practice I think should go away.
    - Bratmon 7mo ago
      But that's exactly what Docker provides.
- andrewmcwatters 7mo ago
  [dead]
talkvoix 7mo ago
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').
- redhanuman 7mo ago
  the real trick was making "ship your machine" sound like best practice and ten years later we r doing the same thing with ai "it works in my notebook" jst became "containerize the notebook and call it a pipeline" the abstraction always wins because fixing the actual problem is just too hard.
  - goodpoint 7mo ago
    ...while completely forgetting about security
  - zbentley 7mo ago
    > fixing the actual problem is just too hard. I think it’s laziness, not difficulty. That’s not meant to be snide or glib: I think gaining expertise in how to package and deploy non-containerized applications isn’t difficult or unattainable for most engineers; rather, it’s tedious and specialized work to gain that expertise, and Docker allowed much of the field to skip doing it. That’s not good or bad per se, but I do think it’s different from “pre-container deployment was hard”. Pre-container deployment was neglected and not widely recognized as a specialty that needed to be cultivated, so most shops sucked at it. That’s not the same as “hard”.
    - skydhash 7mo ago
      It's not even laziness or expertise. A lot of people are against learning conventions. They want their way, meaning what works on their computer. That's why they like the current scope of package managers, docker, flatpack,... They can do what they want in the sandbox provided however nonsensical and then ship the whole thing. And it will break if you look at it the wrong way.
  - 7mo ago
mrbluecoat 7mo ago
> 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!
- redhanuman 7mo ago
  repurposing a Palm Pilot dial-up tool to sneak container traffic past enterprise firewalls is unhinged and yet it worked the best infrastructure hacks are never clever in the moment they are just desperate that the cleverness only shows up after someone else has to maintain it.
  - Normal_gaussian 7mo ago
    Exactly. "so I hung the radiator out the window" vibes.
    - arcanemachiner 7mo ago
      I am trying to decipher the meaning of your comment, to no avail.
      - diroussel 7mo ago
        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.
        ufocia 7mo ago
        Facts! That would've been covered on Hackaday not here.
  - avsm 7mo ago
    VPNKit (the SLIRP component) has been remarkably bug free over the years, and hasn't been much of a burden overall. There was another component that we didn't have room to cover in the article that has been very stable (for filesystem sharing between the container and the host) that has been endlessly criticised for being slow, but has never corrupted anyone's data! It's interesting that many users preferred potential-dataloss-but-speed using asynchronous IO, but only on desktop environments. I think Docker did the right thing by erring on the side of safety by default.
INTPenis 7mo ago
I thought it was 2014 when it launched? The article says the command line interface hasn't changed since 2013.
- avsm 7mo ago
  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.
bmitch3020 7mo ago
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 long time. And as ugly as that flexibility is, I think it will remain the dominant solution for quite a while longer.
- whateveracct 7mo ago
  Nix is exceptionally good at making docker containers.
  - mikepurvis 7mo ago
    Especially if you use nix2container to take control over the layer construction and caching.
  - Spivak 7mo ago
    Yes but then you're committed to using Nix which doesn't work so well the moment you need some software not packaged by Nix. Want to throw a requirements.txt in there? No no, why would you even ask that? Meanwhile docker says yeah sure just run pip install, why should I care?
    - okso 7mo ago
      LLMs are getting very good at packaging software using Nix.
      - CuriouslyC 7mo ago
        This. I wouldn't have touched Nix when you needed someone who was really good at Nix to keep it working, but agents make it viable to use in a number of place.
      - mort96 7mo ago
avsm 7mo ago
An extremely random fact I noticed when writing the companion article [1] to this (an OCaml experience report): "Docker, Guix and NixOS (stable) all had their first releases during 2013, making that a bumper year for packaging aficionados." Now we get coding agent updates every week, but has there been a similar year since 2013 where multiple great projects all came out at the same time? [1]: https://anil.recoil.org/papers/2025-docker-icfp.pdf https://anil.recoil.org/papers/2025-docker-icfp.pdf
- esseph 7mo ago
  TBH I feel as if only docker belongs in that list. Guix and nix have users, sure, but not remotely like docker.
  - NewJazz 7mo ago
    Yeah they are way better than docker for packaging
    - atomicnumber3 7mo ago
      Why is docker used by far the most, then?
      - ufocia 7mo ago
        Laziness
        pas 7mo ago
        docker got popular because it had better DX (better tooling), it was like a super lightweight VM (and initially people really wanted to put init and SSH into containers) easy but powerful, it's not just packaging, it's also a very basic deployment system too. (docker ps) and said better allowed a relatively foolproof cross-platform develop-deploy loop.
- ezst 7mo ago
deleted 7mo ago
[deleted]
brcmthrowaway 7mo ago
I dont use Dockerfile. Am i slumming it?
- vvpan 7mo ago
  Probably? How do you deploy?
  - rglover 7mo ago
    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.
    - hard_times 7mo ago
      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.
      - rglover 7mo ago
        Read what I wrote. The answer to your question is there.
user3939382 7mo ago
It solves a practical problem that’s obvious. And on one hand the practical where-were-at-now is all that matters, that’s a legitimate perspective. There’s another one, at least IMHO, that this entire stack from the bottom up is designed wrong and every day we as a society continue marching down this path we’re just accumulating more technical debt. Pretty much every time you find the solution to be, “ok so we’ll wrap the whole thing and then…” something is deeply wrong and you’re borrowing from the future a debt that must come due. Energy is not free. We tend to treat compute like it is. Maybe I’m in a big club but I have a vision for a radically different architecture that fixes all of this and I wish that got 1/2 the attention these bandaids did. Plan 9 is an example of the theme if not the particular set of solutions I’m referring to.
arikrahman 7mo ago
I'm hoping the next decade introduces more declarative workflows with Nix and work with docker to that end.
brtkwr 7mo ago
I realise apple containers haven't quite taken off yet as expected but omission from the article stands out. Nice that it mentions alternative approaches like podman and kata though.
- avsm 7mo ago
  > but omission from the article stands out. (article author here) Apple containers are basically the same as how Docker for Mac works; I wrote about it here: https://anil.recoil.org/notes/apple-containerisation https://anil.recoil.org/notes/apple-containerisation Unfortunately Apple managed to omit the feature we all want that only they can implement: namespaces for native macOS! Instead we got yet another embedded-Linux-VM which (imo) didn't really add much to the container ecosystem except a bunch of nice Swift libraries (such as the ext2 parsing library, which is very handy).
politelemon 7mo ago
Somewhere along the line they started prioritising docker desktop over docker. It's a bit jarring to see new features coming to desktop before it comes to Linux, such as the new sandbox features. Is there any insight into this, I would have thought the opposite where developers on the platform that made docker succeed are given first preview of features.
- krapht 7mo ago
  Paying customers use docker desktop.
phplovesong 7mo ago
We have shipped unikernels for the last decade. Zero sec issues so far. I highly recommend looking into the unikernel space for a docker alternative. MirageOS being a good start.
- avsm 7mo ago
  cool! What services have you shipped as unikernels? Docker doesn't have to be an alternative; it can help with the build/run pipeline for them too: https://www.youtube.com/watch?v=CkfXHBb-M4A https://www.youtube.com/watch?v=CkfXHBb-M4A (Dockercon 2015!)
  - phplovesong 7mo ago
    Mostly finance stuff, and all the sensitive stuff that comes with it. But the main benefit is the attack surface is greatly reduced when running a unikernel. Also we use way less resources and get really good perf.
gogasca 7mo ago
Something that I recently have explored is the optimization of Docker layers and startup time for large containers. Using shared storage, tar layers preload, overlayBD https://github.com/codeexec/overlaybd-deploy https://github.com/codeexec/overlaybd-deploy is something that I would like to see more natively. Great article
- a_t48 7mo ago
  This is neat. I’m about to dive into snapshooters myself, any pitfalls to watch out for?
  - gogasca 7mo ago
    [dead]
heraldgeezer 7mo ago
I still havent learned it being in IT its so embarassing. Yes I know about the 2-3h Youtube tutorials but just...
forrestthewoods 7mo ago
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 the binary. (Aka what windows does). Replicating a faux “shared” filesystem is a gross hack. This is a distinctly Linux problem. Windows software doesn’t typically have this issue. Because programs ship their dependencies and then work. Docker is one way to ship dependencies. So it’s not the worst solution in the world. But I swear it’s a bad solution. My blood boils with righteous fury anytime anyone on my team mentions they have a 15 minute docker build step. And don’t you damn dare say the fix to Docker being slow is to add more layers of complexity with hierarchical Docker images ohmygodiswear. Running a computer program does not have to be hard I promise!!
- ahnick 7mo ago
  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 ignoring huge swaths of the SDLC. Anyone can cast stones, very few can actually implement a better solution. Bring the receipts.
  - forrestthewoods 7mo ago
    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.
1970-01-01 7mo ago
I now wonder if we'll end up switching it all back to VMs so the LLMs have enough room to grow and adapt.
- skybrian 7mo ago
  Maybe, but the install will often be done using a Docker file.
tzs 7mo ago
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 server on port 80 I want to access it at container_ip:80, not 127.0.0.1:2000 or something that gets mapped to container port 80. On Linux I'd just used Docker bridged networking and I believe that would work, but on Mac that just bridges to the Linux VM running under the hypervisor rather than to the Mac. Is there some officially recommended and supported way to do this? For a while I did it by running WireGuard on the Linux VM to tunnel between that and the Mac, with forwarding enabled on the Linux VM [1]. That worked great for quite a while, but then stopped and I could not figure out why. Then it worked again. Then it stopped. I then switched to this [2] which also uses WireGuard but in a much more automated fashion. It worked for quite a while, but also then had some problems with Docker updates sometimes breaking it. It would be great if Docker on Mac came with something like this built in. [1] https://news.ycombinator.com/item?id=33665178 https://news.ycombinator.com/item?id=33665178 [2] https://github.com/chipmk/docker-mac-net-connect https://github.com/chipmk/docker-mac-net-connect
- djs55 7mo ago
  (co-author of the article and Docker engineer here) I think WireGuard is a good foundation to build this kind of feature. Perhaps try the Tailscale extension for Docker Desktop which should take care of all the setup for you, see https://hub.docker.com/extensions/tailscale/docker-extension https://hub.docker.com/extensions/tailscale/docker-extension BTW are you trying to avoid port mapping because ports are dynamic and not known in advance? If so you could try running the container with --net=host and in Docker Desktop Settings navigate to Resources / Network and Enable Host Networking. This will automatically set up tunnels when applications listen on a port in the container. Thanks for the links, I'll dig into those!
  - tzs 7mo ago
    I'm basically using Docker on Mac as an alternative to VMWare Fusion with a much faster startup startup time and more flexible directory sharing. I want to avoid port mapping because I already have things on the Mac using the ports that my things in the container are using. I have a test environment that can run in a VM, container, or an actual machine like an RPi. It has copies of most of our live systems, with customer data removed. It is designed so that as much as possible things inside it run with the exact same configuration they do live. The web sites in then are on ports 80 and 443, MySQL/MariaDB is on 3306, and so on. Similarly, when I'm working on something that needs to access those services from outside the test system I want to as much as possible use the same configuration they will use when live, so they want to connect to those same port numbers. Thus I need the test environment to have its own IP that the Mac can reach. Or maybe not...I just remembered something from long ago. I wanted a simpler way to access things inside the firewall at work than using whatever crappy VPN we had, so I made a poor man's VPN with ssh. If I needed to access things on say port 80 and 3306 on host foo at work, I'd ssh to somewhere I could ssh to inside the firewall at work, setting that up to forward say local 10080 and 13306 to foo:80 and foo:3306. I'd add an /etc/hosts entry at foo giving it some unused address like 10.10.10.1. Then I'd use ipfw to set it up so that any attempt to connect to 10.10.10.1:80 or 10.10.10.1:3306 would get forwarded to 127.0.0.1:10080 or 127.0.0.1:13306, respectively. That worked great until Apple replaced ipfw with something else. By then we had a decent VPN for work and so I no longer need my poor man's VPN and didn't look into how to do this in whatever replaced ipfw. Learning how to do that in whatever Apple now uses might be a nice approach. I'll have to look into that.
callamdelaney 7mo ago
The fact that docker still, in 2026, will completely overwrite iptables rules silently to expose containers to external requests is, frankly, fucking stupid.
- netrem 7mo ago
  Indeed. I've had even experienced sysadmins be surprised that their ufw setup will be ignored.
pixelmonkey 7mo ago
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 recorded tech talk on the subject:” YouTube link: https://youtu.be/1vui-LupKJI?t=1579 https://youtu.be/1vui-LupKJI?t=1579 Note: starts at t=1579, which is 26:19. Just being pedantic though. That’s about 13 years ago. The lightning talk is fun as a bit of computing history. (Edit: as I was digging through the paper, they do cite this YouTube presentation, or a copy of it anyway, in the footnotes. And they refer to a 2013 release. Perhaps there was a multi-year delay between the paper being submitted to ACM with this title and it being published. Again, just being pedantic!)
- deleted 7mo ago
  [deleted]
- FlyingSnake 7mo ago
  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 https://news.ycombinator.com/item?id=5408002
  - pixelmonkey 7mo ago
    Nice find. Check out shykes commenting here on that thread! https://news.ycombinator.com/item?id=5409678 https://news.ycombinator.com/item?id=5409678
  - musicale 7mo ago
    I still prefer LXC to docker. Improving libvirt and making virtualization a first-class OS feature with a library interface - vs. relying on an external tool and company interested in monetization - was and is the right approach.
rando1234 7mo ago
Didn't Vagrant/Vagrantfiles precede Docker? Unclear why that would be the key to its success if so.
- idoubtit 7mo ago
  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).
  - rando1234 7mo ago
    Sure - I was just referring to the use of a Vagrantfile to configure the VM. The start of the article seemed to be pushing the Dockerfile itself as a big innovation.
netrem 7mo ago
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.
- Joe_Cool 7mo ago
  I have an immutable Alpine Linux running from an ISO that includes a few docker containers (mostly ruby and php). All in about 750MB.
- a_t48 7mo ago
  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.
  - netrem 7mo ago
    Sounds like it would be useful. Many common dev workflows started falling apart when it's not just tiny code files they need to deal with. In the python world, uv has helped massively, with pip we were seeing 30+ min build times on fairly simple images with torch
    - a_t48 7mo ago
      uv is one of my inspirations. Take a familiar interface, do the same thing but better/faster.
tsoukiory 7mo ago
[dead]
- webdevver 7mo ago
  [dead]
mberning 7mo ago
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.
benatkin 7mo ago
> 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.
- saltpath 7mo ago
  The "invisible" goal is harder than it sounds in air-gapped setups. We run AKS for a public sector client — private API server, no public egress, Azure Firewall with explicit allowlists. K8s is the right call, but invisible it is not. Podman for builds works fine until someone adds a base image that isn't mirrored locally. Then you get a silent pull failure at 2am.Most tooling just assumes outbound connectivity. Helm charts, operators,even some CNI plugins phone home somewhere at install. You don't find out until it breaks in prod.Not disagreeing with the direction just that invisible infrastructure means something different when egress is locked down by policy, not convention.
rr808 7mo ago
Back then I didn't foresee the 22GB image our jupyter/ML is in 2026. There must be a better way.
- therealdrag0 7mo ago
  Is that dockers fault? A basic Linux image is like 400MB right?
vegabook 7mo ago
Nix and never looked back.
- nudpiedo 7mo ago
  I often want to try, but never get the time, aren’t you missing packages and solutions out of the shelf and ready to use?
  - vegabook 7mo ago
    Increasingly flake.nix is present in good repos. Zillions of packages are available. But yes, you will need to learn and sometimes File System Hierarchy assumptions need to be worked around. The rewards however, dominate the (few) inconveniences once you know your way around.
nudpiedo 7mo ago
This was AI generated right? And saying that in 2010 Linux was complex and needed to compile everything across virtual machines for cloud solutions and that socket solved that… really in what universe people lived? Docker made convenient distribute some functionalities which were planned as stack of services rather than packaging appropriately for each distribution and handling to an administrator the configuration. That’s it. And it has many inconveniences. And Linux as well as BSD had containers before and chroots and many other things.
einpoklum 7mo ago
> While convenient, this single shared filesystem makes it very difficult to install multiple applications at the same time if they have conflicting dynamic library requirements. No, it does not make it "very difficult". And like other comments here grumble - this rationale is essentially a sanctification of the sentiment of "It builds and runs on my system and I can't be bothered to make fewer assumptions so that it runs on yours".
eudamoniac 7mo ago
I've been a professional in the industry for over a decade and I've still not found any meaningful benefit for learning or using containerization in the real world. I just install my dependencies with good old fashioned version managers (asdf) and I develop the project. I ignore all docker documentation, and everything works fine. When I try to use containers to develop, it's seemingly two dozen gotchas that sum up to my IDE needing endless configuration to function properly. I don't get it.
- scubbo 7mo ago
  Curious what you build/work on? If you're only shipping software library or tools, then yeah, your perspective makes sense - `asdf` or `mise` seem superior to `devcontainer`s. But I wouldn't want to deploy a web application without Dockerizing it.
  - eudamoniac 7mo ago
    Mostly web applications actually. Most web stuff is not that complicated. Usually the deployment itself is from docker (ops insists) but I just do development without it and I've never had a problem. I understand in theory I could get mismatched versions of things from production and thereby introduce a bug; in practice this has never happened a single time.
    - scubbo 7mo ago
      Right, yeah - I'm specifically _not_ talking about development (I agree that the likelihood of mismatches causing bugs is so small as to be worth fixing as that arises, rather than wasting effort on building a containerized dev environment), but about deployment. How could you deploy without first containerizing your application?
- JodieBenitez 7mo ago
  I don't get it either. Worse: it even makes developer lazy as they don't put the effort to ensure their development is portable.
- 7mo ago
amelius 7mo ago
I can remember the first time I used docker, and the layer limit was a big bummer that made me stop using it initially.
JodieBenitez 7mo ago
A decade of seeing my colleagues machines crumble under the weight of containers. > It is also something developers seem to enjoy using Count me out.
alex_dev42 7mo ago
[dead]
hei-lima 7mo ago
Great. I started developing in the Docker era, and while I can see some flaws, it is one of the easiest, most reliable tools I constantly use. I can't imagine how people dealt with those problems before Docker
pmarreck 7mo ago
A Docker image is an accidentally-correct cache of a nondeterministic build, and nothing will ever change that
with 7mo ago
docker is bloated. i'm almost certain half of every image is dead weight. unused apt packages, full distros for a single binary, shell configs nobody touches. but the incentive is to make things work, not make them small. so bloat wins. still, i use it every day and i don't see what replaces it. every "docker killer" solves one problem while ignoring the 50 things docker does well enough.
- stephbook 7mo ago
  Docker released "Docker Hardened Images" last year and made them free. They contain less bloat. Buying more RAM for your server or only touching a select few images that are run most often is also a way to make things work. It might not be the most elegant software engineering approach, but it just works.
- Zizizizz 7mo ago
  https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless These are pretty handy to use
  - with 7mo ago
    nice share!
JEONSEWON 7mo ago
[flagged]
paddle_work 7mo ago
[dead]
neop1x 7mo ago
No mention of OpenVZ or LXC
throwaway_2494 7mo ago
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 as in life, hell is other people's containers. My own I can at least try to keep them simple and minimal. But I have seen many use the kitchen sink approach, giving me the feeling that even the developer don't seem to know how they arrived at their deployment anymore. But this all seems quaint today. With LLMs, now we can look forward to a flood of code the developers haven't even looked at, but which is widely believed to work...
- jellyfishbeaver 7mo ago
  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.
  - LtWorf 7mo ago
    I have read the setns() manpage. I'm feeling very special and unique :D :D
Surac 7mo ago
I always wanted to use docker. Installed it and every time there was a feature i needed not included. Perhaps its because tried to use a technologie not commonly used
- oceansky 7mo ago
  What kind of features?
oceansky 7mo ago
Shoutout to Rancher Desktop
devonkelley 7mo ago
[dead]
rldjbpin 7mo ago
use the tech at work on a daily, but glad OCI exists to not be fleeced by the enterprise arm. installing docker desktop on my personal laptop permanently bricked it, right in the middle of chip/memory shortage. thanks docker!!!

366 points by zacwest 7mo ago

The historic information in here was really interesting, and a great example of an article rapidly expanding in scope and detail. How they combatted corporate IT “security” software by pretending to be a VPN is quite unexpected.

the__alchemist 7mo ago

I'm optimistic we will succeed in efforts to simplify linux application / dependency compatibility instead of relying on abstractions that which work around them.

Joker_vD 7mo ago
I am also optimistic we will succeed in efforts to properly annotate the data on the Internet with useful and accurate meta-data and achieve the semantic web vision instead of relying on search engines and LLMs.
__MatrixMan__ 7mo ago
Agreed. I've recently switched from docker compose to process compose and it's super nice not to have to map ports or mount volumes. What I actually needed from docker had to do less with containers and more with images, and nix solves that problem better without getting in the way at runtime.
- onei 7mo ago
  Assuming I've found the right process-compose [1], it struck me as having much overlap with the features of systemd. Or at least, I would tend to reach for systemd if I wanted something to run arbitrary processes. Is there something additional/better that process-compose does for you? [1]: https://github.com/F1bonacc1/process-compose https://github.com/F1bonacc1/process-compose
  - __MatrixMan__ 7mo ago
    That's the one, although I tend to reference it through https://github.com/juspay/services-flake https://github.com/juspay/services-flake because that way I end up using the community-maintained configs for whatever well-known services I've enabled (I'll use postgres as an example below, but there are many: https://community.flake.parts/services-flake/services https://community.flake.parts/services-flake/services) What process-compose gives me is a single parent with all of that project's processes as children, and a nice TUI/CLI for scrolling through them to see who is happy/unhappy and interrogating their logs, and when I shut it down all of that project's dependencies shut down. Pretty much the same flow as docker-compose. It's all self-contained so I can run it on MacOS and it'll behave just the same as on Linux (I don't think systemd does this, could be wrong), and without requiring me to solve the docker/podman/rancher/orbstack problem (these are dependencies that are hard to bundle in nix, so while everything else comes for free, they come at the cost of complicating my readme with a bunch of requests that the user set things up beforehand). As a bonus, since it's a single parent process, if I decide to invoke it through libfaketime, the time inherited by subprocess so it's consistently faked in the database and the services and in observability tools... My feeling for systemd is that it's more for system-level stuff and less for project-level dependencies. Like, if I have separate projects which need different versions of postgres, systemd commands aren't going to give me a natural way to keep track of which project's postgres I'm talking about. process-compose, however, will show me logs for the correct postgres (or whatever service) in these cases: ~/src/projA$ process-compose process logs postgres ~/src/projB$ process-compose process logs postgres This is especially helpful because AI agents tend to be scoped to working directory. So if I have one instance of claude code on each monitor and in each directory, which ever one tries to look at postgres logs will end up looking at the correct postgres's logs without having to even know that there are separate ones running. Basically, I'm alergic to configuring my system at all. All dependencies besides nix, my text editor, and my shell are project level dependencies. This makes it easy to hop between machines and not really care about how they're set up. Even on production systems, I'd rather just clone the repo `nix run` in that dir (it then launches process compose which makes everything just like it was in my dev environment). I am however not in charge of any production systems, so perhaps I'm a bit out of touch there.
mihaelm 7mo ago
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.
- the__alchemist 7mo ago
  Hah indeed that's my perspective. I'm used to being able to compile program, distribute executable, "just works", across win, Linux, MacOs. (With appropriate compile targets set)
- Hackbraten 7mo ago
  > 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.
  - esseph 7mo ago
    > From an I/O, storage, and memory utilization point of view, it feels baffling to me that containers are so popular. Why? It's not virtualization, it's containerization. It's using the host kennel. Containers are fast.
    - Hackbraten 7mo ago
      I was referring to the userspace runtime stack, not the kernel. What I criticize is that multiple containers that share a single host usually overdo it with filesystem isolation. Hundreds of MBs of libraries and tools needlessly duplicated, even though they could just as well have used distro packages and deployed their apps as system-level packages and systemd unit files with `DynamicUser=`. You can hardly call this efficient hardware utilization.
Bratmon 7mo ago
I'm curious why. To me "We updated our library to change some things in a way that's an improvement on net but only mostly backwards compatible" seems like an extremely common instinct in software development. But in an environment where people are doing that all the time, the only way to reliably deploy software is to completely freeze all your direct and indirect dependencies at an exact version. And Docker is way better at handling that than traditional Linux package managers are. Why do you think other tools will make a comeback?
- the__alchemist 7mo ago
  You can write any software you want without worrying about depending on a specific set of system dependencies. I like software that "just works", and making something that will give you inscrutable linking or dependency errors if the OS isn't set up just so is a practice I think should go away.
  - Bratmon 7mo ago
    But that's exactly what Docker provides.
andrewmcwatters 7mo ago
[dead]

talkvoix 7mo ago

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

redhanuman 7mo ago
the real trick was making "ship your machine" sound like best practice and ten years later we r doing the same thing with ai "it works in my notebook" jst became "containerize the notebook and call it a pipeline" the abstraction always wins because fixing the actual problem is just too hard.
- goodpoint 7mo ago
  ...while completely forgetting about security
- zbentley 7mo ago
  > fixing the actual problem is just too hard. I think it’s laziness, not difficulty. That’s not meant to be snide or glib: I think gaining expertise in how to package and deploy non-containerized applications isn’t difficult or unattainable for most engineers; rather, it’s tedious and specialized work to gain that expertise, and Docker allowed much of the field to skip doing it. That’s not good or bad per se, but I do think it’s different from “pre-container deployment was hard”. Pre-container deployment was neglected and not widely recognized as a specialty that needed to be cultivated, so most shops sucked at it. That’s not the same as “hard”.
  - skydhash 7mo ago
    It's not even laziness or expertise. A lot of people are against learning conventions. They want their way, meaning what works on their computer. That's why they like the current scope of package managers, docker, flatpack,... They can do what they want in the sandbox provided however nonsensical and then ship the whole thing. And it will break if you look at it the wrong way.
- 7mo ago

mrbluecoat 7mo ago

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

redhanuman 7mo ago
repurposing a Palm Pilot dial-up tool to sneak container traffic past enterprise firewalls is unhinged and yet it worked the best infrastructure hacks are never clever in the moment they are just desperate that the cleverness only shows up after someone else has to maintain it.
- Normal_gaussian 7mo ago
  Exactly. "so I hung the radiator out the window" vibes.
  - arcanemachiner 7mo ago
    I am trying to decipher the meaning of your comment, to no avail.
    - diroussel 7mo ago
      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.
      - ufocia 7mo ago
        Facts! That would've been covered on Hackaday not here.
- avsm 7mo ago
  VPNKit (the SLIRP component) has been remarkably bug free over the years, and hasn't been much of a burden overall. There was another component that we didn't have room to cover in the article that has been very stable (for filesystem sharing between the container and the host) that has been endlessly criticised for being slow, but has never corrupted anyone's data! It's interesting that many users preferred potential-dataloss-but-speed using asynchronous IO, but only on desktop environments. I think Docker did the right thing by erring on the side of safety by default.

INTPenis 7mo ago

I thought it was 2014 when it launched? The article says the command line interface hasn't changed since 2013.

avsm 7mo ago
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.

bmitch3020 7mo ago

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 long time. And as ugly as that flexibility is, I think it will remain the dominant solution for quite a while longer.

whateveracct 7mo ago
Nix is exceptionally good at making docker containers.
- mikepurvis 7mo ago
  Especially if you use nix2container to take control over the layer construction and caching.
- Spivak 7mo ago
  Yes but then you're committed to using Nix which doesn't work so well the moment you need some software not packaged by Nix. Want to throw a requirements.txt in there? No no, why would you even ask that? Meanwhile docker says yeah sure just run pip install, why should I care?
  - okso 7mo ago
    LLMs are getting very good at packaging software using Nix.
    - CuriouslyC 7mo ago
      This. I wouldn't have touched Nix when you needed someone who was really good at Nix to keep it working, but agents make it viable to use in a number of place.
    - mort96 7mo ago

avsm 7mo ago

An extremely random fact I noticed when writing the companion article [1] to this (an OCaml experience report): "Docker, Guix and NixOS (stable) all had their first releases during 2013, making that a bumper year for packaging aficionados." Now we get coding agent updates every week, but has there been a similar year since 2013 where multiple great projects all came out at the same time? [1]: https://anil.recoil.org/papers/2025-docker-icfp.pdf https://anil.recoil.org/papers/2025-docker-icfp.pdf

esseph 7mo ago
TBH I feel as if only docker belongs in that list. Guix and nix have users, sure, but not remotely like docker.
- NewJazz 7mo ago
  Yeah they are way better than docker for packaging
  - atomicnumber3 7mo ago
    Why is docker used by far the most, then?
    - ufocia 7mo ago
      Laziness
      - pas 7mo ago
        docker got popular because it had better DX (better tooling), it was like a super lightweight VM (and initially people really wanted to put init and SSH into containers) easy but powerful, it's not just packaging, it's also a very basic deployment system too. (docker ps) and said better allowed a relatively foolproof cross-platform develop-deploy loop.
ezst 7mo ago

deleted 7mo ago

[deleted]

brcmthrowaway 7mo ago

I dont use Dockerfile. Am i slumming it?

vvpan 7mo ago
Probably? How do you deploy?
- rglover 7mo ago
  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.
  - hard_times 7mo ago
    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.
    - rglover 7mo ago
      Read what I wrote. The answer to your question is there.

user3939382 7mo ago

It solves a practical problem that’s obvious. And on one hand the practical where-were-at-now is all that matters, that’s a legitimate perspective. There’s another one, at least IMHO, that this entire stack from the bottom up is designed wrong and every day we as a society continue marching down this path we’re just accumulating more technical debt. Pretty much every time you find the solution to be, “ok so we’ll wrap the whole thing and then…” something is deeply wrong and you’re borrowing from the future a debt that must come due. Energy is not free. We tend to treat compute like it is. Maybe I’m in a big club but I have a vision for a radically different architecture that fixes all of this and I wish that got 1/2 the attention these bandaids did. Plan 9 is an example of the theme if not the particular set of solutions I’m referring to.

arikrahman 7mo ago

I'm hoping the next decade introduces more declarative workflows with Nix and work with docker to that end.

brtkwr 7mo ago

I realise apple containers haven't quite taken off yet as expected but omission from the article stands out. Nice that it mentions alternative approaches like podman and kata though.

avsm 7mo ago
> but omission from the article stands out. (article author here) Apple containers are basically the same as how Docker for Mac works; I wrote about it here: https://anil.recoil.org/notes/apple-containerisation https://anil.recoil.org/notes/apple-containerisation Unfortunately Apple managed to omit the feature we all want that only they can implement: namespaces for native macOS! Instead we got yet another embedded-Linux-VM which (imo) didn't really add much to the container ecosystem except a bunch of nice Swift libraries (such as the ext2 parsing library, which is very handy).

politelemon 7mo ago

Somewhere along the line they started prioritising docker desktop over docker. It's a bit jarring to see new features coming to desktop before it comes to Linux, such as the new sandbox features. Is there any insight into this, I would have thought the opposite where developers on the platform that made docker succeed are given first preview of features.

krapht 7mo ago
Paying customers use docker desktop.

phplovesong 7mo ago

We have shipped unikernels for the last decade. Zero sec issues so far. I highly recommend looking into the unikernel space for a docker alternative. MirageOS being a good start.

avsm 7mo ago
cool! What services have you shipped as unikernels? Docker doesn't have to be an alternative; it can help with the build/run pipeline for them too: https://www.youtube.com/watch?v=CkfXHBb-M4A https://www.youtube.com/watch?v=CkfXHBb-M4A (Dockercon 2015!)
- phplovesong 7mo ago
  Mostly finance stuff, and all the sensitive stuff that comes with it. But the main benefit is the attack surface is greatly reduced when running a unikernel. Also we use way less resources and get really good perf.

gogasca 7mo ago

Something that I recently have explored is the optimization of Docker layers and startup time for large containers. Using shared storage, tar layers preload, overlayBD https://github.com/codeexec/overlaybd-deploy https://github.com/codeexec/overlaybd-deploy is something that I would like to see more natively. Great article

a_t48 7mo ago
This is neat. I’m about to dive into snapshooters myself, any pitfalls to watch out for?
- gogasca 7mo ago
  [dead]

heraldgeezer 7mo ago

I still havent learned it being in IT its so embarassing. Yes I know about the 2-3h Youtube tutorials but just...

forrestthewoods 7mo ago

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 the binary. (Aka what windows does). Replicating a faux “shared” filesystem is a gross hack. This is a distinctly Linux problem. Windows software doesn’t typically have this issue. Because programs ship their dependencies and then work. Docker is one way to ship dependencies. So it’s not the worst solution in the world. But I swear it’s a bad solution. My blood boils with righteous fury anytime anyone on my team mentions they have a 15 minute docker build step. And don’t you damn dare say the fix to Docker being slow is to add more layers of complexity with hierarchical Docker images ohmygodiswear. Running a computer program does not have to be hard I promise!!

ahnick 7mo ago
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 ignoring huge swaths of the SDLC. Anyone can cast stones, very few can actually implement a better solution. Bring the receipts.
- forrestthewoods 7mo ago
  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.

1970-01-01 7mo ago

I now wonder if we'll end up switching it all back to VMs so the LLMs have enough room to grow and adapt.

skybrian 7mo ago
Maybe, but the install will often be done using a Docker file.

tzs 7mo ago

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 server on port 80 I want to access it at container_ip:80, not 127.0.0.1:2000 or something that gets mapped to container port 80. On Linux I'd just used Docker bridged networking and I believe that would work, but on Mac that just bridges to the Linux VM running under the hypervisor rather than to the Mac. Is there some officially recommended and supported way to do this? For a while I did it by running WireGuard on the Linux VM to tunnel between that and the Mac, with forwarding enabled on the Linux VM [1]. That worked great for quite a while, but then stopped and I could not figure out why. Then it worked again. Then it stopped. I then switched to this [2] which also uses WireGuard but in a much more automated fashion. It worked for quite a while, but also then had some problems with Docker updates sometimes breaking it. It would be great if Docker on Mac came with something like this built in. [1] https://news.ycombinator.com/item?id=33665178 https://news.ycombinator.com/item?id=33665178 [2] https://github.com/chipmk/docker-mac-net-connect https://github.com/chipmk/docker-mac-net-connect

djs55 7mo ago
(co-author of the article and Docker engineer here) I think WireGuard is a good foundation to build this kind of feature. Perhaps try the Tailscale extension for Docker Desktop which should take care of all the setup for you, see https://hub.docker.com/extensions/tailscale/docker-extension https://hub.docker.com/extensions/tailscale/docker-extension BTW are you trying to avoid port mapping because ports are dynamic and not known in advance? If so you could try running the container with --net=host and in Docker Desktop Settings navigate to Resources / Network and Enable Host Networking. This will automatically set up tunnels when applications listen on a port in the container. Thanks for the links, I'll dig into those!
- tzs 7mo ago
  I'm basically using Docker on Mac as an alternative to VMWare Fusion with a much faster startup startup time and more flexible directory sharing. I want to avoid port mapping because I already have things on the Mac using the ports that my things in the container are using. I have a test environment that can run in a VM, container, or an actual machine like an RPi. It has copies of most of our live systems, with customer data removed. It is designed so that as much as possible things inside it run with the exact same configuration they do live. The web sites in then are on ports 80 and 443, MySQL/MariaDB is on 3306, and so on. Similarly, when I'm working on something that needs to access those services from outside the test system I want to as much as possible use the same configuration they will use when live, so they want to connect to those same port numbers. Thus I need the test environment to have its own IP that the Mac can reach. Or maybe not...I just remembered something from long ago. I wanted a simpler way to access things inside the firewall at work than using whatever crappy VPN we had, so I made a poor man's VPN with ssh. If I needed to access things on say port 80 and 3306 on host foo at work, I'd ssh to somewhere I could ssh to inside the firewall at work, setting that up to forward say local 10080 and 13306 to foo:80 and foo:3306. I'd add an /etc/hosts entry at foo giving it some unused address like 10.10.10.1. Then I'd use ipfw to set it up so that any attempt to connect to 10.10.10.1:80 or 10.10.10.1:3306 would get forwarded to 127.0.0.1:10080 or 127.0.0.1:13306, respectively. That worked great until Apple replaced ipfw with something else. By then we had a decent VPN for work and so I no longer need my poor man's VPN and didn't look into how to do this in whatever replaced ipfw. Learning how to do that in whatever Apple now uses might be a nice approach. I'll have to look into that.

callamdelaney 7mo ago

The fact that docker still, in 2026, will completely overwrite iptables rules silently to expose containers to external requests is, frankly, fucking stupid.

netrem 7mo ago
Indeed. I've had even experienced sysadmins be surprised that their ufw setup will be ignored.

pixelmonkey 7mo ago

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 recorded tech talk on the subject:” YouTube link: https://youtu.be/1vui-LupKJI?t=1579 https://youtu.be/1vui-LupKJI?t=1579 Note: starts at t=1579, which is 26:19. Just being pedantic though. That’s about 13 years ago. The lightning talk is fun as a bit of computing history. (Edit: as I was digging through the paper, they do cite this YouTube presentation, or a copy of it anyway, in the footnotes. And they refer to a 2013 release. Perhaps there was a multi-year delay between the paper being submitted to ACM with this title and it being published. Again, just being pedantic!)

deleted 7mo ago
[deleted]
FlyingSnake 7mo ago
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 https://news.ycombinator.com/item?id=5408002
- pixelmonkey 7mo ago
  Nice find. Check out shykes commenting here on that thread! https://news.ycombinator.com/item?id=5409678 https://news.ycombinator.com/item?id=5409678
- musicale 7mo ago
  I still prefer LXC to docker. Improving libvirt and making virtualization a first-class OS feature with a library interface - vs. relying on an external tool and company interested in monetization - was and is the right approach.

rando1234 7mo ago

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

idoubtit 7mo ago
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).
- rando1234 7mo ago
  Sure - I was just referring to the use of a Vagrantfile to configure the VM. The start of the article seemed to be pushing the Dockerfile itself as a big innovation.

netrem 7mo ago

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.

Joe_Cool 7mo ago
I have an immutable Alpine Linux running from an ISO that includes a few docker containers (mostly ruby and php). All in about 750MB.
a_t48 7mo ago
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.
- netrem 7mo ago
  Sounds like it would be useful. Many common dev workflows started falling apart when it's not just tiny code files they need to deal with. In the python world, uv has helped massively, with pip we were seeing 30+ min build times on fairly simple images with torch
  - a_t48 7mo ago
    uv is one of my inspirations. Take a familiar interface, do the same thing but better/faster.

tsoukiory 7mo ago

[dead]

webdevver 7mo ago
[dead]

mberning 7mo ago

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.

benatkin 7mo ago

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

saltpath 7mo ago
The "invisible" goal is harder than it sounds in air-gapped setups. We run AKS for a public sector client — private API server, no public egress, Azure Firewall with explicit allowlists. K8s is the right call, but invisible it is not. Podman for builds works fine until someone adds a base image that isn't mirrored locally. Then you get a silent pull failure at 2am.Most tooling just assumes outbound connectivity. Helm charts, operators,even some CNI plugins phone home somewhere at install. You don't find out until it breaks in prod.Not disagreeing with the direction just that invisible infrastructure means something different when egress is locked down by policy, not convention.

rr808 7mo ago

Back then I didn't foresee the 22GB image our jupyter/ML is in 2026. There must be a better way.

therealdrag0 7mo ago
Is that dockers fault? A basic Linux image is like 400MB right?

vegabook 7mo ago

Nix and never looked back.

nudpiedo 7mo ago
I often want to try, but never get the time, aren’t you missing packages and solutions out of the shelf and ready to use?
- vegabook 7mo ago
  Increasingly flake.nix is present in good repos. Zillions of packages are available. But yes, you will need to learn and sometimes File System Hierarchy assumptions need to be worked around. The rewards however, dominate the (few) inconveniences once you know your way around.

nudpiedo 7mo ago

This was AI generated right? And saying that in 2010 Linux was complex and needed to compile everything across virtual machines for cloud solutions and that socket solved that… really in what universe people lived? Docker made convenient distribute some functionalities which were planned as stack of services rather than packaging appropriately for each distribution and handling to an administrator the configuration. That’s it. And it has many inconveniences. And Linux as well as BSD had containers before and chroots and many other things.

einpoklum 7mo ago

> While convenient, this single shared filesystem makes it very difficult to install multiple applications at the same time if they have conflicting dynamic library requirements. No, it does not make it "very difficult". And like other comments here grumble - this rationale is essentially a sanctification of the sentiment of "It builds and runs on my system and I can't be bothered to make fewer assumptions so that it runs on yours".

eudamoniac 7mo ago

I've been a professional in the industry for over a decade and I've still not found any meaningful benefit for learning or using containerization in the real world. I just install my dependencies with good old fashioned version managers (asdf) and I develop the project. I ignore all docker documentation, and everything works fine. When I try to use containers to develop, it's seemingly two dozen gotchas that sum up to my IDE needing endless configuration to function properly. I don't get it.

scubbo 7mo ago
Curious what you build/work on? If you're only shipping software library or tools, then yeah, your perspective makes sense - `asdf` or `mise` seem superior to `devcontainer`s. But I wouldn't want to deploy a web application without Dockerizing it.
- eudamoniac 7mo ago
  Mostly web applications actually. Most web stuff is not that complicated. Usually the deployment itself is from docker (ops insists) but I just do development without it and I've never had a problem. I understand in theory I could get mismatched versions of things from production and thereby introduce a bug; in practice this has never happened a single time.
  - scubbo 7mo ago
    Right, yeah - I'm specifically _not_ talking about development (I agree that the likelihood of mismatches causing bugs is so small as to be worth fixing as that arises, rather than wasting effort on building a containerized dev environment), but about deployment. How could you deploy without first containerizing your application?
JodieBenitez 7mo ago
I don't get it either. Worse: it even makes developer lazy as they don't put the effort to ensure their development is portable.
7mo ago

amelius 7mo ago

I can remember the first time I used docker, and the layer limit was a big bummer that made me stop using it initially.

JodieBenitez 7mo ago

A decade of seeing my colleagues machines crumble under the weight of containers. > It is also something developers seem to enjoy using Count me out.

alex_dev42 7mo ago

[dead]

hei-lima 7mo ago

Great. I started developing in the Docker era, and while I can see some flaws, it is one of the easiest, most reliable tools I constantly use. I can't imagine how people dealt with those problems before Docker

pmarreck 7mo ago

A Docker image is an accidentally-correct cache of a nondeterministic build, and nothing will ever change that

with 7mo ago

docker is bloated. i'm almost certain half of every image is dead weight. unused apt packages, full distros for a single binary, shell configs nobody touches. but the incentive is to make things work, not make them small. so bloat wins. still, i use it every day and i don't see what replaces it. every "docker killer" solves one problem while ignoring the 50 things docker does well enough.

stephbook 7mo ago
Docker released "Docker Hardened Images" last year and made them free. They contain less bloat. Buying more RAM for your server or only touching a select few images that are run most often is also a way to make things work. It might not be the most elegant software engineering approach, but it just works.
Zizizizz 7mo ago
https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless These are pretty handy to use
- with 7mo ago
  nice share!

JEONSEWON 7mo ago

[flagged]

paddle_work 7mo ago

[dead]

neop1x 7mo ago

No mention of OpenVZ or LXC

throwaway_2494 7mo ago

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 as in life, hell is other people's containers. My own I can at least try to keep them simple and minimal. But I have seen many use the kitchen sink approach, giving me the feeling that even the developer don't seem to know how they arrived at their deployment anymore. But this all seems quaint today. With LLMs, now we can look forward to a flood of code the developers haven't even looked at, but which is widely believed to work...

jellyfishbeaver 7mo ago
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.
- LtWorf 7mo ago
  I have read the setns() manpage. I'm feeling very special and unique :D :D

Surac 7mo ago

I always wanted to use docker. Installed it and every time there was a feature i needed not included. Perhaps its because tried to use a technologie not commonly used

oceansky 7mo ago
What kind of features?

oceansky 7mo ago

Shoutout to Rancher Desktop

devonkelley 7mo ago

[dead]

rldjbpin 7mo ago

use the tech at work on a daily, but glad OCI exists to not be fleeced by the enterprise arm. installing docker desktop on my personal laptop permanently bricked it, right in the middle of chip/memory shortage. thanks docker!!!