Заряжай Patroni. Тестируем Patroni + Zookeeper кластер (Часть первая)25.12.2020 00:18

Зачем читать именно этот туториал?

Есть уже немало туториалов, которые рассказывают, как поднять кластер Patroni. Этот затрагивает вопросы деплоя в среде docker swarm и использования Zookeeper в качестве DCS.

Почему Zookeeper?

Я считаю, это один из моментов, которые стоит рассмотреть всерьез, прежде чем выбрать конечный сетап для продакшена. Дело в том, что Patroni использует сторонние сервисы чтобы установить и обслуживать коммуникацию между своими нодами. Их общее название — DCS (Dynamic Configuration Storage).

Если вы уже смотрели какие-то из туториалов о Patroni, то, должно быть, заметили, что самый частый кейс — это когда в качестве DCS используют Etcd кластер.

Интересный момент в работе Etcd кластера заключается в том, что:

Since etcd writes data to disk, its performance strongly depends on disk performance. For this reason, SSD is highly recommended.

(из документации Etcd)

Словом, если у вас нет по SSD диску на каждой машине, где будут работать ноды Etcd, то вы в зоне опасности. Конечно, пока нагрузка небольшая, то ничего критичного происходить не будет, но если это рабочий, нагруженный прод, то очень возможно (и даже вероятно), что вы просто перегрузите Etcd кластер. А это приведет к IO ошибкам при доступе к базе. Звучит скверно? На самом деле так и есть. Ловить такие ошибки на проде очень неприятно.

Здесь нам на помощь и может прийти Zookeeper, который ничего не пишет на диск и хранит все данные в памяти. Такой вариант оптимален в ситуации, когда не на всех серверах есть SSD, зато RAM хватает.

Почему Docker Swarm?

У меня не было выбора, так как одним из ключевых требований было, чтобы кластер был развернут в Swarm«е. Так что, если это и ваш кейс тоже, то вы в правильном месте!

Для тех же, кто открыл пост с желанием потестировать технологию, выбор Docker Swarm«а тоже может быть вполне органичным. Хотя бы по той причине, что вам не придется устанавливать и настраивать никаких сторонних сервисов (ну за исключением самого Docker«а, разумеется) или тянуть на локальную машину ворох непонятных зависимостей. Полагаю, недалеко от истины утверждение, что Docker у нас у всех и так уже настроен везде где только можно, мы все знаем, как он работает, так что почему бы не использовать его.

Потребуется лишь одна команда, чтобы сделать тюнинг Docker«а, который позволит развернуть на локальной машине кластер Patroni на 3 ноды без виртуальных машин, Kubernetes или подобных вещей.

Если вы не хотите копать в сторону каких-то еще инструментов за пределами Docker«а и хотите сделать все чисто и аккуратно, то данный туториал вам более чем подойдет.

А в конце будет небольшой бонус

Во второй части туториала я покажу различные варианты проверки статуса кластера (целых 3), и в конце дам простой скрипт с инструкциями для быстрого теста кластера.

Окей, достаточно разговоров. Давайте перейдем к практике.

version: '3.7'

services:
  zoo1:
    image: zookeeper:3.4
    hostname: zoo1
    ports:
      - 2191:2181
    networks:
      - patroni
    environment:
      ZOO_MY_ID: 1
      ZOO_SERVERS: server.1=0.0.0.0:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.hostname == floitet
      restart_policy:
        condition: any

  zoo2:
    image: zookeeper:3.4
    hostname: zoo2
    networks:
      - patroni
    ports:
      - 2192:2181
    environment:
      ZOO_MY_ID: 2
      ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=0.0.0.0:2888:3888 server.3=zoo3:2888:3888
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.hostname == floitet
      restart_policy:
        condition: any

  zoo3:
    image: zookeeper:3.4
    hostname: zoo3
    networks:
      - patroni
    ports:
      - 2193:2181
    environment:
      ZOO_MY_ID: 3
      ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=0.0.0.0:2888:3888
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.hostname == floitet
      restart_policy:
        condition: any

networks:
  patroni:
    driver: overlay
    attachable: true

Конечно же, важно дать каждой ноде уникальное имя и внешний порт. Hostname лучше ставить одинаковое с именем сервиса.

zoo1:
    image: zookeeper:3.4
    hostname: zoo1
    ports:
      - 2191:2181

Стоит отметить и то, как мы перечисляем host«ы в строке ниже: для первого сервиса server.1 будет привязан к 0.0.0.0, а, например, для zoo2 это уже будет server.2 соответственно и т.д.

ZOO_SERVERS: server.1=0.0.0.0:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

А таким образом мы контролируем распределение сервисов по нодам. Поскольку нода у нас сейчас только одна, мы спокойно могли бы убрать эти строчки из конфига, но когда серверов будет несколько, можно будет менять node.hostname и тем самым определять на какую ноду пойдет сервис.

     placement:
        constraints:
          - node.hostname == floitet

И последний момент, который мы здесь обсудим, это network. Я намерен деплоить все сервисы Zookeeper«а и все сервисы Patroni в одну сеть с драйвером overlay, чтобы они были изолированы от других сервисов и могли общаться между собой по именам, а не по IP (как это выглядит, будет видно дальше).

networks:
  patroni:
    driver: overlay
// мы должны отметить сеть как attachable  
// чтобы потом можно было присоединять к ней остальные сервисы
    attachable: true

scope: patroni
namespace: /service/

bootstrap:
    dcs:
        ttl: 30
        loop_wait: 10
        retry_timeout: 10
        maximum_lag_on_failover: 1048576
        postgresql:
            use_pg_rewind: true

    postgresql:
      use_pg_rewind: true

    initdb:
    - encoding: UTF8
    - data-checksums

    pg_hba:
    - host replication all all md5
    - host all all all md5

zookeeper:
  hosts: 
      - zoo1:2181
      - zoo2:2181
      - zoo3:2181

postgresql:
    data_dir: /data/patroni
    bin_dir: /usr/lib/postgresql/11/bin
    pgpass: /tmp/pgpass
    parameters:
        unix_socket_directories: '.'

tags:
    nofailover: false
    noloadbalance: false
    clonefrom: false
    nosync: false

Важно указать Patroni путь к бинарным файлам Postgres«а. В моем случае, так как я использую Postgres 11, директория выглядит так:»/usr/lib/postgresql/11/bin».

В директории, внутри уже созданного контейнера, Patroni будет искать файлы Postgres«а. Без этой настройки скорее всего ничего не взлетит (по крайней мере у меня не взлетело). И также еще есть «data_dir» — это место в контейнере, где будут храниться данные. Позже мы сделаем mount этой директории к месту на локальном жестком диске, чтобы не потерять все полимеры, если кластер все же упадет безнадежно. Это добавит нам работы по созданию этих папок локально, но, по-моему, оно того стоит.

postgresql:
    data_dir: /data/patroni
    bin_dir: /usr/lib/postgresql/11/bin

Также я перечисляю все сервера Zookeeper«а в этом конфиг файле, чтобы потом передать информацию о них утилите patronictl. Стоит отметить, что если не указать их в patroni.yml, то мы останемся в итоге с нерабочим patronictl. Как вы видите, перечисляя сервера, я не пишу никакие IP, а использую их имена. Это та самая фича Docker Swarm«а о которой я рассказывал выше.  

zookeeper:
  hosts: 
      - zoo1:2181
      - zoo2:2181
      - zoo3:2181

#!/bin/sh

readonly CONTAINER_IP=$(hostname --ip-address)
readonly CONTAINER_API_ADDR="${CONTAINER_IP}:${PATRONI_API_CONNECT_PORT}"
readonly CONTAINER_POSTGRE_ADDR="${CONTAINER_IP}:5432"

export PATRONI_NAME="${PATRONI_NAME:-$(hostname)}"
export PATRONI_RESTAPI_CONNECT_ADDRESS="$CONTAINER_API_ADDR"
export PATRONI_RESTAPI_LISTEN="$CONTAINER_API_ADDR"
export PATRONI_POSTGRESQL_CONNECT_ADDRESS="$CONTAINER_POSTGRE_ADDR"
export PATRONI_POSTGRESQL_LISTEN="$CONTAINER_POSTGRE_ADDR"
export PATRONI_REPLICATION_USERNAME="$REPLICATION_NAME"
export PATRONI_REPLICATION_PASSWORD="$REPLICATION_PASS"
export PATRONI_SUPERUSER_USERNAME="$SU_NAME"
export PATRONI_SUPERUSER_PASSWORD="$SU_PASS"
export PATRONI_approle_PASSWORD="$POSTGRES_APP_ROLE_PASS"
export PATRONI_approle_OPTIONS="${PATRONI_admin_OPTIONS:-createdb, createrole}"

exec /usr/local/bin/patroni /etc/patroni.yml

На самом деле, основной смысл вообще делать такой скрипт заключается в том, что мы просто не сможем стартануть сервис с Patroni, не зная IP адрес host«а. И в том случае, когда host«ом оказывается Docker-контейнер, нам как-то нужно сначала узнать какой же IP этот контейнер получил, и только потом мы можем запустить Patroni. Эта потребность закрывается вот здесь:

readonly CONTAINER_IP=$(hostname --ip-address)
readonly CONTAINER_API_ADDR="${CONTAINER_IP}:${PATRONI_API_CONNECT_PORT}"
readonly CONTAINER_POSTGRE_ADDR="${CONTAINER_IP}:5432"
...
export PATRONI_RESTAPI_CONNECT_ADDRESS="$CONTAINER_API_ADDR"
export PATRONI_RESTAPI_LISTEN="$CONTAINER_API_ADDR"
export PATRONI_POSTGRESQL_CONNECT_ADDRESS="$CONTAINER_POSTGRE_ADDR"

Как я уже говорил раньше, параметры конфига Patroni можно передавать разными способами. В этом скрипте мы пользуемся тем, что один из таких способов — это «Environment configuration». «PATRONIRESTAPICONNECTADDRESS», «PATRONIRESTAPILISTEN», «PATRONIPOSTGRESQLCONNECTADDRESS» — специальные переменные среды, о которых Patroni знает заранее и которые будут считаны. И кстати, они переписывают локальные настройки из patroni.yml, так что be aware!

И еще момент. Документация Patroni не рекомендует использовать superuser«а для подключения к базе приложений. Т.е. нужно создать отдельного юзера, который мы будем использовать непосредственно для коннекта, а superuser«а и replicator«а трогать не будем совсем. Создать такого юзера можно также через переменную среды. Если хотите, чтобы юзер назывался как-то иначе чем «approle», просто замените в этой строке «approle» на что-то другое.

export PATRONI_approle_PASSWORD="$POSTGRES_APP_ROLE_PASS"
export PATRONI_approle_OPTIONS="${PATRONI_admin_OPTIONS:-createdb, createrole}"

И в последней строчке, когда всё уже готово к старту, мы делаем запуск Patroni сервиса с указанием откуда брать основной конфиг файл:

exec /usr/local/bin/patroni /etc/patroni.yml

FROM postgres:11 

RUN apt-get update -y\ 
    && apt-get install python3 python3-pip -y\
    && pip3 install --upgrade setuptools\
    && pip3 install psycopg2-binary \
    && pip3 install patroni[zookeeper] \
    && mkdir /data/patroni -p \
    && chown postgres:postgres /data/patroni \
    && chmod 700 /data/patroni 

COPY patroni.yml /etc/patroni.yml
COPY patroni-entrypoint.sh ./entrypoint.sh
USER postgres

ENTRYPOINT ["bin/sh", "/entrypoint.sh"]

Одна из главных деталей здесь это директория, которую мы указываем создать внутри контейнера, а также ее владелец и его права. Позже, когда будем деплоить Patroni, нужно будет подобным же образом создать папки на локальной машине, куда мы сможем сделать mount этой директории из контейнера.

// владелец должен быть 'postgres', а mode 700

    mkdir /data/patroni -p \
    chown postgres:postgres /data/patroni \
    chmod 700 /data/patroni 
    ...
// устанавливаем в кач-ве активного юзера внутри контейнера 
// юзера postgres
    
    USER postgres

Файлы, которые мы создали, ранее копируются в имейдж в этих строчках:

COPY patroni.yml /etc/patroni.yml
COPY patroni-entrypoint.sh ./entrypoint.sh

И, как я уже упомянул ранее, мы хотим запустить этот скрипт сразу после создания контейнера:

ENTRYPOINT ["bin/sh", "/entrypoint.sh"]

version: "3.4"

networks:
    patroni_patroni: 
        external: true
services:
    patroni1:
        image: patroni-test
        networks: [ patroni_patroni ]
        ports:
            - 5441:5432
            - 8091:8091
        hostname: patroni1
        volumes:
          - /patroni1:/data/patroni
        environment:
            PATRONI_API_CONNECT_PORT: 8091
            REPLICATION_NAME: replicator 
            REPLICATION_PASS: replpass
            SU_NAME: postgres
            SU_PASS: supass
            POSTGRES_APP_ROLE_PASS: appass
        deploy:
          replicas: 1
          placement:
            constraints: [node.hostname == floitet]

    patroni2:
        image: patroni-test
        networks: [ patroni_patroni ]
        ports:
            - 5442:5432
            - 8092:8091
        hostname: patroni2
        volumes:
          - /patroni2:/data/patroni
        environment:
            PATRONI_API_CONNECT_PORT: 8091
            REPLICATION_NAME: replicator 
            REPLICATION_PASS: replpass
            SU_NAME: postgres
            SU_PASS: supass
            POSTGRES_APP_ROLE_PASS: appass
        deploy:
          replicas: 1
          placement:
            constraints: [node.hostname == floitet]


    patroni3:
        image: patroni-test
        networks: [ patroni_patroni ]
        ports:
            - 5443:5432
            - 8093:8091
        hostname: patroni3
        volumes:
          - /patroni3:/data/patroni
        environment:
            PATRONI_API_CONNECT_PORT: 8091
            REPLICATION_NAME: replicator 
            REPLICATION_PASS: replpass
            SU_NAME: postgres
            SU_PASS: supass
            POSTGRES_APP_ROLE_PASS: appass
        deploy:
          replicas: 1
          placement:
            constraints: [node.hostname == floitet]

Первое, о чем хочется сказать, это момент с external network, о котором говорилось ранее. Мы хотим разместить Patroni сервисы там же, где мы держим и сервисы Zookeeper. Таким образом мы сможем обращаться к сервисам по именам, и все имена: «zoo1′, «zoo2′, «zoo3′, — которые мы перечислили в patroni.yml, задавая сервера Zookeeper«а, будут работать, как надо.

networks:
    patroni_patroni: 
        external: true

Нужно отметить, что у нас будут два end point«а: сама база данных и API. И для того и для другого требуется открыть порты:

ports:
    - 5441:5432
    - 8091:8091
...

environment:
    PATRONI_API_CONNECT_PORT: 8091

// также нужно убедиться, что в PATRONI_API_CONNECT_PORT мы передаем
// тот же самый, который мы открываем для сервиса   

Также, нам, конечно, нужно передать все переменные среды, которые мы заявили в entrypoint скрипте. Но и это еще не всё. Есть вопрос с директорией для mount«а, который мы тоже здесь решаем:

volumes:
   - /patroni3:/data/patroni

Как видно из этой строки, ту директорию »/data/patroni», которая была создана в Dockerfile, мы монтируем к локальной директории. Так вот эту локальную директорию нам нужно создать. И не только создать, но и выставить правильного юзера и режим доступа, например так:

sudo mkdir /patroni3
sudo chown 999:999 /patroni3
sudo chmod 700 /patroni3

// 999 это дефолтный uid для юзера postgres  
// эти шаги нужно повторить для каждой ноды Patroni