#4: Support for NFS Volume sharing under Swarm as well as Kubernetes. With Docker for Mac 18.03 release, NFS Volume sharing support for both Swarm & Kubernetes was introduced. Then, the container reads and write to the volume just like a normal directory. One of the most useful types of volumes in Kubernetes is nfs. NFS stands for Network File System – it's a shared filesystem that can be accessed over the network. The NFS must already exist – Kubernetes doesn't run the NFS, pods in just access it.
We heavily use Docker for Mac for the internal development of our products. It allows us to closely replicate the internal, automated testing, user acceptance testing and production platforms.
There is just one problem, that I'm sure you've also found.. The performance of the file system when using volume mounts.
OSX Catalina. This article has been recently updated, please see the amendments at the bottom.
Before Docker, came Vagrant, before Vagrant, came MAMP stacks. As developers we have been through a few different development environments in our time. Moving from Vagrant to Docker was a blessing, although one thing that hit us hard was the performance of Docker on Mac, specifically the file system performance.
When developing under a MacOS you would typically mount your local project folder volume to the /app
directory within your container. If you made a change in your IDE, it would be replicated into the container (somehow), and you could then serve the updated content through your application.
This is fairly simple to set-up, i.e. you could start your docker container like this:
or if you are using docker-compose
(tip: you should), then you might have an block of config in your docker-compose.yml
file looking like this:
By default this will create a consistent
link between the host and docker file system, this is extremely slow.
i.e. if you perform anything with extensive file I/O in either the docker container or the host file system, such as $ bin/console cache:clear
, you can expect a long wait.
In Docker for Mac 17.04 CE, the option to use a delegated
link became available, this is pretty much the same speed as consistent
in terms of transferring information between host and container, but with one important difference - it did not block the container when performing I/O inside the container. This meant that the host file system was the last to know about the changes, but this was a good thing (generally) as it meant your application would run fairly smoothly inside the container.
There is much more about the subject here:https://docs.docker.com/docker-for-mac/osxfs-caching/
However the long and short of it is you can add a :delegated
flag to the volume mount to enable this, such as:
or in your docker-compose.yml
file:
Look why this is such a problem
I should point out these were tested very unscientifically, on a Mac Book Pro 2018 with a typical Symfony project and your mileage may vary.
Running on host file system
Running in the docker container in consistent
(default) mode
Running in the docker container in delegated
mode
Enter NFS
NFS is a popular mechanism that volumes were mounted when using Vagrant and it's performance has been pretty consistent in the past, it's been a stretch to bring it to docker as there have been a number of challenges to overcome, however if you create a volume in your docker-compose.yml
config file to point to NFS such as:
.. then modify your volume mount in docker-compose.yml
as such:
.. then run a nice little script I found from https://gist.github.com/seanhandleyGitHub Link
It will set up a NFS link between your $PWD
(current working directory) and the containers /app
directory, and finally when you run a cache:clear
again:
Running in the docker container in NFS
mode
Verdict
While I hope sincerely you have already been using delegated
mode before finding this labs post, NFS is much nicer as it removes a lot of the CPU overhead between host and container. Now, I/O peformance is not the only element of the overall app performance, but I'll take this performance improvement over delegated
anyday.
Go forth and NFS things!
OSX Catalina had changed the volume for various paths, including your user folder, this is a simple fix to move the NFS path to the new location. The above scripts/config must be changed so that
LINE='/Users -alldirs -mapall=$U:$G localhost'
changes to
LINE='/System/Volumes/Data -alldirs -mapall=$U:$G localhost'
and also
device: ':$PWD'
changes to
device: ':/System/Volumes/Data/${PWD}'
Be sure to re-run the script and also remove/recreate any Docker volumes, you can list your Docker volumes with:
docker volume ls
and then delete the relevant volumes created in a past Docker session with:
docker rm <YOUR_VOLUME_NAME>
Credit goes to:https://www.firehydrant.io/blog/nfs-with-docker-on-macos-catalina/
#4: Support for NFS Volume sharing under Swarm as well as Kubernetes. With Docker for Mac 18.03 release, NFS Volume sharing support for both Swarm & Kubernetes was introduced. Then, the container reads and write to the volume just like a normal directory. One of the most useful types of volumes in Kubernetes is nfs. NFS stands for Network File System – it's a shared filesystem that can be accessed over the network. The NFS must already exist – Kubernetes doesn't run the NFS, pods in just access it.
We heavily use Docker for Mac for the internal development of our products. It allows us to closely replicate the internal, automated testing, user acceptance testing and production platforms.
There is just one problem, that I'm sure you've also found.. The performance of the file system when using volume mounts.
OSX Catalina. This article has been recently updated, please see the amendments at the bottom.
Before Docker, came Vagrant, before Vagrant, came MAMP stacks. As developers we have been through a few different development environments in our time. Moving from Vagrant to Docker was a blessing, although one thing that hit us hard was the performance of Docker on Mac, specifically the file system performance.
When developing under a MacOS you would typically mount your local project folder volume to the /app
directory within your container. If you made a change in your IDE, it would be replicated into the container (somehow), and you could then serve the updated content through your application.
This is fairly simple to set-up, i.e. you could start your docker container like this:
or if you are using docker-compose
(tip: you should), then you might have an block of config in your docker-compose.yml
file looking like this:
By default this will create a consistent
link between the host and docker file system, this is extremely slow.
i.e. if you perform anything with extensive file I/O in either the docker container or the host file system, such as $ bin/console cache:clear
, you can expect a long wait.
In Docker for Mac 17.04 CE, the option to use a delegated
link became available, this is pretty much the same speed as consistent
in terms of transferring information between host and container, but with one important difference - it did not block the container when performing I/O inside the container. This meant that the host file system was the last to know about the changes, but this was a good thing (generally) as it meant your application would run fairly smoothly inside the container.
There is much more about the subject here:https://docs.docker.com/docker-for-mac/osxfs-caching/
However the long and short of it is you can add a :delegated
flag to the volume mount to enable this, such as:
or in your docker-compose.yml
file:
Look why this is such a problem
I should point out these were tested very unscientifically, on a Mac Book Pro 2018 with a typical Symfony project and your mileage may vary.
Running on host file system
Running in the docker container in consistent
(default) mode
Running in the docker container in delegated
mode
Enter NFS
NFS is a popular mechanism that volumes were mounted when using Vagrant and it's performance has been pretty consistent in the past, it's been a stretch to bring it to docker as there have been a number of challenges to overcome, however if you create a volume in your docker-compose.yml
config file to point to NFS such as:
.. then modify your volume mount in docker-compose.yml
as such:
.. then run a nice little script I found from https://gist.github.com/seanhandleyGitHub Link
It will set up a NFS link between your $PWD
(current working directory) and the containers /app
directory, and finally when you run a cache:clear
again:
Running in the docker container in NFS
mode
Verdict
While I hope sincerely you have already been using delegated
mode before finding this labs post, NFS is much nicer as it removes a lot of the CPU overhead between host and container. Now, I/O peformance is not the only element of the overall app performance, but I'll take this performance improvement over delegated
anyday.
Go forth and NFS things!
OSX Catalina had changed the volume for various paths, including your user folder, this is a simple fix to move the NFS path to the new location. The above scripts/config must be changed so that
LINE='/Users -alldirs -mapall=$U:$G localhost'
changes to
LINE='/System/Volumes/Data -alldirs -mapall=$U:$G localhost'
and also
device: ':$PWD'
changes to
device: ':/System/Volumes/Data/${PWD}'
Be sure to re-run the script and also remove/recreate any Docker volumes, you can list your Docker volumes with:
docker volume ls
and then delete the relevant volumes created in a past Docker session with:
docker rm <YOUR_VOLUME_NAME>
Credit goes to:https://www.firehydrant.io/blog/nfs-with-docker-on-macos-catalina/