Как развернуть полноценный кластер Redis? Часть 1
Здравствуй, $username! В данной статье мы рассмотрим, как развернуть полноценный кластер Redis с отказоустойчивостью и миграцией мастера между нодами в случае его падения.
Как мы уже знаем, Redis представляет собой базу данных класса NoSQL с открытым исходным кодом и работает со структурой данных типа ключ:значение. Также данный продукт часто используется для хранения кэшей и в качестве брокера сообщений. Redis sentinel предоставляет мониторинг, оповещение и переключение в автоматическом режиме мастера.
Docker swarm является оркестратором, который позволяет управлять, декларативно описывать и обслуживать сервисы (контейнеры). Также он предоставляет встроенный сервис дискавери, при помощи которого все сервисы могут находить друг друга без проблем.
Немного вводной информации по проекту
К нашему кластеру Redis будет подключаться некое приложение, которое будет писать и читать данные. Также это приложение умеет определять, является ли Redis, к которому оно подключилось, мастером, а в случае, если это slave, оно будет переключаться на другой. Кластер Docker swarm состоит из трёх нод (swarm-1, swarm-2, swarm-3); swarm-1 является лидером кластера и на ней будет запущен redis-мастер.
Чтобы определённый контейнер размещался на конкретной ноде, нам необходимо использовать теги. Сделать это можно следующим образом:
docker node update --label-add redis-master=true swarm-1 --label-add redis-master=true — добавляем тег к нужной ноде, тег представляет собой ключ-значение.
Теги для всего кластера будут такими:
docker node update --label-add redis-master=true swarm-1 docker node update --label-add redis-slave-1=true swarm-2 docker node update --label-add redis-slave-2=true swarm-3 docker node update --label-add redis-sentinel-1=true swarm-1 docker node update --label-add redis-sentinel-2=true swarm-2 docker node update --label-add redis-sentinel-3=true swarm-3
Посмотреть какие теги установлены на нодах мы можем следующей командой:
docker node ls -q | xargs docker node inspect -f '{{ .ID }} [{{ .Description.Hostname }}]: {{ .Spec.Labels }}'
Функционала просмотра тегов из коробки нет, поэтому и придётся прибегнуть к таким ухищрениям.
Таким образом, на схеме размещение контейнеров будет следующим:
Собираем контейнеры
Теперь пришло время собирать контейнеры с нашими сервисами. Сначала мы создадим Dockerfile для каждого сервиса. За основу мы возьмем Ubuntu 18.04. Dockerfile для redis-master будет следующим:
FROM ubuntu:18.04 RUN apt update && apt upgrade -y && apt install redis-server -y && apt clean COPY redis.conf /etc/redis/redis.conf EXPOSE 6379 CMD ["redis-server", "/etc/redis/redis.conf"]
Файл конфигурации будет redis.conf. Он будет выглядеть следующим образом:
bind 0.0.0.0 port 6379
Стоит обратить внимание, что у нас не настроена авторизация в Redis, поэтому к нашему кластеру может подключиться абсолютно любой. Будьте с этим внимательны!
Dockerfile для redis-slave будет аналогичен redis-master:
FROM ubuntu:18.04 RUN apt update && apt upgrade -y && apt install redis-server -y && apt clean COPY redis.conf /etc/redis/redis.conf EXPOSE 6379 CMD ["redis-server", "/etc/redis/redis.conf"]
А конфигурация в файле redis.conf будет отличаться:
bind 0.0.0.0 port 6379 slaveof redis-master 6379
slaveof redis-master 6379 — данной директивой мы указываем, к какому мастеру подключаться. Dockerfile для redis-sentinel будет отличаться от рассмотренных ранее:
FROM ubuntu:18.04 RUN apt update && apt upgrade -y && apt install redis-server -y && apt clean COPY sentinel.conf /etc/redis/sentinel.conf EXPOSE 6379 CMD ["redis-server", "/etc/redis/sentinel.conf", "--sentinel"]
Аналогично и файл конфигурации:
bind 0.0.0.0 port 5000 sentinel monitor mymaster redis-master 6379 2 sentinel down-after-milliseconds mymaster 3000 sentinel failover-timeout mymaster 6000 sentinel parallel-syncs mymaster 1 logfile "/var/log/redis/redis-sentinel.log"
В конфигурационном файле указываем, что мы мониторим redis-master, который слушает порт 6379 и будет называть его mymaster. down-after-milliseconds mymaster указываем, через какое время мы считаем, что наш мастер «умер». failover-timeout указываем, через какое время начнёт работать failover. parallel-syncs указываем, сколько реплик будет переконфигурировано. Более подробно с описанием всех опций вы можете ознакомиться здесь.
Во второй части нашей статьи мы продолжим развёртывание полноценного кластера Redis, поэтому не пропустите! И оставляйте комментарии!
