Массовое обновление d7/d8, как лучше?
Всем привет!
Наверняка у многих, кто делает сайты в основном на Drupal, и занимается поддержкой, накопился изрядный зоопарк из экземпляров различной сложности и версий. Уж у меня - так точно! В основном это сайты d7 и d8. И этот зоопарк надо содержать, чистить клетки и делать прививки.
В общем хотел поднять вопрос про обновления и рабочий процесс, с этим связанный.
Итак, у нас много (в основном не коммерческих) сайтов, которые обновляются раз в месяц. Если сайт на семёрке, работу с ним мы ведём прямо на сервере (Написал и затаился на секунду. Но нет, слава богу, молния не ударила.) Естественно есть бекапы и работа (в случае ошибок обновления, которые можно пересчитать по пальцам), не простаивает больше 10-20 минут.
В итоге 2 команды, и 2 минуты занимает обновление.
drush up
С восьмёркой всё сложнее. Я начал переходить на восьмёрку, когда ещё не имел практики работы с композером, и делал первые сайты на d8 по старинке, через drush. Года 2 назад, когда раскурил композер, стал переводить все, сделанные по старинке сайты на него. Но вот теперь, глядя, как хорошо обновлять сайты через drush и сравнивая с обновлением через композер, думаю что зря переводил.
composer работает медленней, жрет много памяти и на сервере с ним работать опасней и неудобно. Однако всё-равно быстрее, чем обновлять локально и заливать через git репозиторий.
Я вижу несколько решений:
- Научить стажера раз в месяц заходить и обновлять. Минус в том, что надо вручную отслеживать обновления безопасности ит.п.
- Настроить cron. Минус - не контролируешь процесс и надо вручную отслеживать SA.
- Использовать модуль Automatic Updates, но он не работает с композером.
В общем, хочу спросить, так ли нужен composer? В чём я ошибаюсь или что упускаю? И вообще у кого как решены эти проблемы? Или это не проблемы вовсе?
Заранее спасибо )
- Блог
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
Я всегда обновляю вручную.
Сайты на семерке тоже обновляю на сервере. Сайты на восьмерке обновляю локально, а потом GitLab CI деплоит
Про восьмёрку, напрягает, что надо хранить 10-ток сайтов локально, под каждый свой docker4drupal.. в общем как-то не оптимизировано кажется.
"под каждый свой docker4drupal" в смысле под каждый свой?
ну в каждой папке папке docker-compose и .env, который может быть неодинаковый.
И?
.htaccess и robots.txt тоже могут быть не одинаковыми.
Это тоже смущает?
.htaccess и robot.txt не тянут имиджы каждый под свою версию. Конечно стараемся унифицировать, но не всегда получается.
Алексей, я тоже все еще начинающий пользователь Композера. Может фигню сморозил.
Кароче, дамп БД +
docker-compose rm - все лишние имейджи удаляются.
Кстати а где эти имейджи лежат? Как их вес глянуть?
Если удалять контейнеры и имиджи, то при следующем старте он будет качать и создавать их снова.
лежат тут /var/lib/docker/
А в чем проблема? Я купил ssd на терабайт. На 3-5 лет хватит
Я пока так и делаю, только, всё же, напрягает ))
Поэтому ищу больше "промышленное" решение, которое можно будет масштабировать.
Промышленное - это то, что Александр Дубовской чуть ниже написал. Я пока для такого не созрел)
вот и я тоже )) Но ни чего.. не боги горшки обжигают ))
Был такой случай.
На сайте на семёрке был установлен модуль Display Suite. Причем, каждый раз глядя на него, я недоумевал - зачем он здесь, мы же используем панели, а формы не темизируем. Ну да ладно, работает - не трогай.
После очередного обновления безопасности DS, отвалились иконки цветов у атрибутов товара.
Дело в том, что цветов было гораздо больше 7, использовались комбинации этих цветов, и на странице каталога выводилось больше сотни таких иконок (30 карточек товара х 4-8 вариантов цвета в каждом).
Поэтому, генерить изображения для каждого цвета, поддерживать их в актуальном состоянии при редактировании атрибута, и тянуть на фронт 100+ иконок при каждой загрузке страницы каталога было совсем не вариант, цвета сделали инлайн-стилями:
style="background-color: <?php print $color; ?>"В общем-то, для такой задачи, я считаю, инлайн-стили - вполне приемлемое решение.
Обновление безопасности DS заключалось именно в том, чтобы вырезать недопустимые атрибуты тегов, в число которых попал и style. Тогда-то я и вспомнил, зачем нам DS на сайте. Фактически, все это время мы эксплуатировали незакрытую "дыру" (раз это было обновление безопасности) в коде модуля.
Отсюда мораль: никаких обновлений на проде. Сначала обновляем локально, смотрим дифф, чтобы понять в каких местах тестировать в первую очередь (вряд ли функционал ваших сайтов на 100% покрыт тестами), затем тестируем, и только после этого - выкатываем на прод.
Получается, что каждое обновление должно включать в рабочий процесс тестирование, в том числе и визуальное. Это в разы увеличит стоимость. Я повторюсь, что у меня речь о некоммерческих сайтах (садики, школы и администрации разных посёлков). Им платить тупо нечем. Мы берем 500 руб за обновление, но и от этого отказываются.
Поэтому вопрос не в том, как кошерно и бохато, а в том, как оптимизировать и делать это дешевле.
Самый оптимальный и дешевый вариант - не обновлять совсем. (Были и такие сайты).
Ну а дальше начинается компромисс между ценой и качеством.
Если владелец сайта согласен на вариант "мы сейчас накатим обновления, вы потом посмотрите, если где-то отвалится, то откатим обратно, правда придется заново создать весть контент с момента бэкапа" - то ок, почему бы и нет.
Ага ))
Только они приходят, когда хостер за рассылку спама забанит. ))
500р это 30-60 минут в зависимости от ставки. Даже 30 минут хватит, чтобы протестировать сайт после обновления
Во-первых, надо ставить уже второй композер. Он жрёт ресурсов в разы меньше. Это прямо очень заметно.
Во-вторых, чтобы не держать всё локально, можно посмотреть в сторону CI или даже просто Github actions. Нужно создать два экшена с мануальным триггером. Один будет выполнять в своей виртуалке composer update и в случае отсутствия ошибок делать коммит. А второй будет деплоить коммит на сервер. Можно конечно и в один экшн это засунуть. А ещё в экшн можно прописать, чтобы он сходил на продакшн, слил оттуда базу и накатил в тестовой среде drush updb.
Ну сказать по правде, это всё теория)) Максимум, что я делал - писал экшены, которые автоматом деплоят коммиты на продакшн - типа сделал git push с локалки и всё готово.
хм, недавно так сделал, восьмерка стала жаловаться на какие-то зависимости (проект старый)
Пришлось деградировать на 1.9
Там друпал-консоль надо снести и ещё пару зависимостей. Может быть какой час придётся повозиться, но оно того стоит.
Composer же прежде всего - для сохранения стейта и возможности делать деплой.
Для задачи вашего плана я бы рассмаотрел написать следующий скриптик:
- поднимаем контейнеры для теста
- скачиваем туда сайт с прода в докер
- запускаем composer update, drush updatedb/etc
- если без ошибок - загружаем назад и делаем composer install. (этот пункт имхо удобнее через что-то типа gitlabci коммитом, получаем запуск воркеров и наглядную инфу всё ли нормально прошло + удобный лог).
В целом автоматизируется и 99% кейсов может проходить без ручного внимания.
без композера нельзя пользоваться webform в 8,9. кроме того на него делается ставка.
я обслуживаю сайты так:
1. ежедневный инкрементальный бэкап.
2. для каждого сайта (8, 9) написан скрипт обновления. запускаю в ручную. но думаю написать один скрипт для всех сайтов. у меня 2х7, 8, 9.
Скрипт работает на сервере? Типа просто composer update, drush updb, etc.
да, все так. но есть фишки которые я хочу реализовать с помощью этого.
1. обновление всех сайтов одним скриптом он вызывает все локальные (для каждого сайта свой) скрипты. они в принципе похожи друг на друга.
2. автоматический вызов обновления когда это будет нужно. информация от drush core:requirements говорит что требуется обновление. но нужно тогда чтоб все модули были установлены через композер.
мне приходят письма от Security advisories. сейчас уже подписаться нельзя.
скрипт бэкапа, скрипт обновления.
P.S. а вот сайты на удаленных хостингах на друпал 7 обновлять сложно. думаю сначала организовать автоматический инкрементальный бэкап.
Чего сложного? Всё также, даже проще на одну команду, чем 8 - drush up на каждый сайт, с предварительным бекапом, если использовать такой подход.
Кстати, включать перед дампом режим обслуживания, как в скриптах выше, на мой взгляд, излишне.
И вообще, с таким зоопарком лучше какой-нибудь rsnapshot с pull стратегией а не push использовать, и тянуть бекапы себе, и от себя через ssh запускать скрипты, тогда их даже не придётся по серверам раскладывать. И всё будет более надёжно и централизовано.
у меня на удаленных серверах друпал 7 и там не работает drush потомучто версия пхп 7.3 в командной строке, а 5.5(4) уже не поддерживается. а композер для друпал 7 вроде не предназначен.
я еще подумаю.
Drush работающий с drupal 7 умеет работать с php 7.x, и кстати, наверняка есть не только php-cli 7.3, но и постарше под другим именем.
вот тут таблица совместимостей. о каком друше ты говоришь?
P.S. может плюсик означает что друш 8 работает с версиями пхп выше 5.4!?
Ага.
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 5.10.0
Вот пример даже более устаревший. Тут drush из репозитория OS.
Прям сегодня им был обновлён drupal...
Но использовать стоит 8.х drush, конечно.
я уже разобрался и настроил.
composer require drush/drush:8.*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.
набросал скрипт для быстрого бэкапа. но это не правильный бэкап. лучше инкрементальный.
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
может использовать drush aliases?
на любителя. если много машин . еще там алиасы настраивать. мороки много.
в общем у меня заработал массовый запуск обновления для всех сайтов 8,9 те что на сервере сразу.
sudo su user2 -c 'bash -c /var/www/site2/updatedrupal.sh'