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.
You could use anything to manage the Docker VM... VSCode is just one option.
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.
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).
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.
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.
$ docker pull hello-world@sha256:7d91b69e04a9029b99f3585aaaccae2baa80bcf318f4a5d2165a9898cd2dc0a1There 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`)
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.
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?
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 just SSH into my server. The biggest pain about macOS is that it can't easily mount SFTP.
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.
It seems to me you would be the one cutting off your nose to spite your face in this scenario.
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.
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).
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…
How does this affect consultants that want to introduce docker to large corporations but small teams? A lot of scenarios become crappy now.
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.
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)
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.