3 ms·

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 V

by 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.
        nicoburns 5y ago
        > This is how any sane production setup works Well sure, but almost nobody is running production workloads on macOS. Regarding development workflows. Won't rebuilding the image every time you make changes be slow? I can get ~1 second reload times for node.js services outside of Docker. And I believe inside Docker too on linux.
        deleted 5y ago
        [deleted]
        victorhooi 5y ago
        It's not necessarily because people are serving their production workloads from macOS systems. However, they develop on them - and it makes sense to make those environments (and the processes) similar to your actual production setup. So if your applications code gets compiled, and deployed as part of the Docker image - then ideally when you spin up a dev environment, it should follow the same process.
    - cmckn 5y ago
      That isn’t how Docker Desktop works, there’s one VM.

by cmckn 5y ago

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.
      - nicoburns 5y ago
        > This is how any sane production setup works Well sure, but almost nobody is running production workloads on macOS. Regarding development workflows. Won't rebuilding the image every time you make changes be slow? I can get ~1 second reload times for node.js services outside of Docker. And I believe inside Docker too on linux.
        deleted 5y ago
        [deleted]
        victorhooi 5y ago
        It's not necessarily because people are serving their production workloads from macOS systems. However, they develop on them - and it makes sense to make those environments (and the processes) similar to your actual production setup. So if your applications code gets compiled, and deployed as part of the Docker image - then ideally when you spin up a dev environment, it should follow the same process.
  - cmckn 5y ago
    That isn’t how Docker Desktop works, there’s one VM.