У меня есть докеризованные образы Redis (как официальные руководства dockerhub при использовании пользовательского redis.conf) и пользовательское изображение (на основе альпийского изображения см. здесь: https://pastebin.com/9WsMk1JC ) дозорного (также с пользовательским sentinel.conf).
В redis.conf, были добавлены эти три параметра (остальные остаются в файле конфигурации по умолчанию):
мастер-пароль
мастер-пользователь по умолчанию
требуемый пароль
В sentinel.conf, из-за разделения экземпляра Redis (другие контейнеры) и Sentinel настроен на загрузку с несуществующим мастером на локальном хосте. Я добавил параметры для выполнения аутентификации на мастере. Таким образом, файл конфигурации имеет два дополнительных параметра (остальные остаются файлом конфигурации по умолчанию):
Sentinel auth-pass мой мастер-пароль
дозорный пользователь авторизации mymaster по умолчанию
После того, как контейнер Redis загружен и готов к подключениям, я запускаю образ Sentinel, когда это будет сделано, я подключаюсь к Redis CLI на порту Sentinel и переключаю мастер вручную:
redis-cli -p 26379 sentinel remove mymaster && redis-cli -p 26379 sentinel monitor mymaster <redis container ip> 6379 2
CLI sentinel два раза возвращает OK, но через некоторое время выводит сообщение о том, что мастер не работает. И остается в этом статусе навсегда.
Связь между контейнерами проверена через telnet и ping — все в порядке.
Я предполагаю, что Redis Sentinel не может подключиться к мастеру из-за пароля.
Почему?
- Реплики контейнера Redis — запуск пары копий образа и объединение их в MASTER-SLAVE через CLI работает как шарм. Контейнеры могут общаться друг с другом, используя пароль из redis.conf.
- Прежде чем вводить пароли для Redis Contianers, Sentinels могли подключаться и выполнять успешные аварийные переключения.
- Работал на Openshift без установки пароля.
