It's for small experiments and to play around with Docker a little bit. I doubt that it will ever be able to do this. If your network has a certain bandwidth and a certain latency in production, it's a good idea to configure the network conditioner on the hypervisor on your development machine with the same conditions.ĭocker for Mac cannot do this now. When you are running Docker on CoreOS inside a VM in production, it's a good idea to do the same in development. It's good practice to mimic your production as closely as possible in your development environment. It's probably not even fit for development. It's not for production yet and probably never will be. we're just talking about different things.ĭocker for Mac is helping people getting started. It's like I'm saying a car is faster than a bicycle and you're saying that a bike can be faster than a car under certain conditions and that any place you're going to is close by so it doesn't make a difference anyways. But usually there is a performance loss when running your program inside a virtual environment.
If you are experiencing a faster execution than on bare metal, that's some interesting anecdotal evidence.
It might still have it's use cases since you're still able to use the Docker ecosystem, but as long as it has to use this additional layer, it is really more like all the other virtualization solutions out there and not like Docker. My point is, that Docker is built around the idea of using containers. Docker just made it user-friendly and created an ecosystem around it. This isn't really a new concept (greetings to the freeBSD people). all do a pretty good job nowadays.ĭocker (on Linux) is different because it uses container-virtualization. I'm afraid I haven't been able to get my point across.ĭocker for Mac (after some optimization) is probably usable.
0 kommentar(er)
