What is dinghy or how to speed up docker

Once I looked at Habr to see how developers use dinghy and generally speed up the work of docker on a poppy. To my surprise, at the request of the dinghy, I found exactly zero articles. It would be dishonest not to mention that the same query returned 4 comments. On the other hand, this fact did not change the picture as a whole.

It turned out that dingy very successfully fit into my technological stack, and also helped me solve some problems, the most important of which:

• Osx docker performance
• Running multiple containers that run on port 80

Under the cut, a more detailed description of the above problems, as well as methods for solving them.

Problem 1: low performance docker on a poppy

Since the docker is written on top of the Linux kernel, for other OSs, you must use virtual machines. This, in turn, negatively affects the performance of your work environment. Indeed, now, in order for your changes to fall into the container, you need to take additional steps.

Docker toolbox

If you have a small project, then you may be satisfied with the docker toolbox . Included with it is a boot that docker as a virtual machine. In this case, you also need to have a virtual box, where this virtual machine will be launched.

In my case, the toolbox turned out to be quite slow. This tool is well suited for launching “static” containers. When you need to intensively develop an application, you need to create mounted volumes (have I been trying to find the Russian equivalent for a long time, have any ideas?) Of your working directory, that is, the directory with the code of your application. And here the problems begin. Finding out that the toolbox uses neither NFS nor rsync, I began to look for other solutions.

Advantages:
- easy to install and configure
Disadvantages:
- slow when developing large projects

Docker for mac

Unlike the toolbox, the docker for the poppy does not use virtual boxing. It uses HyperKit as a virtualization layer. Feature - you can use only one virtual machine. However, if necessary, you can run the docker for the poppy in parallel with the toolbox.

Unfortunately, the docker for the poppy was even slower. I did not find any obvious (and non-obvious) way to speed up this application.

Advantages:
- even easier to install and configure
Minuses:
- terribly slow

docker-osx-dev

A good solution to speed up work on local machines when working with the toolbox. Docker-osx-dev uses rsync, which greatly speeds up the sending of changes to the container. The disadvantage of this solution is the "bloated" container size, since the files themselves are copied to the container.

Therefore, using this approach, you need to take care of a virtual machine with an increased amount of memory. Caches, builds, logs - everything will increase the amount of memory.
Another drawback I would call a process hanging in the terminal. Background mode is not supported by default.

Advantages:
- significantly speeds up the transfer of files to the container
Disadvantages:
- hanging process
- inflates the size of the container

Dinghy

Dinghy is an add-on for docker-machine, which includes NFS and proxy (which we will talk about a bit later, now we are interested in the performance problem). And as far as I know, nothing faster than NFS (in this context) has yet been invented.

Now, instead of creating and using a default or boot that docker virtual machine, we create a ding machine. By default, NFS will already be included in it. If you do not want to use a proxy, you can turn it off in the ding settings by setting the corresponding flag to true:

cat ~/.dinghy/preferences.yml
:preferences:
  :proxy_disabled: false
  :fsevents_disabled: false
  :create:
    provider: virtualbox
    disk: 30000

Disadvantage: since you explicitly import environment variables (for example export DOCKER_MACHINE_NAME=dinghy, etc.), using conventional docker machines in parallel with dinges can be a lot of trouble.

Advantages:
- speed of operation
- no additional processes
Disadvantages:
- additional configs (docker-compose.yml) may be required
- conflict DOCKER_MACHINE_NAME with a regular docker machine

Problem 2: applications on port 80

After we have accelerated the work of our working environment, another problem may arise: the need to have 2 or more containers running on port 80. What a problem, just pick up and use another port, the attentive reader can say. Indeed, often this solution is enough. But sometimes, the configuration of projects is quite complicated and confusing. In these cases, you must have exactly 80 ports.

Well, good news, because proxies are included in the dingies by default. Along with the launch of the dingi virtual machine, you can notice the always running container:

169b86af85da        codekitchen/dinghy-http-proxy:2.5   "/app/docker-entry..."    4 hours ago         Up 4 hours          0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp, 19322/tcp, 0.0.0.0:19322->19322/udp   dinghy_http_proxy

This container listens on port 80 and accepts all requests for itself. Inside this container there is a nginx server that automatically creates virtual servers based on your docker-compose file. All that you need to specify hostnamein this file. Further, when accessing this host, the dingi will find the desired record and redirect to the desired container. Profit

Conclusion

Initially, I planned to give more technical details, examples of configurations and scripts, but as I wrote this article I realized that I had gone a little different way. Besides, it would have turned out too long, probably. At the same time, I answered the questions posed and I really hope that this article turned out to be useful and / or interesting to you.

If you have an interest in technical details, leave comments, I will try to answer everything.

Thanks for attention.

Update
as of September 18 : after a discussion in the comments with umputun, I removed the docker for the Mac from the flaws:
- there is only one virtual machine, we configure it by the application itself