Docker mac os медленно

Докер в MacOs очень медленный

У меня есть этот docker-compose.yml:

Когда я запускаю на нем свой новый проект в Symfony 4, он работает очень медленно. 🙁

У меня есть новые MacOs и Docker Desktop. В настоящее время я изучаю фреймворк Symfony и Laravel, но это очень медленно для Docker. Это даже не работает над этим.

Как я могу это починить?

На самом деле, для запуска Docker необходимо простое Linux kernel . К сожалению, Mac OS и Windows не могут обеспечить это. Поэтому в Mac OS есть клиент для запуска Docker. В дополнение к этому, существует уровень абстракции между ядром Mac OS и приложениями (контейнеры Docker), а файловые системы не одинаковы. Из-за этого Docker работает на Mac OS медленно. Вы не можете запустить Docker в Mac OS, как в Linux.

Если мне нужно привести несколько примеров о реальных случаях использования. У меня такая же машина. Итак, я использую Symfony 4 на Docker v18 на Mac OS Mojave. Это мое общее время выполнения Symfony на Docker. (Очевидно, это зависит от вашего внешнего интерфейса и запросов к базе данных, но я пытаюсь объяснить вам основную логику.)

первый раз рендеринг 12000 мс с кешем Symfony: 344 мс с кешем Docker (: свойство cached для Docker для томов): 195 мс

Пока я использую Symfony без Docker, вот мое общее время выполнения.

без докера, с кешем Symfony: 82 мс

Принимая во внимание, что мы могли бы сделать некоторые улучшения, чтобы улучшить рабочее пространство. Например, вы можете использовать такие объемы, как это,

Источник

Что такое dinghy или как ускорить docker

Однажды я заглянул на Хабр, чтобы посмотреть как разработчики используют динги (dinghy) и вообще ускоряют работу докера на маке. На моё удивление по запросу динги я нашёл ровно ноль статей. Было бы нечестно не упомянуть, что тот же запрос вывел 4 комментария. С другой стороны этот факт не изменил картины в целом.

Так вышло, что динги очень удачно вписался в мой технологический стек, а так же помог мне решить некоторые проблемы, самые важные из которых:

• Производительность докера на osx
• Запуск нескольких контейнеров, которые работают на порте 80

Под катом более подробное описание вышеперечисленных проблем, а так же способы их решения.

Проблема 1: низкая производительность докера на маке

Поскольку докер написан поверх линуксовсого ядра, для других ОС необходимо использовать виртуальные машины. Это, в свою очередь, негативно сказывается на производительности вашего рабочего окружения. Действительно, теперь, чтобы ваши изменения попали в контейнер вам необходимо предпринять дополнительные шаги.

Docker toolbox

Если у вас небольшой проект, то возможно вас устроит докер тулбокс. В комплекте с ним находится бут ту докер в качестве виртуальной машины. В этом случае, вам так же необходимо иметь виртуал бокс, где данная виртуальная машина и будет запущена.

В моём случае тулбокс оказался достаточно медленным. Данный инструмент хорошо подходит для запуска «статических» контейнеров. Когда же нужно интенсивно разрабатывать приложение, необходимо создавать mounted volumes (уже давно пытаюсь найти русский эквивалент, есть идеи?) вашей рабочей директории, то есть директории с кодом вашего приложения. И вот тут начинаются проблемы. Выяснив, что тулбокс не использует ни NFS ни rsync, я стал искать другие решения.

Преимущества:
— легко устанавливается и настраивается
Недостатки:
— медленный при разработке больших проектов

Docker for mac

В отличие от тулбокса, докер для мака не использует виртуал бокс. В качестве слоя виртуализации он использует HyperKit. Особенность — вы можете использовать только одну виртуальную машину. Впрочем, если необходимо, вы можете запустить докер для мака параллельно с тулбоксом.

К сожалению, докер для мака оказался ещё медленней. Никакого очевидного (и неочевидного) способа как ускорить сие приложение я не нашёл.

Преимущества:
— ещё легче устанавливается и настраивается
Недостатки:
— ужасно медленный

docker-osx-dev

Хорошее решение для ускорения работы на локальных машинах при работе с тулбоксом. Docker-osx-dev использует rsync, что значительно ускоряет отправку изменений в контейнер. Недостатком данного решения можно назвать «раздутый» размер контейнера, поскольку сами файлы копируются в контейнер.

Поэтому, используя данный подход, необходимо позаботиться о виртуальной машине с увеличенным объёмом памяти. Кэши, билды, логи — всё будет увеличивать объём памяти.
Другим недостатком я бы назвал процесс, висящий в терминале. Бэкграунд режим по умолчанию не поддерживается.

Преимущества:
— значительно ускоряет перенос файлов в контейнер
Недостатки:
— висящий процесс
— раздувает размер контейнера

Dinghy

Dinghy — это надстройка над докер машиной (docker-machine), которая включает в себя NFS и proxy (о котором мы поговорим чуть позже, cейчас нас интересует проблема производительности). А насколько мне известно, ничего быстрее NFS (в данном контексте) ещё не придумали.

Теперь, вместо создания и использования дефолтной или бут ту докер виртуальной машины, мы создаём динги машину. По умолчанию в ней уже будет включен NFS. Если вы не хотите использовать прокси, то можно его отключить в настройках динги, поставив соответствующий флаг в true:

Недостаток: поскольку вы явным образом импортируете переменные окружения (например export DOCKER_MACHINE_NAME=dinghy и пр.), то использование обычных докер машин параллельно с динги может принести много хлопот.

Преимущества:
— скорость работы
— никаких дополнительных процессов
Недостатки:
— возможно потребуются дополнительные конфиги (docker-compose.yml)
— конфликт DOCKER_MACHINE_NAME с обычной докер машиной

Проблема 2: приложения на 80 порту

После того, как мы ускорили работу своей рабочей среды, может появиться ещё одна проблема: необходимость иметь 2 и более контейнеров, работающие на 80 порту. Что за проблема, просто взять и заэкспойзить другой порт, — может сказать внимательный читатель. Действительно, зачастую данного решения бывает достаточно. Но иногда, конфигурация проектов достаточно сложна и запутана. В этих случаях необходимо иметь именно 80 порты.

Что же, хорошие новости, ведь в динги по умолчания включен прокси. Вместе с запуском виртуальной машины динги, вы можете заметить всегда запущенный контейнер:

Этот контейнер слушает на 80 порту и принимает все запросы на себя. Внутри этого контейнера имеется nginx сервер, который автоматически создаёт виртуальные сервера исходя из вашего docker-compose файла. Всё, что вам нужно, указать hostname в этом файле. Далее, при обращении на данный хост, динги найдёт нужную запись и перенаправит на нужный контейнер. Профит.

Заключение

Изначально я планировал привести больше технических подробностей, примеры конфигураций и скриптов, но по ходу написания статьи понял, что ушёл немного в другое русло. К тому же она получилось бы слишком длинной, наверное. При этом я ответил на поставленные вопросы и очень надеюсь, что данная статья оказалась вам полезной и/или интересной.

Если у вас возник интерес по техническим деталям, оставляйте комментарии, постараюсь на всё ответить.

Спасибо за внимание.

Обновление от 18.09:
после обсуждения в комментариях с umputun удалил из недостатков докера для мака:
— только одна виртуальная машина, настраиваемся самим приложением

Источник

Docker in MacOs is very slow

I have this docker-compose.yml:

When I run my newest project in symfony 4 on it, it works very slowly. 🙁

I have new MacOs and Docker Desktop. I’m currently learning the Symfony and Laravel framework, but this is very slow for Docker. It is not even working on it.

How can I repair it?

6 Answers 6

As a matter of fact, Docker needs a plain Linux kernel to run. Unfortunately, Mac OS and Windows cannot provide this. Therefore, there is a client on Mac OS to run Docker. In addition to this, there is an abstraction layer between Mac OS kernel and applications (Docker containers) and the filesystems are not the same. Because of that, Docker runs on Mac OS slowly. You are not able to run the Docker on Mac OS like on Linux.

If I need to give some instances about real use-cases. I have the same machine. So, I use Symfony 4 on Docker v18 on Mac OS Mojave. This is my Symfony total execution time on Docker. (Obviously, it depends on your frontend and database queries but I try to enlighten you for main logic.)

• first time rendering 12000 ms
• with Symfony cache: 344 ms
• with Docker cache(:cached property of Docker for volumes): 195 ms

As long as I use Symfony without Docker, the following is my total execution time.

• without Docker, with Symfony cache: 82 ms

Whereas, we could do some improvements to get better workspace. For example, you can use volumes like this,

Источник

Нормально ли что при работе через Docker у меня заметно тормозит app?

Доброе время суток!

Начал изучать докер. После суток мучений я запустил проект в полном стеке с использованием докера. Но теперь я вижу увеличение времени ответа от сервера. App работало моментально на локальной машине на стандартном стеке nginx + php-fpm 7 + mysql. После настройки подобного стека на докере все работает заметно медленнее. Как можно это пофиксить?

• Вопрос задан более трёх лет назад
• 3107 просмотров

Сделал как вы сказали, запустилась виртуалка, запустил docker compose up
Все собралось.

В хост машине прописал

Не удается получить доступ к сайту

Сайт mooraway.dev не позволяет установить соединение.
Возможно, вы имели в виду moodaway.com/.
Выполните поиск по запросу mooraway dev в Google
ERR_CONNECTION_REFUSED

Что не так сделал?

/Documens/www и все ок стало.

Docker — это средство контейнеризации исключительно Linux (хотя и FreeBSD можно там взвести внутри).
Таким образом, изнчально нам нужно РАБОТАЮЩЕЕ ядро Linux.
Если вы используете Docker под Linux — проблем с этим нет. Запуск контейнера почти мгновенный.
Если вы используете Docker под Windows или MacOSX, то нужно сначала загрузить сам Linux для того, чтобы уже там загружать контейнеры.
В реальных системах боевых — Docker запускают ТОЛЬКО на Linux серверах. Но для отладки вы можете делать это где угодно. Только смиритесь с тем, что если это будет не под Linux, то запуск будет долгим.

Под Linux запуск приложения в Docker — это всего лишь контейнер, то есть всего лишь изоляция вызовов API операционной системы.

Под не-Linux запуск приложения в Docker требует изначально запуска самого Linux в виртуальной машине.

то есть Docker — под Linux?

вы часом, файлы БД и логов не в слоеную FS запустили?
так нельзя делать.

вы часом, файлы БД и логов не в слоеную FS запустили?
так нельзя делать.

Не понял, выше docker-compose

markmoskalenko, ну во первых на Mac — это будет через ВИРТУАЛКУ.
Какие тесты производительности тут могут быть.
Как вариант — поставить в виртуалку драйвера паравиртуализации и включить паравиртуализацию, тогда скорость должна подняться.

Docker-Compose или не Compose не означает что у вас данные лежат правильным образом.

При корректной настройке НИЧЕГО не должно писаться внуть контейнеров Докера. Все что пишется на диск — только подключенные внешние папки должны быть.

Источник

docker on OSX slow volumes

I’m trying to use docker beta on OSX, mainly for Symfony development but the mounted volumes are incredible slow. Even for a vanilla Symfony project I get 6s page load time. That’s unbearable! Has anyone found a solution to this issue? Trying to move away from vagrant but I just can’t find any reasonable way to work with docker instead.

9 Answers 9

Okay the user Spiil gave a solution but I wanted to elaborate on the exact steps to take since I went through 12 hours trying to figure it out, but once you know how its super easy and fixes all the slow down issues!

The key here is to understand this solution creates NFS (Network File System) drives as the means of communication from the Docker Containers to your Mac instead of the standard OSX File System which is very slow currently either due to bugs or the way it works*

Follow these steps exactly.

1.) Clone this repo here (https://github.com/IFSight/d4m-nfs) in your home directory. To do this open up terminal and type cd

Then type git clone https://github.com/IFSight/d4m-nfs

Alternatively you can also do this in a one liner git clone https://github.com/IFSight/d4m-nfs

2.) Next go into the d4m-nfs folder and create a new file in the /etc folder and title it d4m-nfs-mounts.txt

3.) Add the following lines of code to this.

What the above does is allows you to still use relative folders with docker-compose and allows all ports to connect on it hence the 0:0.

EDIT Do not put /Volumes here!!

4.) Go to your docker preferences and do the following

Make sure only /tmp is showing and NOTHING ELSE. I mean nothing else it won’t work if there is anything else since it will create conflicts with the NFS systems that the script will make for you later. Restart docker and docker-compose down any containers as well.

5.) Finally navigate to the d4m-nfs directory we created in step 1 and type the following command, /bin/bash d4m-nfs.sh

edit The correct way to type the command above is this as another user from the github (if-kenn) pointed out, ./d4m-nfs.sh which uses the Shebang for what shell should run it.

If done correctly there should be no errors and this should work. Please note DO NOT RUN as sh d4m-nfs.sh this will create errors and you will have to delete your exports file to start over. In fact anytime you make any changes you will have to clear your exports file.

This is what mine looks like.

EDIT:: IMPORTANT — Remove the /private and volumes! This should only be users/username now!

If you see anything other than this you were not running with bash. You can quickly get to the exports file like this in Mac if you make any errors and just clear it out to start over.

Just select go to folder

and then type /etc/exports

This is a nice shortcut to quickly get to it and clear it out in your favorite text editor.

Also make sure no containers are running or you will get the . loop of death. If this loop of death continues make sure you upgrade docker and then restart your computer. Yes restart. it seemed to be the only way to get it to work on my friends computer. Refer to this (https://github.com/IFSight/d4m-nfs/issues/3)

Note to . loop. I recently found another solution. Make sure you are NOT logged as root, and make sure you pulled the git repo into your users

folder not the root

folder. In otherwords, it should be in Users/username.

Also, make sure /tmp folder has full write permissions since the script needs to write here or this won’t work either. chmod 777 -R /tmp

6.) If you did it right when running the script it will look like this.

Then simply run your docker-compose up -d as usual in your symfony project folder (or whatever project you are using with docker) and everything should work. except NO MORE slow downs!

You will need to run this anytime you restart your computer or docker.

Источник