But I've run into issues emulating more complex environments where you need multiple exposed ports, more complex host-to-Docker networking, etc., which generally works on Linux because it's not stuck in a VM shim layer.
But most of the time, I don't have any issues, just sometimes slower environments on Mac if I don't tune folder mounts and run apps like Ruby/Node/PHP with hundreds or thousands of files.
Here's a description of my setup for that: https://news.ycombinator.com/item?id=33665178
And the same with Docker Desktop on Linux: https://docs.docker.com/desktop/install/linux-install/
Why would the Docker developers do this? Did doing it locally not work well? Is all that just to 'spare' Linux developers from actually installing Docker on their machines?
Here they appear to have chosen to vendor in the whole damn OS, which, given the realities of supporting Linux, doesn't seem totally insane to me. I'd expect it also lets you run it with reduced permissions (not everyone has root on their workstation) and to generally make cross-distro operation much more reliable and consistent.
Lots to do to combat this, like: not sharing the volume with the host (vscode dev containers recommends this)
With that said if you're doing mostly backend stuff in Go/Python/Ruby etc it's quite good. Most of my complaints are from full-stack development.
The other upside of being fully containerized - even for FE stuff - is that you side-step having to worry about having any sort of "local" dev environment configured beyond Docker/Podman/etc and some environment variables set. It makes onboarding new developers a breeze and eliminates "Weird, works locally on my machine!" types of issues.
Eh, yes it is. Apple doesn't provide a containerisation API for their OS, which means Docker is forced to run non-natively!
Containers on macOS don't use OCI images or anything like that, but scoped and grouped access to system resources with a separate user land that 'looks' like a full OS has been available for over 5 years. Even without that, XNU has plenty of facilities for it, and even if it didn't you'd still be able to use Launchd environments (which are more akin to LXC).
Docker relies on specific implementation details of the Linux kernel. It always has. That is why you always need a Linux OS somewhere to run the containers.
Example: there are artefacts you can store as OCI images that contain Mach-O binaries, and Windows and Linux won't really run those. You can even still PPC code in those binaries, and link to Cocoa frameworks. This means that the OS and architecture you are targeting will not be Windows or Linux, and that is not their fault.
Is that true? Plenty of people are using multi-arch images (x86 and aarch64) which are essentially the Docker image equivalent of a fat binary. I might be wrong, but I think what I want are preconfigured macOS binaries packaged up a convenient image format with a layered filesystem, networking support, etc. Ideally with an equivalent linux image such that I can later switch the OS specifier and get an image containing an equivalent linux binary to run on linux.
I am for example quite happy to run a macOS native version of Postgres. But that doesn't give me the easy disposable database for testing that a docker-compose setup gives me. If I could specify that I want the "postgres" docker image in my docker-compose file, and running that file on macOS ran a macOS version of postgres in a macOS-native container then I'd be very happy.
Packaging (including fat binaries but also byte code self-unpackers) has tried to make this possible for decades but it just won't stick. Take Debian or RedHat packages for example, there have been tools and repositories for very long times that were meant to make a universal method of distributing pre-packaged (and natively also chrootable/jailable) software for a multitude of architectures and operating systems possible, but package authors just didn't really want to do the work for what is essentially not something they wanted themselves.
Building software for 1 or 2 major release versions within a single operating system is hard enough, tacking on extra systems is usually a step too far.
The closest we got (and it still exists) is autotools, but that's just build tooling. It does however make it possible to build software from a single source for many targets and check for all the required features ahead of time. But this is so close to developing the software itself that it's not really compatible with the influx of end-user-style developers that expect pre-packaged 'commercial grade' software, which is essentially what Docker and OCI and Containers are.
The only 'new' thing so far has been cgroupsv2, the v1 version and everything else (distribution, sandboxing, capabilities, separate user land etc) has been done for over three decades. But again, using it means knowing how to use chroot, cap, tun and jail for example, and not everyone wants to learn that much. So we get things like docker, which under the hood does exactly that, plus some union filesystem magic to make it cheaper/faster for registries to store data; essentially a re-implementation of dynamic linking and shared libraries, but for files.
So now we have created an interface (docker) that is easy to adopt, easy to promote and easy to use, but it's hard-wired into Linux (the kernel) and only much later (post-OCI) got some hacked up windows version that is completely different and doesn't work anywhere else (because, well duh, not-windows isn't going to run windows apps). Aside from the fact that it's an OCI artefact, windows containers have very little to do with docker containers as we know them.
Most of this stuff also didn't really come from a need to get containers on windows (or macOS) but from the need to get more 'developer light edition' into the workforce, which can be trained and onboarded faster. If you can get people to ignore the foundation they stand on, they can be put to work in building upwards much sooner. This does of course come to bite everyone in the ass at some point, because if you're standing on top some 'magic' infrastructure and something breaks, it's going to be really hard to fix it. Right now we're all trying to make it redundant enough so we can ignore the breakage, but I doubt this is a winnable race.
Docker is a convenience, not a technical solution to a technical problem.
Will macOS run them? That seems to be the missing functionality.
On Linux, I quite like Podman! It has a couple of gaps, but for simple things it works great
It's too complex to thunk windows calls to linux, that is what WSL1 tried and failed at, because windows is just too different from a POSIX paradigm for that to work well. But posix-on-posix isn't really all that hard... nor is other *nix-on*nix.
What did they do differently with WSL2+?
I use the Remote SSH plugin in VSCode and configured the VM to forward all container ports to localhost (as well as forward port 22 to port 2222 on localhost). I also have `alias vmlogin=ssh -X -p 2222 localhost` in my .zsh_profile and set up ssh to use a public/private key pair for quick logins.
Just do a 'colima start' once a month when I actually have to reboot my mac, to boot up the background VM, and everything else basically runs as normal.
It was working fine for me, maybe requiring one restart per month. But the slowness was unbearable anymore. Don't even get me started on the effects of it on battery life.
To anyone looking for a replacement, Windows is usable. I still miss the consistency of MacOS tho.
Since I only use laptops, I haven't even bothered to try Linux again, my last experience was not that great with compatibility issues and hibernation problems.
MacBook Pro (14-inch, 2021)
Chip Apple M1 Pro
Memory 16 GB
macOS Monterey
Docker 20.10.17
I agree it was awful on the previous generations tho.
I have nothing but horrible memories when I had to use Linux on the desktop.
This includes multiple editors and IDEs used, multiple languages and multiple frameworks, also multiple types of development (from common devops facilities development to front-end simulation, on-prem and cloud, C#, Python, Java, Go, Rust, Swift, Objective-C, C++, TypeScript, Scala, T-SQL, PL/SQL (yep, RDBMS with on-DB applications), some on plain docker, some on Podman some on local Kubernetes clusters, all using wired and wireless connections (or both), one or more VPN connections), and nobody is having any issues with macOS and Docker on Intel or ARM. The only non-ARM OS we have around is Windows because we can't legally get it. Everything else is multi-arch, except for some legacy Oracle and IBM applications that are being phased out and have been handed off to a third party to maintain while we rip them out.
We have the luxury of not really doing and foreign architecture compilation because you can develop locally and CI will do matrix builds so we can run on a mixed spot fleet on AWS. We used to build for POWER8 too (before we handed off the IBM nonsense). Some people do it anyway, especially those who want to test binary protocols (a very small percentage) when they write applications that do IT<-->OT communication and want to make sure that the architecture on the IT side doesn't mess up binary payloads that the OT side won't know what to do with. This is usually done with k3s and skaffold where we attach and 2nd node to a Rancher Desktop instance that runs pure x86 instead of x86-in-ARM via Rosetta. We also have 1 Linux user who does this, but she's just using plain qemu emulation for ARM-on-x86 (instead of the other way around on M1/M2 Macs).
So all in all, I think the problem is still valid, but your experience is not really representative it seems. Keep in mind that happy people tend to not go on the internet and tell everyone about all the problems they don't have ;-) So most reports we'll see will be from people having issues with something.
The biggest issue we used to have was the AUFS support, but even that was mostly a painpoint for those who could not auto build from the ide or didn't have things like Jib. That has been resolved for over 5 years tho.
This is surprising. I run FreeBSD on a home server but I would imagine that it'd be rather unproductive to run as a web dev workstation OS, since it shares friction points with macOS (mainly, it's not Linux) but doesn't have even a fraction as many users which means you're basically on your own for fixing any issues that crop up.
More power to this individual if they're making it work though. It's great to see diversity in the desktop/workstation OS usage… in my view, desktop monoculture will only come back to bite us in the ass.
I also think that monoculture isn't really the best way, but neither is an abundance of variations causing uncertainty. We need to be able to plan ahead and look ahead, and have enough of a standard to operate.
Luckily, convincing stakeholders that "but we imaged this workstation last year" isn't a valid argument in any scenario (security, productivity, DLP) wasn't all that hard, and the jump from there to "images and MDM are all fun, but near realtime posture verification is the only way" was made with relative ease.
Most people still stick to the "supported and automated" provisioned workstations, but those who want something else can have it, if they deliver on their compliance, non-friction and actual work. Best of all worlds.
I'd change this to "web" development. There are a lot of us not doing anything that requires even thinking about docker.
I'm not alone in picking the word "fundamental". In the same survey that is article is based on, Docker was the #1 "other tool" for professional devs. SO had this to say about it " Last year we saw Git as a fundamental tool to being a developer. This year it appears that Docker is becoming a similar fundamental tool for Professional Developers, increasing from 55% to 69%." I think the comparison is works too. Git isn't the best tool for everyone, but is extremely common and a sound default. Docker also isn't the best tool for everyone, but isn't far off on being as ubiquitous.
Stop trying to get me to switch to MacOS :-P
> It's such a fundamental tool to development
s/fundamental/gratuitous, undesirable/ . IMNSHO.
brew install podman-desktop
Meanwhile, the client works just fine and can connect to a headless machine running Linux if you don't want the cost of virtualizing the host OS. Like, if my Linux laptop were having trouble running a Mac copy of Photoshop in a Mac VM (ignore the legality) and it was really important for work and that was getting in my way, I'd... get a Mac. If Docker on Mac isn't cutting it, get a Linux box—it's not Mac-native software and you can still interact with it pretty seamlessly from the Mac.
I remember playing around with running our codebase through Docker when M1 first got released and it was really slow (due to ARM and/or shared disk read speeds?). But from what I understood it was something that was to be fixed soon...
I'd love to use Docker at work but it was a show stopper.
Aside from build and stability issues, I've also hit not-so-subtle bugs in MITM proxies they add for connections on some ports.
I get why building Docker on MacOS, especially with the x86 emulation twist, is such a difficult problem. I don't envy the engineers working on this. But I don't get a developer who knows they need Docker would pick a mac for their main machine.