5 ms·

> 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

> 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.
- towawy 5y ago
  Git credentials are not a huge deal if you use ssh keys. You can forward your local ssh identity to the VM / remote host by adding these options to the Host entry in you ssh config: IdentitiesOnly yes AddKeysToAgent yes ForwardAgent yes
treesknees 5y ago
What you described (running a Linux VM and forwarding ports) is exactly what Docker Desktop already does for you without having to maintain packages, configure ssh keys, deal with networking, etc. The thing I don't like about your method is having all my code checked out on the VM. As soon as I want to start using anything other than VSCode to manage it, I'm now hopping through layers. I'm also restricted to the VM's filesystem/size limits, and individual changes to files are not backed up by Time Machine, only the entire VM disk image. And only because you mentioned corporate how-to guides, Docker Desktop requires a paid license for commercial use. I think your method is a perfectly valid way to work around needing a license, but the license comes with commercial support and some other features some companies may find useful.
kayodelycaon 5y ago
Well, I use SublimeText, SublimeMerge, Finder, and Preview. All of which you can pry from my cold, dead paws. :) Before anyone mentions sshfs, macFUSE+sshf is literally the only thing I’ve seen that can fuck up the entire disk subsystem’s ability to mount and unmount anything until you reboot.
cmckn 5y ago
Sorry, what do you think Docker for Mac does? It’s exactly what you’ve described, with more ease of use and features like volume mounts from your Mac into the VM (which this post talks about optimizing). Your approach requires lots more fiddling with little to no benefit.
- nicoburns 5y ago
  Prior to these improvements there was a huge benefit: much better filesystem performance. This blog post says they increased performance by up to 98%, which tells you just how slow it was before (slow enough that I personally chose to forgo Docker altogether).
  - cmckn 5y ago
    The filesystem performance within the VM is the same; the issue only arises/arose when mounting from macOS into the VM. To each their own, of course; but there’s no real perf difference between rolling your own and using Docker for Mac.
    - TimTheTinker 5y ago
      If you're running 10+ docker containers like my company does, running all of them inside a single VM will use significantly less memory than spinning up multiple VMs like Docker Desktop does.
      - nicoburns 5y ago
        > the issue only arises/arose when mounting from macOS into the VM Isn't that the usual case: you have your code on your local filesystem and then run it using an interpreter in the Docker VM?
        cmckn 5y ago
        Nope. You can certainly do that; but “the right way” is to add your sources and compile them (as necessary) during the image build; and then treat the container as an “application”, not as an “environment”. This is how any sane production setup works, and you get a lot of benefits using it during development (such as reproducible builds and only one pre-req for a dev setup: Docker). If you’re just volume-mounting your code into the container, all Docker is providing is a disposable runtime environment. Which is handy for some things, but the general idea is to end up with a fully containerized program that you can tag, push to a registry; and pull to your production environment.
FooBarWidget 5y ago
Docker Desktop is a VM because it allows you to run Linux containers. If it weren't a VM then you can onlu use it to run macOS containers (which don't exist thanks to the lack of necessary kernel primitives) or Windows containers.
johnstonnorth 5y ago
This is exactly how we configure our development environments after trying all sorts of different combinations. We find it significantly faster to do macOS + Linux VM + Docker than macOS + Docker for Mac. We're using the Remote Containers plugin in VSCode. I just tried Docker for Mac 4.6.0 and it is still slower than the above setup - though I think this might be down to bind vs. volume mounts.

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.
towawy 5y ago
Git credentials are not a huge deal if you use ssh keys. You can forward your local ssh identity to the VM / remote host by adding these options to the Host entry in you ssh config: IdentitiesOnly yes AddKeysToAgent yes ForwardAgent yes

treesknees 5y ago

What you described (running a Linux VM and forwarding ports) is exactly what Docker Desktop already does for you without having to maintain packages, configure ssh keys, deal with networking, etc. The thing I don't like about your method is having all my code checked out on the VM. As soon as I want to start using anything other than VSCode to manage it, I'm now hopping through layers. I'm also restricted to the VM's filesystem/size limits, and individual changes to files are not backed up by Time Machine, only the entire VM disk image. And only because you mentioned corporate how-to guides, Docker Desktop requires a paid license for commercial use. I think your method is a perfectly valid way to work around needing a license, but the license comes with commercial support and some other features some companies may find useful.

kayodelycaon 5y ago

Well, I use SublimeText, SublimeMerge, Finder, and Preview. All of which you can pry from my cold, dead paws. :) Before anyone mentions sshfs, macFUSE+sshf is literally the only thing I’ve seen that can fuck up the entire disk subsystem’s ability to mount and unmount anything until you reboot.

cmckn 5y ago

Sorry, what do you think Docker for Mac does? It’s exactly what you’ve described, with more ease of use and features like volume mounts from your Mac into the VM (which this post talks about optimizing). Your approach requires lots more fiddling with little to no benefit.

nicoburns 5y ago
Prior to these improvements there was a huge benefit: much better filesystem performance. This blog post says they increased performance by up to 98%, which tells you just how slow it was before (slow enough that I personally chose to forgo Docker altogether).
- cmckn 5y ago
  The filesystem performance within the VM is the same; the issue only arises/arose when mounting from macOS into the VM. To each their own, of course; but there’s no real perf difference between rolling your own and using Docker for Mac.
  - TimTheTinker 5y ago
    If you're running 10+ docker containers like my company does, running all of them inside a single VM will use significantly less memory than spinning up multiple VMs like Docker Desktop does.
    - nicoburns 5y ago
      > the issue only arises/arose when mounting from macOS into the VM Isn't that the usual case: you have your code on your local filesystem and then run it using an interpreter in the Docker VM?
      - cmckn 5y ago
        Nope. You can certainly do that; but “the right way” is to add your sources and compile them (as necessary) during the image build; and then treat the container as an “application”, not as an “environment”. This is how any sane production setup works, and you get a lot of benefits using it during development (such as reproducible builds and only one pre-req for a dev setup: Docker). If you’re just volume-mounting your code into the container, all Docker is providing is a disposable runtime environment. Which is handy for some things, but the general idea is to end up with a fully containerized program that you can tag, push to a registry; and pull to your production environment.

FooBarWidget 5y ago

Docker Desktop is a VM because it allows you to run Linux containers. If it weren't a VM then you can onlu use it to run macOS containers (which don't exist thanks to the lack of necessary kernel primitives) or Windows containers.

johnstonnorth 5y ago

This is exactly how we configure our development environments after trying all sorts of different combinations. We find it significantly faster to do macOS + Linux VM + Docker than macOS + Docker for Mac. We're using the Remote Containers plugin in VSCode. I just tried Docker for Mac 4.6.0 and it is still slower than the above setup - though I think this might be down to bind vs. volume mounts.