Kubernetes is planned - my devops wants me to add it badly!
Author note - Most of you guys here are power users, for whom UI is a visual poem that you need or not.
This is not a commercial project, it is not following any business goals.
But this does not mean concessions to quality, it does try to offer minimal resource usage everywhere, easy experience, good UI/UX.
It explains all it does behind the scenes if you enable the developer console.
It can help one learn so at a certain moment one understands and automates with scripts and specs.
But everyone these days is either seen as too smart or too dumb, I don't consider users like this. I know everyone started somewhere and a gradual learning experience is the best.
I broke so many radios and toys when I was a kid and I learned so much, by looking at what was is inside.
It is a project done by one dude, after work and when it rains outside (In Belgium it rains a lot).
I never finished it, but I had a lot of fun documenting a basic-ass K8S (well, K3S) setup that costs about 20€/mo on Hetzner.
You don't really learn about sysadmin through it, or even about docker that much, but you get an idea of how you might easily run a few different things on a server while only needing to know YAML, and not some custom DSL like chef or puppet.
I did something similar between jobs—built a k8s "cluster" on my home Linux box using kops+qemu. It didn't make me an experienced admin, but it was really enlightening and fun! Projects like these are a great way to learn.
> only needing to know YAML, and not some custom DSL like chef or puppet.
YAML may be a known syntax, but the use of it still requires domain specific knowledge, and is still a domain specific language expressing those domain specific concepts, as to what the expected keys and values are allowed to be and how they are interpreted.
YAML isn’t the DSL, it’s just the language used to express declarative config because the tooling is ubiquitous and it’s rare that anyone uses it as anything more than a nicer version of JSON.
For Kubernetes, it’s CRDs that are written in YAML and they conform to a specification.
> But everyone these days is either seen as too smart or too dumb
Vert succinct and poetic way to describe so much these days in this space.
Sorry for being pandentic but you don't learn much by looking at the inside of a radio because it's mostly electronic components except for the knobs, antenna, dial. Without understanding how the the electronics work, you're just looking at parts. Mechanical parts like a bicycle, much easier to reason. Not knowing your background, can you build a radio if giving a box of parts? I certainly can't.
Maybe he's talking about a crystal radio? Those are relatively trivial to put together.
Looks cool, but how is the Kubernetes support? One of the major reasons we use Docker Desktop at work is to host a local Kubernetes cluster with services deployed there. We also support Rancher Desktop since it uses k3s, and k3s is arguably a nicer Kubernetes distribution than the one set up by Docker Desktop.
With that said, I have recently tried OrbStack, and it is able to start up near instantly, while Kubernetes spends at most 2 seconds to start up. The UI is minimal, but it offers just enough to inspect containers, pods, services, logs, etc. It also is very lightweight on memory usage and battery. I personally cannot return to either Docker or Rancher Desktop after having tried OrbStack.
OrbStack also allows using Kubernetes service domains directly on the host. So no need to use kubectl port-forward, and applications running on the host can use identical configuration to what's inside the Kubernetes cluster.
The battery savings, dynamic memory usage, fast startup time, and QOL of OrbStack is pretty much my standard for a Docker Desktop alternative. I am not sure if container-desktop satisfies all of these requirements. (Rancher Desktop certainly doesn't)
+1 for OrbStack, it’s one of the few software subscriptions I pay for, and is worth every penny. Leagues head of Docker Desktop.
I demoed Orbstack to my whole department of 100+ engineers, now we've canceled our Docker Desktop account and switched everyone over. Zero complaints.
I'm a fan of k3s. Mostly because Rancher Desktop, but there are more useful features, like a full k3s distribution within a single docker container. It includes some nice QoL features, like pre-loading images from a mounted folder. Great for CI.
I love kind! Used it a lot when I was writing my thesis on Kubernetes schedulers.
Literally or figuratively?
Curious to see your thesis!
I've been using Rancher Desktop as an alternative to Docker Desktop, https://rancherdesktop.io/ on macOS and Windows, it's pretty solid.
It has some kinks to work out but I got it working with IDEs too (e.g. the Intellij IDEA Docker Compose integration to work with it).
What I also like is that existing scripts and etc that use the docker-compose cli work with Rancher Desktop too, as it uses nerdctl https://github.com/containerd/nerdctl
Rancher Desktop is great, because kubernetes just works. Not only that, you can "docker build" an image, and then immediately spin it up as a kubernetes pod, without spending ten minutes googling the correct commands to correctly "load" the image.
Been using Rancher Desktop for 2 years, can definitely recommend this as an alternative to Docker Desktop.
I really like the whole Rancher ecosystem. Setting up a cluster with rancher is such a pleasant experience.
We just completed the switch to Rancher where I work. 1200ish engineers, mostly on Macs. So far it's worked out pretty well..fewer hiccups than I expected.
Yup +1 for Rancher Desktop. Works as smooth as Docker Desktop on MacOS.
Currently it is the best alternative I have used, in what concerns the same experience as Docker Desktop on Windows.
If you’re on macOS, then Orbstack is a nice alternative to Docker Desktop
(I’m not affiliated with Orbstack)
I would love to use it but I loathe subscriptions, especially for something I’d need work to pay for. I would happily pay a one-time $50-100 and get a perpetual license so I don’t have to deal with the headache…
IMO if Docker is important to you then Orbstack is worth it.
The debug shell feature alone makes it better than any alternative, and hopefully that subscription money is put towards more unique features.
https://docs.orbstack.dev/features/debug
Colima offers the best experience for docker alternative. LIMA offers the equivalent of WSL, where both docker and podman are supported. I like LIMA a lot as I deal with both, but COLIMA rocks for simplicity. I think COLIMA + Container Desktop are perfect replacement on mac for traditional Docker Desktop users.
Colima has been great to support x86 images on Apple Silicon like OracleDB 19, instead of building arm64 images.
The flexibility of container runtimes and host architecture (via QEMU) has proven useful.
Yeah, I use this to support extremely old C++ project on x86_64 docker images and it's tolerable if not speedy.
Orbstack is wicked good. I love it. I compile to 4 platforms with it (Ubuntu/Mac x x86_64/arm) and it's the fastest emu/docker thing.
Of course Orbstack is fast, it uses LXD, not actual VMs. In fact, Orbstack on Mac is what made me switch to LXD (Incus) on Linux to replace Docker and virt-manager.
Switched to it, and paid for the license. I agree with others about not wanting to get subcriptioned to death, but I feel like it's worth $8/month.
I've also used Colima, and if Orbstack wasn't an option, I'd be happy to keep using it.
It's nice, but only for personal use.
Be aware that you need a license if you use it at work.
As is true with a lot of developer tooling. Including Docker Desktop itself.
Another enthusiastic +1 for OrbStack. It's fantastic.
GPU support would be a real benefit, but for anything not needing that, Orbstack's become my strong preference.
Is there anything you can actually _do_ with the Apple GPUs outside of macOS? I know the Asahi Linux person was working on a driver for it, but is it in a useful state?
Oh neat! Thanks for the tip!
Orthogonal rant: Podman allows host mounts during image build, whereas docker does not. Ran into a big headache where a monorepo using podman leveraged this to create container images from source and the equivalent docker implementation had to copy the monorepo into the docker build context every time.
We needed to use Docker for M1 support (probably should've tried Colima, etc).
I may be wrong, but I think BuildKit gives Docker that functionality.
I'd bind-mount the tree into the context. (I assume Docker won't follow simple symlinks.)
I've really enjoyed using Orbstack: https://orbstack.dev/
it also has support for Linux VMs and kubernetes (although i haven't tried that yet)
I'm currently using colima, and none of the other alternatives that I have found support forwarding UDP ports, which I use a lot, so that's a bummer!
Thankfully, lima has landed a new port forwarder with UDP support! [0]. I'm hoping to be able to use it soon once it makes into a release.
[0]: https://github.com/lima-vm/lima/commit/13e9cbcabc6a0a05ec389...
Last I checked podman's support of docker-compose.yml was very limited to say the least. Has it changed?
There are two approaches to using compose w/ podman:
Replace docker-compose with podman-compose -- somewhat limited capabilities, but works in a lot of cases.
Use docker-compose against podman w/ podman's system service, which provides a docker compatible API endpoint (https://docs.podman.io/en/v5.2.1/markdown/podman-system-serv...). This basically has full docker-compose capabilities, but, you do need run the socket service as a specific user account which end up running all the pods.
I found the most stable to be a third option: 'podman compose' with docker-compose-v2 cli "backend" connecting to the actual podman socket. This will be done if you run 'podman compose' with 'docker-compose' in PATH, and DOCKER_HOST set to your podman socke, since 'podman compose' will just shim through to whichever command it finds available.
Both podman-compose (the Python project) and docker-compose-v1 have significant gaps in the compose spec.
What parts did you find lacking? I haven't had any issues using podman-compose to launch stuff using unmodified docker-compose.yml files.
Yeah, I'm using it and it's nearly everything I need.
What does podman desktop offer that WSL does not (at least for those of us on Windows)?
Ease of use, even used as a GUI for WSL, that doesn't mean it doesn't add value.
It's not fully baked. Sigh
- Buggy as heck with bad error messages.
- Bad UX with inadequate help.
- Requires extra tweaking and installing more stuff to get going, which defeats its entire purpose.
- Confusing.
- Can't browse or choose tags of images.
It's not a viable alternative yet, but maybe it will improve sometime in the future.
not affiliated with the project but thanks for the feedback! Now they have some more items in their TODO list which will make their product better.
While I'm basically fine with Colima on Mac, this seems like a nice alternative to Docker Desktop.
After some initial pains with colima, I tend to agree. Mostly, just needing to specify some VZ args[0] so I could run x86_64 docker images on my M-series.
Is there something in these desktop UIs that colima is completely missing?
[0] `colima start --vm-type=vz --vz-rosetta`
Could this be the answer I needed to run an SQL Server image that refused to run on my M3 MBP? I was about to, sadly, try Docker Desktop, because of that.
That is exactly why I needed it, too! :D
Be sure to increase RAM over the default 2GB as well, that SQL Server container is hungry and will crash without enough resources dedicated to it.
"some initial pains" = Colima VM running out of resources running kind, so I had to raise the CPU and RAM, and then raise the fd's in the VM itself to get it to work. but now it works!
colima + docker CLI goes a long way.
$ colima start
$ docker context use colima
And that's it.
And Kubernestes? No thank you, life is already hard as is.
Honest question, what’s wrong with docker desktop? Looking at all the alternatives suggested it’s not clear to me why any other tools are better? I’m not using k8s locally, just docker compose. To connect to our remote k8s cluster, I use IntelliJ k8s extension (I just need to do some basic dev tasks, I’m not administrating the cluster)
One big difference is the licensing. Docker Engine itself is apache licensed (and hence free to use at a company of any scale), but Docker Desktop requires a paid plan if your company has more than 250 employees or more than $10 million in annual revenue [0].
[0]: https://docs.docker.com/engine/#licensing
Which like, seems entirely fair, but when there are suitable enough replacements that cost $0, why pay for it? Sure there are big picture reasons, but companies often don't think that long-term.
Docker Desktop requires a paid licence for companies with over 250 employees. While that's totally fair, it can add red tape if you want to use it in a project.
I'm not completely sure about licensing for Container Desktop but the footer suggests MIT license.
For me, it was consuming so much memory. Switching to OrbStack helped fix that
Rancher desktop is fine. I did migration within 30 minutes.
Does it support VSCode Devcontainers? That's the only reason I haven't been able to switch to an alternative.
My team switched our medium sized org over to Rancher Desktop with no major issues after about 10 months. We don't need kubernetes though.
Is Ubuntu 24.04 supported? (Docker Desktop doesn't support 24.04 currently)
Is it ok to run the Windows version on a normal desktop (not in a VM). Does it uninstall cleanly. Thx
how is this different from the usual podman client ?
Why does Docker feel like it was designed by people with no Unix background?
I don't know if your comment was intended to imply that Docker was against the Unix philosophy in some way (a debatable point, but not really one I share), or if you mean that the tools don't follow a lot of common Unix convension.
When Docker was only a few years old, I did keep running into lots of small things which implied that the people developing docker in fact did NOT have a Unix (or even Linux) background. Things like source code files having the wrong type of newlines (or a mix of types), and forgetting to add a newline to the last line in a file. (A correct Unix text file has a newline at the end of _every_ line, even the last one.) There were of course more giveaways than this, I just remember the newline stuff irritating me the most.
Why is newline at the end relevant?
I remember not having a newline breaks some tools... but why? It can't be because of unix philosophy!?
Some old tools had bugs where they'd read a line (up to the new line) and then process it, so if the last line didn't end with a new line they'd never do the processing. So a manual workaround for bugs became the convention.
Back in ~2002 this was the case with cron. Found out the hard way when all the backup tapes we desperately needed were completely empty.
so that you can cat(1) multiple files at once, and their bookends don't get glued.
Is another crap electron app?
Personally I just build all my software so it includes its dependencies and then you don't need docker or any complex image manager. Don't rely on a bunch of crap being installed in the system path! Much much simpler this way imho.
Personally, I just ship every user a small Chromebook that runs my software so I can guarantee the environment is the same every time.
(I get your point, but docker has made distribution way easier in a lot of ways, and you accept sole tradeoffs for that convenience)
You can have convenience and reliability with fewer tradeoffs!
That's basically what a docker image does in a more formalized, isolated, and repeatable fashion.
In most scenarios it is definitely good-enough but even in just my own personal experiences over a decade I need to asterisk all three of your listed benefits.
True. But Docker comes with a lot of complexity. And it comes with a meaningful performance hit on macOS and Windows. And it doesn't work at all on Android/iOS.
It's so sad that running software on Linux is so wildly complicated and unreliable than things like Docker had to be invented. :(
I think that's the right way to do it from the software distributor's side, but most software distributors don't do it like you.
So, from a consumer's point of view, if you want to use their software, then docker is the lesser evil compared to all the others. Notably, it's much better than binaries with dynamic libraries that don't come included in the bundle itself.
As a user, I'd rather use a container then figure out how to run a binary. The onboarding process is typically so much easier, and most enterprise folks already have container infrastructure in place. For big customers, getting a Kubernetes namespace can have significantly less friction than a VM these days.
> then figure out how to run a binary
It should never be more complicated than "run the binary". Running programs shouldn't require infrastructure or VMs or Docker images. Deploying a program should be, and can be, as simple as sharing a zip file, extracting, and running.
It's not that hard!
> better than binaries with dynamic libraries that don't come included in the bundle itself.
Binaries should always include the dynamic libraries they require. Docker is one way to include them. But you can also just include them the vanilla way. Works great! Very easy and reliable.
I'm sorry but this doesn't work. Over the last 10 years so I was fucked over by countless "software that includes all its dependencies" that stopped working when I upgraded some other totally irrelevant software because "well duh it obviously uses system libC" or whatever. Examples: critical .AppImage binaries stopping working after random system upgrades. Nothing runs on my computer is ever fully isolated, not even Docker. So, any isolation guarantee I get is guarantee I'll take. You claim today that your software is isolated, but I don't know if 3 years down the road I'll upgrade my freaking text editor and your program will stop working because that one library from 1987 has to be exactly version A.X but my text editor upgraded it to A.Y. Thanks but no thanks.
> your program will stop working because that one library from 1987 has to be exactly version A.X but my text editor upgraded it to A.Y.
Perhaps you misunderstand. This issue is fully solved by including dependencies and not relying on anything in the system path. Programs should not touch the system path. If a program requires library A.Y then it should include and use A.Y. But it should not touch the system path and thus should not impact any other program. Nor will it be impacted by other programs wanting A.Z.
It's often literally not possible to ship everything. You wouldn't want to spin up a second X11 (or Wayland) server, for example, because you can't have two of them talk to the same video card device at the same time usefully.
The number of things that can't be shipped is extremely small. And I don't think that Docker is a silver bullet for Wayland vs X11 issues? Although I'm not sure about the fine details as I don't have a ton of experience there. Shouldn't you be using an abstraction that can automatically support which ever is available?
I tend to ship code that needs to run on Linux + macOS + Windows + Android. So Docker is a total non-option. And it's totally fine! Very easy in fact.
On some projects and teams, more than usually expected, this is more than fine.