Массовое обновление d7/d8, как лучше?

Аватар пользователя Алексей Дёмин Алексей Дёмин 26 ноября 2020 в 13:31

Всем привет!

Наверняка у многих, кто делает сайты в основном на Drupal, и занимается поддержкой, накопился изрядный зоопарк из экземпляров различной сложности и версий. Уж у меня - так точно! В основном это сайты d7 и d8. И этот зоопарк надо содержать, чистить клетки и делать прививки.
В общем хотел поднять вопрос про обновления и рабочий процесс, с этим связанный.
Итак, у нас много (в основном не коммерческих) сайтов, которые обновляются раз в месяц. Если сайт на семёрке, работу с ним мы ведём прямо на сервере (Написал и затаился на секунду. Но нет, слава богу, молния не ударила.) Естественно есть бекапы и работа (в случае ошибок обновления, которые можно пересчитать по пальцам), не простаивает больше 10-20 минут.
В итоге 2 команды, и 2 минуты занимает обновление.

drush arb
drush up

С восьмёркой всё сложнее. Я начал переходить на восьмёрку, когда ещё не имел практики работы с композером, и делал первые сайты на d8 по старинке, через drush. Года 2 назад, когда раскурил композер, стал переводить все, сделанные по старинке сайты на него. Но вот теперь, глядя, как хорошо обновлять сайты через drush и сравнивая с обновлением через композер, думаю что зря переводил.
composer работает медленней, жрет много памяти и на сервере с ним работать опасней и неудобно. Однако всё-равно быстрее, чем обновлять локально и заливать через git репозиторий.

Я вижу несколько решений:

  • Научить стажера раз в месяц заходить и обновлять. Минус в том, что надо вручную отслеживать обновления безопасности ит.п.
  • Настроить cron. Минус - не контролируешь процесс и надо вручную отслеживать SA.
  • Использовать модуль Automatic Updates, но он не работает с композером.

В общем, хочу спросить, так ли нужен composer? В чём я ошибаюсь или что упускаю? И вообще у кого как решены эти проблемы? Или это не проблемы вовсе?

Заранее спасибо )

Комментарии

Аватар пользователя ivnish ivnish 26 ноября 2020 в 13:35

Я всегда обновляю вручную.

Сайты на семерке тоже обновляю на сервере. Сайты на восьмерке обновляю локально, а потом GitLab CI деплоит

Аватар пользователя Алексей Дёмин Алексей Дёмин 26 ноября 2020 в 14:08

Про восьмёрку, напрягает, что надо хранить 10-ток сайтов локально, под каждый свой docker4drupal.. в общем как-то не оптимизировано кажется.

Аватар пользователя Алексей Дёмин Алексей Дёмин 26 ноября 2020 в 15:04

.htaccess и robot.txt не тянут имиджы каждый под свою версию. Конечно стараемся унифицировать, но не всегда получается.

Аватар пользователя VasyOK VasyOK 26 ноября 2020 в 15:34

Алексей, я тоже все еще начинающий пользователь Композера. Может фигню сморозил.
Кароче, дамп БД +
docker-compose rm - все лишние имейджи удаляются.

Кстати а где эти имейджи лежат? Как их вес глянуть?

Аватар пользователя Алексей Дёмин Алексей Дёмин 26 ноября 2020 в 16:44

Если удалять контейнеры и имиджи, то при следующем старте он будет качать и создавать их снова.
лежат тут /var/lib/docker/

Аватар пользователя Алексей Дёмин Алексей Дёмин 26 ноября 2020 в 15:13

Я пока так и делаю, только, всё же, напрягает ))
Поэтому ищу больше "промышленное" решение, которое можно будет масштабировать.

Аватар пользователя ivnish ivnish 26 ноября 2020 в 15:15

Промышленное - это то, что Александр Дубовской чуть ниже написал. Я пока для такого не созрел)

Аватар пользователя Andruxa Andruxa 26 ноября 2020 в 14:01

Был такой случай.
На сайте на семёрке был установлен модуль Display Suite. Причем, каждый раз глядя на него, я недоумевал - зачем он здесь, мы же используем панели, а формы не темизируем. Ну да ладно, работает - не трогай.
После очередного обновления безопасности DS, отвалились иконки цветов у атрибутов товара.

Дело в том, что цветов было гораздо больше 7, использовались комбинации этих цветов, и на странице каталога выводилось больше сотни таких иконок (30 карточек товара х 4-8 вариантов цвета в каждом).
Поэтому, генерить изображения для каждого цвета, поддерживать их в актуальном состоянии при редактировании атрибута, и тянуть на фронт 100+ иконок при каждой загрузке страницы каталога было совсем не вариант, цвета сделали инлайн-стилями: style="background-color: <?php print $color; ?>"
В общем-то, для такой задачи, я считаю, инлайн-стили - вполне приемлемое решение.

Обновление безопасности DS заключалось именно в том, чтобы вырезать недопустимые атрибуты тегов, в число которых попал и style. Тогда-то я и вспомнил, зачем нам DS на сайте. Фактически, все это время мы эксплуатировали незакрытую "дыру" (раз это было обновление безопасности) в коде модуля.

Отсюда мораль: никаких обновлений на проде. Сначала обновляем локально, смотрим дифф, чтобы понять в каких местах тестировать в первую очередь (вряд ли функционал ваших сайтов на 100% покрыт тестами), затем тестируем, и только после этого - выкатываем на прод.

Аватар пользователя Алексей Дёмин Алексей Дёмин 26 ноября 2020 в 14:14

Получается, что каждое обновление должно включать в рабочий процесс тестирование, в том числе и визуальное. Это в разы увеличит стоимость. Я повторюсь, что у меня речь о некоммерческих сайтах (садики, школы и администрации разных посёлков). Им платить тупо нечем. Мы берем 500 руб за обновление, но и от этого отказываются.

Поэтому вопрос не в том, как кошерно и бохато, а в том, как оптимизировать и делать это дешевле.

Аватар пользователя Andruxa Andruxa 26 ноября 2020 в 14:25

Самый оптимальный и дешевый вариант - не обновлять совсем. (Были и такие сайты).
Ну а дальше начинается компромисс между ценой и качеством.
Если владелец сайта согласен на вариант "мы сейчас накатим обновления, вы потом посмотрите, если где-то отвалится, то откатим обратно, правда придется заново создать весть контент с момента бэкапа" - то ок, почему бы и нет.

Аватар пользователя ivnish ivnish 26 ноября 2020 в 15:12

500р это 30-60 минут в зависимости от ставки. Даже 30 минут хватит, чтобы протестировать сайт после обновления

Аватар пользователя gun_dose gun_dose 26 ноября 2020 в 14:35
1

Во-первых, надо ставить уже второй композер. Он жрёт ресурсов в разы меньше. Это прямо очень заметно.
Во-вторых, чтобы не держать всё локально, можно посмотреть в сторону CI или даже просто Github actions. Нужно создать два экшена с мануальным триггером. Один будет выполнять в своей виртуалке composer update и в случае отсутствия ошибок делать коммит. А второй будет деплоить коммит на сервер. Можно конечно и в один экшн это засунуть. А ещё в экшн можно прописать, чтобы он сходил на продакшн, слил оттуда базу и накатил в тестовой среде drush updb.

Ну сказать по правде, это всё теория)) Максимум, что я делал - писал экшены, которые автоматом деплоят коммиты на продакшн - типа сделал git push с локалки и всё готово.

Аватар пользователя Andruxa Andruxa 26 ноября 2020 в 15:21

gun_dose wrote: надо ставить уже второй композер

хм, недавно так сделал, восьмерка стала жаловаться на какие-то зависимости (проект старый)
Пришлось деградировать на 1.9

Аватар пользователя gun_dose gun_dose 26 ноября 2020 в 17:49

Там друпал-консоль надо снести и ещё пару зависимостей. Может быть какой час придётся повозиться, но оно того стоит.

Аватар пользователя adubovskoy adubovskoy 26 ноября 2020 в 14:40
1

Composer же прежде всего - для сохранения стейта и возможности делать деплой.

Для задачи вашего плана я бы рассмаотрел написать следующий скриптик:
- поднимаем контейнеры для теста
- скачиваем туда сайт с прода в докер
- запускаем composer update, drush updatedb/etc
- если без ошибок - загружаем назад и делаем composer install. (этот пункт имхо удобнее через что-то типа gitlabci коммитом, получаем запуск воркеров и наглядную инфу всё ли нормально прошло + удобный лог).

В целом автоматизируется и 99% кейсов может проходить без ручного внимания.

Аватар пользователя jura12 jura12 27 ноября 2020 в 4:01

без композера нельзя пользоваться webform в 8,9. кроме того на него делается ставка.
я обслуживаю сайты так:
1. ежедневный инкрементальный бэкап.
2. для каждого сайта (8, 9) написан скрипт обновления. запускаю в ручную. но думаю написать один скрипт для всех сайтов. у меня 2х7, 8, 9.

Аватар пользователя jura12 jura12 27 ноября 2020 в 21:53
1

да, все так. но есть фишки которые я хочу реализовать с помощью этого.
1. обновление всех сайтов одним скриптом он вызывает все локальные (для каждого сайта свой) скрипты. они в принципе похожи друг на друга.
2. автоматический вызов обновления когда это будет нужно. информация от drush core:requirements говорит что требуется обновление. но нужно тогда чтоб все модули были установлены через композер.
мне приходят письма от Security advisories. сейчас уже подписаться нельзя.
скрипт бэкапа, скрипт обновления.

P.S. а вот сайты на удаленных хостингах на друпал 7 обновлять сложно. думаю сначала организовать автоматический инкрементальный бэкап.

Аватар пользователя bsyomov bsyomov 28 ноября 2020 в 0:15

jura12 wrote: P.S. а вот сайты на удаленных хостингах на друпал 7 обновлять сложно. думаю сначала организовать автоматический инкрементальный бэкап.

Чего сложного? Всё также, даже проще на одну команду, чем 8 - drush up на каждый сайт, с предварительным бекапом, если использовать такой подход.
Кстати, включать перед дампом режим обслуживания, как в скриптах выше, на мой взгляд, излишне.
И вообще, с таким зоопарком лучше какой-нибудь rsnapshot с pull стратегией а не push использовать, и тянуть бекапы себе, и от себя через ssh запускать скрипты, тогда их даже не придётся по серверам раскладывать. И всё будет более надёжно и централизовано.

Аватар пользователя jura12 jura12 28 ноября 2020 в 0:19

у меня на удаленных серверах друпал 7 и там не работает drush потомучто версия пхп 7.3 в командной строке, а 5.5(4) уже не поддерживается. а композер для друпал 7 вроде не предназначен.
я еще подумаю.

Аватар пользователя bsyomov bsyomov 28 ноября 2020 в 0:27

Drush работающий с drupal 7 умеет работать с php 7.x, и кстати, наверняка есть не только php-cli 7.3, но и постарше под другим именем. Smile

Аватар пользователя bsyomov bsyomov 28 ноября 2020 в 1:03

Ага. Smile

$ php -v        
PHP 7.2.34-2+ubuntu16.04.1+deb.sury.org+1 (cli) (built: Oct 10 2020 19:44:01) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.34-2+ubuntu16.04.1+deb.sury.org+1, Copyright (c) 1999-2018, by Zend Technologies
$ drush --version
drush version 5.10.0

Вот пример даже более устаревший. Тут drush из репозитория OS. Smile
Прям сегодня им был обновлён drupal...

Но использовать стоит 8.х drush, конечно.

Аватар пользователя jura12 jura12 28 ноября 2020 в 4:40

я уже разобрался и настроил.
composer require drush/drush:8.*

$ php -v
PHP 7.3.24 (cli) (built: Nov  3 2020 07:16:01) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.24, Copyright (c) 1998-2018 Zend Technologies
    with the ionCube PHP Loader + ionCube24 v10.4.3, Copyright (c) 2002-2020, by ionCube Ltd.
Аватар пользователя jura12 jura12 28 ноября 2020 в 5:46

набросал скрипт для быстрого бэкапа. но это не правильный бэкап. лучше инкрементальный.

dirofusername="myusername"
drush --root=/home/$dirofusername/public_html vset site_offline 1
drush archive-dump default --root=/home/$dirofusername/public_html --destination=/home/$dirofusername/myetcandwork/mysite$( date +%H.%M_%d.%m.%Y ).tar
drush --root=/home/$dirofusername/public_html vset site_offline 0
Аватар пользователя jura12 jura12 28 ноября 2020 в 18:20

на любителя. если много машин . еще там алиасы настраивать. мороки много.

Аватар пользователя jura12 jura12 28 ноября 2020 в 7:05

в общем у меня заработал массовый запуск обновления для всех сайтов 8,9 те что на сервере сразу.

sudo su user1 -c 'bash -c /var/www/site1/updatedrupal.sh'
sudo su user2 -c 'bash -c /var/www/site2/updatedrupal.sh'