Pull to refresh

Comments 7

Спасибо за статью.
Помимо мелочей с «непривычным» объемом резервируемом локальной памяти из-за LMDB и необходимости городить конструкции типа "> /dev/null 2>&1; [ $? -ge 1 ] && exit 2 || exit 0" для привычной проверки rc кодов сервисов.
На одном из пилотных проектов, при использовании консула, очень смутили следующие вещи:
1. sudo -u nobody consul maint -enable
2. sudo -u nobody consul keyring -list
которые на момент сворачивания консула все еще не были пофикшены, подскажите, как сейчас с этим дела обстоят?
А можно немного больше подробностей? Не очень понятно, что именно вас смутило
Любой непривилегированный локальный процесс может перевести ноду, с установленным консулом, в режим обслуживания.
Любой непривилегированный локальный процесс может увидеть ключи шифрования, используемые консулом.
Да, беда :) Ничего не изменилось на данный момент. Похоже, что безопасность в этом моменте необходимо обеспечивать на уровне ОС, а не средствами консула
Спасибо ща статьи. Хотело бы спросить такую вещь, тестирую сейчас кластер из 3 нод, и пытаюсь зарегистрировать службу

$ curl -X PUT -d '{"Service":{"Service":"nginx","Port":8080,"Address":"10.10.10.11","Port":8080},"Node":"consul01","Address":"10.10.10.1"}' http://127.0.0.1:8500/v1/catalog/register
true

Служба регистрируется и даже вижна в веб интерфейсе
но через минуту она пропадает. Не смог нигде найти даже что-то похожее на описание этого поведения
Сервис нужно регистрировать с того узла, на котором он запущен.
Иначе сервис будет удален, как и происходит в вашем случае. Судя по всему.
Sign up to leave a comment.

Articles