Now, after latest announcement (https://www.docker.com/blog/updating-product-subscriptions/), I've started to wonder is there any good alternative for Docker?
I'm a Podman skeptic. Whenever I've tried these "OCI compatible" alternatives in the past it's been a painful experience because something doesn't work as expected. Podman's homepage proclaims it's as simple as "alias docker=podman" but it has never worked out for me this way.
Docker is ubiquitous and significantly more battle-tested, and even has a rootless mode now. And it works on Mac and PC alike.
Calling docker battle tested is an extremely long stretch. It has several security issues[0], many of which are ignored by upstream as "working as intended".
Arch packager here, looks like this can't realistically be packaged due to a dependency (runv[0]) being deprecated at it's upstream source.
A lot of these container runtimes are needlessly complicated and not very enjoyable to package, so this is why not many are available in the official repositories.
The Docker Desktop is just a GUI and some scripts to run Docker in a local VM. You can do the same manually or use alternatives to do the same, like Docker machine (now deprecated though). Better GUI and tools will probably appear soon.
The Docker Registry is already easy to replace. The API is not complex and almost everyone is providing a Docker Registry as a Service. AWS, Gitlab, Github, Azure... You can also self-host it but I would not recommend that.
To run Docker in production, you can use Kubernetes.
I heard some horrors stories about the registry going down and dying without working backups. They had to rebuild all containers more or less manually in a specific order because the build system did need some containers during the build.
Of course you can setup a high availability self hosted registry and test your backups regularly, but it's not super interesting in my humble opinion and it's a lot more expensive. Hosted Docker registries are cheap.
Having a local copy of the images is very interesting I agree. I would use a cache for that.
Sounds like FUD to me. These neither of these arguments apply specifically to docker registries and are more an argument against any form of self-hosting, which is a totally different conversation.
Having to rebuild if your server dies and you have no backups is obvious, same is for true for any part of your infrastructure and seems more like a deeply flawed ops strategy as a whole at the organization.
And in this case we are talking about self hosting as in not buying it as a service, not necessarily on your own hardware. I've self-hosted docker registries on a VPS from cloud provides who also provide backup and resilience against underlying hardware failures as a part of their service. If a server dies the VM is transparently moved to another machine, no big deal.
If you mean the Docker client, Podman comes to mind. Honestly though, if you don't like Podman, I'd recommend Minikube.
Then again, if you know nothing of Kubernetes, I'd stick with Podman (which has limitations on anything but Linux AFAIK). You might create wrappers around runc [1] if you really wanted (wouldn't recommend) or containerd [2] (no personal experience on my part).
If you mean the Docker registry, there are a number of alternatives, like quay.io or MCR.
Nix and Guix (my preference) are good alternatives. Guix, in particular, has its own system/application containers (not runc compatible). Highly efficient since they are essentially composed of symlinks of individual items in the Guix store.
I've had a bit of a play with Singularity containers and thought they were quite cool. Popular in the science circles but not so much anywhere else. I wonder why.
The docker daemon is easy to install on any *nix. Docker desktop doesn't really actually do much.
If you're on Windows, you'll need WSL. Enable remote daemon access on the internal IP, then install the CLI (scoop or chocolatey) and set your default context to your WSL instance.
The docker registry is easy to self-host for development purposes (https://docs.docker.com/registry/). Securing it for production is another topic though.
If you use Kubernetes you can self-host the registry and use Harbor (goharbor.io), it supports security scanning of images and can sign them too.
29 comments
[ 0.23 ms ] story [ 82.2 ms ] thread[1] https://podman.io
Docker is ubiquitous and significantly more battle-tested, and even has a rootless mode now. And it works on Mac and PC alike.
For me, it was, but I'm very much not doing anything complicated - just running some services in containers with an occasional 'compose' scenario.
> Docker is ubiquitous and significantly more battle-tested
Sure but if you now have to pay to use Docker Desktop at your company, Podman might be a better option.
I think that's fair. Then again, Docker as a company has been struggling to get customers, and their practices are... Let's say highly sub-optimal.
Feel free to pay for Docker. In our company, Docker is almost a curse word by now.
[0]: https://blog.newsblur.com/2021/06/28/story-of-a-hacking/
A lot of these container runtimes are needlessly complicated and not very enjoyable to package, so this is why not many are available in the official repositories.
[0]:https://github.com/hyperhq/runv
The Docker Registry is already easy to replace. The API is not complex and almost everyone is providing a Docker Registry as a Service. AWS, Gitlab, Github, Azure... You can also self-host it but I would not recommend that.
To run Docker in production, you can use Kubernetes.
It’s really nice to have it in the same network as the consuming servers to get great speeds.
Of course you can setup a high availability self hosted registry and test your backups regularly, but it's not super interesting in my humble opinion and it's a lot more expensive. Hosted Docker registries are cheap.
Having a local copy of the images is very interesting I agree. I would use a cache for that.
Sounds like FUD to me. These neither of these arguments apply specifically to docker registries and are more an argument against any form of self-hosting, which is a totally different conversation.
Having to rebuild if your server dies and you have no backups is obvious, same is for true for any part of your infrastructure and seems more like a deeply flawed ops strategy as a whole at the organization.
And in this case we are talking about self hosting as in not buying it as a service, not necessarily on your own hardware. I've self-hosted docker registries on a VPS from cloud provides who also provide backup and resilience against underlying hardware failures as a part of their service. If a server dies the VM is transparently moved to another machine, no big deal.
Then again, if you know nothing of Kubernetes, I'd stick with Podman (which has limitations on anything but Linux AFAIK). You might create wrappers around runc [1] if you really wanted (wouldn't recommend) or containerd [2] (no personal experience on my part).
If you mean the Docker registry, there are a number of alternatives, like quay.io or MCR.
[1] https://github.com/opencontainers/runc#introduction
[2] https://containerd.io/
Here's a convenient installer for that: https://github.com/dziemba/mobymac
It does however have some rather annoying limitations. Also no Apple Silicon support.
If you're on Windows, you'll need WSL. Enable remote daemon access on the internal IP, then install the CLI (scoop or chocolatey) and set your default context to your WSL instance.
If you use Kubernetes you can self-host the registry and use Harbor (goharbor.io), it supports security scanning of images and can sign them too.
Seems cheaper than docker
Minikube sets up a Linux VM using MacOS Hypervisor.
It even has a convenience command to configure docker-cli/docker-client.
For corporate situations where MITM proxies are used, you can inject/trust custom CAs using https://minikube.sigs.k8s.io/docs/handbook/untrusted_certs/