4 ms·

It's bizzare to want to run Docker on a Mac anyway. Docker has never and will never run on a Mac natively. The way it works on Intel-based Macs is through the x

It's bizzare to want to run Docker on a Mac anyway. Docker has never and will never run on a Mac natively. The way it works on Intel-based Macs is through the xhyve/hyperkit hypervisor, i.e. it virtualises Linux. That's the only way it can work. It's also why you can limit how many CPU cores and RAM Docker can use, since you're just giving the underlying virtual machine those limits through the Docker settings app. And it's just a memory hog. It will eat RAM up to the amount you specify rather than dynamically allocating and deallocating as per the requirements of each running container like on Linux. It shocks me that so many people want to run Docker on a platform it was never built for. The suggestion above is not bizzare, it's a normal use case: run Docker on Linux like it's meant to be run. Docker for Mac has had performance issues for years, especially related to file I/O. The common suggestion is to use NFS to get around those, which is just ridiculous when you think about it. [0] [0] https://vivait.co.uk/labs/docker-for-mac-performance-using-nfs https://vivait.co.uk/labs/docker-for-mac-performance-using-n...

weaksauce 6y ago
> It shocks me that so many people want to run Docker on a platform it was never built for. surely you can imagine a situation in which a developer prefers to develop on a mac but wants to deploy to a linux server though? that's the use case here.
- chipsa 6y ago
  Seems like the sensible solution is to have a linux VM and do push everything into the VM to run. Which is what Docker on Mac apparently does, but with less control over doing it yourself. This is the exact workflow that VSCode w/ remote is supposed to enable: you just connect to the VM and everything works. VM could be somewhere else. Or it could be on the local machine. Doesn't matter.
  - robertlagrant 6y ago
    It's not the same flow. What if I want to use docker-compose to spin up some services locally and test them? How does a linux VM help me compared to just running docker-compose up and having the details of needing a VM abstracted away?
  - derefr 6y ago
    Why would I want that control when Docker on Mac does everything exactly the way I would do it if I set it up myself? I don't want to maintain my own special-snowflake VM just to run docker containers on it. I want a dumb cattle VM running Container OS or an equivalent, whose only job is to run containers, ephemerally, connected to my host. The less it can do other than that, the better. In fact, best if it gets blown away on every restart. Any statefulness is to be avoided, because a stateful Docker host might mislead me that my images will work in prod, when they're really dependent on something in my dev VM. Caches, databases, message queues? In development, they're ephemeral. Blow those containers away, please. I don't want any persistent volumes, host mounts, any of that. This is development, not deployment. Any data is just there to verify that the code is doing the right thing. Why would any such data need to live longer than the containers producing+consuming it? (In the rare case that I do want a persistent database, I run it on the host. It's already a special snowflake; may as well treat it like one. As a bonus, this forces me to ensure my applications can target external resources using connection-string env-vars — which is almost-always relevant in production, where the DBMS is going to be some cluster external to the compute environment.) > VM could be somewhere else. Or it could be on the local machine. Doesn't matter. I don't know about docker itself, but I'm using Docker on Mac for Kubernetes "application" development. Targeting my commands to my local Docker-on-Mac k8s cluster vs a remote one is just a `kubectl config set-context` away. (Or you can do the same from the Docker on Mac tray menu.)
jml78 6y ago
And docker on Linux doesn’t support all the features that docker on Mac does. Specifically kubernetes. You can dismiss this but if your dev shop is doing dev work that lands in a k8s cluster, it sure is nice to just have devs install docker desktop for Mac and they have a fully functioning k8s cluster that just works. My whole company uses macs except me. I had to spend a bunch of time figuring out how to get a dev environment working on Linux. And it wasn’t easy as none of the out of the box k8s solutions support how we developed our build system. If I wasn’t a k8s admin from early versions of k8s I would have just given up. No platform is perfect.
- reissbaker 6y ago
  Kubernetes runs natively on Linux. It sounds like your company built its dev tooling specifically around Docker for Mac. It's not surprising that it was a pain to replicate on Linux your company's work as a sole programmer. But that doesn't mean that Linux doesn't support Kubernetes well. Linux is the primary target for k8s! It runs more efficiently and has better support than Kubernetes on Mac. Minikube has worked as a dev cluster on Linux long before Docker for Mac shipped a k8s dev cluster. (I, too, have been involved with Kubernetes projects since the early days, and have built k8s tooling at fairly large companies.)
  - jml78 6y ago
    I never said kubernetes wasn’t supported on Linux. I said docker on Linux does not have that as a feature out of the box. Go install docker desktop for Mac. Click a preference and you have kubernetes. That is not the case in Linux. Can you install kind? Sure. Can you install minikube? Sure. And define support? To give you a simple example, in minikube on Linux how do you make local images built by docker available in minikube? https://hasura.io/blog/sharing-a-local-registry-for-minikube-37c7240d0615/ https://hasura.io/blog/sharing-a-local-registry-for-minikube... It involves using dockerhub (rate limited) or running another local registry that you retag and push. How about docker for Mac? No changes required at all, if the image is in the docker registry, it works in kubernetes This is the exact type of retagging non sense that I hate in a dev workflow and is completely hacky. So I solved it myself using k3s but I don’t think I have seen anyone else tackle it on Linux. Especially not minikube or kind
pardner 6y ago
> It shocks me that so many people want to run Docker on a platform it was never built for. Yet, it works, and well, your shock notwithstanding. If your goal is a SINGLE portable, virtualized platform for your developers, which does not require a persistent internet/SSH connection, and which is "fast enough" for developers to be effective, Docker on Mac is a pretty swell solution.

weaksauce 6y ago

> It shocks me that so many people want to run Docker on a platform it was never built for. surely you can imagine a situation in which a developer prefers to develop on a mac but wants to deploy to a linux server though? that's the use case here.

chipsa 6y ago
Seems like the sensible solution is to have a linux VM and do push everything into the VM to run. Which is what Docker on Mac apparently does, but with less control over doing it yourself. This is the exact workflow that VSCode w/ remote is supposed to enable: you just connect to the VM and everything works. VM could be somewhere else. Or it could be on the local machine. Doesn't matter.
- robertlagrant 6y ago
  It's not the same flow. What if I want to use docker-compose to spin up some services locally and test them? How does a linux VM help me compared to just running docker-compose up and having the details of needing a VM abstracted away?
- derefr 6y ago
  Why would I want that control when Docker on Mac does everything exactly the way I would do it if I set it up myself? I don't want to maintain my own special-snowflake VM just to run docker containers on it. I want a dumb cattle VM running Container OS or an equivalent, whose only job is to run containers, ephemerally, connected to my host. The less it can do other than that, the better. In fact, best if it gets blown away on every restart. Any statefulness is to be avoided, because a stateful Docker host might mislead me that my images will work in prod, when they're really dependent on something in my dev VM. Caches, databases, message queues? In development, they're ephemeral. Blow those containers away, please. I don't want any persistent volumes, host mounts, any of that. This is development, not deployment. Any data is just there to verify that the code is doing the right thing. Why would any such data need to live longer than the containers producing+consuming it? (In the rare case that I do want a persistent database, I run it on the host. It's already a special snowflake; may as well treat it like one. As a bonus, this forces me to ensure my applications can target external resources using connection-string env-vars — which is almost-always relevant in production, where the DBMS is going to be some cluster external to the compute environment.) > VM could be somewhere else. Or it could be on the local machine. Doesn't matter. I don't know about docker itself, but I'm using Docker on Mac for Kubernetes "application" development. Targeting my commands to my local Docker-on-Mac k8s cluster vs a remote one is just a `kubectl config set-context` away. (Or you can do the same from the Docker on Mac tray menu.)

jml78 6y ago

And docker on Linux doesn’t support all the features that docker on Mac does. Specifically kubernetes. You can dismiss this but if your dev shop is doing dev work that lands in a k8s cluster, it sure is nice to just have devs install docker desktop for Mac and they have a fully functioning k8s cluster that just works. My whole company uses macs except me. I had to spend a bunch of time figuring out how to get a dev environment working on Linux. And it wasn’t easy as none of the out of the box k8s solutions support how we developed our build system. If I wasn’t a k8s admin from early versions of k8s I would have just given up. No platform is perfect.

reissbaker 6y ago
Kubernetes runs natively on Linux. It sounds like your company built its dev tooling specifically around Docker for Mac. It's not surprising that it was a pain to replicate on Linux your company's work as a sole programmer. But that doesn't mean that Linux doesn't support Kubernetes well. Linux is the primary target for k8s! It runs more efficiently and has better support than Kubernetes on Mac. Minikube has worked as a dev cluster on Linux long before Docker for Mac shipped a k8s dev cluster. (I, too, have been involved with Kubernetes projects since the early days, and have built k8s tooling at fairly large companies.)
- jml78 6y ago
  I never said kubernetes wasn’t supported on Linux. I said docker on Linux does not have that as a feature out of the box. Go install docker desktop for Mac. Click a preference and you have kubernetes. That is not the case in Linux. Can you install kind? Sure. Can you install minikube? Sure. And define support? To give you a simple example, in minikube on Linux how do you make local images built by docker available in minikube? https://hasura.io/blog/sharing-a-local-registry-for-minikube-37c7240d0615/ https://hasura.io/blog/sharing-a-local-registry-for-minikube... It involves using dockerhub (rate limited) or running another local registry that you retag and push. How about docker for Mac? No changes required at all, if the image is in the docker registry, it works in kubernetes This is the exact type of retagging non sense that I hate in a dev workflow and is completely hacky. So I solved it myself using k3s but I don’t think I have seen anyone else tackle it on Linux. Especially not minikube or kind

pardner 6y ago

> It shocks me that so many people want to run Docker on a platform it was never built for. Yet, it works, and well, your shock notwithstanding. If your goal is a SINGLE portable, virtualized platform for your developers, which does not require a persistent internet/SSH connection, and which is "fast enough" for developers to be effective, Docker on Mac is a pretty swell solution.