Как подключиться к Redis, развернутому в Google Cloud?

Основы кейса: развернул экземпляр Redis (единственный экземпляр) в Google Cloud. Использование сервера на основе NodeJS и библиотеки redis-sentinel для подключения к узлу. Причина в том, что это дозорное управление узлами в облаке Google.

Я могу войти в экземпляр Redis через SSH-логин на приборной панели / консоли. Подключайтесь к локальной запущенной службе redis с помощью redis-cli и можете создавать / редактировать различные наборы данных.

Проблема: когда я пытаюсь получить к нему доступ через свой локальный хост или любой другой вычислительный экземпляр, развернутый в том же домене проекта. Я использую общедоступный IP-адрес и порт 26379/6379 для подключения, но в подключении отказывается.

Возможные причины:

  • Политики доступа к сети.

node.js google-app-engine redis redis-sentinel
person Vikram Tiwari    schedule 14.01.2015    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Я изо всех сил пытался настроить это для себя на прошлой неделе, хотел поделиться уроками, которые я здесь усвоил. Надеюсь, это поможет, даже если это почти на год позже :)

Я использовал схему развертывания по нажатию, которую можно найти здесь (Redis от Redis, а не Bitnami), что позволяет использовать нечетное количество виртуальных машин в качестве кластера.

После создания развертывания мне пришлось вручную выполнить следующие действия на каждой виртуальной машине, чтобы сделать ее пригодной для использования в качестве сигнального кластера:

  • redis-cli и запустите CONFIG SET protected-mode no и CONFIG REWRITE. Это откроет сервер Redis для внешних подключений.

  • sudo vi /etc/redis/sentinel.conf и добавьте protected-mode no, чтобы дозорные также могли подключаться друг к другу.

  • sudo /etc/init.d/redis-sentinel start, чтобы запустить дозорную службу

  • redis-cli -p 26379 и проверьте статус дозорного, запустив sentinel ckquorum master. Ожидайте увидеть «OK X usable Sentinels», где X - количество виртуальных машин в кластере.

Остатки:

  • redis-sentinel НЕ запускается как служба. Необходимо добавить в /etc/rc?.d рядом с redis-server
  • /etc/init.d/redis-{server,sentinel} не написаны как надлежащие службы Debian, поэтому они не возрождаются после уничтожения.

В целом очень разочарован этим предложением, ожидал более законченной настройки.

person Anton Drukh    schedule 22.10.2016
comment
Вы не просто запускаете / останавливаете службы в производственной среде, вы перезагружаете всю машину, и служба должна запускаться после перезагрузки. Думаю, именно поэтому вы не увидите нужных служебных файлов. - person Shay Erlichmen; 25.10.2016
comment
Вместо того, чтобы использовать vi на каждой машине, просто echo "protected-mode no" | sudo tee -a /etc/redis/sentinel.conf - person Roman; 30.06.2017

arrow_upward
1
arrow_downward

Обычно службы Google для развертывания по щелчку НЕ добавляют автоматически правила и политики сети / брандмауэра - вам придется сделать это самостоятельно.

Очевидно, что при открытии порта следует проявлять осторожность, чтобы разрешить доступ только из сети Compute Engine.

person Tom    schedule 14.01.2015
comment
Я развертываю кластер Redis, используя щелчок для развертывания. Он создает там три vm. Теперь, когда я подключаюсь к одному экземпляру из node js, он работает. Но когда я пытаюсь подключить его как кластер, он выдает ошибку [Ошибка: не удалось обновить кеш слотов.] github .com / luin / ioredis # cluster Я также попробовал контрольный код github.com/luin/ ioredis # sentinel Моя виртуальная машина prntscr.com/860m65 - person Max; 18.08.2015

arrow_upward
0
arrow_downward

Когда вы запускаете Google Cloud, они хранят всю вашу инфраструктуру в частном облаке (даже если это происходит в разных регионах), которому назначаются частные IP-адреса, если вы не запускаете экземпляры, которые требуют взаимодействия с внешним облаком и, следовательно, нуждаются в эфемерном IP-адресе. Всем экземплярам в частном облаке разрешен доступ друг к другу с использованием частных IP-адресов. Это по умолчанию установлено в правилах брандмауэра системы, поэтому вам не нужно их устанавливать.

Лучшей практикой было бы предоставить единую узловую точку для вашего публичного доступа к графическому интерфейсу / API и привязать остальные через внутренние IP-адреса. Экономит время, снижает время ожидания и обеспечивает безопасность в частном облаке.

В моем случае проблема, безусловно, заключалась в правиле брандмауэра, указанном @Tom. Вы можете изменить политики, чтобы разрешить соединения. Но я бы порекомендовал всем использовать внутренние IP-адреса для соединений между разными экземплярами.

person Vikram Tiwari    schedule 15.01.2015
comment
где пароль, который нам нужен для авторизации. Я не вижу пароль на панели управления. - person Gandalf the White; 16.12.2015
comment
@RanganathanSwamy нету. Вам нужно будет самостоятельно управлять авторизацией. - person Vikram Tiwari; 16.12.2015