This is only a myth because of the full os base images - which not every container has. And frequently, the more minimal base images are missing a lot of useful tooling, so it's still an issue.
> Docker hardly works on macOS and Windows
Docker for mac is still not very reliable. Shared volumes (related to IDE and DB "myths") frequently get "stuck", it still occasionally consumes a full core of CPU, and finding a shared port (say, for remote debugging) is still a pain.
It's a useful tool, but for reliable development I still prefer a normal local environment; going back to Docker when I'm done developing and am ready to do a release.
> And frequently, the more minimal base images are missing a lot of useful tooling, so it's still an issue.
Oh yeah, I know that problem. This happened to me a while ago:
Me: "Hm, that container is having trouble."
$ kubectl logs my-container-24fa8
ERROR: cannot connect to theotherthing.example.corp:443
Me: "Let's see if DNS is working from the container."
$ kubectl exec -ti my-container-24fa8 bash
kubectl: bash: command not found
$ kubectl exec -ti my-container-24fa8 sh
sh$ dig A theotherthing.example.corp
sh: dig: command not found
sh$ host theotherthing.example.corp
sh: host: command not found
sh$ nslookup theotherthing.example.corp
sh: nslookup: command not found
sh$ ls /bin /usr/bin
...
...
sh$ openssl s_client -connect theotherthing.example.corp:443
But I still build my containers on an Alpine base, because the datacenter on the literal other side of the planet has such a shitty link that if the image is 100 MB (rather than 10 MB), it will take multiple minutes to download it on all nodes, even though we have a Squid proxy in place for that in every DC.
This is only a myth because of the full os base images - which not every container has. And frequently, the more minimal base images are missing a lot of useful tooling, so it's still an issue.
> Docker hardly works on macOS and Windows
Docker for mac is still not very reliable. Shared volumes (related to IDE and DB "myths") frequently get "stuck", it still occasionally consumes a full core of CPU, and finding a shared port (say, for remote debugging) is still a pain.
It's a useful tool, but for reliable development I still prefer a normal local environment; going back to Docker when I'm done developing and am ready to do a release.