|
|
|
4.7, SunXE (ok), 17:10, 03/08/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Конкретно etcd, но думаю и CoreOS так же расслабленно разрабатывают.
Простой пример, когда выпустили первую стабильную версию, не проверили работу этой поделки по шифрованным протоколам! Из-за чего на следующий день после релиза стейбла пришлось выпускать внеочередное обновление. На нашем опыте эта штука работает очень не предсказуемо. Хотели внедрять её, но передумали.
| |
|
5.10, crypt (ok), 17:27, 03/08/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
вот блин! а казалось бы небольшая утилита! я вот как раз раздумывал, не начать ли использовать ли ее, если появилась авторизация. У вас давно глюки были? На старых или текущих версиях?
| |
|
6.11, SunXE (ok), 17:45, 03/08/2015 [^] [^^] [^^^] [ответить]
| +/– |
Последний раз смотрели версию 2.0. Попробуйте может подкрутили постабильности, главное использовать больше 3-х нод.
| |
|
|
|
|
|
1.5, jOKer (ok), 17:09, 03/08/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Ну и зачем эти наколенные поделия если есть каталожные сервера, которые (в том числе) для этого и предназначены?
| |
|
2.8, SunXE (ok), 17:16, 03/08/2015 [^] [^^] [^^^] [ответить]
| +/– |
Это не каталог, это быстрая хранилка ключь-значение как redis или zookeeper.
Etcd отличается от них тем, что она изначально планировалась как распределенная и отказоустойчивая.
| |
|
3.9, anonymous (??), 17:19, 03/08/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
Ну LDAP - это тоже своего рода "хранилка ключ-значение", оптимизированная на чтение
| |
|
|
5.15, dss (ok), 18:56, 03/08/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
ты даже не поверишь, насколько.
это запись в ldap обычно медленная, оно больше для справочных данных, которые обновляются редко, а нужны часто.
а на чтение боевые ldap решения быстрые как понос.
| |
|
|
|
|
3.17, jOKer (ok), 20:25, 03/08/2015 [^] [^^] [^^^] [ответить]
| +5 +/– |
А можно сперва узнать нафейхоа? В смысле, зачем может понадобится этот протокол в деле синхронизации узлов LDAP? Сколько мне известно в OpenLDAP эту задачу выполняет LDAP Content Synchronization protocol и его (вы не поверите!) вполне достаточно для решения всех задач связанных с распространением обновленных данных по узлам. У других каталожных серверов тоже есть подобные механизмы, так зачем цеплять кирпич к хвосту синицы?
| |
|
4.21, Аноним (-), 00:29, 04/08/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
он просто не знает ничего про лдап, это даже не NIH-синдром, это простая безграмотность, как у авторов сабжа.
| |
4.30, Аноним (-), 00:45, 05/08/2015 [^] [^^] [^^^] [ответить]
| +/– |
Давайте Вы сначала расскажете как вместо реализаций Raft (etcd) использовать LDAP с LDAP Content Synchronization protocol? :-)
| |
|
5.31, Аноним (-), 01:19, 05/08/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Давайте Вы сначала расскажете как вместо реализаций Raft (etcd) использовать LDAP с
> LDAP Content Synchronization protocol? :-)
ровно так же как школофанбои вместо давно известных средств для всего лепят новые и новые костыли, только по итогам использования проблем меньше огребётся
| |
|
|
|
2.23, Crazy Alex (ok), 01:53, 04/08/2015 [^] [^^] [^^^] [ответить]
| +/– |
Единственное, что могу придумать - это адовая сложность этих самых каталожных серверов. Нужная далеко не всегда, начиная с тех же asn.1 и kerberos.
| |
|
3.24, Аноним (-), 03:54, 04/08/2015 [^] [^^] [^^^] [ответить]
| +/– |
>адовая сложность этих самых каталожных серверов.
мозг из задницы вынь и вставь обратно в голову
| |
|
2.32, . (?), 08:30, 06/08/2015 [^] [^^] [^^^] [ответить]
| +/– |
>Ну и зачем эти наколенные поделия если есть каталожные сервера, которые (в том числе) для этого и предназначены?
Для LDAP нужен код, который его поддерживает, библиотеки, конфигурационные файлы. А эта хрень конфигурирует микросервисы прямо по DNS ничего лишнего.
| |
|
|