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.
A decade of Docker containers
71–80 of 275 posts
Re: A decade of Docker containers
#72Somewhere 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.
Paying customers use docker desktop.
Re: A decade of Docker containers
#73I dont use Dockerfile. Am i slumming it?
Probably? How do you deploy?
Re: A decade of Docker containers
#74Earlier quoted context omitted.
> 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…
> Puppet or terraform or something more declarative would have been such a better alternative Until you need to do something that isn't covered with its DSL, and you extend it with an external command execution declaration... At which point people will just write bash scripts anyway and use your declarative language as a glorified exec.
If you have 90-95% of everyone's needs (installing packages, compiling, putting files) covered in your DSL, and it has strong consistency and declarativeness, it's not that big of a problem if you need an escape hatch from time to time. Terraform, Puppet, Ansible, SaltStack show this pretty well, and the vast majority of them that isn't bash scripts is better and more maintainable than their equivalents in pure bash would be.
Re: A decade of Docker containers
#75I'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.
In some situations, yes, others no. For instance if you want to control memory or cpu using a container makes sense (unless you want to use cgroups directly). Also if running Kubernetes a container is needed.
Re: A decade of Docker containers
#76I'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.
Wasn’t this the same argument for .jar files?
Re: A decade of Docker containers
#77I 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.
> 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
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).
Re: A decade of Docker containers
#78I'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.
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?
Re: A decade of Docker containers
#79Earlier quoted context omitted.
Nix is exceptionally good at making docker containers.
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?
LLMs are getting very good at packaging software using Nix.
Re: A decade of Docker containers
#80An 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/…
TBH I feel as if only docker belongs in that list. Guix and nix have users, sure, but not remotely like docker.