[HN Gopher] Docker Desktop Alternative
___________________________________________________________________
Docker Desktop Alternative
Author : istoica
Score : 168 points
Date : 2024-09-20 18:08 UTC (4 hours ago)
(HTM) web link (container-desktop.com)
(TXT) w3m dump (container-desktop.com)
| bradleyy wrote:
| While I'm basically fine with Colima on Mac, this seems like a
| nice alternative to Docker Desktop.
| veonik wrote:
| 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`
| fragmede wrote:
| "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!
| dmonitor wrote:
| what does this offer that podman desktop does not?
|
| https://podman-desktop.io/
| gnulinux wrote:
| Last I checked podman's support of docker-compose.yml was very
| limited to say the least. Has it changed?
| scheme271 wrote:
| What parts did you find lacking? I haven't had any issues
| using podman-compose to launch stuff using unmodified docker-
| compose.yml files.
| mfenniak wrote:
| 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.
| 3np wrote:
| 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.
| EdwardDiego wrote:
| Yeah, I'm using it and it's nearly everything I need.
| candiddevmike wrote:
| What does podman desktop offer that WSL does not (at least for
| those of us on Windows)?
| eterm wrote:
| Ease of use, even used as a GUI for WSL, that doesn't mean it
| doesn't add value.
| moondowner wrote:
| 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
| manojlds wrote:
| Yup +1 for Rancher Desktop. Works as smooth as Docker Desktop
| on MacOS.
| SystemOut wrote:
| 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.
| aaqureshi wrote:
| Been using Rancher Desktop for 2 years, can definitely
| recommend this as an alternative to Docker Desktop.
| pjmlp wrote:
| Currently it is the best alternative I have used, in what
| concerns the same experience as Docker Desktop on Windows.
| PufPufPuf wrote:
| 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.
| cortesoft wrote:
| I really like the whole Rancher ecosystem. Setting up a cluster
| with rancher is such a pleasant experience.
| hnlmorg wrote:
| If you're on macOS, then Orbstack is a nice alternative to Docker
| Desktop
|
| (I'm not affiliated with Orbstack)
| cweagans wrote:
| Another enthusiastic +1 for OrbStack. It's fantastic.
| throwanem wrote:
| GPU support would be a real benefit, but for anything not
| needing that, Orbstack's become my strong preference.
| cweagans wrote:
| 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?
| rahen wrote:
| Yes. In fact it's accelerated and supports OpenGL 4.6
| while macOS tops at OpenGL 4.1, and in fact mostly only
| supports Metal nowadays. With Asahi you can use OpenGL
| and Vulkan.
|
| https://arstechnica.com/gadgets/2024/02/asahi-linux-
| projects...
| cweagans wrote:
| Oh neat! Thanks for the tip!
| alexandre_m wrote:
| It's nice, but only for personal use.
|
| Be aware that you need a license if you use it at work.
| corytheboyd wrote:
| 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...
| swyx wrote:
| colima is also good https://www.swyx.io/running-docker-without-
| docker-desktop
|
| also no affiliation and have not tried orbstack
| comprev wrote:
| 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.
| lanstin wrote:
| Yeah, I use this to support extremely old C++ project on
| x86_64 docker images and it's tolerable if not speedy.
| istoica wrote:
| 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.
| bdcravens wrote:
| 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.
| renewiltord wrote:
| 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.
| rahen wrote:
| 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.
| samz wrote:
| Rancher desktop is fine. I did migration within 30 minutes.
| koito17 wrote:
| 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)
| linkdd wrote:
| You should check out https://kind.sigs.k8s.io/ and
| https://k0sproject.io
| leonheld wrote:
| I love kind! Used it a lot when I was writing my thesis on
| Kubernetes schedulers.
| arjvik wrote:
| Curious to see your thesis!
| yard2010 wrote:
| Literally or figuratively?
| hu3 wrote:
| I'm torn between https://k0sproject.io and https://k3s.io to
| use in CI and production.
|
| Any suggestions or personal experience?
| PufPufPuf wrote:
| 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.
| adhamsalama wrote:
| What about minikube?
| JosephRedfern wrote:
| +1 for OrbStack, it's one of the few software subscriptions I
| pay for, and is worth every penny. Leagues head of Docker
| Desktop.
| forrestthewoods wrote:
| 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.
| diego_sandoval wrote:
| 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.
| candiddevmike wrote:
| 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.
| forrestthewoods wrote:
| > 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!
| forrestthewoods wrote:
| > 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.
| borski wrote:
| 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)
| forrestthewoods wrote:
| You can have convenience and reliability with fewer
| tradeoffs!
| gnulinux wrote:
| 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.
| forrestthewoods wrote:
| > 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.
| mook wrote:
| 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.
| dpkirchner wrote:
| That's basically what a docker image does in a more formalized,
| isolated, and repeatable fashion.
| mtndew4brkfst wrote:
| 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.
| forrestthewoods wrote:
| 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. :(
| hu3 wrote:
| On some projects and teams, more than usually expected, this is
| more than fine.
| achristmascarl wrote:
| 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)
| Apreche wrote:
| Does it support VSCode Devcontainers? That's the only reason I
| haven't been able to switch to an alternative.
| saghul wrote:
| 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...
| ekzy wrote:
| 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)
| alx__ wrote:
| For me, it was consuming so much memory. Switching to OrbStack
| helped fix that
| bboygravity wrote:
| FreeBSD jails? :p
| maxyurk wrote:
| it's not free
| Andoryuuta wrote:
| 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
| Delk wrote:
| 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.
| istoica wrote:
| 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).
| beepbooptheory wrote:
| > 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.
| ljm wrote:
| I never finished it, but I had a lot of fun documenting a
| basic-ass K8S (well, K3S) setup that costs about 20EUR/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.
| thwarted wrote:
| > _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.
| 2OEH8eoCRo0 wrote:
| Why does Docker feel like it was designed by people with no Unix
| background?
| bityard wrote:
| 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.
| jve wrote:
| 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!?
| mook wrote:
| 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.
| ape4 wrote:
| Is it ok to run the Windows version on a normal desktop (not in a
| VM). Does it uninstall cleanly. Thx
| leoqa wrote:
| 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).
| jmholla wrote:
| I may be wrong, but I think BuildKit gives Docker that
| functionality.
| nine_k wrote:
| I'd bind-mount the tree into the context. (I assume Docker
| won't follow simple symlinks.)
| taspeotis wrote:
| https://docs.docker.com/reference/dockerfile/#run---mount
| ademup wrote:
| Is Ubuntu 24.04 supported? (Docker Desktop doesn't support 24.04
| currently)
| wg0 wrote:
| 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.
| delduca wrote:
| +1 for OrbStack.
| delduca wrote:
| Is another crap electron app?
| jpace121 wrote:
| I would also encourage people to look at Podman desktop which has
| pretty good support from Red Hat.
|
| https://podman-desktop.io/
| dzonga wrote:
| how is this different from the usual podman client ?
___________________________________________________________________
(page generated 2024-09-20 23:00 UTC)