У меня есть Wordpress, работающий внутри Docker для локальной разработки, и он очень медленный. Мой docker-compose.yml выглядит так:
version: '3.3'
services:
db:
image: mysql:5.7
volumes:
- ./db_data:/var/lib/mysql
- ./dbconfig.cnf:/etc/mysql/conf.d/custom.cnf
restart: always
ports:
- "3308:3306"
environment:
MYSQL_ROOT_PASSWORD: root_password
MYSQL_DATABASE: wp_database
MYSQL_USER: db_user
MYSQL_PASSWORD: some_secure_password
wordpress:
depends_on:
- db
image: wordpress:latest
ports:
- "80:80"
- "443:443"
restart: always
volumes:
- ./wp-content:/var/www/html/wp-content
- ./.htaccess:/var/www/html/.htaccess
- ./wp-config.php:/var/www/html/wp-config.php
- ./logs/debug.log:/var/www/html/wp-content/debug.log
volumes:
db_data: {}
wp_content: {}
Насколько я читал в Интернете, это может быть причиной того, что я монтирую том wp-content, что вызывает очень медленную загрузку страницы (загрузка каждого файла занимает полсекунды, например, файл jquery, и он должен загрузить тонну файлов за одну страницу).
Есть ли решение для этого? Я читал о NFS, но у меня не получилось настроить NFS с помощью docker-compose, почему-то я продолжаю получать «ошибки разрешения». С другой стороны, интерфейс Docker в macOS уже показывает мне вкладку «Общая папка», но я не знаю, использую ли я эти общие папки в данный момент или просто монтирую их снова.
Любая помощь приветствуется.

TL;DR Подключитесь к временной папке в контейнере, синхронизируйте эту папку с Bindfs с общедоступной папкой сервера. Обслуживание сайта WP с прямым монтированием происходит медленно, потому что контейнер должен обращаться к файлам хоста один за другим, что является трудоемким процессом. Обслуживание из общей папки, в то время как файлы являются частью непосредственно контейнера, намного быстрее.
Я столкнулся с точно такой же проблемой при разработке локального WordPress в Docker Compose. Неважно, насколько быстрым может быть ваш компьютер, он все равно будет медленным при монтировании папок в контейнерах.
Я также пробовал решения, такие как NFS, и другие рекомендации, такие как правильное исключение проекта из антивируса, добавление .dockerignore и т. д., которые в лучшем случае немного улучшают производительность.
При поиске аналогичного улучшения скорости я наткнулся на этот файл Dockerfile в репозитории WordPress Starter https://github.com/visiblevc/wordpress-starter/blob/master/Dockerfile. Если вы посмотрите на этот файл, вы увидите, что они инициализируют и монтируют проект в контейнере, монтируя его, скажем, не в /var/www/html/ напрямую, а вместо этого во временную папку. Затем они синхронизируют эту временную папку с /var/www/html/ через bindfs. Таким образом, каждый раз, когда вы загружаете страницу WordPress в браузере, она будет молниеносной, потому что ей не нужно будет обращаться к файлам хоста и читать их при каждом запросе. Файлы WordPress являются частью контейнера Linux. Когда вы вносите изменения в свой код, эти изменения будут отражаться во временной папке контейнера, а bindfs мгновенно синхронизирует эти изменения с общедоступной папкой контейнера и наоборот. Все изменения, внесенные в общую папку, будут синхронизированы с временной папкой, а оттуда — с файлами вашего хост-проекта.
Часть, о которой я говорю, находится в последнем блоке файла докеров. Вы можете видеть, что он добавляет пользователя и администратора, настраивает права доступа к папке /app, в которую будут смонтированы ваши хост-файлы WordPress, и, наконец, добавляет символическую ссылку из /app в /var/www/html с помощью магии bindfs.
Это будет 404
Вам просто нужно вернуться в прошлое, чтобы найти репозиторий вокруг даты публикации, чтобы найти файл докеров, который предлагает @ArmanShahinyan: github.com/visiblevc/wordpress-starter/blob/…
Спасибо за зад в правильном направлении. Но я не использовал bindfs, так как он не так популярен, и я стараюсь избегать слишком большого количества зависимостей из неизвестных источников. Но я нашел программу с похожей функциональностью и очень простым синтаксисом: lsyncd --rsync /source/path /target/path. Хотя он не двунаправленный. github.com/axkibe/lsyncd
Обычно TL;DR будет вверху вашего поста, а не внизу. Не слишком полезно, если кто-то прочитает весь ваш пост, а затем наткнется на часть TL; DR в конце. На тот момент они уже все прочитали и больше не нуждаются в части TL;DR.
Я столкнулся с такой же проблемой, но, возможно, нашел решение.
В приложении docker Desktop (вверху со временем, выглядит как кит)
Открыть настройки Выберите Ресурсы\Общий доступ к файлам.
Добавьте соответствующие папки. У меня были папки MySQL и Wordpress в одной родительской папке, поэтому я добавил это.
Нажмите Применить и перезапустить.
Мой сайт значительно ускорился.
Надеюсь, это поможет.
Совсем не помогло :( В моем случае точно такое же плохое время загрузки, как и раньше. Не могли бы вы поделиться скриншотами или фрагментами кода вашего docker-compose.yml и/или Dockerfile?
В Mac и Windows есть некоторые проблемы с производительностью томов, которые мы должны учитывать.
Я внес изменения в свой docker-compose.yml
Обратите внимание, как я изменил короткий синтаксис в длинный синтаксис.
Эта нотация позволяет добавить consistency option.
Я добавил wp-content и php-conf (чтобы получить php.ini), потому что это каталог файлов, который чаще всего вызывается каждый раз, когда страница Wordpress загружается в браузере.
services:
wordpress:
...
volumes:
- ./data:/data
- ./scripts:/docker-entrypoint-initwp.d
#- ./wp-content:/app/wp-content
- type: bind
source: ./wp-content
target: /app/wp-content
consistency: cached
#- ./php-conf:/usr/local/etc/php
- type: bind
source: ./php-conf
target: /usr/local/etc/php
consistency: cached
Я понял, что если вы сузите каталоги, которые Docker должен просматривать для запуска вашего сайта, он будет работать намного быстрее. Например, в настройках рабочего стола Docker параметр /Users по умолчанию находится в разделе «Настройки» > «Ресурсы» > «Общий доступ к файлам». Если вы удалите этот ресурс и просто сократите его до каталога, в котором находятся ваши сайты, это избавит Docker от больших накладных расходов.
Примечания. Я работаю в OS X. Я пытался увеличить объем ОЗУ и ЦП, выделенных для Docker, а также включить папки в качестве ресурсов, но все равно все было медленно.
Я старался улучшить докер, насколько мог, и самые важные вещи, которые я сделал, это:
Я должен был убедиться, что не загружаю в контейнер никаких дополнительных файлов. В моем проекте почему-то кто-то захотел загрузить в контейнер текущий $PWD. Удаление очень помогло
Я добавил флаг :delegated в том mysql. Зачем использовать это вместо :cached, я разрабатывал локально, поэтому я не хотел, чтобы файлы кэшировались, что привело бы к перезагрузке страницы, чтобы попытаться получить последние изменения.
Затем, после этих улучшений, время загрузки страницы составляло около 1-3 минут. Прошла пара недель, и мне пришла в голову идея отключить все функции WordPress, связанные с чтением или записью в базу данных, которые не были необходимы, такие как автосохранение при редактировании, wp-cron; которые являются хорошими функциями для производства, но во время разработки я подозревал, что они делают слишком много и вызывают долгую загрузку страниц. вот что я использовал в своем файле wp-config.php, который я использую только при локальной разработке:
define( 'AUTOSAVE_INTERVAL', 60*60*60*24*365 ); // Set autosave interval to 1x per year
define( 'EMPTY_TRASH_DAYS', 0 ); // Empty trash now: Zero days
define( 'WP_POST_REVISIONS', false );
define( 'DISABLE_WP_CRON', true ); // sends an XHR request with timestamp to server on every page load which queries db for posts that may need to be published and does so; :gross:
Я надеюсь, что это помогает кому-то. ИМХО, мне не нужно было этого делать, так как я могу нормально запускать стек MAMP/LAMP с wordpress. У меня НЕТ ответа, почему docker и wordpress так плохо работают в моей операционной системе и с Docker Desktop.
Я не вижу, где это делается в Dockerfile, который вы предлагаете.