Hacker News Reader

Comment by dpratt | Hacker News Reader

This appears to be cutting of their nose to spite their face. We have a team of 50+ engineers that all use Docker for Mac for daily development tasks, but I suspect that will no longer be true in a rather short amount of time. Frankly, I don’t really know if anybody actually uses the UI components for it outside of starting and stopping the engine and for basic configuration of the VM. Everything else that comes with it is just useless cruft for our use cases.

As soon as there is a viable alternative (and I’d be happy to contribute to the effort), I’ll be moving away from Docker for Mac.

View on HN

For the Mac, just get Canonical’s Multipass (http://multipass.run) and do an apt-get to install Docker into a VM and use VS Code to “remote” to it. It will automatically install the Docker extension inside the Linux VM and you’re set.

For Windows, use WSL2 and do the same.

Both can mount “local” folders, although the setup is obviously different.

You now have a better way to manage containers than ever before.

Can’t say that limiting developers to VSCode is necessarily a step forward.

Well, it does set up everything automagically for you. I can also dig around for my Docker CLI config and the right way to expose the Docker TCP socket to the host, but if you need a quick way to get working, VS Code is it.

You don't need VSCode specifically, but it does provide an alternative GUI for managing Docker containers that isn't tied directly to Docker Desktop.

You could use anything to manage the Docker VM... VSCode is just one option.

Doesn't work on M1 chips yet.

It's in "beta" right now but it works quite well (you can find the binary in the dedicated GitHub issue). Under the hood it just uses QEMU which in turn uses Apple's Hypervisor.framework for virtualization

I believe this is the issue referenced above: https://github.com/canonical/multipass/issues/1857

Do you mean APT via https://docs.docker.com/engine/install/ubuntu/, correct?

No, you can apt-get docker.io (the repackaged version available for the last 2-3 LTS releases, built from source and with fan networking support). Works for 99.9% of your use cases.

I would strongly recommend docker.io from Ubuntu/Debian repos. This will be always Apache 2.0 licensed. (It's a fork of Moby packaged by Debian people).

Docker Engine looks problematic since the license isn't clear at all. For instance, Microsoft didn't include Docker into GitHub Actions, they also forked Moby and packaged it on their own, since they can't comply with the End User Agreement of Docker Engine.

Regarding the GitHub Docker license thing, this is directly from GH staff (you’re correct): https://github.community/t/what-really-is-docker-3-0-6/16171...

Why run Docker inside a VM on a Mac, when you can just run the Linux dev environment directly inside the VM? That's just starting to sound like Docker for the sake of Docker.

Multipass, Qemu, and Parallels can all provide a solid VM on Mac host. All you need after that is your dev environment VM guest image to deploy to the team.

https://wiki.qemu.org/Hosts/Mac

https://www.parallels.com/

Some people here actually want and need Docker features. For me it's the ability to run from a given image and know that I've got _exactly_ the same image that other developers have. Reproducibility.

When I want a very specific version if the image, I use the SHA to pull/run

  $ docker pull hello-world@sha256:7d91b69e04a9029b99f3585aaaccae2baa80bcf318f4a5d2165a9898cd2dc0a1

Or you could tag a little more optimally.

Tags are mutable, digests aren't.

Why, how often do you change tags after you've built a container and for what reason if so?

Digests cryptographically guarantee that you get the correct content, which prevents both malicious tampering (mitm, stolen credentials, etc) or accidental mutations. This is why "immutable tags" are a bad substitute and an oxymoron.

There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.

With a sha you shouldn’t have to change the pull policy. However there isn’t a need for always if you have the sha.

> There are also better caching properties when using content addressable identifiers. For example with kubernetes pull policies, using IfNotPresent and deploying by digest means you don't even have to check with the registry to initialize a pod if the image is already cached, which can improve startup latency.

While agree on the unquoted part, this is true also for human-readable (aka mutable-that-should-be-immutable) tags, when that pull policy is set (which is by default for everything that is not `latest`)

I might be wrong, but I think his point is that by the time you're running a linux VM for docker, why not go ahead and get the rest of the tooling for free?

Docker can still be run in the VM just fine, for cases where you want a reproducible build environment.

I do this at any company that lets me (and by lets, I mean doesn't explicitly forbid) - They all give me a Mac, and the first (and sometimes only) thing I install is usually vmware fusion, followed by the linux distro of my choice (Arch).

>for cases where you want a reproducible build environment.

Or just create your reproducible build environment as a QEMU VM image instead of a docker file. That way you only have to install a VM image, instead of install VM image/OS + install Docker + install your Docker file.

Just the cost of porting one single Dockerfile to anything else is bigger than the Docker licence cost for 1 year.

See, I don't really agree here.

Containers solve a different problem than vms. The biggest issues (at least for me) are

1. The second a dev starts using that VM, it's no longer reproducible. The goal of docker is that a developer can create reproducible images as a part of normal development.

2. I won't be running that QEMU vm in production, but I might very well be running the exact same container image in both development and production.

On Apple Silicon Multipass actually uses QEMU under the hood. Basically it's just a (very convenient) wrapper

Because you can map your working folder inside it on both Multipass and WSL2, and you can get an integrated editor experience with VS Code, which is what many people apparently want to do (I’m a tmux guy so I don’t care, but I thought I’d provide a user-friendly approach).

Because the end result of a lot of workflows (eg k8s) is a buildable dockerfile, or built docker image for deployment.

I want to ship a dockerfile in my CI/CD pipeline, not a VM image

Why don't you just use the VM directly?

Folder mapping, which both options provide.

Multipass uses reverse sshfs for mounting into the VM. This is a concept also used by lima now. https://github.com/lima-vm/lima

This is the best solution. Multipass is also great software.

> (and I’d be happy to contribute to the effort)

Isn't paying their fee also contributing to the effort of what they've put in to it so far, and ideally what they'll do to keep it working and improve over time?

So you have a tool that your team use daily, but won’t pay a small license for it? I’m not sure I understand that logic. If the tool you have worked for you when it was free, it still works for you when you pay a small cost per month. Unless the cost is really that huge, I don’t see why that would be a reason to change.

Not only is he opposed to paying a license fee, he will contribute to the development of an entirely new, almost certainly worse, tool.

I think it is mostly the issue of dealing with byzantine corporate procurement processes. Also, it's really not all the clear what value-add Docker for Desktop is. Essentially it is just doing what you can do using the OSS components (running a Linux VM which runs the docker daemon and mounting a Unix socket on the host machine to talk to it). The only "value add" is a UI app on the host machine which I have never once used personally or witnessed anyone else using.

I certainly don't begrudge Docker for trying to create a sustainable business, but as an "open core" model it's really hard to understand what their proprietary extensions are that people will want to pay for. They took a stab at the container orchestration space with Docker Swarm (which you could definitely imagine having an "enterprise version") but that lost out pretty definitively to Kubernetes. So they're left with Docker Hub? That just doesn't seem like it will really be much of a revenue generator. You're either using whatever cloud container registry is available (ECR, GCR etc) or you're using a more general artifact repository like Artifactory, GitHub which can be a container registry as well as a Maven/NPM/etc artifact repository.

I made https://github.com/lime-green/remote-docker-aws a while ago and I've been happily using it for about a year. It throws docker in a ec2 VM and allows you to call docker as if it were running locally by tunneling and syncing files. The network file systems I tried (sshfs, nfs) were way too slow when used as docker volumes so it uses a tool called unison which does two-way file syncing (rsync only does one way, which is a problem for something like making django migrations)

> As soon as there is a viable alternative (and I’d be happy to contribute to the effort), I’ll be moving away from Docker for Mac.

I just SSH into my server. The biggest pain about macOS is that it can't easily mount SFTP.

Ouch, really? Cyberduck was always one of my first installs simply due to how much I spited Finder, but I didn't know things were... that bad.

You can mount SFTP with Mountain Duck [1], from the creators of Cyberduck. Costs around $40.

[1]: https://mountainduck.io

Fuse/sshfs exists for OSX. Seems to work okay the little I played with it.

I used fuse/sshfs quite a lot in the past, and never had much issues (I think most of my issues were with how my editor displayed and refreshed the file list, not with the actual sshfs implementation, and were similar to those on Linux/Windows.)

It’s not completely awful, but quite a long way from mounting a natively supported share, made worse by the already convoluted setup process that has been made worse by the project going proprietary.

Lima project works on an alternative to sshfs https://github.com/lima-vm/sshwebdav

I've been doing development in docker, but unrelated to that I did an upgrade to big sur and borked the machine for a few days.

Pulling the same projects to my (admittedly quite fast) linux box in the cloud is night and day for speed in docker with volume mounts. Browserfy runs 5x faster, at least. Yarn install is 10x faster.

And it's reliable. Docker's filesharing on the mac has about a 25% failure rate that any given save will be properly picked up by watch, with a complete, uncorrupted, updated file.

You’re going to spend scarce engineering resources reimplementing a Docker for Mac alternative, then roll out your immature alternative to 50+ engineers, instead of paying a few hundred dollars a month for a good product and moving on?

It seems to me you would be the one cutting off your nose to spite your face in this scenario.

The reason this move isn't popular is because it seemed like local docker development (for any size corporation) was always going to be free. If I personally had known this was in the cards I would have invested (time, money and effort) into alternatives earlier on. Instead they killed all the competition and are now demanding money. So yeah, this is the first move by Docker that has made me kind of mad at the company.

How does this affect consultants that want to introduce docker to large corporations but small teams? A lot of scenarios become crappy now.

> Instead they killed all the competition and are now demanding money. So yeah, this is the first move by Docker that has made me kind of mad at the company.

Which alternatives did they kill? The Podman tool ecosystem is doing fine and is closing in on being a complete replacement, and Docker Swarm hasn't exactly killed k{number}s.

"k{number}s" means k8s, right? Is this a reference or something?

k8s, k3s

Assuming that you currently don‘t need any other than the functionality the free plan provides, and assuming all 50 engineers need a license, your „a few hundred dollars“ is actually $1‘250/month just for getting the same as before.

I understand (in some way) the decision Docker made but I am not sure it is the way-to-go. However, it is a very hard question and if I had to pay a monthly fee for each component I‘m using to develop a solution, one or the other project would not even start because it‘s not worth it anymore.

That 50 people team probably costs at least 250000/month. Are you going to take away a tool that everyone on the team needs to save 1250?

Or put another way, how much time would you need to replicate what Docker offers for a team of 50 people? If it takes more than 25% of the time of a single employee, then Docker is cheaper (assuming your employee costs $5000 a month, which I guess is a lower bound for an engineer).

No, I am not (that was also not my point basically). My point is that you are going to pay for a) something you got for free (as in beer) before and b) something you don‘t (maybe) need/want.

I think it is a very valid question how to monetize Docker (and all the other libraries we are using for free), but I am personally not sure that subscriptions to everything are the solution.

I am sure that this expense should not get into your way if you have 50+ engineers, however if you think that with all expenses…

Personally I think just running portainer as a container is a viable alternative to docket desktop. But I never really used the UI much, so perhaps there are features I don’t know of.

Unless there's podman or similar for local dev, you'd still need Docker Desktop to use it on Windows/MacOS.

21$/month/user is nothing for the business setting.

Between getting that approved and paid by the company or just using another tool, I will use another tool.

Yes, it's nothing for a single tool, even with hundreds or thousands of dev. But in total it quickly adds up for a lot of tools.

I tried getting podman working pointing at a Linux server and ram into issues as an alternative to Docker. I’m hoping the kinks get worked out and I can move over.

We have been using podman here for all of our developers and have yet to find anything different to docker. Perhaps you are using a more obscure feature.

I think podman is a lot easier than docker. You can stop all containers easily (without xargs)

podman stop -a

or you can mount the current directory

podman run -v .:/mnt

or you can mount while you build

podman build -v /dir:/dir

or you can work entirely without root and have the same user on the host also in the container:

podman run --userns=keep-id

(useful when a directory is mounted into container but the application refuses to run as root)

Reply on news.ycombinator.com