9 ms·

Lots of chatter here about alternatives that all seem to miss the point that the alternatives suffer from the same filesystem performance issues that this relea

Lots of chatter here about alternatives that all seem to miss the point that the alternatives suffer from the same filesystem performance issues that this release claims to improve. Might not be an issue for you but if you've ever had to work with a volume mount with a ton of small files (like php or node dependencies) then this could be a real life saver.

flurie 5y ago
Both Kata Containers and UTM support virtio-fs, so this is not strictly true. The former can be used as a stand-in replacement for the runtime used by docker desktop[1]. With the latter, one could use a UTM-backed guest as a docker runtime in macOS[2] or run docker directly on the guest[3]. [1] https://github.com/kata-containers/documentation/blob/master/how-to/how-to-use-virtio-fs-with-kata.md https://github.com/kata-containers/documentation/blob/master... [2] https://www.codeluge.com/post/setting-up-docker-on-macos-m1-arm64-to-use-debian-10.4-docker-engine/ https://www.codeluge.com/post/setting-up-docker-on-macos-m1-... [3] https://www.lifeintech.com/2021/11/03/docker-performance-on-m1/ https://www.lifeintech.com/2021/11/03/docker-performance-on-...
- deleted 5y ago
  [deleted]
cutler 5y ago
Is this an issue with dynamic languages in general? Are Java/Kotlin and Golang, for example, not affected?
- rad_gruchalski 5y ago
  It depends what you need to do. If you build a golang binary in a container and run go mod tidy, you get hit by it. If you build a java app with, say, maven, you will pull deps into a volume mount and you get hit by it. Of course, you can mount a host dir to avoid the problem to a certain extent.
- shagie 5y ago
  When using Java, with say, jib and skaffold, when a change is detected the image is rebuilt with some fairly smart cacheing being done to minimize the build time. In more interesting setups, the class files aren't in the image but rather mapped in - much the same way one would with dynamic and then a hot reload - https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/reference/html/howto-hotswapping.html#howto-reload-java-classes-without-restarting https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/refere... > Spring Loaded goes a little further in that it can reload class definitions with changes in the method signatures. With some customization it can force an ApplicationContext to refresh itself (but there is no general mechanism to ensure that would be safe for a running application anyway, so it would only ever be a development time trick probably). And this way, the container can remain the same with the class files being changed underneath it. https://github.com/spring-projects/spring-loaded https://github.com/spring-projects/spring-loaded
TimTheTinker 5y ago
> the alternatives suffer from the same filesystem performance issues that this release claims to improve Hehe, not if you run Docker in a Linux VM, edit your code using the SSH VSCode plugin, and port forward any services from the VM to your Mac. After doing this for over a year, I don't know why anyone still uses Docker for Mac, other than corporate how-to guides that still start with "1. Download Docker for Mac", or feeling unfamiliar with Linux. Docker was originally created as a chroot'ed process container with abstracted networking, nothing more -- and certainly not a full VM. Why not run it as it was intended to be run? Edit: Am I incorrect? Or is something else wrong?
- BHSPitMonkey 5y ago
  Ease of use. Some people like the conveniences in Desktop and the stuff you described has to be set up and maintained. Lots of people out there just need to start writing application code and get it running in the dev environment they've been given. And employers will happily pay for licenses.
- rtpg 5y ago
  So in that model, you have to ship your codebase into the VM and then work on it from there. If you're git-managed now you're having to either ship your git credentials into that VM to push stuff up, or you're like having to figure out how to ship the codebase back to the host when you need to. The whole "magic" is that you work on the files on your host machine! I think VSCode is doing god's work (along with other tools) to make remote editing a nicer experience, but well... I use Docker on Linux and just edit files locally. It's nice!
  - allendoerfer 5y ago
    At this point you can just use Vagrant again and skip using Docker.
    - FooBarWidget 5y ago
      Vagrant also has filesystem performance issues. VirtualBox host directory sharing is awfully — unusably — slow, even more so than the old Docker Desktop mount. Vagrant takes a lot more disk space and RAM. VirtualBox isn't as efficient as the macOS hypervisor. And every Vagrant project is a separate VM, instead sharing the same VM for multiple projects.

flurie 5y ago

Both Kata Containers and UTM support virtio-fs, so this is not strictly true. The former can be used as a stand-in replacement for the runtime used by docker desktop[1]. With the latter, one could use a UTM-backed guest as a docker runtime in macOS[2] or run docker directly on the guest[3]. [1] https://github.com/kata-containers/documentation/blob/master/how-to/how-to-use-virtio-fs-with-kata.md https://github.com/kata-containers/documentation/blob/master... [2] https://www.codeluge.com/post/setting-up-docker-on-macos-m1-arm64-to-use-debian-10.4-docker-engine/ https://www.codeluge.com/post/setting-up-docker-on-macos-m1-... [3] https://www.lifeintech.com/2021/11/03/docker-performance-on-m1/ https://www.lifeintech.com/2021/11/03/docker-performance-on-...

deleted 5y ago
[deleted]

cutler 5y ago

Is this an issue with dynamic languages in general? Are Java/Kotlin and Golang, for example, not affected?

rad_gruchalski 5y ago
It depends what you need to do. If you build a golang binary in a container and run go mod tidy, you get hit by it. If you build a java app with, say, maven, you will pull deps into a volume mount and you get hit by it. Of course, you can mount a host dir to avoid the problem to a certain extent.
shagie 5y ago
When using Java, with say, jib and skaffold, when a change is detected the image is rebuilt with some fairly smart cacheing being done to minimize the build time. In more interesting setups, the class files aren't in the image but rather mapped in - much the same way one would with dynamic and then a hot reload - https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/reference/html/howto-hotswapping.html#howto-reload-java-classes-without-restarting https://docs.spring.io/spring-boot/docs/1.3.8.RELEASE/refere... > Spring Loaded goes a little further in that it can reload class definitions with changes in the method signatures. With some customization it can force an ApplicationContext to refresh itself (but there is no general mechanism to ensure that would be safe for a running application anyway, so it would only ever be a development time trick probably). And this way, the container can remain the same with the class files being changed underneath it. https://github.com/spring-projects/spring-loaded https://github.com/spring-projects/spring-loaded

TimTheTinker 5y ago

> the alternatives suffer from the same filesystem performance issues that this release claims to improve Hehe, not if you run Docker in a Linux VM, edit your code using the SSH VSCode plugin, and port forward any services from the VM to your Mac. After doing this for over a year, I don't know why anyone still uses Docker for Mac, other than corporate how-to guides that still start with "1. Download Docker for Mac", or feeling unfamiliar with Linux. Docker was originally created as a chroot'ed process container with abstracted networking, nothing more -- and certainly not a full VM. Why not run it as it was intended to be run? Edit: Am I incorrect? Or is something else wrong?

BHSPitMonkey 5y ago
Ease of use. Some people like the conveniences in Desktop and the stuff you described has to be set up and maintained. Lots of people out there just need to start writing application code and get it running in the dev environment they've been given. And employers will happily pay for licenses.
rtpg 5y ago
So in that model, you have to ship your codebase into the VM and then work on it from there. If you're git-managed now you're having to either ship your git credentials into that VM to push stuff up, or you're like having to figure out how to ship the codebase back to the host when you need to. The whole "magic" is that you work on the files on your host machine! I think VSCode is doing god's work (along with other tools) to make remote editing a nicer experience, but well... I use Docker on Linux and just edit files locally. It's nice!
- allendoerfer 5y ago
  At this point you can just use Vagrant again and skip using Docker.
  - FooBarWidget 5y ago
    Vagrant also has filesystem performance issues. VirtualBox host directory sharing is awfully — unusably — slow, even more so than the old Docker Desktop mount. Vagrant takes a lot more disk space and RAM. VirtualBox isn't as efficient as the macOS hypervisor. And every Vagrant project is a separate VM, instead sharing the same VM for multiple projects.