Заметка с полей по решению проблем при размещении сайта wordpress за внешним проксирующим nginx. Если кому-то инетресно узнать полную схему размещения сайтов таким образом и зачем все это нужно в подробностях, пишите в комментариях. Напишу отдельную статью по этой теме.
https://serveradmin.ru/oshibka-wordpress-izvinite-vam-ne-razresheno-prosmatrivat-etu-straniczu/
#статья #webserver #wordpress
https://serveradmin.ru/oshibka-wordpress-izvinite-vam-ne-razresheno-prosmatrivat-etu-straniczu/
#статья #webserver #wordpress
Server Admin
Ошибка WordPress - Извините, вам не разрешено просматривать эту...
Столкнулся при переносе сайтов на wordpress с одного хостинга на другой с неожиданной проблемой. Ошибка не информативная и совсем не очевидно, как ее решать. В итоге победил и разобрался в...
Небольшая статья на тему анализа производительности сайта на wordpress с помощью wp-cli и профайлера. Иногда бывает так, что с сервером все в порядке. Более того, другие сайты на нем летают, а конкретный тормозит. Необходимо профилировать работу самой cms, чтобы понять в чем проблема. Чтобы не опускаться до уровня профилирования непосредственно php кода, можно предварительный, а зачастую и достаточный для решения проблемы, анализ сделать с уровня самой cms. Рассказываю как раз об этом.
https://serveradmin.ru/wordpress-tormozit-kak-bystro-najti-prichinu/
#статья #wordpress
https://serveradmin.ru/wordpress-tormozit-kak-bystro-najti-prichinu/
#статья #wordpress
Server Admin
WordPress тормозит! Как быстро найти причину? | serveradmin.ru
# cd ~ # curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar Делаем исполняемым и копируем в системную директорию, откуда он будет вызываться. # chmod +x wp-cli.phar...
Я тут подколхозил немного yaml и bash для разработки сайтов под wordpress. Статья больше для разработчиков на тему того, как быстро и удобно развернуть рабочее окружение, начать разработку сайта локально и потом перенести его куда-то, чтобы показать.
Тема разработки под wordpress не сильно мне знакома. И вообще особо нигде не рассматривается в контексте современной разработки, хотя это самый популярный движок в мире. Из-за того, что он на php и монолитный, в современные концепции ci/cd не вписывается.
В общем, видя как некоторые разработчики разрабатывают, я решил им немного помочь в этом деле. Любопытно увидеть критику и улучшения, но только не в общем случае, а в контексте конкретной задачи.
https://serveradmin.ru/ci-cd-proekta-na-wordpress
#статья #wordpress #devops
Тема разработки под wordpress не сильно мне знакома. И вообще особо нигде не рассматривается в контексте современной разработки, хотя это самый популярный движок в мире. Из-за того, что он на php и монолитный, в современные концепции ci/cd не вписывается.
В общем, видя как некоторые разработчики разрабатывают, я решил им немного помочь в этом деле. Любопытно увидеть критику и улучшения, но только не в общем случае, а в контексте конкретной задачи.
https://serveradmin.ru/ci-cd-proekta-na-wordpress
#статья #wordpress #devops
Server Admin
CI/CD проекта на WordPress | serveradmin.ru
# cd ~ && mkdir wordpress && cd wordpress Создаем в директории конфигурационный файл docker-compose.yaml следующего содержания. version: '3' services: mysql: image: mysql:8 command:...
Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).
#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала
Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала
Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow
Самый популярный движок для сайтов во всём мире — Wordpress. Именно на нём создано больше всего сайтов. Сам я все сайты делал исключительно на нём, хотя администрировать приходилось разные движки. Если меня спросит кто-нибудь посоветовать движок для информационного сайта или сайта-визитки, то совет будет однозначный. Я не вижу смысла использовать что-то другое.
Wordpress обычно предъявляют пару основных претензий: он небезопасный и он тормозной. Небезопасные чаще всего плагины, а не сам движок, в котором даже если и находят уязвимости, то исправления выходят в тот же день. А вот насчёт скорости дам один практический совет, как решить эту проблему для информационного сайта, который можно закэшировать.
Ставим плагин WP Super Cache. Включаем кэширование, указываем директорию для кэша, настраиваем предварительную загрузку кэша (отдельный раздел настроек). С такими настройками плагин будет автоматически создавать и периодически обновлять статические страницы, размещая их в определённой директории.
Теперь идём в настройки Nginx и настраиваем отдачу этих статических страниц напрямую через веб сервер, в обход php движка. Для этого настраиваем корневой location примерно так:
Убедитесь, что маска пути, указанная в настройках, совпадает с реальным расположением файлов кэша. С данными настройками первым делом страница будет проверяться в директории с кэшом, где она уже сформирована в статическом виде. Отдача такой страницы будет максимально быстрой.
С этими настройками вы закрываете вопрос тормознутости сайта на Wordpress процентов на 90. Остальное останется под другие оптимизации, которые можно уже не делать. Сайт и так будет грузиться очень быстро. Он фактически стал статическим.
В WP Super Cache есть возможность указать настройки обновления или сброса кэша, например, при появлении нового комментария или новой статьи. Также можно выбрать пользователей или группы, для которых кэширование работать не будет. Кэшированием можно гибко управлять, в отличие от такого же кэша, только средствами Nginx. Он по быстродействию будет такой же, только без настроек, что неудобно.
Более подробно этот метод описан в документации самого плагина:
https://wordpress.org/documentation/article/nginx/#wp-super-cache-rules
Там имеет смысл добавить ещё немного настроек для исключения кэширования некоторых запросов. Примерно так. Эти настройки должны быть выше в конфигу виртуального хоста, чем предыдущий корневой location.
Далее можно заняться оптимизацией картинок и включением сжатия brotli. Но это если хотите сделать всё максимально возможное. В общем случае и так нормально будет.
Тема ускорения Wordpress плотно оккупирована в поисковой выдаче сеошниками. А они про настройки Nginx ничего не знают и не умеют, поэтому найти подобное решение с плагином где-то через поиск вряд ли получится. А если искать по-серьёзному материалы админов, то найдёте скорее всего кэширование напрямую через сам Nginx или какой-нибудь Varnish. Но это будет не так гибко и удобно.
#webserver #wordpress
Wordpress обычно предъявляют пару основных претензий: он небезопасный и он тормозной. Небезопасные чаще всего плагины, а не сам движок, в котором даже если и находят уязвимости, то исправления выходят в тот же день. А вот насчёт скорости дам один практический совет, как решить эту проблему для информационного сайта, который можно закэшировать.
Ставим плагин WP Super Cache. Включаем кэширование, указываем директорию для кэша, настраиваем предварительную загрузку кэша (отдельный раздел настроек). С такими настройками плагин будет автоматически создавать и периодически обновлять статические страницы, размещая их в определённой директории.
Теперь идём в настройки Nginx и настраиваем отдачу этих статических страниц напрямую через веб сервер, в обход php движка. Для этого настраиваем корневой location примерно так:
location / { try_files /wp-content/cache/supercache/$http_host/$cache_uri/index-https.html $uri $uri/ /index.php?$args;}Убедитесь, что маска пути, указанная в настройках, совпадает с реальным расположением файлов кэша. С данными настройками первым делом страница будет проверяться в директории с кэшом, где она уже сформирована в статическом виде. Отдача такой страницы будет максимально быстрой.
С этими настройками вы закрываете вопрос тормознутости сайта на Wordpress процентов на 90. Остальное останется под другие оптимизации, которые можно уже не делать. Сайт и так будет грузиться очень быстро. Он фактически стал статическим.
В WP Super Cache есть возможность указать настройки обновления или сброса кэша, например, при появлении нового комментария или новой статьи. Также можно выбрать пользователей или группы, для которых кэширование работать не будет. Кэшированием можно гибко управлять, в отличие от такого же кэша, только средствами Nginx. Он по быстродействию будет такой же, только без настроек, что неудобно.
Более подробно этот метод описан в документации самого плагина:
https://wordpress.org/documentation/article/nginx/#wp-super-cache-rules
Там имеет смысл добавить ещё немного настроек для исключения кэширования некоторых запросов. Примерно так. Эти настройки должны быть выше в конфигу виртуального хоста, чем предыдущий корневой location.
set $cache_uri $request_uri;if ($request_method = POST) { set $cache_uri 'null cache'; }if ($query_string != "") { set $cache_uri 'null cache'; }if ($request_uri ~* "(/wp-admin/|/forum/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") { set $cache_uri 'null cache'; }if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") { set $cache_uri 'null cache'; }Далее можно заняться оптимизацией картинок и включением сжатия brotli. Но это если хотите сделать всё максимально возможное. В общем случае и так нормально будет.
Тема ускорения Wordpress плотно оккупирована в поисковой выдаче сеошниками. А они про настройки Nginx ничего не знают и не умеют, поэтому найти подобное решение с плагином где-то через поиск вряд ли получится. А если искать по-серьёзному материалы админов, то найдёте скорее всего кэширование напрямую через сам Nginx или какой-нибудь Varnish. Но это будет не так гибко и удобно.
#webserver #wordpress
Покажу на простом и наглядном примере методику защиты от типичных брутфорс атак (перебор учётных записей). Для этого возьму всем привычный инструмент nmap и популярный движок сайта Wordpress. Все настройки возьму с реально работающего сервера, где блокировка переборов паролей успешно работает.
Сайты на Wordpress брутят повсеместно. Из-за того, что этот движок очень легко установить, много установок, сделанных дилетантами (сеошники, блогеры и т.д.). О безопасности там никто особо не заботится, поэтому и вероятность взлома значительная, чтобы заинтересованные люди решили потратить на это своё время.
Для примера покажу, как легко и просто начать подбор паролей. Возьмём всем известный сетевой сканер nmap. Нам понадобится любой список паролей, по которому мы будем делать перебор. Можно взять для тестов простые списки в репозитории BruteX или огромный список в wordlist.
В составе nmap есть готовый скрипт для брута админки Wordpress. Достаточно указать адрес сайта, учётную запись, например, admin и список паролей для перебора. Запускаем перебор:
В логах веб сервера увидите POST запросы к
Теперь расскажу, как работает защита от такого перебора с помощью fail2ban. Устанавливаете его в систему и делаете очень простой фильтр
Он ищет все POST запросы к указанным url. Это защита от подборка учёток через wp-login и xmlrpc (последний лучше вообще отключить или закрыть доступ через nginx). Далее создаём настройку jail
Это пример настроек, когда используется iptables. Теперь, как только в логе access.log появится более 5 попыток POST запросов к wp-login.php или xmlrpc.php, IP адрес обратившегося будет забанен. Это удобно проверить с помощью скрипта для nmap.
Подобным образом можно настроить защиту от перебора учётных записей любого сервиса, который записывает информацию об аутентификации в текстовый лог файл. Главное не забыть очень важный момент. Лог файл не должен быть очень большим. Обязательно необходима ротация по размеру файла. Если лог становится очень большим, то fail2ban может сам повесить сервер. Он написан, если не ошибаюсь, на Python и работает не очень быстро. Если вас начинают ддосить и access лог разрастается за минуту до гигабайтов, fail2ban вам сам повесит сервер. Его надо оперативно выключать. В отдельной заметке расскажу, как сделать более универсальную защиту без необходимости парсить access.log.
Более подробно с примерами эта настройка описана у меня на сайте в статье: Защита админки wordpress с помощью fail2ban.
Отдельно отмечу, что для fail2ban есть веб интерфейс — fail2web
#security #webserver #wordpress #fail2ban
Сайты на Wordpress брутят повсеместно. Из-за того, что этот движок очень легко установить, много установок, сделанных дилетантами (сеошники, блогеры и т.д.). О безопасности там никто особо не заботится, поэтому и вероятность взлома значительная, чтобы заинтересованные люди решили потратить на это своё время.
Для примера покажу, как легко и просто начать подбор паролей. Возьмём всем известный сетевой сканер nmap. Нам понадобится любой список паролей, по которому мы будем делать перебор. Можно взять для тестов простые списки в репозитории BruteX или огромный список в wordlist.
В составе nmap есть готовый скрипт для брута админки Wordpress. Достаточно указать адрес сайта, учётную запись, например, admin и список паролей для перебора. Запускаем перебор:
# nmap example.com --script http-wordpress-brute --script-args \'user=admin, passdb=password.lst, http-wordpress-brute.thread=3, brute.firstonly=true'В логах веб сервера увидите POST запросы к
/wp-login.php от user_agent="Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse.html)". Этот скрипт удобно использовать для тестирования своей защиты. Теперь расскажу, как работает защита от такого перебора с помощью fail2ban. Устанавливаете его в систему и делаете очень простой фильтр
wp-login.conf, положив его в директорию /etc/fail2ban/filter.d:[Definition]failregex = <HOST>.*POST.*(wp-login\.php|xmlrpc\.php).*Он ищет все POST запросы к указанным url. Это защита от подборка учёток через wp-login и xmlrpc (последний лучше вообще отключить или закрыть доступ через nginx). Далее создаём настройку jail
wp-login.conf и кладём её в директорию /etc/fail2ban/jail.d:[wp-login]enabled = trueport = http,httpsaction = iptables-multiport[name=WP, port="http,https", protocol=tcp]filter = wp-loginlogpath = /var/log/nginx/example.com/access.logmaxretry = 5Это пример настроек, когда используется iptables. Теперь, как только в логе access.log появится более 5 попыток POST запросов к wp-login.php или xmlrpc.php, IP адрес обратившегося будет забанен. Это удобно проверить с помощью скрипта для nmap.
Подобным образом можно настроить защиту от перебора учётных записей любого сервиса, который записывает информацию об аутентификации в текстовый лог файл. Главное не забыть очень важный момент. Лог файл не должен быть очень большим. Обязательно необходима ротация по размеру файла. Если лог становится очень большим, то fail2ban может сам повесить сервер. Он написан, если не ошибаюсь, на Python и работает не очень быстро. Если вас начинают ддосить и access лог разрастается за минуту до гигабайтов, fail2ban вам сам повесит сервер. Его надо оперативно выключать. В отдельной заметке расскажу, как сделать более универсальную защиту без необходимости парсить access.log.
Более подробно с примерами эта настройка описана у меня на сайте в статье: Защита админки wordpress с помощью fail2ban.
Отдельно отмечу, что для fail2ban есть веб интерфейс — fail2web
#security #webserver #wordpress #fail2ban
Самой популярной CMS в мире является Wordpress. Если не ошибаюсь, то в интернете и самих сайтов в целом больше всего именно на ней, а не только среди CMS. Сейчас не уверен, что это так, не проверял специально. Но лет 5 назад видел такую статистику.
У меня и свои сайты всегда были на Wordpress, и кучу проектов на них вёл и веду. Да и вообще, большинство блогов сделаны на WP. Это реально удобный движок. Ему приписывают проблемы с безопасностью и общую тормознутость. Но это всё мимо кассы претензии. Проблемы с безопасностью обычно в плагинах, не надо ставить всё подряд. А вопросы производительности хорошо решаются кэшированием. Контентные сайты вообще полностью в кэш загоняются и напрямую статические html отдаёт веб сервер. И всё это средствами самого движка WP. Удобно и просто в настройке.
У меня давно подготовлен набор инструментов для быстрого запуска и настройки этого движка через Docker Compose. Была когда-то давно серия статей на сайте, но они устарели, не обновлялись, поэтому ссылки на них не даю. Я на днях обновил весь этот стек и делюсь с вами информацией.
У меня будет 4 контейнера:
▪️mysql:8.4 - база данных;
▪️nginx:latest - веб сервер;
▪️wordpress:php8.3-fpm - образ с php-fpm от wordpress;
▪️wordpress:cli - консольный инструмент для управления конфигурацией wordpress.
Отдельно остановлюсь на wp-cli. Это консольная утилита, с помощью которой можно автоматизировать управление Wordpress. С её помощью можно делать как преднастройки новой установки, так и управлять уже работающим сайтом. Последнее я покажу в следующей заметке, а сейчас займёмся начальной установкой.
Я положил все необходимые файлы в отдельный репозиторий. Сделал это, чтобы вы могли их скопировать из этой заметки. Я не буду поддерживать и развивать этот проект, поэтому и с выбором репозитория не заморачивался:
В директории 3 файла:
- docker-compose.yml
- nginx_default.conf
- configure-wp.sh
С первыми двумя всё стандартно, не буду на них задерживаться. Остановлюсь подробно только на последнем файле. Это bash скрипт для wp-cli, который:
1. Устанавливает WP с заданной настройкой url и учёткой админа.
2. Устанавливает новую тему и удаляет стандартные.
3. Устанавливает и удаляет плагины.
4. Устанавливает русский язык.
Показал эти действия для примера. Туда же можно добавить какие-то материалы в виде xml файлов и через импорт их туда загнать. Это может быть удобно, если вы на потоке создаёте или тестируете какие-то темы, плагины с набором данных. Делается это примерно так:
Эти команды надо добавить в конец configure-wp.sh. Этот файл - простой набор консольных команд с wp-cli.
Перед запуском измените имя домена в
Через пару минут получите настроенный сайт wordpress с заданными параметрами и наполнением. В директориях ./db и ./wp будут лежать файлы СУБД и сайта. Возможно вам будет удобнее хранить их в volumes. Мне в директории как-то привычнее.
Если вы разработчик и работаете с Wordpress, то просто клонируйте этот проект, меняйте url, настраивайте CMS через конфиг wp-cli и всегда будете иметь возможность очень быстро развернуть свой проект в любом месте.
Данный проект не предусматривает настройку TLS, так как я подразумеваю, что входящие соединения приходят куда-то на прокси и оттуда уже летят на эти контейнеры, либо это локальный запуск для разработки. Для запуска в работу в таком виде нужно будет добавить ещё что-то для настройки сертификатов. Можно взять другой образ с Nginx, где это уже сделано. Таких образов полно. Например, linuxserver/swag. Кстати, интересный контейнер. Можно о нём отдельно рассказать.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wordpress
У меня и свои сайты всегда были на Wordpress, и кучу проектов на них вёл и веду. Да и вообще, большинство блогов сделаны на WP. Это реально удобный движок. Ему приписывают проблемы с безопасностью и общую тормознутость. Но это всё мимо кассы претензии. Проблемы с безопасностью обычно в плагинах, не надо ставить всё подряд. А вопросы производительности хорошо решаются кэшированием. Контентные сайты вообще полностью в кэш загоняются и напрямую статические html отдаёт веб сервер. И всё это средствами самого движка WP. Удобно и просто в настройке.
У меня давно подготовлен набор инструментов для быстрого запуска и настройки этого движка через Docker Compose. Была когда-то давно серия статей на сайте, но они устарели, не обновлялись, поэтому ссылки на них не даю. Я на днях обновил весь этот стек и делюсь с вами информацией.
У меня будет 4 контейнера:
▪️mysql:8.4 - база данных;
▪️nginx:latest - веб сервер;
▪️wordpress:php8.3-fpm - образ с php-fpm от wordpress;
▪️wordpress:cli - консольный инструмент для управления конфигурацией wordpress.
Отдельно остановлюсь на wp-cli. Это консольная утилита, с помощью которой можно автоматизировать управление Wordpress. С её помощью можно делать как преднастройки новой установки, так и управлять уже работающим сайтом. Последнее я покажу в следующей заметке, а сейчас займёмся начальной установкой.
Я положил все необходимые файлы в отдельный репозиторий. Сделал это, чтобы вы могли их скопировать из этой заметки. Я не буду поддерживать и развивать этот проект, поэтому и с выбором репозитория не заморачивался:
# git clone https://gitflic.ru/project/serveradmin/wordpress.git# cd wordpressВ директории 3 файла:
- docker-compose.yml
- nginx_default.conf
- configure-wp.sh
С первыми двумя всё стандартно, не буду на них задерживаться. Остановлюсь подробно только на последнем файле. Это bash скрипт для wp-cli, который:
1. Устанавливает WP с заданной настройкой url и учёткой админа.
2. Устанавливает новую тему и удаляет стандартные.
3. Устанавливает и удаляет плагины.
4. Устанавливает русский язык.
Показал эти действия для примера. Туда же можно добавить какие-то материалы в виде xml файлов и через импорт их туда загнать. Это может быть удобно, если вы на потоке создаёте или тестируете какие-то темы, плагины с набором данных. Делается это примерно так:
curl -O https://raw.githubusercontent.com/manovotny/wptest/master/wptest.xmlwp import wptest.xml --authors=createЭти команды надо добавить в конец configure-wp.sh. Этот файл - простой набор консольных команд с wp-cli.
Перед запуском измените имя домена в
nginx_default.conf и configure-wp.sh. А также название сайта, имя пользователя и пароль в configure-wp.sh. Больше ничего менять не надо. Запускаем:# docker compose upЧерез пару минут получите настроенный сайт wordpress с заданными параметрами и наполнением. В директориях ./db и ./wp будут лежать файлы СУБД и сайта. Возможно вам будет удобнее хранить их в volumes. Мне в директории как-то привычнее.
Если вы разработчик и работаете с Wordpress, то просто клонируйте этот проект, меняйте url, настраивайте CMS через конфиг wp-cli и всегда будете иметь возможность очень быстро развернуть свой проект в любом месте.
Данный проект не предусматривает настройку TLS, так как я подразумеваю, что входящие соединения приходят куда-то на прокси и оттуда уже летят на эти контейнеры, либо это локальный запуск для разработки. Для запуска в работу в таком виде нужно будет добавить ещё что-то для настройки сертификатов. Можно взять другой образ с Nginx, где это уже сделано. Таких образов полно. Например, linuxserver/swag. Кстати, интересный контейнер. Можно о нём отдельно рассказать.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wordpress
Продолжаю тему с Wordpress. Покажу несколько практических примеров с wp-cli. Напомню для тех, кто не читал предыдущие публикации по этой теме. Это консольный инструмент для управления CMS Wordpress. Его удобно использовать для различных прикладных задач. Ниже я покажу несколько практических примеров использования.
Утилиту wp-cli можно установить напрямую на сервер, где работают сайты. Если они в контейнерах, то удобнее запускать рядом контейнер wordpress:cli сразу в составе docker compose. По своей сути это скрипт на php, как и сам движок Wordpress.
Устанавливаем на сервер:
Или запускаем сразу из контейнера в составе docker compose:
Разберу прикладной пример анализа производительности WP. Не всегда бывает просто узнать, почему он внезапно начал тормозить. В общем случае нужно запустить профилирование php чем то наподобие xhprof или xdebug и смотреть, в чём проблема. Но это длинный путь, для того чтобы по нему пройти, необходимы знания и работа с кодом сайта. Есть путь проще с помощью wp-cli и profile-command.
Устанавливаем профайлер wp-cli/profile-command от пользователя, под которым работает сайт:
Если через compose запускаете, о пользователе переживать не надо. Там всё под одним работает.
Запускаем профилировщик, указывая ему путь к директории с сайтом.
Вы увидите разные стадии загрузки сайта. Если явно видно, что какая-то из них работает медленно, можно погрузиться в подробности. Посмотрим подробнее на загрузку плагинов, тем и хуков движка на этапе bootstrap:
Смотрим глубже на загрузку плагинов и выделяем некоторые поля:
Если какой-то плагин тормозит, вы увидите это в таблице. Более подробно про работу wp profile можно посмотреть в моей статье.
Другие примеры с wp-cli. Я опущу указание пользователя и директории сайта, чтобы команды были короче. Установка или удаление темы:
Установка, удаление плагинов:
Бэкап базы данных:
Импорт базы данных:
Удобно использовать wp-cli для бэкапа и загрузки дампа базы данных. Там используется обычный mysqldump, но тебе не нужно заботиться об учётных данных для доступа к базе. Wp-cli берёт их из настроек WP.
С помощью docker compose, wp-cli и небольших скриптов можно быстро переносить свою заготовку сайта. Вы можете описать установку нужных плагинов и тем, сохранить их настройки и в целом состояние движка в sql дампе. Потом развернуть где-то в другом месте и через команды wp-cli с импортом дампа получить нужное состояние нового сайта.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wordpress
Утилиту wp-cli можно установить напрямую на сервер, где работают сайты. Если они в контейнерах, то удобнее запускать рядом контейнер wordpress:cli сразу в составе docker compose. По своей сути это скрипт на php, как и сам движок Wordpress.
Устанавливаем на сервер:
# curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar# chmod +x wp-cli.phar# mv wp-cli.phar /usr/local/bin/wp# wp --infoИли запускаем сразу из контейнера в составе docker compose:
# docker-compose run --rm wp-cli wp --infoРазберу прикладной пример анализа производительности WP. Не всегда бывает просто узнать, почему он внезапно начал тормозить. В общем случае нужно запустить профилирование php чем то наподобие xhprof или xdebug и смотреть, в чём проблема. Но это длинный путь, для того чтобы по нему пройти, необходимы знания и работа с кодом сайта. Есть путь проще с помощью wp-cli и profile-command.
Устанавливаем профайлер wp-cli/profile-command от пользователя, под которым работает сайт:
# sudo -u nginx wp package install wp-cli/profile-command:@stableЕсли через compose запускаете, о пользователе переживать не надо. Там всё под одним работает.
Запускаем профилировщик, указывая ему путь к директории с сайтом.
# sudo -u nginx wp profile stage --path=/web/wwwВы увидите разные стадии загрузки сайта. Если явно видно, что какая-то из них работает медленно, можно погрузиться в подробности. Посмотрим подробнее на загрузку плагинов, тем и хуков движка на этапе bootstrap:
# sudo -u nginx wp profile stage bootstrap --path=/web/wwwСмотрим глубже на загрузку плагинов и выделяем некоторые поля:
# sudo -u nginx wp profile hook plugins_loaded --fields=callback,location,time,cache_ratio,request_time --path=/web/wwwЕсли какой-то плагин тормозит, вы увидите это в таблице. Более подробно про работу wp profile можно посмотреть в моей статье.
Другие примеры с wp-cli. Я опущу указание пользователя и директории сайта, чтобы команды были короче. Установка или удаление темы:
# wp theme install astra --activate# wp theme uninstall twentytwentyfiveУстановка, удаление плагинов:
# wp plugin install wordpress-seo --activate# wp plugin uninstall akismetБэкап базы данных:
# wp-cli wp db export --add-drop-tableИмпорт базы данных:
# wp-cli wp db import wp_base.sqlУдобно использовать wp-cli для бэкапа и загрузки дампа базы данных. Там используется обычный mysqldump, но тебе не нужно заботиться об учётных данных для доступа к базе. Wp-cli берёт их из настроек WP.
С помощью docker compose, wp-cli и небольших скриптов можно быстро переносить свою заготовку сайта. Вы можете описать установку нужных плагинов и тем, сохранить их настройки и в целом состояние движка в sql дампе. Потом развернуть где-то в другом месте и через команды wp-cli с импортом дампа получить нужное состояние нового сайта.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wordpress
Server Admin
WordPress тормозит! Как быстро найти причину? | serveradmin.ru
# cd ~ # curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar Делаем исполняемым и копируем в системную директорию, откуда он будет вызываться. # chmod +x wp-cli.phar...
На днях рассказывал про то, как быстро запустить уже настроенный сайт на Wordpress. Решил немного развить эту тему и подготовить docker compose, который позволит сразу запустить сайт с HTTPS, чтобы его можно было полноценно использовать для публикации в интернете.
Для этой задачи взял веб сервер Angie, который имеет встроенный модуль ACME, позволяющий автоматически получить сертификаты от Let's Encrypt. Причём настройка очень простая. Пример посмотрел в документации. Достаточно добавить в раздел http:
и в раздел server:
В данном случае значение параметра acme_client и acme в виде wordpress может быть любым. Это я его так обозвал. Лучше его привязать к домену и сделать таким же как server_name. Но у меня в примере поддомен, а параметр после точки не воспринимает значение, поэтому обозвал просто wordpress. Если сайтов будет несколько, то эти параметры тоже должны различаться.
После запуска Angie, он сам получит сертификаты на указанное доменное имя, положит их у себя в контейнере в директорию
Упаковал всё это в отдельный репозиторий. Достаточно его клонировать:
Указать своё имя домена в файлах
О том, что из себя представляет файл configure-wp.sh и как выполняется начальная настройка Worpdress, я писал в предыдущей заметке.
В репозитории конфигурация Angie немного расширена помимо стандартных настроек. Сначала хотел туда добавить всё, что я использую: мониторинг, разные форматы логов, лимиты, веб консоль angie и т.д. Но потом передумал. Всё это бездумно добавлять нельзя. Для того же мониторинга и консоли нужно настраивать ограничения доступа, для лимитов нужно тоже понимать, что это и зачем, а то можно поисковых ботов заблокировать.
Думаю, что подробно про настройку Angie напишу отдельно. Я его уже повсеместно использую вместо Nginx. Он лучше и функциональнее. Бесплатная версия Nginx после продажи почти не развивается. Такое ощущение, что продукт просто решили похоронить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wordpress #angie
Для этой задачи взял веб сервер Angie, который имеет встроенный модуль ACME, позволяющий автоматически получить сертификаты от Let's Encrypt. Причём настройка очень простая. Пример посмотрел в документации. Достаточно добавить в раздел http:
http { resolver 62.76.76.62 62.76.62.76 1.1.1.1; acme_client wordpress https://acme-v02.api.letsencrypt.org/directory; ............}и в раздел server:
server { listen 443 ssl; http2 on; server_name 337153.simplecloud.ru; acme wordpress; ssl_certificate $acme_cert_wordpress; ssl_certificate_key $acme_cert_key_wordpress; .....................}В данном случае значение параметра acme_client и acme в виде wordpress может быть любым. Это я его так обозвал. Лучше его привязать к домену и сделать таким же как server_name. Но у меня в примере поддомен, а параметр после точки не воспринимает значение, поэтому обозвал просто wordpress. Если сайтов будет несколько, то эти параметры тоже должны различаться.
После запуска Angie, он сам получит сертификаты на указанное доменное имя, положит их у себя в контейнере в директорию
/var/lib/angie/acme/ и будет автоматически обновлять. Организовано очень удобно. Не нужны никакие дополнительные программы типа certbot или acme.sh.Упаковал всё это в отдельный репозиторий. Достаточно его клонировать:
# git clone https://gitflic.ru/project/serveradmin/wordpress-angie-tls.git# cd wordpress-angie-tlsУказать своё имя домена в файлах
angie_default.conf и configure-wp.sh, установить Docker и запустить:# curl https://get.docker.com | bash -# docker compose upО том, что из себя представляет файл configure-wp.sh и как выполняется начальная настройка Worpdress, я писал в предыдущей заметке.
В репозитории конфигурация Angie немного расширена помимо стандартных настроек. Сначала хотел туда добавить всё, что я использую: мониторинг, разные форматы логов, лимиты, веб консоль angie и т.д. Но потом передумал. Всё это бездумно добавлять нельзя. Для того же мониторинга и консоли нужно настраивать ограничения доступа, для лимитов нужно тоже понимать, что это и зачем, а то можно поисковых ботов заблокировать.
Думаю, что подробно про настройку Angie напишу отдельно. Я его уже повсеместно использую вместо Nginx. Он лучше и функциональнее. Бесплатная версия Nginx после продажи почти не развивается. Такое ощущение, что продукт просто решили похоронить.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#wordpress #angie