[ITEM]
13.02.2020

Docker For Mac Kubernetes Nfs Volume

49

#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'

Boris fx boris continuum complete avx dv v1.0 for mac

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/

[/ITEM]
[/MAIN]
13.02.2020

Docker For Mac Kubernetes Nfs Volume

12

#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'

Boris fx boris continuum complete avx dv v1.0 for mac

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/