Что почитать по инфраструктуре: Docker, K8s, сети и защита серверов
Собрали свежие статьи из нашего блога — те, что легко затерялись в ленте, но которые стоит дочитать до конца. Если на неделе было не до Хабра, вот короткий дайджест с самым полезным.
Ваш docker-compose.yml сломается: 5 настроек, которые все забывают Локально всё крутится, на сервере неделю тоже — а потом Postgres съедает всю память, OOM-киллер убивает соседний сервис, а логи забивают диск. Всё лечится парой строк в compose-файле, но про них забывают: на машине разработчика они просто не проявляются. Разбираем пять настроек, без которых compose не доживёт до второй недели на проде.
Прощай, Fail2Ban: усиливаем защиту Netbird и Caddy с CrowdSec Fail2Ban десять лет был золотым стандартом, но он реактивен: чтобы он сработал, атакующему сначала нужно постучаться в ваш SSH пять раз. А что, если блокировать вредоносные IP ещё до того, как их трафик дойдёт до сервера? История о переходе на CrowdSec с пошаговыми примерами кода — и о том, как «шум» от атак упал на 99%.
Разбираемся с форвардингом IP-пакетов в сетевых уровнях L2 и L3 Чем коммутатор отличается от маршрутизатора, зачем нужен TTL, как устроена CAM-таблица и почему без ARP ваш пакет никогда не доедет до получателя. Спокойный разбор основ, который наводит порядок в голове — для тех, кто хочет наконец перестать путать L2 и L3.
Self-service деплой: как перестать ждать DevOps и ускорить команду Знакомая картина: разработчик полчаса висит в Slack, ожидая, пока кто-то накатит сборку на стенд. С ростом команды DevOps-инженер становится единственным шлюзом между кодом и продакшеном — и это горлышко съедает до 30% времени. Tech Lead рассказывает, как self-service платформа убирает узкое место, с кейсами Monzo и Spotify.
Kubernetes: архитектура и абстракции — полный гайд K8s называют стандартом, но понимание его механик встречается редко. Control Plane и Worker Nodes, Pod, Service, Deployment, Namespace — «прожиточный минимум» абстракций, без которых нельзя выходить в прод. Плюс отрезвляющая история о том, как Tinder год переезжал на кластер из 1000 узлов и что у них при этом ломалось.
От capabilities к AppArmor: что реально остановит атакующего в контейнере Уязвимость в веб-приложении, злоумышленник уже выполняет команды внутри контейнера — что именно его остановит? На одной и той же рабочей нагрузке показано, как последовательно срабатывают три слоя защиты: capabilities, seccomp и AppArmor. Где каждый помогает, где бессилен и почему работать они должны только вместе.
Хотите системно закрыть пробелы по инфраструктуре? Собрали большой дайджест по Linux, Docker, Kubernetes, CI/CD и сетевой безопасности: бесплатные уроки, практические гайды и курсы — всё в одном месте.
Как я в Zabbix мониторю аккаунт в REG.RU: баланс, неоплаченные счета и сроки всех услуг - через API reg.ru
Домен можно сторожить по WHOIS: взял имя, посмотрел дату, повесил триггер «истекает через 30 дней». Но WHOIS видит ровно один домен и ничего вокруг. Он не знает, что на счёте кончились деньги, что висит неоплаченный счёт, из-за которого услугу снимут раньше срока, что в том же аккаунте ещё десяток доменов, SSL и хостинг. Поэтому я опрашиваю не WHOIS, а биллинговый API самого регистратора - он отдаёт весь аккаунт целиком. Собрал из этого шаблон под Zabbix 7.0, MIT. Расскажу, как он устроен и что в нём, на мой взгляд, сделано правильно.
Архитектура Три HTTP-айтема ходят в api.reg.ru - список услуг, неоплаченные счета и баланс - и складывают сырой JSON. Дальше всё считается из него: dependent items тянут баланс, сумму и число счетов через JSONPath, а LLD разворачивает прототипы под каждую услугу (ненужные типы отсекаются макросом-регуляркой). Каждая цепочка начинается с error_handler - битый или пустой ответ API не роняет айтем, а подставляет безопасное значение. На весь аккаунт получается несколько запросов в час, а не отдельная проверка на каждую услугу.
Что считаю правильным дизайном - две цепочки зависимостей Первое - nodata. Когда API регистратора отваливается целиком, каждый триггер «нет данных» (услуги, счета, баланс) хочет сработать сам, и ты получаешь пачку алертов про одну причину. Я завязал nodata услуг и счетов на корневой «No data from balance API». Полный отвал API теперь - один алерт, а не три. Корень я специально оставил без зависимостей, чтобы случайно не завязали и его, - об этом есть комментарий прямо в шаблоне.
Второе - сроки. На каждую услугу не один триггер, а каскад: ИСТЕКЛА (Disaster) → ≤7 дней (High) → ≤14 (Warning) → ≤30 (Info). Каждый уровень зависит от более тяжёлого. Поэтому услуга, которой осталось три дня, даёт один алерт High - а не три штуки (Info, Warning, High) одновременно. По мере приближения срока ты видишь ровно один триггер нужной серьёзности.
Для работы API, необходимо прописать разершенные IP в кабинете https://www.reg.ru/user/account/settings/api/, в настройках API задать адьтернативный пароль, и сохранить в макрос хоста {$RR_PASSWORD} как Secret. Логин - {$RR_USERNAME}. Для рег.облако взять API в https://cloud.reg.ru/panel/settings и сохранить в {$RRC_API_KEY}
Итог Баланс, неоплаченные счета и сроки всех услуг - под алертами в одном дашборде, без отдельного демона-прослойки. В репозитории два шаблона: разобранный выше под api.reg.ru (домены, хостинг, SSL) и отдельный под облачный api.cloudvps.reg.ru - там к балансу и срокам добавлен мониторинг самих VPS: реглеты, снапшоты, сети. Шаблоны, README и changelog - GitHub, PR и issues welcome.
А чем вы следите за биллингом у провайдеров и регистраторов - дёргаете API, или живёте на письмах «ваша услуга истекает»?
Подключайтесь к вебинару — покажем, как автоматизировать управление сложной инфраструктурой
Когда часть сервисов находится в облаке, а остальное — в изолированных контурах, доставка серверного ПО и контроль лицензий превращаются в настоящий квест для команды DevOps.
На вебинаре расскажем, как собрать весь зоопарк решений в единую систему с помощью MWS B2B Store. Разберем деплой инсталляций, когда разные ноды находятся на разных инфраструктурных провайдерах, доставку и обновления в закрытых контурах, версионирование и распространение внутренних и внешних решений.
В прямом эфире в режиме демо покажем:
Деплой сервисов (VMware + K8S) для разных сред, имплементацию Terraform as a service.
Автоматическое развертывание в изолированные контуры: от стандарта упаковки до «раскатки» в гибридную инфраструктуру.
Как управлять лицензиями на серверное ПО и контролировать, кто, где и сколько использовал.
Работу с инстансами из разных инфраструктур в едином окне: мониторинг, аудит и управление жизненным циклом.
Будет полезно CTO, DevOps, директорам по инфраструктуре и тимлидам инфраструктурных команд.
📅 Когда: 30 июня в 11:00 мск.
📍 Где: онлайн. Зарегистрируйтесь, подключайтесь и задавайте вопросы нашим экспертам в чате трансляции.
Определяет представление планировщика об эффективном размере дискового кеша, доступном для одного запроса. Это представление влияет на оценку стоимости использования индекса; чем выше это значение, тем больше вероятность, что будет применяться сканирование по индексу, чем ниже, тем более вероятно, что будет выбрано последовательное сканирование.
Вот прямо с первых строк мозги выносит: при чём тут оценка (ОЦЕНКА!) размера дискового кэша и выбор между индексным или полным сканированием? Не знаю, кому как, но лично мне совсем непонятно. Следующее, если effective_cache_size показывает оценку размера ДИСКОВОГО кеша (для меня одного словосочетание “дисковый кэш” означает “кэш файловой системы”?), то откуда взялась рекомендация в значение 3/4 размера оперативной памяти, если 1/4 - это shared_buffers? Рекомендатели, ау! 1/4 + 3/4 = 1, арифметика, начальная школа. А где СУБД должна выполнять манипуляции с данными? В свопе? Всё остальное описание совершенно не добавляет ясности по использованию данного параметра, увы нам, постгресовым администраторам баз данных.
Кратко. Главное. Данный параметр показывает ОБЩИЙ размер кэша: постгресовый shared_buffersплюс (плюс выделен жирным шрифтом в оригинальной статье!) кэш файловой системы. С этим уточнением рекомендация в 3/4 размера оперативной памяти выглядит приемлемой. Следующее. Обсуждаемый параметр применяется для вычисления вероятности того, что однажды прочитанные данные будут находиться в кэше при повторном обращении в рамках ОДНОГО запроса. Т.е. для предпочтения соединения таблиц вложенным циклом (Nested loop join) при выборе методов соединения. Если высока вероятность того, что данных при повторном запросе в кэше не окажется, то будет выбрано либо полное сканирование таблиц(ы), либо сканирование по битовой маске, либо соединение хешем (hash join), либо соединение слиянием (merge join). Далее. Этот параметр - верхняя оценка, завышенное значение не приводит к серьёзным проблемам (по крайней мере в статье об этом говорится). Ограничение. effective_cache_size должен быть больше shared_buffers, ибо меньшее значение является бессмысленным (по статье).
Обновили ядро Linux на всех Ryzen-серверах в Москве
В копилку стабильности — и с конкретным обновлением под капотом.
Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.
Это могло обернуться внезапной недоступностью виртуальных машин, хотя с самими проектами все было в порядке.
Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.
Переезд выполнили поэтапно: сначала подняли резервные серверы, перенесли на них проекты и только потом приступили к обновлению основных хостов. Поэтому пользователи не столкнулись с простоем.
Теперь гипервизоры работают на новом ядре, а риски возможных зависаний нод осталась в прошлом.
Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.
Представлено бесплатное десктопное приложение Streambert с открытым исходным кодом для ПК на Windows, macOS и Linux. Решение распространяется по лицензии GNU GPL v3.0. Главное преимущество Streambert — здесь совсем нет рекламы и трекеров. Разработчики подчёркивают, что приложение всегда будет бесплатным и не станет собирать личные данные пользователей.
Для поиска и отображения информации о фильмах и сериалах Streambert использует базу TMDB и для работы понадобится бесплатный API-ключ TMDB. Программа поддерживает русский интерфейс и субтитры, а также даёт возможность скачивать любые медиафайлы для офлайн-просмотра.
Разработчики утверждают, что приложение обеспечивает более быструю потоковую передачу видео по сравнению с большинством браузерных кинотеатров и поддерживает многопоточную загрузку файлов. При этом Streambert не хранит и не распространяет защищённый авторским правом контент, программа лишь агрегирует ссылки с внешних источников и выступает в роли поисковика.
30 июня эксперты «Тантор Лабс» представят разбор Tantor XData Gen3 — третьего поколения машины баз данных для высоконагруженных корпоративных систем, реализующей ряд технологий, ранее доступных в таких западных продуктах как Oracle Exadata, SAP HANA и IBM Netezza.
В программе:
эволюция архитектуры Tantor XData и ключевые изменения в Gen3: независимое масштабирование подсистем вычислений и хранения, полноценная обработка смешанной нагрузки (HTAP) на едином наборе данных;
новые возможности платформы и сценарии их применения;
устройство и особенности распределенной СУБД Tantor Polar;
организация вычислительных ресурсов и ресурсов хранения;
инструменты управления и мониторинга.
Отдельный блок будет посвящён практической работе с машиной баз данных. Пройдем интерактив с реальным ситуациями, демонстрирующими преимущества новой машины баз данных перед классическими СУБД.
Эксперты мероприятия:
Вадим Яценко, генеральный директор «Тантор Лабс»
Сергей Серегин, руководитель технического пресейл «Тантор Лабс».
Зачем провайдеру помогать клиенту снижать счёт за облако
Облачный счёт редко становится проблемой за один день
Обычно всё растёт постепенно: сервисов стало больше, команды активнее используют инфраструктуру, появились новые тестовые среды, где-то добавились AI-нагрузки, где-то остались временные инстансы после задачи.
Потом приходит счёт, и начинается разбор.
— Кто создал ресурс? — Он ещё нужен? — Можно ли его выключить? — Почему рост увидели только в конце месяца? — Кто должен отвечать за такие расходы: финансы, инженеры, продуктовая команда или владелец сервиса?
На этом месте появляется ещё один вопрос, уже к рынку:
На первый взгляд это конфликт интересов. Клиент оптимизирует расходы, провайдер получает меньше. Но в облачной модели всё устроено сложнее, чем простая связка «меньше потребил, меньше заплатил».
В новом выпуске «Практики FinOps» мы поговорили об этом с Александром Либкиндом, руководителем направления развития сервисов управления затратами в Cloud.ru.
О чём выпуск
Разговор получился не про разовые скидки и не про универсальный способ «порезать облако».
В центре выпуска, управление затратами на инфраструктуру: как компании начинают видеть расходы, где возникают первые сложности, почему месячного отчёта часто недостаточно и что меняется, когда облако становится заметной частью ИТ-бюджета.
Отдельно обсудили, как провайдер смотрит на оптимизацию со своей стороны и почему снижение счёта клиента не всегда означает прямую потерю для облачной платформы.
Какие вопросы разобрали
почему FinOps в России развивается медленнее, чем на западных рынках;
зачем Cloud.ru помогает клиентам снижать счета;
где обычно находятся первые 15–30% экономии;
почему отчёт раз в месяц плохо работает для управления затратами;
чем FinOps для AI отличается от классического FinOps;
почему автоматические рекомендации не решают проблему без владельцев ресурсов и процессов;
как компании проходят этап Inform и почему на нём часто начинаются сложности.
Для кого выпуск
Для команд, которые уже используют облако и сталкиваются с вопросами стоимости инфраструктуры. Для инженеров, которые видят ресурсы, но не всегда видят их финансовый эффект. Для финансовых и продуктовых команд, которым важно понимать, из чего складываются облачные расходы и почему общий счёт сам по себе не помогает принимать технические решения. Для тех, кто только подходит к FinOps и хочет понять, с чего обычно начинается системное управление затратами.
Представлен открытый проект Navidrome Music Server, который позволяет слушать музыку с ПК где угодно. Работает очень просто: пользовательский ПК превращается в сервер, к которому можно получить доступ с любого устройства. Есть демо-версия проекта, чтобы понять принцип работы.
Открытые уроки для прокачки: Linux, backend, ИИ, безопасность и управление
Эта неделя хорошо закрывает сразу несколько рабочих зон: инфраструктуру, backend, безопасность, ИИ, аналитику и управление. Темы подобраны так, чтобы за один открытый урок можно было не просто «послушать про тренды», а разобраться в конкретной задаче: от cache и swap в Linux до проектирования аутентификации, SRE-инцидентов, NLP и системного анализа.
Все уроки бесплатные и проходят с преподавателями-практиками OTUS — можно познакомиться с экспертами, протестировать формат обучения и задать вопросы по теме.
Представлен проект CamLoop для Zoom, Meet, Slack и Teams. Решение записывает несколько секунд лица пользователя, а затем подменяет во время созвона веб-камеру зацикленным видео Переключаться между настоящей и фейковой камерой можно одной кнопкой.
Главная фишка — запись специально имитирует лаги и плохой интернет, поэтому выглядит как обычные проблемы со связью, а не как зацикленный ролик.
Юху! Смотрите sshto обновилось до версии 1.01! В новой версии по многочисленным (2) просьбам добавил поддержку множественных значений Host. Теперь вот такой конфиг:
Host homyak home house
HostName localhost
User root
Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис
В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:
пользователи – в одном контуре;
серверы и рабочие станции – в другом;
тестовая среда – в третьем.
На схеме это выглядит логично: сегментация, изоляция ошибок, разные зоны ответственности, поэтапная миграция без шуму и пыли.
Но в эксплуатации важен не только вопрос «где лежит объект».
Важнее другое: какие зависимости связывают объекты между собой.
Многодоменная архитектура не опасна сама по себе. Проблема начинается тогда, когда её начинают восстанавливать как набор независимых доменов.
Сценарий
Пользователь – в домене A. Рабочая станция – в домене B. Группа доступа к приложению – в домене C.
Цепочка доступа:
учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.
Каждый компонент по отдельности может выглядеть исправным:
KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.
А доступ к приложению всё равно не работает.
Почему? Потому что сломался не отдельный объект, а связь между объектами.
Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.
В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.
Что стоит проверить заранее
Основной источник данных – где создаются пользователи, где живут группы, какие домены участвуют в кросс-аутентификации.
Карта доверительных отношений – какие домены доверяют друг другу, в каком направлении работает доверие и что произойдёт, если одно звено станет недоступным.
Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.
DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».
Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.
Главный вывод
Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.
Если пользователи, ресурсы, группы и политики разнесены по разным доменам, план восстановления должен описывать всю цепочку, а не один объект.
Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.
Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?
В июне вас ждут еще три онлайн-встречи с экспертами Cloud.ru — о Spark, облачных расходах и Redis. Регистрируйтесь заранее, чтобы ничего не пропустить.
🎥Spark Connect для ИТ-команд: упрощаем разработку и работу с данными
Покажем, как сделать использование Apache Spark удобным для всей команды с помощью Spark Connect и Evolution Managed Spark. Затронем вопросы разработки в IDE, анализа данных в Jupyter и построения ETL на чистом SQL в dbt. Не бойтесь споткнуться о порог входа — здесь он минимальный.
🧑💻 Для кого: дата-инженеры, аналитики, руководители дата-отделов.
🎥Как управлять расходами в облаке и не удивляться счетам
Разберем, как сделать облачные расходы прозрачными с помощью FinOps-инструментов. Вы узнаете, почему важно назначать владельцев ресурсов, как правильно выбирать тариф, выставлять автоматические квоты и настраивать алерты, чтобы сократить затраты на 20–30%. Всё — с живым демо в личном кабинете.
🧑💻 Для кого: ИТ-менеджеры, DevOps, финансовые директора.
🎥Эволюция приложения в облаке: как настроить кеш с Redis и ничего не сломать
Четвертый вебинар большого трека про эволюцию приложений. Обсудим стратегии кеширования и какую из них выбрать под ваш сценарий, типичные ошибки инвалидации и защиту от всплесков нагрузки. Разберем, как оценивать эффективность кеша и ситуации, когда он только маскирует проблемы.
🧑💻 Для кого: бэкенд-разработчики, DevOps-инженеры, архитекторы.
Terraform в zVirt: базовая автоматизация виртуальной инфраструктуры
Привет, Хабр! 24 июня в 11:00 мы проведем вебинар о различных подходах к автоматизации.
Автоматизация — это способ сделать ИТ-ландшафт более прозрачным, управляемым и предсказуемым. На вебинаре разберем, как применять Terraform в zVirt, чтобы сократить объем рутинных операций, снизить риск ошибок и перейти к управлению инфраструктурой с помощью кода.
Что разберем:
- Различные подходы к автоматизации: когда и зачем нужен Terraform?
- Технический обзор: архитектура поддержки Terraform в zVirt
- Управление примитивами виртуализации: виртуальные машины, диски и сети
- Live-demo: от ознакомительных сценариев до устранения неисправностей
Кому будет полезен вебинар?
- Руководителям ИТ-инфраструктуры
- Системным инженерам
- Системным администраторам
- DevOps-инженерам
Участники вебинара первыми получат доступ к Cookbook zVirt Terraform — практическому гайду, составленному на опыте реальных кейсов управления комплексной инфраструктурой zVirt средствами Terraform.
Настроить мониторинг за 60 секунд: вебинар про Deckhouse Observability на практике
Метрики, лейблы, Prometheus, PromQL, Grafana, дашборды, алерты, каналы уведомлений. Тема мониторинга большая и сложная, но базовый пайплайн от сбора метрик до визуализации данных и настройки алертов можно разобрать за 60 минут. Этим и займёмся на вебинаре Deckhouse Академии на примере живого сценария.
Разберём, как формируется метрика, что такое лейблы и кардинальность, а также как не допустить взрыва кардинальности.
Рассмотрим, как Prometheus собирает данные и как начать собирать их со своего приложения, добавив три строчки в Deployment.
Визуализируем метрику и покажем пример агрегации сырых данных с помощью PromQL.
Создадим правило для алерта, настроим свой канал уведомлений и получим уведомление по агрегированной метрике.
Регистрируйтесь и подключайтесь 23 июня в 12:00 (МСК). После вебинара вы поймёте, как работает цепочка App → Metric → Prometheus → PromQL → Grafana → Alert, сможете подключить своё приложение к Prometheus без правки scrape_config, написать простой запрос на PromQL и настроить оповещения с защитой от шума.
Установка и использование Nexus Repository для хранения артефактов
Nexus закрывает типовую DevOps-задачу: единое хранилище для Maven, npm, Docker, NuGet, PyPI и собственных бинарей, кэш внешних зависимостей и предсказуемый источник артефактов в CI/CD. Версии — Community Edition, Pro и связка с Repository Firewall для отсечения небезопасных компонентов на входе.
В статье разобрали установку Nexus Repository 3.91.1 тремя способами, а также показали первичную настройку, загрузку артефактов и политики очистки. И не забыли про разграничение прав через Privileges, Roles и Users, отключение анонимного доступа и вывод Nexus наружу по HTTPS через Nginx с Certbot.
В Китае запустили первую в мире коммерческую оптоволоконную систему, которая работает сразу в трёх диапазонах длин волн: S, C и L. Обычные магистрали задействуют преимущественно C-диапазон, поэтому одновременное использование трёх окон прозрачности сразу расширяет доступную полосу.
Вторая составляющая решения это четырёхъядерное волокно. В одном физическом волокне проложены четыре световедущих ядра, и по каждому идёт свой поток данных. Пространственное разделение каналов внутри одного кабеля умножает ёмкость без прокладки дополнительных линий.
По данным разработчиков, пропускная способность одного ядра выросла почти на 50 процентов, а суммарная ёмкость системы превышает показатели обычного одномодового оптоволокна более чем в пять раз.
Ключевой момент в том, что испытания прошли не в лаборатории, а на действующей линии длиной 35 километров. Она соединила вычислительные центры в Циндао провинции Шаньдун, то есть режим эксплуатации был близок к реальной нагрузке между дата-центрами.
Для задач машинного обучения пропускная способность межсоединений имеет прямое значение. Крупные модели обучают на кластерах из тысяч ускорителей, и скорость обмена между узлами и между дата-центрами часто становится узким местом. Более широкий канал снижает простои дорогого железа.
Если технологию удастся масштабировать, операторы и облачные провайдеры смогут поднять пропускную способность на уже проложенных трассах. Это дешевле и быстрее, чем строить новые линии с нуля.
Представлен открытый проект HTML skills for pragmatic visual artifacts для генерации HTML‑файлов за один клик, включая диаграммы, презентации, резюме, отчёты, планы и прочее:
html — создает любые HTML‑страницы исходя из задачи: от лендингов до портфолио;
html‑diagram — создает схемы, планы и диаграммы с фокусом на SVG;
