4 
Содержание
Ivory перешел от узкого инструмента для PostgreSQL и Patroni к универсальной платформе управления кластерами. В версии 2.0.0 появилась новая архитектура с Keeper, добавилась поддержка MongoDB, Redis, ClickHouse, ZooKeeper и etcd, а также возможность развертывать кластеры из шаблонов прямо из интерфейса. Эти изменения важны для инженеров, которые уже используют Ivory или рассматривают единый инструмент вместо набора отдельных клиентов и скриптов. Перед выбором стоит понять, насколько новая модель снижает рутинные операции и где остаются ограничения по зрелости интеграций.
Новая роль Keeper
Keeper стал центральным понятием в Ivory 2.0.0. Раньше инструмент был плотно завязан на Patroni, теперь Keeper выступает универсальным слоем, который может работать как отдельный компонент или как встроенная часть СУБД. Patroni превратился в одну из реализаций, а не в основу продукта. Это позволяет добавлять новые базы без переписывания ядра.
Keeper отвечает за координацию операций с репликацией, failover и конфигурацией, предоставляя общую точку входа. Инженер получает возможность работать с разными системами через один интерфейс, при этом внутренняя логика отказоустойчивости остается той, что заложена в конкретной СУБД. Такая модель помогает сократить количество скриптов для мониторинга и переключений, но требует понимания, что Keeper не заменяет механизмы самой базы, а только оборачивает их.
Для инженера разница заметна при подключении. Вместо того чтобы ждать нативной интеграции, можно использовать Keeper как точку входа для операций с репликацией, failover и конфигурацией. При этом модель репликации и отказоустойчивости остается той, что заложена в конкретной СУБД. Ivory только предоставляет общий интерфейс поверх различий. Это важно учитывать при оценке: если в инфраструктуре уже выстроены собственные процедуры failover, дополнительный слой может упростить управление, но потребует проверки совместимости с существующими сценариями.
Поддержка ClickHouse и других систем
В релизе появились интеграции с MongoDB, Redis, ClickHouse, ZooKeeper и etcd. Каждая база использует собственные механизмы координации, и Ivory не пытается их унифицировать. Для ClickHouse это означает работу через ZooKeeper, для MongoDB — через replica set. Инженер получает единое место для просмотра состояния, выполнения запросов и управления нодами, но должен учитывать особенности каждой системы.
На практике это снижает количество переключений между инструментами. Если в контуре уже есть ClickHouse и PostgreSQL, можно управлять обоими из одного интерфейса без отдельных скриптов и дашбордов. Зрелость интеграций пока разная, поэтому перед продакшеном стоит проверить, насколько полно реализованы нужные операции для конкретной версии базы. При принятии решения важно оценить, покрывает ли текущая реализация ключевые сценарии мониторинга и управления для используемых версий, особенно если планируется активная работа с несколькими типами кластеров одновременно.
Развертывание и модель нод
Ivory 2.0.0 позволяет создавать кластеры из шаблонов, а не только подключаться к уже существующим. Шаблон описывает Docker-образ и конфигурацию, после чего можно повторно разворачивать окружения для разработки или тестов. Ноды теперь рассматриваются шире: как виртуальная машина, база данных и Keeper вместе. Развертывание идет через Docker по SSH, без обязательного агента на каждой машине.
Это упрощает работу в средах, где часто поднимают и удаляют тестовые кластеры. В то же время текущая реализация привязана к Docker и SSH. Если инфраструктура построена на Kubernetes или другом оркестраторе, потребуется дополнительная настройка или ожидание будущих расширений. При оценке стоит учитывать, насколько удобен Docker-подход в существующих политиках безопасности и есть ли необходимость в частом создании тестовых окружений.
Управление доступом и AI
Добавлено управление пользователями и правами прямо в интерфейсе. Администратор может создавать учетные записи и разграничивать доступ к кластерам, запросам и операциям. Это делает Ivory более подходящим для командной работы, а не только для личного использования инженера. Разграничение прав помогает снизить риски при совместном использовании, особенно когда разные специалисты отвечают за разные кластеры.
Отдельное направление — интеграция с AI через Model Context Protocol. Планируется MCP-сервер, через который ассистент сможет запрашивать состояние кластера, выполнять диагностику и, при наличии прав, проводить операции. Для команд, которые уже экспериментируют с AI-инструментами, это снижает риск прямого доступа моделей к инфраструктуре. Перед внедрением важно оценить, насколько контроль доступа через MCP соответствует внутренним требованиям безопасности.
Особенности внедрения в российских контурах
В российских проектах часто встречается сочетание PostgreSQL и ClickHouse, а также ограничения на облачные сервисы. Ivory 2.0.0 дает возможность управлять обоими типами кластеров из одного места, что сокращает количество инструментов в поддержке. Развертывание через Docker и SSH обычно проходит без проблем в закрытых сетях, однако нужно проверить совместимость с используемыми версиями Docker и политиками безопасности.
Перед обновлением стоит оценить зрелость интеграций под свои версии баз. Если основная нагрузка на Patroni и PostgreSQL, текущий функционал уже покрывает большинство задач. При активном использовании ClickHouse или MongoDB обновление дает заметный прирост, потому что появляется общий интерфейс и возможность развертывать тестовые кластеры по шаблону. В остальных случаях можно подождать стабилизации новых интеграций. Решение о переходе зависит от того, насколько критична унификация управления и готовы ли команды к проверке ограничений Docker- и SSH-развертывания.
Источник
Это краткий разбор материала Habr. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Ivory 2.0 охватывает кластеры разных баз.
Курс по теме — Построение DWH на ClickHouse
