Расправь свои плечи!Я - это я, а ты - это ты. Если нам удалось встретиться - это великолепно, если нет - этому нельзя помочь (Гештальт-молитва, Ф. Перлз). Мой путь - не такой, как у тебя, а твой путь - не такой, как мой. Каждый из нас идёт по жизни своими тигриными тропами. Но иногда возникает желание поделиться описанием своих тропинок. А иногда - прочитать про пути соседей. Здесь - можно сделать и то и другое. Есть желание присоединиться? Много разных возможностей заниматься йогой в Омске и на этом сайте Вы можете выбрать йогу для себя. Вход для пользователейКак мотивировать себя что-то делать? |
СайтостроениеМиграция проекта в Kubernetes: из каких этапов состоит и сколько времени занимает. Опыт IT-компанииЧтобы сделать ваш проект таким же отказоустойчивым и масштабируемым, как, например, Spotify, нужно мигрировать в Kubernetes. Вокруг него много споров, но на текущий момент это один из лучших инструментов для контейнеризации больших проектов. И, надо сказать, задача переехать в него не самая простая. Наши специалисты уже накопили достаточно опыта в работе с проектами, которые на разных этапах нуждались во внедрении или поддержке Kubernetes. Но чтобы грамотно внедриться в столь масштабный процесс из любой точки, важно не просто спросить команду клиента, что уже готово или что требуется от нас. Нужно иметь представление обо всех этапах работы, дабы не упустить ничего важного. Если на вашем проекте планируется внедрение контейнеризации Kubernetes, предлагаем нашу статью для ознакомления с основными этапами этого процесса. Так вы будете понимать, к чему быть готовыми и сколько времени это займёт. В этой статье команда Initlab поделится опытом миграции различных проектов в Kubernetes и даст пошаговый план грамотного переезда. Любые описания таких сложных процессов лишь «пример в вакууме». Мы составили наш список, исходя из собственного опыта и приводим его как некий идеальный с нашей точки зрения вариант. Успешная миграция должна проходить по следующим этапам. 1. Аудит и документирование текущей серверной инфраструктуры проекта. На этом этапе мы определяем, какие приложения и на каких серверах запускаются, какой стек технологий используется. В случае, если нас приглашают на проект с уже запущенным процессом перехода на Kubernetes, мы должны оценить количество выполненных работ и готовых скриптов, которые можно использовать повторно. Результатом аудита является документ с описанием текущей инфраструктуры и взаимосвязей, а также оценкой состояния процесса миграции. 2. Формулирование требований к масштабированию и отказоустойчивости приложений. Здесь мы выясняем, требуется ли запуск дополнительных экземпляров приложений при увеличении нагрузки на систему. Помимо этого, для нас важно понимать, требуется ли запуск резервных копий приложений для повышения надёжности системы. Например, у нас есть интернет-магазин, на который в чёрную пятницу ложится очень большая нагрузка. Чтобы сайт не тормозил и не падал, нам понадобится автоматическое развёртывание дополнительных веб-серверов, которое как раз можно реализовать при помощи Kubernetes. 3. Подготовка приложения к запуску в кластере Kubernetes. На этом шаге мы проверяем, соответствует ли приложение требованиям 12-факторного приложения. Мы описали это понятие с техническими подробностями на примере запуска Drupal в Kubernetes в этой статье. При необходимости дорабатываем и завершаем настройку приложения для соответствия требованиям. На этом этапе нашим DevOps-инженерам нужно знать ответы от команды разработки на следующие ключевые вопросы:
Для stateful:
4. Контейнеризация каждого приложения. Создаём Docker-контейнеры. По возможности используем готовые базовые образы. 5. Проектирование и внедрение системы сбора логов и мониторинга приложений и кластера. В этот момент нужно решить, нет ли необходимости организовать сбор логов централизованно. 6. Автоматизация CI/CD. Она необходима, чтобы разработчики могли писать код приложений, который, по мере изменений, будет оперативно доставляться в кластер, благодаря чему соответствующие приложения смогут корректно собираться и перезапускаться. Иными словами, чтобы любые изменения и коммиты разработчиков вступали в силу при помощи автоматизации. 7. Подготовка сред и миграции, создание манифестов Kubernetes. На данном этапе выполняется настройка кластера Kubernetes, настройка необходимых для работы приложения СУБД, ПО для очередей и другого ПО. Для каждого сервиса подготавливается манифест для деплоя его в кластер Kubernetes. Выполняется запуск и тестирование деплоев всех сервисов и работы приложения. 8. Тестирование под нагрузкой, тестирование в случае сбоев. Работает ли кластер так, как он спроектирован? Выдерживает ли текущая инфраструктура необходимую нагрузку/количество обращений? На этом этапе тестируется отказ в работе нод кластера, выясняется, сколько по времени займёт перенос подов на рабочую ноду, а также проверяется отказ одного из нод в кластерах СУБД, очередей и подобного ПО. 9. Миграция приложений и запуск. Выполняется актуализация сервисов путем запуска деплоев для последних версий сервисов, актуализируются данные в СУБД и файлы во внешних хранилищах. В этом случае требуется приостановка работы приложения на время актуализации, чтобы не рассинхронизировались данные на старом и новом стенде. Также есть возможность переключения работы приложения без приостановки, когда на новом стенде настраиваются реплики для СУБД. В момент переключения они переводятся в мастер-роль. Затем выполняется переключения продакшн доменов на новый кластер. 10. Финальное тестирование после запуска. После запуска приложения на основном домене, тестировщики проводят полноценное тестирование его функционала с целью поиска ошибок и дальнейшего их устранения. В случае, если они будут слишком серьёзными и помешают дальнейшей работе приложения, их исправление может занять продолжительное время. В таком случае, вероятнее всего, придётся переключиться обратно на старый стенд и исправить найденные ошибки. 11. Мониторинг и поддержка кластера Kubernetes. Мониторинг — регулярная проверка работоспособности всех компонентов кластера Kubernetes: системных, а также запущенных подом с сервисами. Проверяется их работа, а также количество рестартов. В случае, если сервис часто перезагружается, это говорит о проблемах, которые необходимо устранить. Также выполняется мониторинг всего дополнительного ПО для работы приложения — СУБД, очередей, хранилищ и т.д. Поддержка кластера — обработка проблем, найденных при помощи мониторинга. В развивающемся проекте — добавление новых сервисов: контейнеризация, написание манифестов, написание CI/CD, деплой. А также интеграция тестирования в процессы CI/CD, интеграция проверок на уязвимости в коде сервисов и docker-образов. Канареечные релизыЧтобы не бояться масштабных перемен при миграции приложений и запуске, Kubernetes позволяет делать развёртывание и откаты сервисов новых версий. Это означает, что мы можем совершать так называемые канареечные релизы — частично запускать новую версию и переводить часть пользователей на неё. Это помогает оценивать изменение нагрузки, отслеживать ошибки, контролировать состояние проекта и в случае, если всё идёт хорошо, плавно продолжать перевод на новую версию. При этом данный процесс автоматизирован. В случае критических неполадок можно также автоматически откатиться на предыдущую версию для исправления ошибок. Наши кейсыРазумеется, наш опыт не ограничивается тремя кейсами. Мы подобрали их для демонстрации вступления на проект на разных этапах. Проект №1. Приложение для взаимодействия с автомобилем Отрасль: приложение для автомобиля: управление, заправка, отслеживание маршрутов, штрафы и счета за парковку. Каждый функционал — отдельный сервис, который запускается в кластере. Язык, платформа приложения:
Какие шаги проделали: На старте работы с проектом все микросервисы запускались отдельно на одном-единственном сервере. В какой-то момент количество сервисов сильно увеличилось — их стало около 50, из-за чего стало сложно управлять ими. Понадобилось:
Также мы настроили мониторинг доступности при запуске сервисов в кластере. Он проверяет работоспособность сервисов и оповещает о проблемах в кластере. Миграция в кластер позволила гибко распределять ресурсы серверов под сервисы. Был выделен пул серверов, на которых запущены сервисы, и если какой-то из них начинает потреблять много ресурсов, происходит перераспределение сервисов на нодах так, чтобы остальные сервисы продолжали работать, а самый ресурсоёмкий сервис не мешал. В кластере настроен CI/CD. Для каждого сервиса реализована проверка его работоспособности, а в случае обнаружения некорректного функционирования, выполняется его перезагрузка. Разработчикам стало проще: они могут вносить свои изменения в процесс запуска приложения. Срок реализации: 6 месяцев. Проект №2. Туристический портал Отрасль: сервис для планирования путешествий Язык, платформа приложения:
Какие шаги проделали: Перед нами стояла задача: из существующего dev-а развернуть кластер для prod-а с учётом нагрузки и отказоустойчивости. Приложение было уже разработано. Понадобилось:
В этом кейсе за отдельный функционал каждого микросервисного приложения отвечает разный сервис. Фронт — отдельный сервис, т.е. отображение, которое обращается к большому количеству сервисов бэка. На сайте могут быть условные отели, кинотеатры, самолёты в виде отдельных сервисов, которые, при взаимодействии через фронт, начинают обращаться к своему правильному сервису бэка. Обычно для приложений, которые разделяются на фронт и на бэк, а также при большом количестве бэкэнд-сервисов как раз используется Kubernetes. Бэкэнд — это сервис, у которого нет графического интерфейса. Он отвечает на запрос текстом, из которого фронт строит итоговое отображение. Например, если нас интересует театр, бэк ответит массивом спектаклей с названиями, афишами и url-ами для бронирования. Срок реализации: 6 месяцев. Проект №3. Государственный портал Отрасль: госзакупки Язык, платформа приложения:
Какие шаги проделали: Сервис «большие данные» в экосистеме портала предназначался для обработки данных, которые настолько секретны, что мы не можем на них сослаться. От предыдущих разработчиков нам был передан архив с кодом и скриптами развертывания. Понадобилось:
В основном из проблем со сборкой сервисов долго разворачивался первый dev стенд, пока нас не связали с разработчиками и они не помогли собрать сервисы. Пришлось ставить свой репозиторий для mvn библиотек и собирать библиотеки, которые являются зависимостями в сервисах. После запуска мы исправляли конфигурации сервисов и настраивали интеграции между ними, а без знания проекта было очень сложно. Затем prod развернули буквально за пару недель, так как всё было актуализировано и работало. Срок реализации: 6 месяцев. Ещё немного о сроках развёртывания и процессе запускаМожет показаться, что часть проектов нам досталась на полпути, но на самом деле все три кейса — это развертывание кластера с нуля. И хотя в двух случаях мы получили скрипты и код,
Если же все приложения контейнеризованы, то есть выполнены 5-10 шаги, по опыту больших данных, миграция готового рабочего проекта может занять около двух недель. Иногда часть третьего пункта сделана заказчиком. То есть мы заходим на проект, проводим аудит готовых скриптов, аудит качества контейнеризации, но такое происходит нечасто — в основном работаем с нуля. Без погружения в проект нельзя быть уверенным в том, насколько хорошо всё уже работает и спрогнозировать, как процесс пойдёт в дальнейшем. Запуск на девятом шаге, одном из самых ответственных, происходит в зависимости от архитектуры приложения. Если его можно разделить на части так, чтобы одна часть работала в одном месте, а другая в другом, то можно переносить частично и постепенно исправлять ошибки миграции. Но если все сервисы представляют одно приложение и общаются между собой, как в Проекте №1, то переезд всего приложения осуществляется целиком. В этом случае очень важно, чтобы была возможность тестирования новой среды. При миграции нам нужно актуализировать данные на новом кластере а потом переключить трафик на него. Есть случаи, когда можно это сделать без остановки — тогда нужно настраивать репликацию всех данных в новый кластер, а есть когда остановка нужна. Заранее сказать, сколько времени займет миграция, очень сложно и ближе к невозможному. Проекты, на которых требуется внедрение Kubernetes в большинстве своём очень крупные, где нельзя всё продумать и предусмотреть. Особенно пока devops не знает нюансов приложения и что ему требуется для работы. В случае, когда нас привлекают для всех этапов целиком, начиная с первого шага, заканчивая мониторингом и поддержкой, нам приходится плотно взаимодействовать с разработчиками, проводить аудиты, документировать систему приложений и проектировать кластер, при необходимости задействовать инфраструктурные сервисы initlab для мониторинга и CI/CD кластера Kubernetes или внедрять новые по требованиям заказчика. Переходить в Kubernetes или нет?Однозначного ответа на вопрос о переходе нет. С уверенностью можно говорить только о проектах с большими массивами данных и количеством приложений. С увеличением количества последних работоспособности серверов может начать не хватать и контейнеризация станет единственным выходом из положения. Тем, кто планирует расширяться и тем, кто уже на грани своих возможностей однозначно стоит рассмотреть вариант переезда в кластер Kubernetes, который работает на любых платформах. Если вы планируете переезд проекта в кластер Kubernetes для масштабирования и повышения отказоустойчивости или вашему проекту нужна поддержка кластера k8s — обращайтесь к нам.
Категорий: Сайтостроение
Обновление сайта с Drupal 9 на Drupal 10Релиз Drupal 10 состоялся в декабре 2022 года, на фоне чего клиенты всё чаще приходят в Drupal-студии с запросом на обновление версии CMS до свежей. На официальном сайте Drupal можно изучить, на каком ядре и в каких количествах работают сайты по всей планете — видно, что пока растёт число сайтов на десятой версии, с её предшественниками всё наоборот. Если у вас уже есть сайт на Drupal, то его обновление займёт от 20 до 200 часов — объём контента, контрибных и кастомных модулей, профайлов и тем, а также наличие на сайте сторонних сервисов влияют на продолжительность процедуры. Последовательность обновления давно прописана и понятна, что лишает эту работу творчества, а потому её хотелось бы сделать поскорее. На основе лучших практик и своих взглядов на процесс мы собрали инструкцию, как сократить время на обновление Drupal-сайта примерно в два раза. РАЗРАБОТЧИКИ! Пропустите первые два раздела статьи и начинайте с того, что мы рекомендуем помнить перед началом обновления ядра. Если вы разработчик или владелец сайта, построенного на устаревающей версии Drupal, и планируете обновление версии ядра либо вообще не задумывались об этом, эта статья окажется для вас полезной. Зачем обновлять версию ядра DrupalПредставьте, что вы вышли на улицу: этот город, район, дорога вдоль домов и сам дом знакомы вам много лет, а до вас здесь жили ваши родители. Все вы помните времена, когда место было чище и спокойнее, а теперь тут всё реже появляются даже уборщики мусора и полиция — район стал ульем криминала и маргиналов. Заблудившиеся здесь люди уйдут отсюда в лучшем случае без денег и смартфонов. Что делать? Можно лично воевать с бандами, создать общественную дружину для контроля за порядком, вставлять новые стёкла вместо разбитых. А можно переехать в другой район или город, где за порядком следят власти. И сделать это так быстро, как это возможно. Сайты на устаревающих и неподдерживаемых версиях Drupal чем-то похожи на когда-то цветущие, а теперь неблагополучные районы. Что делают владельцы почти 15 тысяч сайтов на Drupal 6 для поддержания их работы? Неужели сами выпускают патчи безопасности для модулей, не поддерживаемых ни разработчиками ядра, ни сообществом? Это напоминало бы ту самую замену выбитого окна: его разобьют снова, это тщетно. Можно стараться поддерживать интерфейс на современном уровне, но от него нет никакого толка, если через разбитые окна небезопасных модулей лезут хакеры и гигабайтами выносят данные о вас и ваших пользователях. В целом, работа сайта на устаревших версиях Drupal негативно затрагивает:
Опытные разработчики помнят, что обновляя ядро на версиях 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
1. Обновите свой сайт до последней версии Drupal 9 (9.4 минимум).
composer update "drupal/core-*" --with-all-dependencies
composer update
drush updatedb
2. Обновитесь до Drupal 10. Отредактируйте файл composer.json и обновите версию для ядра drupal/core-* до ^10. "require" : { Помимо указанных комонентов, в 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. Обновите версии совместимости в кастомных модулях и темах.
Пример: строка {{ attach_library('classy/node') }} меняется на {{ attach_library('starterkit_theme/node') }} ).
Пример: Устаревшая функция drupal_get_path('module', 'my_module_name') меняется на \Drupal::service('extension.list.module')->getPath('my_module_name') Если в качестве IDE вы используете PhpStorm, то в настройках проекта можно запустить проверку кода с помощью PHP_CodeSniffer:
composer global require "squizlabs/php_codesniffer=*"
Как искать ошибки в коде с помощью Upgrade status:
6. Twig обновился до 3 версии, поэтому вам может понадобиться обновить ваши Twig-файлы. Как обновить Twig-файлы с использованием PhpStorm:
Как обновить Twig-файлы с использованием Upgrade Status:
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_ids = []; После обновления вы не должны найти эту ошибку в Status report. Шаблон шпаргалки для быстрого обновления сайта до Drupal 10Однажды наш Drupal-разработчик обновляла не особо большой клиентский сайт до Drupal 10. В перспективе маячил ещё один подобный сайт. А сколько их ещё впереди, таких же или сложнее? Поэтому, чтобы не вспоминать каждый раз заново, что разработчик делала с тем или иным модулем и темой, она составила себе несколько таблиц с типичным поведением, которое надо применять к модулям, темам и конфигам, которые встречаются на проектах: поменять на dev или patch-версию, применить хук, пометить модуль как контрибный и т. п. В левой части таблицы — установленные на сайте модуль или тема, в правой — изменения, которые надо внести в файл composer.json, чтобы эти модули и темы работали на Drupal 10. Как интерпретировать комментарии в правой части:
Эта таблица нужна для пометок об изменениях в config-файлах. В частности, описано, как обновляются старые темы на сайте на новые. В этой таблице фиксируются состояния зависимостей до их обновления в ваших файлах .libraries.yml и то, как их нужно обновить. Благодаря этим подсказкам обновление второго сайта заняло у разработчика в два раза меньше времени. По ссылке вы найдёте Google-таблицу, структура которой готова к тому, чтобы вы или разработчик из вашей команды делали пометки для своих проектов. Таблица открыта только для чтения, поэтому сделайте копию для себя. Желаем вам безболезненного и быстрого обновления до последней версии Drupal! Оригинал статьи был опубликован в блоге ADCI Solutions.
Категорий: Сайтостроение
Организаторы Russian Drupal Awards продлевают сбор заявокСбор заявок на участие в конкурсе 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.
Категорий: Сайтостроение
![]() |
Сайтостроение |