Почувствуй себя собой

Чтобы сделать ваш проект таким же отказоустойчивым и масштабируемым, как, например, Spotify, нужно мигрировать в Kubernetes. Вокруг него много споров, но на текущий момент это один из лучших инструментов для контейнеризации больших проектов. И, надо сказать, задача переехать в него не самая простая.

Наши специалисты уже накопили достаточно опыта в работе с проектами, которые на разных этапах нуждались во внедрении или поддержке Kubernetes. Но чтобы грамотно внедриться в столь масштабный процесс из любой точки, важно не просто спросить команду клиента, что уже готово или что требуется от нас. Нужно иметь представление обо всех этапах работы, дабы не упустить ничего важного.

Если на вашем проекте планируется внедрение контейнеризации Kubernetes, предлагаем нашу статью для ознакомления с основными этапами этого процесса. Так вы будете понимать, к чему быть готовыми и сколько времени это займёт. В этой статье команда Initlab поделится опытом миграции различных проектов в Kubernetes и даст пошаговый план грамотного переезда.

11 этапов миграции

Любые описания таких сложных процессов лишь «пример в вакууме». Мы составили наш список, исходя из собственного опыта и приводим его как некий идеальный с нашей точки зрения вариант. Успешная миграция должна проходить по следующим этапам.

1. Аудит и документирование текущей серверной инфраструктуры проекта. На этом этапе мы определяем, какие приложения и на каких серверах запускаются, какой стек технологий используется. В случае, если нас приглашают на проект с уже запущенным процессом перехода на Kubernetes, мы должны оценить количество выполненных работ и готовых скриптов, которые можно использовать повторно. Результатом аудита является документ с описанием текущей инфраструктуры и взаимосвязей, а также оценкой состояния процесса миграции.

2. Формулирование требований к масштабированию и отказоустойчивости приложений. Здесь мы выясняем, требуется ли запуск дополнительных экземпляров приложений при увеличении нагрузки на систему. Помимо этого, для нас важно понимать, требуется ли запуск резервных копий приложений для повышения надёжности системы.

Например, у нас есть интернет-магазин, на который в чёрную пятницу ложится очень большая нагрузка. Чтобы сайт не тормозил и не падал, нам понадобится автоматическое развёртывание дополнительных веб-серверов, которое как раз можно реализовать при помощи Kubernetes.

3. Подготовка приложения к запуску в кластере Kubernetes. На этом шаге мы проверяем, соответствует ли приложение требованиям 12-факторного приложения. Мы описали это понятие с техническими подробностями на примере запуска Drupal в Kubernetes в этой статье. При необходимости дорабатываем и завершаем настройку приложения для соответствия требованиям. На этом этапе нашим DevOps-инженерам нужно знать ответы от команды разработки на следующие ключевые вопросы:

• работает ли приложение без сохранения состояния? (stateless)
• хранит ли состояние взаимодействия с пользователем? (stateful)

Для stateful:

• как организована работа с сессиями пользователей?
• каковы зависимости?
• как приложение настраивается и как запускается?

4. Контейнеризация каждого приложения. Создаём Docker-контейнеры. По возможности используем готовые базовые образы.

5. Проектирование и внедрение системы сбора логов и мониторинга приложений и кластера. В этот момент нужно решить, нет ли необходимости организовать сбор логов централизованно.

6. Автоматизация CI/CD. Она необходима, чтобы разработчики могли писать код приложений, который, по мере изменений, будет оперативно доставляться в кластер, благодаря чему соответствующие приложения смогут корректно собираться и перезапускаться. Иными словами, чтобы любые изменения и коммиты разработчиков вступали в силу при помощи автоматизации.

7. Подготовка сред и миграции, создание манифестов Kubernetes. На данном этапе выполняется настройка кластера Kubernetes, настройка необходимых для работы приложения СУБД, ПО для очередей и другого ПО. Для каждого сервиса подготавливается манифест для деплоя его в кластер Kubernetes. Выполняется запуск и тестирование деплоев всех сервисов и работы приложения.

8. Тестирование под нагрузкой, тестирование в случае сбоев. Работает ли кластер так, как он спроектирован? Выдерживает ли текущая инфраструктура необходимую нагрузку/количество обращений? На этом этапе тестируется отказ в работе нод кластера, выясняется, сколько по времени займёт перенос подов на рабочую ноду, а также проверяется отказ одного из нод в кластерах СУБД, очередей и подобного ПО.

9. Миграция приложений и запуск. Выполняется актуализация сервисов путем запуска деплоев для последних версий сервисов, актуализируются данные в СУБД и файлы во внешних хранилищах. В этом случае требуется приостановка работы приложения на время актуализации, чтобы не рассинхронизировались данные на старом и новом стенде. Также есть возможность переключения работы приложения без приостановки, когда на новом стенде настраиваются реплики для СУБД. В момент переключения они переводятся в мастер-роль. Затем выполняется переключения продакшн доменов на новый кластер.

10. Финальное тестирование после запуска. После запуска приложения на основном домене, тестировщики проводят полноценное тестирование его функционала с целью поиска ошибок и дальнейшего их устранения. В случае, если они будут слишком серьёзными и помешают дальнейшей работе приложения, их исправление может занять продолжительное время. В таком случае, вероятнее всего, придётся переключиться обратно на старый стенд и исправить найденные ошибки.

11. Мониторинг и поддержка кластера Kubernetes. Мониторинг — регулярная проверка работоспособности всех компонентов кластера Kubernetes: системных, а также запущенных подом с сервисами. Проверяется их работа, а также количество рестартов. В случае, если сервис часто перезагружается, это говорит о проблемах, которые необходимо устранить. Также выполняется мониторинг всего дополнительного ПО для работы приложения — СУБД, очередей, хранилищ и т.д.

Поддержка кластера — обработка проблем, найденных при помощи мониторинга. В развивающемся проекте — добавление новых сервисов: контейнеризация, написание манифестов, написание CI/CD, деплой. А также интеграция тестирования в процессы CI/CD, интеграция проверок на уязвимости в коде сервисов и docker-образов.

Канареечные релизы

Чтобы не бояться масштабных перемен при миграции приложений и запуске, Kubernetes позволяет делать развёртывание и откаты сервисов новых версий. Это означает, что мы можем совершать так называемые канареечные релизы — частично запускать новую версию и переводить часть пользователей на неё. Это помогает оценивать изменение нагрузки, отслеживать ошибки, контролировать состояние проекта и в случае, если всё идёт хорошо, плавно продолжать перевод на новую версию.

При этом данный процесс автоматизирован. В случае критических неполадок можно также автоматически откатиться на предыдущую версию для исправления ошибок.

Наши кейсы

Разумеется, наш опыт не ограничивается тремя кейсами. Мы подобрали их для демонстрации вступления на проект на разных этапах.

Проект №1. Приложение для взаимодействия с автомобилем

Отрасль: приложение для автомобиля: управление, заправка, отслеживание маршрутов, штрафы и счета за парковку. Каждый функционал — отдельный сервис, который запускается в кластере.

Язык, платформа приложения:

• Node.js — фронт и бэк сервисы;
• Python — бэкенд;
• PHP (Laravel) — бэкенд.

Какие шаги проделали:

На старте работы с проектом все микросервисы запускались отдельно на одном-единственном сервере. В какой-то момент количество сервисов сильно увеличилось — их стало около 50, из-за чего стало сложно управлять ими.

Понадобилось:

• с нуля проектировать архитектуру, мигрировать и запускать проект;
• масштабировать некоторые микросервисы, чтобы ускорить обработку данных;
• осуществить переезд с одного облака на другое, который мы заодно связали с настройкой кластера;
• повышать отказоустойчивость, потому что все системы были в единичном экземпляре. Один сервер под приложение привёл к тому, что выход из строя любого сервера приводил к недоступности всего приложения. Поэтому был развернут кластер, где под сервисы выделен пул серверов, а также все системы (СУБД, очереди) развернуты в кластерном виде.

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

В кластере настроен CI/CD. Для каждого сервиса реализована проверка его работоспособности, а в случае обнаружения некорректного функционирования, выполняется его перезагрузка. Разработчикам стало проще: они могут вносить свои изменения в процесс запуска приложения.

Срок реализации: 6 месяцев.

Проект №2. Туристический портал

Отрасль: сервис для планирования путешествий

Язык, платформа приложения:

• Node.js — фронт и бэк сервисы;
• Java — бэкенд.

Какие шаги проделали:

Перед нами стояла задача: из существующего dev-а развернуть кластер для prod-а с учётом нагрузки и отказоустойчивости. Приложение было уже разработано.

Понадобилось:

• спроектировать архитектуру серверов и служб (СУБД, очереди, кэш) под prod;
• настроить отказоустойчивость СУБД, служб очередей, кэширования;
• настроить сервера под кластер k8s;
• настроить CI/CD для prod-а кластера.

В этом кейсе за отдельный функционал каждого микросервисного приложения отвечает разный сервис. Фронт — отдельный сервис, т.е. отображение, которое обращается к большому количеству сервисов бэка. На сайте могут быть условные отели, кинотеатры, самолёты в виде отдельных сервисов, которые, при взаимодействии через фронт, начинают обращаться к своему правильному сервису бэка. Обычно для приложений, которые разделяются на фронт и на бэк, а также при большом количестве бэкэнд-сервисов как раз используется Kubernetes.

Бэкэнд — это сервис, у которого нет графического интерфейса. Он отвечает на запрос текстом, из которого фронт строит итоговое отображение. Например, если нас интересует театр, бэк ответит массивом спектаклей с названиями, афишами и url-ами для бронирования.

Срок реализации: 6 месяцев.

Проект №3. Государственный портал

Отрасль: госзакупки

Язык, платформа приложения:

• Java

Какие шаги проделали:

Сервис «большие данные» в экосистеме портала предназначался для обработки данных, которые настолько секретны, что мы не можем на них сослаться. От предыдущих разработчиков нам был передан архив с кодом и скриптами развертывания.

Понадобилось:

• в первую очередь развернуть dev;
• затем развернуть prod;
• исправить скрипты развертывания, так как это всё разрабатывалось давно и версии софта и библиотек устарели в зависимостях сервисов.
• настроить CI/CD для автоматического деплоя.

В основном из проблем со сборкой сервисов долго разворачивался первый dev стенд, пока нас не связали с разработчиками и они не помогли собрать сервисы. Пришлось ставить свой репозиторий для mvn библиотек и собирать библиотеки, которые являются зависимостями в сервисах. После запуска мы исправляли конфигурации сервисов и настраивали интеграции между ними, а без знания проекта было очень сложно.

Затем prod развернули буквально за пару недель, так как всё было актуализировано и работало.

Срок реализации: 6 месяцев.

Ещё немного о сроках развёртывания и процессе запуска

Может показаться, что часть проектов нам досталась на полпути, но на самом деле все три кейса — это развертывание кластера с нуля. И хотя в двух случаях мы получили скрипты и код,

• в Проекте №1 были инфраструктурные сложности, он осуществлялся вместе с поддержкой проекта, из-за чего затянулся переезд;
• в Проекте №2 нужно было продумать и организовать архитектуру + процесс получился довольно долгим, потому что параллельно велась разработка и несколько месяцев добавляли сервисы и исправлялись текущие. К идеалу пришлось идти долго.

Если же все приложения контейнеризованы, то есть выполнены 5-10 шаги, по опыту больших данных, миграция готового рабочего проекта может занять около двух недель.

Иногда часть третьего пункта сделана заказчиком. То есть мы заходим на проект, проводим аудит готовых скриптов, аудит качества контейнеризации, но такое происходит нечасто — в основном работаем с нуля. Без погружения в проект нельзя быть уверенным в том, насколько хорошо всё уже работает и спрогнозировать, как процесс пойдёт в дальнейшем.

Запуск на девятом шаге, одном из самых ответственных, происходит в зависимости от архитектуры приложения. Если его можно разделить на части так, чтобы одна часть работала в одном месте, а другая в другом, то можно переносить частично и постепенно исправлять ошибки миграции.

Но если все сервисы представляют одно приложение и общаются между собой, как в Проекте №1, то переезд всего приложения осуществляется целиком. В этом случае очень важно, чтобы была возможность тестирования новой среды.

При миграции нам нужно актуализировать данные на новом кластере а потом переключить трафик на него. Есть случаи, когда можно это сделать без остановки — тогда нужно настраивать репликацию всех данных в новый кластер, а есть когда остановка нужна.

Заранее сказать, сколько времени займет миграция, очень сложно и ближе к невозможному. Проекты, на которых требуется внедрение Kubernetes в большинстве своём очень крупные, где нельзя всё продумать и предусмотреть. Особенно пока devops не знает нюансов приложения и что ему требуется для работы.

В случае, когда нас привлекают для всех этапов целиком, начиная с первого шага, заканчивая мониторингом и поддержкой, нам приходится плотно взаимодействовать с разработчиками, проводить аудиты, документировать систему приложений и проектировать кластер, при необходимости задействовать инфраструктурные сервисы initlab для мониторинга и CI/CD кластера Kubernetes или внедрять новые по требованиям заказчика.

Переходить в Kubernetes или нет?

Однозначного ответа на вопрос о переходе нет. С уверенностью можно говорить только о проектах с большими массивами данных и количеством приложений. С увеличением количества последних работоспособности серверов может начать не хватать и контейнеризация станет единственным выходом из положения. Тем, кто планирует расширяться и тем, кто уже на грани своих возможностей однозначно стоит рассмотреть вариант переезда в кластер Kubernetes, который работает на любых платформах.

Если вы планируете переезд проекта в кластер Kubernetes для масштабирования и повышения отказоустойчивости или вашему проекту нужна поддержка кластера k8s — обращайтесь к нам. 



Источник: https://vc.ru/dev/782278-kubernetes-masshtabirovanie-rezervirovanie-etapy-i-sroki

Есть вопрос

Статьи и публикации

Релиз Drupal 10 состоялся в декабре 2022 года, на фоне чего клиенты всё чаще приходят в Drupal-студии с запросом на обновление версии CMS до свежей. На официальном сайте Drupal можно изучить, на каком ядре и в каких количествах работают сайты по всей планете — видно, что пока растёт число сайтов на десятой версии, с её предшественниками всё наоборот.

Если у вас уже есть сайт на Drupal, то его обновление займёт от 20 до 200 часов — объём контента, контрибных и кастомных модулей, профайлов и тем, а также наличие на сайте сторонних сервисов влияют на продолжительность процедуры. Последовательность обновления давно прописана и понятна, что лишает эту работу творчества, а потому её хотелось бы сделать поскорее. На основе лучших практик и своих взглядов на процесс мы собрали инструкцию, как сократить время на обновление Drupal-сайта примерно в два раза.

РАЗРАБОТЧИКИ! Пропустите первые два раздела статьи и начинайте с того, что мы рекомендуем помнить перед началом обновления ядра.

Если вы разработчик или владелец сайта, построенного на устаревающей версии Drupal, и планируете обновление версии ядра либо вообще не задумывались об этом, эта статья окажется для вас полезной.

Зачем обновлять версию ядра Drupal

Представьте, что вы вышли на улицу: этот город, район, дорога вдоль домов и сам дом знакомы вам много лет, а до вас здесь жили ваши родители. Все вы помните времена, когда место было чище и спокойнее, а теперь тут всё реже появляются даже уборщики мусора и полиция — район стал ульем криминала и маргиналов. Заблудившиеся здесь люди уйдут отсюда в лучшем случае без денег и смартфонов. Что делать? Можно лично воевать с бандами, создать общественную дружину для контроля за порядком, вставлять новые стёкла вместо разбитых. А можно переехать в другой район или город, где за порядком следят власти. И сделать это так быстро, как это возможно.

Сайты на устаревающих и неподдерживаемых версиях Drupal чем-то похожи на когда-то цветущие, а теперь неблагополучные районы. Что делают владельцы почти 15 тысяч сайтов на Drupal 6 для поддержания их работы? Неужели сами выпускают патчи безопасности для модулей, не поддерживаемых ни разработчиками ядра, ни сообществом? Это напоминало бы ту самую замену выбитого окна: его разобьют снова, это тщетно. Можно стараться поддерживать интерфейс на современном уровне, но от него нет никакого толка, если через разбитые окна небезопасных модулей лезут хакеры и гигабайтами выносят данные о вас и ваших пользователях.

В целом, работа сайта на устаревших версиях Drupal негативно затрагивает:

• кибербезопасность. Если никто не занимается рефакторингом кода, на котором написан модуль, и не пишет для этих модулей патчи, образуется уязвимость, через которую хакеры будут делать на вашем сайте свои грязные дела — это станет заметно и по жалобам пользователей, и по директориям проекта, где вдруг появятся лишние папки и файлы с вредоносным кодом. Ущербы от кибератак измеряются десятками миллионов долларов;
• функциональность. С появлением новой версии Drupal большая часть сил дизайнеров и разработчиков бросается на то, чтобы духу времени отвечали возможности новой версии, а не старых. Поэтому сайты на старых версиях Drupal просто не могут решать современные задачи и радовать внешним видом;
• работу с хостингом. Для хостинг-провайдеров нерентабельно держать и обслуживать оборудование, работающее со старыми версиями языка PHP и старыми версиями баз данных, с которыми работали прежние версии Drupal;
• работу со сторонними сервисами. API всех существующих сейчас сервисов наверняка заточены под работу с современным программным обеспечением.

Обновление до Drupal 10

Опытные разработчики помнят, что обновляя ядро на версиях Drupal 7 и ниже, они были вынуждены переписывать темы оформления и править кастомный код. Объём изменений зависел от сложности сайта и количества кастомного кода, но после обновления версии Drupal это был в значительной степени новый сайт. В ядре Drupal 7 устаревший код хоть и помечался, но политика системы к этому не обязывала — разработчики делали это на своё усмотрение.

Drupal 8 принёс с собой новый подход к обновлению ядра этой CMS, который сохраняется и сейчас. В основе этого подхода лежит семантическое версионирование — принцип присвоения любому программному обеспечению мажорных, минорных и патч-версий, а также версий с маркировками, намекающими на промежуточный характер обновления, которое может вести себя неправильно.

В Drupal 8 появились компоненты фреймворка Symfony, а он, в свою очередь, позволяет разработчикам обновлять Drupal через пакетный менеджер Composer, работающий с принципом семантического версионирования. Это открыло дорогу к поддержке обратной совместимости между версиями Drupal: неработающий код помечается, но удаляется постепенно, и у разработчика есть возможность найти новый способ сохранить функциональность сайта, которую этот код обслуживал.

Таким образом, после прихода Drupal 8 значительно уменьшилась вероятность непредсказуемого появления ошибок при обновлении ядра. Вся кодовая база проверялась на наличие неблагонадёжных кусков кода (так называемый цикл депрекации), которые помечаются как устаревшие для их последующего удаления разработчиками сайтов. Как итог, обновление до Drupal 10 занимает не больше времени, чем обновление на какую-нибудь минорную версию.

Важное замечание: все рекомендации в этой статье справедливы только в случае, если вы будете обновляться с Drupal 9 на Drupal 10. Если же сайт работает на Drupal 7, то одним махом перескочить на Drupal 10 не получится — это уже называется миграцией сайта и требует других инструкций.

Что нужно знать и помнить перед обновлением до Drupal 10

• Сайт должен работать минимум на Drupal 9.4. Почему это важно? Пропустив эту версию и залетев в десятку, например, с Drupal 9.3, ваш сайт рано или поздно перестанет работать из-за устаревших API (Entity API, Database API и др.).
• Ключевая процедура в обновлении до Drupal 10 — это обновление обратных зависимостей. Composer — ваш главный друг в этой задаче.
• Кастомные и контрибные модули и темы должны быть актуальной версии.
• Для поиска и устранения проблем в PHP-коде проекта вам понадобятся либо интегрированная среда разработки PHPStorm, либо модуль Upgrade Status. Последний надо отключить перед самим обновлением и удалить после.
• Ваш сервер должен быть технически готов к новой версии CMS. Ниже — требования к версиям языка PHP, веб-серверам и базах данных, с которыми совместим Drupal 10.
• убедитесь в будущей совместимости системы и проекта через проверку Database support for JSON: откройте в панели вкладку Reports и перейдите на страницу Status report — она должна быть в статусе Available. Другой способ проверить совместимость — через модуль Upgrade status: в той же вкладке Reports откройте страницу Upgrade status и прочтите отчёт Drupal core and hosting environment.

Пошаговая инструкция быстрого обновления сайта с Drupal 9 на Drupal 10

1. Обновите свой сайт до последней версии Drupal 9 (9.4 минимум).

• Обновите ядро:

composer update "drupal/core-*" --with-all-dependencies

• Обновите все контрибные модули в Composer:

composer update

• Запустите апдейт базы:

drush updatedb
drush cache:rebuild

• Убедитесь, что сайт работает.
• Добавьте или обновите патчи, если требуется.

2. Обновитесь до Drupal 10.

Отредактируйте файл composer.json и обновите версию для ядра drupal/core-* до ^10.

"require" : {
"composer/installers" : "^2.0"
"drupal/core-composer-scaffold" : "^10"
"drupal/core-project-message" : "^10"
"drupal/core-recommend" : "^10"

Помимо указанных комонентов, в composer.json могут также входить компоненты drupal/core-dev и drupal/core.

Как только вы запустите composer update, начнётся обновление.

3. Примените патч совместимости к модулям без версии для Drupal 10.

Такие патчи можно найти в разделе Issues соответствующего модуля, а сама issue называется Automated Drupal 10 compatibility fixes. Далее можно либо отредактировать версию ядра в composer.json, заменив “^10” на “10.0.9 as 9.5.9”, либо воспользоваться плагином composer drupal lenient.

4. Добавьте устаревшие модули и темы.

Если вы используете на вашем сайте модули и темы, которые были удалены из ядра Drupal, то добавьте их контрибные версии в свой файл composer.json.

Например, так выглядит команда добавления темы Bartik, которая была дефолтной со времён Drupal 7, но к Drupal 10 сменилась на Olivero:

composer require 'drupal/bartik:^1.0'

5. Обновите версии совместимости в кастомных модулях и темах.

• Удалите из файла my_module.info.yml строку core, если она есть (например, core: 8.x).
• В строке core_version_requirement добавьте 10 версию, например вместо core_version_requirement: ^8 || ^9 должно получиться core_version_requirement: ^8 || ^9 || ^10.
• Если ваш сайт использует устаревшую тему в качестве базовой (например, тему Classy), то её можно поменять на рекомендуемую Starterkit: base theme: classy заменить в my_theme.info.yml на base theme: starterkit_theme.То же самое касается темы Stable, которую можно поменять на stable9. В этом случае нужно поменять библиотеку базовой темы и в Twig-шаблонах, если она там используется.

Пример: строка {{ attach_library('classy/node') }} меняется на {{ attach_library('starterkit_theme/node') }} ).

• Не забудьте включить starterkit_theme, если решили использовать её в качестве базовой темы — она должна появиться в конфигурационном файле core.extension.yml. В конце обновления сайта заменённые устаревшие темы можно будет удалить из файла composer.json.
• найдите и удалите в PHP-коде все вызовы устаревшего API и поправьте код так, чтобы использовался только новый API.

Пример: Устаревшая функция drupal_get_path('module', 'my_module_name') меняется на \Drupal::service('extension.list.module')->getPath('my_module_name')

Если в качестве IDE вы используете PhpStorm, то в настройках проекта можно запустить проверку кода с помощью PHP_CodeSniffer:

• Установите PHP_CodeSniffer через Composer:

composer global require "squizlabs/php_codesniffer=*"

• В разделе Quality Tools зайдите в настройки Code Sniffer и задайте пути до файлов phpcs и phpcbf.
• В разделе Editor -> inspections выберите авто-проверку.

Как искать ошибки в коде с помощью Upgrade status:

• Во вкладке Reports откройте страницу Upgrade status.
• Изучите содержание раздела Drupal core and hosting environment.

6. Twig обновился до 3 версии, поэтому вам может понадобиться обновить ваши Twig-файлы.

Как обновить Twig-файлы с использованием PhpStorm:

• Выполняйте действия по цепочке: Code → Analyze Code → Run Inspection by name и нажмите Enter. Второй вариант: комбинация SHIFT + SHIFT → начните вводить Run inspection by name и нажмите Enter. В результате появится окно Enter inspection name.
• В окне введите Deprecated Twig extension, нажмите Enter. Откроется модальное окно.
• В окне найдите раздел Inspection Scope, выберите Custom Scope и выберите Scope только с собственным кодом.
• Нажмите OK, дождитесь завершения анализа и изучите файлы и места с устаревшим кодом.

Как обновить Twig-файлы с использованием Upgrade Status:

• Во вкладке Reports откройте страницу Upgrade status.
• Укажите собственные модули и темы и нажмите Scan selected.
• После сканирования исправьте указанные ошибки.

7. Обновите зависимости в ваших файлах .libraries.yml.

Например, если в зависимостях у вас есть библиотека core/jquery.once, то замените её на библиотеку core/once, так как теперь once — это отдельная библиотека. Соответственно, JS-код, где используется once, нужно отредактировать:

8. Убедитесь, что ваш код не устарел и удовлетворяет требованиям PHP 8.1.

Для проверки можно использовать модуль Upgrade status. Для этого добавьте с помощью Composer пакет phpcompatibility/php-compatibility в секцию require-dev, а после установки пакета проверьте код своего модуля командой:

phpcs -p ./path/to/my/module --extensions=php,module,inc,install,test,profile,theme --standard=vendor/phpcompatibility/php-compatibility/PHPCompatibility --runtime-set testVersion 8.1

Если всё ок, вы увидите, например, это:

9. Если вы обновляете Drupal до 10.1.x, убедитесь, что после обновления конфигураций в файле core.extension.yml появился модуль Password Compatibility (phpass) (Password hashing is changed).

10. Запустите обновление базы.

drush updatedb

После обновления сайта в Status report может появиться ошибка Mismatched entity and/or field definitions.

Её можно исправить, вставив код ниже в свой модуль и запустив обновление:

<?php/**   
* Implements hook_update_N().   
*/   
function HOOK_update_8701() {

 $entity_type_manager = \Drupal::entityTypeManager();   
 $entity_type_manager->clearCachedDefinitions();

 $entity_type_ids = [];   
 $change_summary = \Drupal::service('entity.definition_update_manager')->getChangeSummary();   
 foreach ($change_summary as $entity_type_id => $change_list) {   
   $entity_type = $entity_type_manager->getDefinition($entity_type_id);   
   \Drupal::entityDefinitionUpdateManager()->installEntityType($entity_type);   
   $entity_type_ids[] = $entity_type_id;   
 }   
 
 return t("Installed/Updated the entity type(s): @entity_type_ids", [   
   '@entity_type_ids' => implode(', ', $entity_type_ids),   
 ]);   
}?>

После обновления вы не должны найти эту ошибку в Status report.

Шаблон шпаргалки для быстрого обновления сайта до Drupal 10

Однажды наш Drupal-разработчик обновляла не особо большой клиентский сайт до Drupal 10. В перспективе маячил ещё один подобный сайт. А сколько их ещё впереди, таких же или сложнее? Поэтому, чтобы не вспоминать каждый раз заново, что разработчик делала с тем или иным модулем и темой, она составила себе несколько таблиц с типичным поведением, которое надо применять к модулям, темам и конфигам, которые встречаются на проектах: поменять на dev или patch-версию, применить хук, пометить модуль как контрибный и т. п.

В левой части таблицы — установленные на сайте модуль или тема, в правой — изменения, которые надо внести в файл composer.json, чтобы эти модули и темы работали на Drupal 10. Как интерпретировать комментарии в правой части:

• 10.0.9 as 9.5.9 — после применения патчей совместимости к модулям без версий для Drupal 10 редактируется версия ядра: “^10” меняется на “10.0.9 as 9.5.9”.
• Automated Drupal 10 compatibility fixes patch — если модуль или тема не имеют даже dev-версии для Drupal 10, либо поищите патч в Issues проекта либо сразу гуглите название модуля или темы вместе с названием issue: Automated Drupal 10 compatibility fixes patch.
• 5.x-dev@dev — модуль, не поддерживающий работу с Drupal 10, заменен на dev-версию.
• contrib now — модуля больше нет в ядре Drupal, поэтому его нужно прописать в composer.json.

Эта таблица нужна для пометок об изменениях в config-файлах. В частности, описано, как обновляются старые темы на сайте на новые.

В этой таблице фиксируются состояния зависимостей до их обновления в ваших файлах .libraries.yml и то, как их нужно обновить.

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

По ссылке вы найдёте Google-таблицу, структура которой готова к тому, чтобы вы или разработчик из вашей команды делали пометки для своих проектов. Таблица открыта только для чтения, поэтому сделайте копию для себя.

Желаем вам безболезненного и быстрого обновления до последней версии Drupal!

Оригинал статьи был опубликован в блоге ADCI Solutions.

Drupal10

Есть вопрос

Статьи и публикации

Сбор заявок на участие в конкурсе Russian Drupal Awards продлён до 28 июля. Это связано с тем, что по некоторым из номинаций сейчас есть очевидный недобор, и обеспечить между участниками конкурентную борьбу за призовые места нельзя. Эти номинации укомплектуются в том числе за счёт тех участников, которые пожелали доработать текущие проекты, написать подробные кейсы и представить свою работу на конкурс в лучшем виде. Организаторы, компания ADCI Solutions, приветствует рост качества подаваемых работ, поэтому приняли этот запрос с пониманием.

Параллельно со сбором заявок организаторы работали над рейтингом Drupal-студий и фрилансеров, составленным исключительно из участников Russian Drupal Awards. Одним из главных условий конкурса является разработка сайтов для русскоговорящей аудитории, но сами участники могут находиться в любой стране. Поэтому сейчас география участников, помимо России, охватывает Турцию, Беларусь, Армению и Азербайджан.

На место в рейтинге влияет количество баллов, выставленных членами жюри работам, количество работ от одного участника и наличием призовых мест.

Основатель компании Александр Кузнецов делится планами по развитию рейтинга в своём посте на vc.ru:

«Да, сейчас мы поощряем участников за число поданных работ. Но мы уже видим, как будем проводить ревизии в будущем: этот сайт — он всё ещё на Drupal или его перевели на другую CMS? а вот этот сайт — им занимается та же самая студия, которая подавала его на участие, или уже другая? Мы только в начале пути, но рейтинг работает и клиентам есть куда смотреть при выборе профессиональных Drupal-разработчиков на свой проект».

Заявки принимаются через форму на сайте конкурса: russiandrupalawards.ru

Конкурс поддерживают: ДАЛЕЕ, WEBSHOP, Selfin.pro, РаДон, РАЭК, Русскоязычное сообщество Drupal, Южное сообщество Drupal, Niklan, Runet-ID, CMS magazine, Envybox, Workspace, ICT ONLINE, ICT2GO.

Есть вопрос

Статьи и публикации