What is dinghy or how to speed up docker

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

So it turned out that the dings very well fit into my technological stack, and also helped me solve some problems, the most important of which are:
')

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

Under the cat a more detailed description of the above problems, as well as ways to solve them.

Problem 1: low docker performance on poppy

Since the docker is written on top of the Linux kernel, it is necessary to use virtual machines for other OSes. This, in turn, adversely affects the productivity 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 might be satisfied with the docker toolbox . Included with it is boot docker as a virtual machine. In this case, you also need to have a virtual box, where this virtual machine will be running.

In my case, the toolbox was quite slow. This tool is well suited for running “static” containers. When it is necessary to intensively develop an application, you need to create mounted volumes (I’ve been trying to find the Russian equivalent for a long time, have 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 does not use either NFS or rsync, I began to look for other solutions.

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

Docker for mac

Unlike the toolbox, the docker for poppy does not use virtual boxing. As a layer of virtualization, he uses HyperKit. 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 poppy was even slower. I did not find any obvious (and non-obvious) way how to speed up this application.

Benefits:
- even easier to install and configure
Disadvantages:
- terribly slow

docker-osx-dev

A good solution for speeding up work on local machines when working with toolbox. Docker-osx-dev uses rsync, which significantly speeds up sending changes to the container. The disadvantage of this solution is the “bloated” size of the container, since the files themselves are copied into 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 the process hanging in the terminal. Background mode is not supported by default.

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

Dinghy

Dinghy is a add-on to the docker-machine (docker-machine), which includes NFS and proxy (which we will talk about 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 the default or boot docker of the virtual machine, we create the dinge machine. By default, it will already have NFS enabled. If you do not want to use a proxy, then you can disable it in the dinga 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 dings can be a lot of trouble.

Benefits:
- work speed
- no additional processes
Disadvantages:
- may need additional configs (docker-compose.yml)
- DOCKER_MACHINE_NAME conflict 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 take and port another port,” a careful reader might say. Indeed, often this solution is enough. But sometimes, the configuration of projects is quite complicated and confusing. In these cases, it is necessary to have exactly 80 ports.

Well, good news, because a proxy is included in the dinghy 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 themselves. Inside this container there is a nginx server that automatically creates virtual servers based on your docker-compose file. All you need to do is specify the hostname in this file. Further, when accessing this host, the ding will find the desired entry and redirect it to the desired container. Profit

Conclusion

Initially, I planned to give more technical details, examples of configurations and scripts, but in the course of writing this article, I realized that I had gone a little differently. In addition, it would have turned out too long, probably. At the same time, I answered the questions posed and very much hope that this article turned out to be useful and / or interesting for you.

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

Thanks for attention.

Update from 18.09:
after discussion in the comments with umputun, removed from the flaws of the docker for the poppy:
- only one virtual machine, customizable by the application itself