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.
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 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 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 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.