Проект CoreOS (https://www.opennet.ru/opennews/art.shtml?num=40275), развивающий основанное на идеях контейнерной изоляции серверное окружение, подготовил (https://coreos.com/blog/etcd3-a-new-etcd.html) релиз etcd 3.0 (https://coreos.com/etcd/), высоконадёжного распределённого хранилища параметров конфигурации, задаваемых в форме ключ/значение. Основным назначением etcd является предоставление унифицированного механизма хранения конфигурации и информации о работающих сервисах для изолированных контейнеров с типовой начинкой. Код etcd написан на языке Go и распространяется (https://github.com/coreos/etcd) под лицензией Apache 2.0.
Etcd позволяет организовать единое хранилище конфигурации для группы серверов, которое реплицируются на все узлы и поддерживается в синхронизированном состоянии с использованием протокола Raft (https://github.com/goraft/raft). Наличие копии данных на всех хостах позволяет исключить потерю конфигурации при выходе из строя отдельного узла. В etcd также могут сохраняться временные данные, для которых предусмотрена возможность определения времени жизни записи. Для доступа к конфигурации предоставляется простой API (https://github.com/coreos/etcd/blob/master/Documentation/dev... основанный на использовании gRPC (http://www.grpc.io/).
Имеется встроенная возможность отслеживания изменения состояния ключа или директории с вызовом обработчика в случае обнаружения изменения (например, можно применить новое значение параметра конфигурации). Для защиты канала связи при обращении из внешней сети предоставляется поддержка TLS-шифрования, аутентификации (https://coreos.com/etcd/docs/latest/authentication.html) клиентов по ключам и разграничения доступа через ACL. На типовом оборудовании etcd обеспечивает производительность порядка 10 тысяч операций записи в секунду. Для доступа к базе можно использовать утилиту etcdctl (https://github.com/coreos/etcd/tree/master/etcdctl).В etcd 3.0 представлена (https://github.com/coreos/etcd/releases/tag/v3.0.0) третья версия API etcd, в котором отражены пожелания пользователей и опыт крупных промышленных внедрений etcd. В частности, в новой версии API решены многие проблемы с масштабированием, благодаря новому движку хранения и полной поддержке механизма управления одновременным доступом с помощью многоверсионности (MVCC (https://ru.wikipedia.org/wiki/MVCC), Multi-Version Concurrency Control). Для обращения к APIv3 теперь может применяться gRPC и HTTP/2 (ранее предлагаемый JSON/HTTP транслируется (https://github.com/coreos/etcd/blob/master/Documentation/dev... через gRPC). Применение протокола gRPC, использующего protobuf, позволило в два раза увеличить скорость обработки запросов, по сравнению с применением JSON в etcd2, а HTTP/2 дал возможность мультиплексирования соединений и создания постоянных двунаправленных каналов без необходимости установки отдельного соединения на каждый запрос и без применения поллинга для проверки состояния.
Из новшеств APIv3 можно отметить:
- Плоское пространство бинарных ключей, в котором вместо иерархии и каталогов применяется выборка по префиксу и интервалу.
- Средства для работы c многоверсионным хранилищем, позволяющие обращаться к прошлым версиям ключей;
- Несколько запросов теперь могут группироваться и выполняться рамках одной операции;
- Поддержка определения времени жизни (TTL), единого для заданного набора ключей (теперь записи могут привязываться к TTL, без сохранения TTL как атрибута записи, что позволяет обновлять лишь одно поле с TTL без необходимости обновления каждой записи);
- Возможность определения квот для ограничения используемого в etcd размера хранилища;
- Экспериментальная поддержка v3 Auth API.
Из не связанных с API улучшений отмечается проведение работы по увеличению отзывчивости и пропускной способности, в частности, снижены накладные расходы при обработке API и оптимизирована реализация лога отложенной записи. Добавлен новый бэкенд хранения, обеспечивающий меньший расход памяти для хранения каждого ключа. Реализована автоматическая настройка шифрования TLS. Реализованы новые возможности утилиты etcdctl: поддержка создания территориально разнесённого зеркала, средства организации блокировок mutex поверх etcd, возможность сохранения снапшотов текущего состояния бэкенда etcd, средства отслеживания работоспособности, поддержка выбора главного экземпляра в кластере и экспериментальная команда "gateway".URL: https://coreos.com/blog/etcd3-a-new-etcd.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=44724
Ааааа, это же РЕЕСТР ! Анафема !!!
Так разве же это плохо?
все что есть на винде - по определению плохо, даже если их копируют.
надо GNOME тоже предать анафеме за gconf..
"надо GNOME тоже предать анафеме" в принципе, как заигравшихся хипстеров.
Так уже...
Жертва ЕГЭ?
как красноречиво о себе :-)
а по теме сказать слабо ?
Они изобрели нескучный редис?
узкоспециализированый проект, интересен очень ограниченому кругу разработчиков.
имхо, вообще нету смысла писать о таких проектах на опеннете, тем более что таких узкоспециализированых проектов можно найти тысячи, и писать об одних и не писать о других как-то несправедливо
ты не прав. в контексте микросервисов - мастхев.
>в контексте микросервисовНу да, я ж там как раз и написал слово "узкоспециализированный"
Ты тоже можешь написать о своём любимом узкоспециализированном проекте.А мне интересно управление конфигурациями.
Интересный софт, но мы предпочли Consul.
Не первый раз слышу о том, что предпочитают Consul вместо Etcd. Чем именно вызван подобный выбор?
Как чем? Синдромом утёнка, конечно же.
Например механизмом добавления мемберов.
В консуле ты просто делаешь consul agent --join <list-of-servers>.
А в етцд это целы
... целый квест, особенно если кластер поднимался с дискавери-урлом.
A ведь еще совсем недавно обычный REST & JSON преподносились как ключевая фишка и возможность доступа хоть с curl, а zookeeper ругали за бинарный протокол. Но потиху пришли почти к такому же состоянию "persistent connection & binary protocol"
Насколько я понимаю архитектуру etcd, там нет концепта агента, как у Consul, и оптимизация сетевого протокола с учётом, что все клиенты этого etcd ломятся на собственно ноды etcd кластера таки имеет смысл.
Другое дело, что пряморукий девелопер напишет свою реализацию агента с поддержкой десятков тысяч клиентов что для zookeeper, что для etcd, при этом принципиально контролируя количество необходимых соединений между агентом и сервером.
так я же не спорю, я делаю упор именно на бинарный протокол и постоянное соединение, так как раньше их отсутствие пытались показать как преимущество над зоокипером =) сейчас походу только go хвалиться и остается (jvm в zookeeper)
Подскажите, я правильно понимаю, что это "разжиревший" docker-compose, с возможностью работы на нескольких реальных узлах?
Нет, это zookeeper на стероидах
zookeeper? на стероидах??г-споди б-же, что ж они такое туда запихнули? лишп поверх jvm?
Зачем нужны контейнеры?
домашнюю жрачку на работу таскать.
Сабж прекрасно работает и без контейнеров, хоть в хардварном "облаке" распределёнки деплоить через него управляющиеся.
Мде, однако же смачно ты перданул в лужу