У меня есть счастье и несчастье, что мне нужно немедленно масштабировать свой сайт Drupal. Он получает больше трафика, чем я в настоящее время могу вместить - и поэтому следующие шаги масштабирования должны быть предприняты.

Я думаю, что сайт отлично работал на Drupal 9. Но я перешел на Drupal 10, и он стал очень, очень медленным. Я не собираюсь возвращаться к Drupal 9, но это еще одна точка зрения и еще одна причина не обновляться. Как я уже писал ранее, нам нравится держать свой стек на плаву, поэтому при переходе на следующую крупную версию (1) не приносит заметной пользы, а (2) увеличивает потребление ресурсов - мы действительно спрашиваем, стоит ли это того. Что не так. Много раз его не стоит обновлять.

Двигаясь дальше, давайте пройдемся по шагам, которые я предпринимаю для решения проблем производительности и повышения общей производительности сайта.

Первый шаг, который я делаю, это восстановление сайта с помощью Ansible. Это означает написание и настройку доступных плейбуков и ролей для установки веб-сайта на голую ОС. Я использую докер для этого внутри. Вы бы сказали - о Виктор, это большая задача - и это большая задача. Тем не менее, я чувствую себя гораздо более комфортно с инфраструктурой как кодом, чем если бы у меня не было этой возможности. Так что поехали!

Я также постараюсь открыть исходный код большей части моего кода. Код Ansible доступен здесь: https://github.com/wasya-co/wasya co ansible.git Если вы не можете найти какой-либо код, который я упоминаю, или считаете, что он не был открытым исходным кодом, и вам нужна копия - свяжитесь со мной напрямую. Примечание: филиал «мастер» почти никогда не является последним. Лучшей ветвью для использования является алфавитно последняя ветвь.

Примечание: Я использую свои собственные изображения докера, такие как piousbox/php83:0.0.2 Вы можете подключить свое собственное изображение или вставить мне, если мое не работает в нашем случае, или вам нужно что-то конкретное, например, другой модуль apache.

Я буду работать над моим самым популярным сайтом, https://piousbox.com Теперь, через несколько дней, я получил учебник, который устанавливает работу веб-сайта: playbooks/setup all drupal site.yml, и вам нужны все значения конфигурации, чтобы быть в vars/.yml или что-то подобное. Вы можете запустить его с:

   ansible-playbook -i inventory/aws.yml -e @vars/piousbox_com.yml \ 
     --limit aws4 playbooks/setup_all_drupal_site.yml    -vv

После того, как я написал его, я обнаружил, что я хочу переписать его, чтобы я мог устранить неполадки в установке локально. То есть, несмотря на то, что я хочу управлять всем этим с помощью съедобного, я хочу быть уверенным, что это работает заранее. Способ сделать это — упаковать приложение в виде докер-проекта. Поэтому я разделил https://github.com/wasya-co/docker drupal.git из репо.

Конечно, тогда мне, возможно, придется иметь две системы шаблонирования, чтобы подключить значения конфигурации. На самом деле это уже возможно, и я подумал, что накладные расходы не слишком велики. В проекте docker drupal.git у меня есть скрипты/update all, sripts/update dc (для docker-compose.yml) и скрипты/update settings - эти скрипты берут шаблон и заменяют значения .env в шаблон.

Затем я переписал полезную роль, чтобы вместо размещения каждого необходимого файла на сервере разместить там docker drupal.git repo, а шаблон-заменить несколько файлов. Это позволяет мне управлять автоматизацией с помощью и без необходимости.

Проект включает в себя базу данных mysql. Я считаю, что именно база данных является узким местом производительности, но я также хочу быть уверен, и я хочу иметь инструменты для устранения неполадок в таких вопросах именно в будущем.

Затем, чтобы упростить вещи, я упаковал все свои темы и модули в качестве реальных модулей для композитора. Раньше я делал все, что мне было нужно, из своих собственных кодовых баз, однако с ростом автоматизации самый простой метод стал просто включать все в файл composer.json, что я и сделал. docker drupal.git/compose.json имеет детали и является примером этого. (Я использую семантические теги версионирования, excelt в моем формализме 1.0.0 всегда является ветвью, тогда как v1.0.0 - тег релиза.) V в начале дает понять, что это не версия, поскольку v не является частью семверного формализма.

Затем я фактически переписал свое съедобное репо рабочего пространства - или, скорее, решил, что единственные общие вещи будут ролями. Таким образом, каждая возможная роль является открытым исходным кодом в своем собственном репо. Пример: wasya-co/wasya co ansible role.git И плейборы, и переменные, и инструкции к запуску находятся в другом месте, вероятно, в документации. Таким образом, мне не нужно открывать исходные коды моего пригодного рабочего пространства, и я по-прежнему получаю выгоду от открытого исходного кода для всей тяжелой работы, которая находится внутри доступных ролей.