IT заметки по программированию
IT заметки по программированию
IT заметки по программированию
IT заметки по программированию

Отказоустойчивый кластер Postgresql

Отказоустойчивая кластерная архитектура для PostgreSQL на основе Patroni, PgBouncer, HAProxy и etcd состоит из нескольких компонентов, каждый из которых играет определенную роль для обеспечения высокодоступности, балансировки нагрузки, отказоустойчивости и упрощения управления подключениями. Вот описание основных компонентов и их взаимодействий:

Компоненты кластера:

  1. PostgreSQL — Основная база данных.
  2. Patroni — Управляет высокодоступным кластером PostgreSQL, следит за состоянием кластера и осуществляет failover (переключение на резервную копию) при необходимости.
  3. etcd (или Consul/Zookeeper) — Координирующая система распределенного консенсуса, которая помогает Patroni поддерживать распределенную информацию о состоянии кластера.
  4. PgBouncer — Легковесный пул соединений для PostgreSQL, который уменьшает накладные расходы на создание и уничтожение подключений.
  5. HAProxy — Балансировщик нагрузки, который управляет маршрутизацией трафика между PostgreSQL-кластером, следя за состоянием мастера и реплик.

Взаимодействие компонентов:

  • PostgreSQL обеспечивает хранение данных и выполняет роль мастера (primary) или реплики (replica) в кластере.
  • Patroni управляет состоянием узлов PostgreSQL. Используя данные от etcd (или другой системы координации), Patroni знает, какой узел является мастером, а какие — репликами. При отказе мастера Patroni автоматически переводит одну из реплик в роль мастера (failover).
  • etcd хранит метаданные состояния кластера. Все узлы Patroni взаимодействуют с etcd для получения информации о текущем состоянии мастера, реплик и других метаданных, связанных с кластером.
  • PgBouncer служит пулом соединений между приложениями и базой данных PostgreSQL. Он поддерживает устойчивые подключения, уменьшая нагрузку на базу данных при большом количестве подключений и переподключений.
  • HAProxy действует как обратный прокси и балансировщик нагрузки. Он направляет трафик приложений к мастеру или репликам PostgreSQL, основываясь на метаданных о состоянии кластера от Patroni (через etcd).

Компоненты кластера и их функции:

1. PostgreSQL

  • Основная база данных, которая выполняет хранение и обработку запросов.
  • Мастер обрабатывает запросы на запись, а реплики могут обрабатывать запросы только на чтение (если настроено).

2. Patroni

  • Функции:
    • Контролирует работу PostgreSQL-кластера.
    • Осуществляет автоматическое переключение на резервный узел при падении мастера (failover).
    • Обеспечивает лидерство в кластере, используя систему координации (etcd).
    • Поддерживает консистентное состояние кластера, автоматически поднимая новую реплику при добавлении нового узла или восстановлении упавшего.
  • Основные задачи:
    • Управление состоянием PostgreSQL (мастер или реплика).
    • Мониторинг состояния PostgreSQL и координация через etcd.
    • Переключение мастера при сбое.

3. etcd

  • Функции:
    • Распределённое хранилище для ключей/значений, обеспечивающее консенсус для Patroni.
    • Обеспечивает согласованность данных и отказоустойчивость за счёт репликации и поддержания кворума.
  • Основные задачи:
    • Хранит метаданные кластера PostgreSQL, такие как текущий мастер, список реплик, их состояния.
    • Помогает Patroni синхронизировать информацию между узлами.

4. PgBouncer

  • Функции:
    • Пул соединений, который уменьшает накладные расходы на подключение к PostgreSQL.
    • Уменьшает нагрузку на PostgreSQL за счет управления соединениями и временного хранения подключений от клиентов.
  • Основные задачи:
    • Обеспечивает управление пулами соединений, поддерживая производительность кластера.
    • Перенаправляет запросы приложений на соответствующий узел PostgreSQL (мастер или реплика).

5. HAProxy

  • Функции:
    • Обратный прокси-сервер и балансировщик нагрузки для PostgreSQL-кластера.
    • Перенаправляет запросы от клиентов на нужные узлы кластера, в зависимости от состояния (мастер или реплика).
    • Может использоваться для балансировки запросов на чтение между репликами.
  • Основные задачи:
    • Проверка доступности мастера и реплик.
    • Маршрутизация запросов на запись к мастеру и запросов на чтение к репликам (если настроено).
    • Поддержка отказоустойчивости — если мастер выходит из строя, HAProxy перенаправляет трафик на новый мастер, который был выбран Patroni.

Архитектура кластера:

  1. Кластер PostgreSQL:
    • Несколько узлов PostgreSQL: один в роли мастера (primary), остальные — реплики (standby/replica).
    • Мастер обрабатывает все запросы на запись, реплики могут обрабатывать запросы на чтение (опционально).
  2. Patroni:
    • Запущен на каждом узле PostgreSQL.
    • Проверяет состояние локального узла (мастер или реплика) и взаимодействует с etcd для синхронизации состояния кластера.
    • При сбое мастера Patroni выбирает новую реплику для перевода в мастер.
  3. etcd:
    • Кластер etcd (3 или более узлов для отказоустойчивости).
    • Обеспечивает координацию между узлами Patroni.
    • Хранит информацию о текущем мастере и репликах, что помогает Patroni координировать действия.
  4. PgBouncer:
    • Локальный на каждом приложении или в отдельном узле между приложением и PostgreSQL.
    • Управляет пулом соединений для уменьшения нагрузки на PostgreSQL.
    • Может настроить маршрутизацию запросов на основе ролей узлов (мастер/реплика).
  5. HAProxy:
    • Прокси-сервер, который передает запросы от приложения к нужному узлу PostgreSQL.
    • Маршрутизирует запросы на запись к мастеру, а запросы на чтение — к репликам.
    • Поддерживает отказоустойчивость, перенаправляя трафик на новый мастер при сбое предыдущего.

Пример архитектуры:

Основные процессы:

  1. Инициализация кластера:
    • Patroni запускается на каждом узле PostgreSQL и взаимодействует с etcd для координации кластера.
    • Один из узлов становится мастером (primary), остальные — репликами.
  2. Мониторинг состояния:
    • Patroni периодически проверяет состояние каждого узла PostgreSQL и обновляет информацию в etcd.
    • HAProxy использует эту информацию для маршрутизации запросов на мастер или реплики.
  3. Failover:
    • Если мастер падает, Patroni выбирает новую реплику для его замены.
    • HAProxy и PgBouncer перенаправляют запросы на нового мастера, обеспечивая отказоустойчивость без остановки системы.
  4. Балансировка запросов:
    • HAProxy может балансировать запросы на чтение между репликами, если это настроено, и все запросы на запись отправляются на мастер.

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

 

Развертывание кластера с помощью Ansible

1. Развертываем кластер etcd + Etcdkeeper, как это сделать можно прочитать в следующих заметках:

2. Далее переходим к развертыванию кластера Postgresql + Patroni + Pgboucer.

Структура папок:

files/etcd.service

Для запуска etcd как сервиса systemd

group_vars/all.yaml

Переменные

inventory/hosts

Группы хостов, к которым будут применены плейбуки

templates/

В этой папке находятся шаблоны конфигурационных файлов

patroni.yaml.j2

Этот конфигурационный шаблон Jinja2 для Patroni используется для настройки узла PostgreSQL-кластера с высокодоступной архитектурой. Он динамически генерирует конфигурацию на основе переменных, которые задаются в Ansible-инвентаре. Разберём каждый ключевой компонент шаблона:

1. Основные параметры

  • name: {{ node_name }}
    • Задает имя узла, на котором будет работать Patroni. Значение подставляется из переменной node_name.
  • scope: {{ cluster_name }}
    • Указывает область кластера (имя кластера), которое также генерируется на основе переменной cluster_name. Все узлы в кластере должны иметь одно и то же значение scope, чтобы Patroni понимал, что они принадлежат одному и тому же кластеру.

2. REST API

  • restapi:
    • listen: 0.0.0.0:8008 — указывает адрес и порт, на которых REST API Patroni будет прослушивать запросы. Здесь используется 0.0.0.0, что позволяет принимать запросы со всех интерфейсов.
    • connect_address: {{ ansible_host }}:8008 — указывает IP-адрес и порт, по которым другие узлы могут обращаться к этому узлу через API Patroni. ansible_host — переменная Ansible, представляющая IP-адрес этого узла.
    • protocol, cacert, cert, key (закомментированные строки) — используются для настройки HTTPS и сертификатов, если нужно включить защищённый доступ к Patroni через API. Эти параметры позволяют установить клиентские сертификаты и ключи для зашифрованного взаимодействия.

3. etcd

  • etcd3:
    • hosts: {% for host in groups[‘etcd_nodes’] %}…{% endfor %} — динамически генерирует список адресов и портов etcd-узлов, к которым Patroni будет подключаться для хранения информации о состоянии кластера. Используется цикл для сбора всех узлов из группы etcd_nodes.
    • protocol: https, cacert, cert, key — настройки для взаимодействия с etcd через зашифрованное соединение (HTTPS). Параметры указывают на пути к сертификатам и ключам для обеспечения безопасности.
    • username, password — учётные данные для аутентификации в etcd, параметры задаются через переменные etcd_username и etcd_password.

4. Bootstrap (Инициализация кластера)

  • bootstrap.dcs:
    • Параметры настройки кластерного распределённого консенсуса через etcd (или другой DCS).
    • ttl: 100, loop_wait: 10, retry_timeout: 10 — определяют тайминги мониторинга кластера (время жизни сессии, время ожидания цикла и таймауты на повторные попытки).
    • maximum_lag_on_failover: 1048576 — максимальный допустимый лаг для реплики, чтобы она могла стать новым мастером при отказе текущего.
    • postgresql:
      • use_pg_rewind: true — позволяет использовать pg_rewind для быстрой синхронизации реплики с мастером после failover.
      • parameters — задаёт важные параметры конфигурации PostgreSQL, такие как уровень журналирования (wal_level), включение горячей реплики (hot_standby), и другие параметры репликации.
  • initdb — параметры для инициализации базы данных при первом запуске:
    • auth-host: md5, auth-local: peer — задают типы аутентификации для хостов и локальных подключений.
    • encoding: UTF8, data-checksums — задают кодировку базы данных и включают контрольные суммы данных.
  • pg_hba — динамически генерирует правила доступа для PostgreSQL:
    • host replication postgres ::1/128 md5 — доступ для репликации по IPv6.
    • {% for host in groups[‘etcd_nodes’] %}…{% endfor %} — задаются динамические правила для каждого узла etcd для репликации через указанный IP-адрес.
    • host all all 0.0.0.0/0 md5 — разрешает подключения ко всем пользователям с любых IP-адресов.

5. PostgreSQL

  • postgresql:
    • listen: 0.0.0.0:5432 — PostgreSQL будет прослушивать все IP-адреса на порту 5432.
    • connect_address: {{ ansible_host }}:5432 — IP-адрес и порт для подключения к этому узлу в кластере.
    • bin_dir — путь к исполняемым файлам PostgreSQL, зависит от версии (например, 11, 12).
    • data_dir — путь к каталогу данных PostgreSQL, задаётся переменной postgresql_data_dir.
    • pgpass — путь к файлу паролей для автоматической аутентификации в PostgreSQL.
    • authentication — параметры для подключения суперпользователя и репликатора:
      • superuser — логин и пароль суперпользователя PostgreSQL, задаётся через переменные.
      • replication — логин и пароль пользователя, ответственного за репликацию.
    • parameters — дополнительные параметры конфигурации PostgreSQL, например, путь для сокетов.

6. Теги (Tags)

  • nofailover, noloadbalance, clonefrom, nosync — параметры для управления поведением узлов:
    • nofailover: false — узел может участвовать в failover.
    • noloadbalance: false — узел участвует в балансировке нагрузки.
    • clonefrom: false — узел не используется в качестве источника для клонирования.
    • nosync: false — узел синхронизируется с кластером.

Заключение:

Шаблон описывает конфигурацию для узла Patroni, который управляет PostgreSQL-кластером.

  • Jinja2 шаблон позволяет динамически генерировать конфигурации для каждого узла на основе переменных Ansible, таких как IP-адреса, имена узлов и группы узлов.
  • Patroni обеспечивает высокую доступность за счёт координации с etcd, а также автоматического failover и управления кластером PostgreSQL.
  • В конфигурации предусмотрены параметры для работы с пулом соединений, настройками репликации и безопасным взаимодействием с etcd через HTTPS.

 

pgbouncer.ini.js

Этот конфигурационный файл предназначен для настройки PgBouncer — легковесного пула соединений для PostgreSQL. Он помогает оптимизировать управление подключениями, уменьшая накладные расходы на создание новых соединений и обеспечивая эффективное использование ресурсов. Рассмотрим каждый блок конфигурации.

1. [databases] — Конфигурация подключаемых баз данных

Этот блок определяет, к каким базам данных PgBouncer будет подключаться и куда направлять запросы клиентов. В данном случае:

  • mydb — это логическое имя базы данных, под которым клиенты будут подключаться через PgBouncer.
  • host=localhost — указывает, что PgBouncer будет подключаться к базе данных PostgreSQL, работающей на локальном хосте.
  • port=5432 — стандартный порт для PostgreSQL, на котором он слушает подключения.

Это означает, что все запросы, поступающие на PgBouncer с указанием базы данных mydb, будут перенаправляться на локальную базу данных PostgreSQL на порту 5432.

2. [pgbouncer] — Настройки самого PgBouncer

Этот блок содержит параметры работы самого PgBouncer.

  • listen_addr = 0.0.0.0
    • Указывает, на каких IP-адресах PgBouncer будет принимать подключения от клиентов. Значение 0.0.0.0 означает, что PgBouncer будет слушать на всех доступных сетевых интерфейсах.
  • listen_port = 6432
    • Порт, на котором PgBouncer будет ожидать подключения клиентов. В данном случае это порт 6432 (отличается от стандартного порта PostgreSQL, чтобы избежать конфликтов).
  • auth_type = md5
    • Тип аутентификации, который будет использоваться PgBouncer для проверки пользователей. В данном случае используется MD5-аутентификация, которая защищает пароли хэшированием.
  • auth_file = /etc/pgbouncer/userlist.txt
    • Путь к файлу, где хранятся учетные данные пользователей для аутентификации. В файле userlist.txt содержатся пары имя пользователя:md5-хэш пароля.
  • pool_mode = transaction
    • Режим работы пула соединений:
      • transaction — PgBouncer будет выделять клиенту подключение к PostgreSQL только на время выполнения одного SQL-транзакции. После завершения транзакции соединение возвращается в пул для использования другим клиентом.
      • Этот режим наиболее эффективен для высоконагруженных систем, так как он минимизирует время удержания соединения.
  • max_client_conn = 100
    • Максимальное количество клиентских подключений, которые PgBouncer одновременно может принимать. Если лимит превышен, новые подключения будут отвергаться.
  • default_pool_size = 20
    • Количество соединений с PostgreSQL, которые PgBouncer будет поддерживать в пуле для базы данных по умолчанию. Например, для базы данных mydb PgBouncer будет поддерживать 20 соединений с PostgreSQL, которые будут повторно использоваться клиентами.

Общий принцип работы:

  1. Подключение клиента: Клиенты подключаются к PgBouncer на порту 6432 и указывают базу данных mydb.
  2. Аутентификация: PgBouncer проверяет пользователя через файл /etc/pgbouncer/userlist.txt с использованием метода MD5.
  3. Пул соединений: После аутентификации PgBouncer выделяет из пула одно из соединений с базой данных PostgreSQL, которое затем используется для выполнения запросов клиента.
  4. Режим работы: В режиме transaction после завершения транзакции соединение возвращается в пул для последующего использования другими клиентами, что уменьшает накладные расходы на создание новых подключений.

Этот файл конфигурации настраивает PgBouncer для эффективной работы с подключениями, обеспечивает безопасность с помощью MD5-аутентификации и поддерживает пул соединений, который оптимизирует использование ресурсов базы данных.

 

haproxy.cfg.j2

Этот шаблон Jinja2 для конфигурации HAProxy настраивает балансировщик нагрузки для управления соединениями с двумя типами PostgreSQL-кластеров через PgBouncer: для мастера (master) и для реплик (read-only). В шаблоне используются переменные Ansible для динамического создания конфигурации на основе данных о хостах. Рассмотрим ключевые элементы и их предназначение.

1. Глобальная секция (global)

  • log 127.0.0.1 local0 — настраивает логирование на локальный syslog-сервер (127.0.0.1) с уровнем логирования local0. Это стандартная практика для записи логов HAProxy.
  • maxconn 4096 — задаёт максимальное количество одновременных соединений, которые HAProxy может обрабатывать (4096 в данном случае).
  • daemon — переводит HAProxy в режим фонового процесса (демона).

2. Секция defaults

  • log global — указывает, что настройки логирования будут использовать глобальные параметры из секции global.
  • option tcplog — включает запись логов для TCP-соединений.
  • retries 3 — определяет количество попыток переподключения к бэкенду в случае неудачи.
  • timeout connect 5000ms — время ожидания для установки соединения с бэкендом (5 секунд).
  • timeout client 500000ms и timeout server 500000ms — время ожидания активности со стороны клиента и сервера (500 секунд), это важно для длительных транзакций.

3. Секция frontend pgbouncer_master

  • *bind :6532 — связывает frontend с портом 6532 на всех доступных интерфейсах (*), чтобы HAProxy мог принимать входящие подключения для подключения к мастеру через PgBouncer.
  • mode tcp — задаёт TCP-режим работы, так как HAProxy будет балансировать соединения на уровне TCP (PgBouncer работает на TCP).
  • default_backend pgbouncer_master_backend — указывает, что все запросы, поступающие на этот frontend, будут перенаправляться в backend, который обрабатывает запросы к мастеру базы данных.

4. Секция backend pgbouncer_master_backend

  • mode tcp — аналогично секции frontend, здесь балансировка также осуществляется на уровне TCP.
  • option httpchk GET /master HTTP/1.1\r\nHost:\ localhost — активная проверка состояния (health check). HAProxy будет отправлять HTTP-запрос /master для проверки состояния мастера. Это полезно для определения доступности узла мастера PostgreSQL через API Patroni.
  • http-check expect status 200 — указывает, что узел считается здоровым, если возвращает HTTP-статус 200 OK.
  • default-server inter 1s fall 3 rise 2 on-marked-down shutdown-sessions — определяет параметры проверки состояния узлов:
    • inter 1s — интервал между проверками состояния (1 секунда).
    • fall 3 — узел считается недоступным, если 3 проверки подряд завершатся неудачей.
    • rise 2 — узел будет считаться снова доступным, если 2 проверки подряд будут успешными.
    • on-marked-down shutdown-sessions — завершает все активные сессии, когда узел помечается как недоступный.

5. Цикл по etcd_nodes для backend pgbouncer_master_backend

  • Это динамически генерируемый список серверов на основе узлов etcd, которые перечислены в группе etcd_nodes в инвентаре Ansible.
  • server {{ host }} — имя сервера (логический идентификатор).
  • {{ hostvars[host].ansible_host }}:{{ pgbouncer_listen_port }} — IP-адрес и порт PgBouncer на каждом узле, берутся из переменных Ansible.
  • maxconn 10000 minconn 10000 — задаёт минимальное и максимальное количество соединений, которые HAProxy может держать для этого узла.
  • check port 8008 — указывает, что HAProxy должен проверять состояние узла через порт 8008, который обычно используется Patroni для health check.

6. Секция frontend pgbouncer_readonly

  • *bind :6533 — связывает frontend с портом 6533 на всех доступных интерфейсах для обработки запросов к репликам базы данных через PgBouncer.
  • mode tcp — используется TCP-режим для балансировки.
  • default_backend pgbouncer_replica_backend — все запросы будут направляться в backend, обрабатывающий реплики.

7. Секция backend pgbouncer_replica_backend

  • mode tcp — режим работы на уровне TCP.
  • option httpchk GET /replica HTTP/1.1\r\nHost:\ localhost — активная проверка для реплик, HAProxy будет отправлять запросы к API Patroni с URI /replica, чтобы убедиться, что узел является здоровой репликой.
  • http-check expect status 200 — узел считается здоровым, если возвращает HTTP-статус 200 OK.
  • Остальные параметры идентичны секции pgbouncer_master_backend.

8. Цикл по etcd_nodes для backend pgbouncer_replica_backend

  • Этот цикл аналогичен тому, что используется в секции pgbouncer_master_backend. Он динамически создает список серверов для реплик, используя те же узлы etcd и параметры соединений.

Заключение:

Этот шаблон конфигурации HAProxy, сгенерированный с помощью Jinja2, позволяет динамически настраивать балансировку нагрузки для кластера PostgreSQL, используя PgBouncer для двух целей:

  • Балансировка подключений к мастеру через frontend на порту 6532.
  • Балансировка подключений к репликам через frontend на порту 6533.

API Patroni используется для активной проверки состояния узлов как мастера, так и реплик, что обеспечивает высокую доступность кластера.

Основной плейбук по развертыванию кластера Postgresql + Patroni + Pgbouncer

Этот плейбук Ansible предназначен для автоматического развертывания кластера PostgreSQL с использованием Patroni и PgBouncer на указанных узлах. Он охватывает несколько этапов: установку необходимых компонентов, настройку конфигурации и запуск соответствующих сервисов. Давайте подробно рассмотрим содержимое плейбука:

1. Инициализация и установка пакетов

Установка необходимых пакетов

  • Устанавливаются основные пакеты, необходимые для PostgreSQL, Patroni, PgBouncer и Python.
  • {{ postgresql_version }} — переменная, которая определяет, какую версию PostgreSQL нужно установить.
  • pgbouncer — это легковесный пул соединений для PostgreSQL.
  • etcd — необходим для координации кластера Patroni.

Установка Python-зависимостей через pip

  • Устанавливается модуль psycopg, который используется для взаимодействия с PostgreSQL через Python.

Установка Patroni и зависимостей для Etcd

  • Patroni — это инструмент для управления высокодоступными кластерами PostgreSQL.
  • Устанавливается с поддержкой etcd3 как одного из backend для хранения данных кластера.

2. Настройка Patroni

Создание каталога конфигурации и конфигурационного файла Patroni

  • Создаётся директория для хранения конфигурации Patroni.
  • Конфигурационный файл создаётся на основе Jinja2-шаблона patroni.yml.j2, который содержит настройки для каждого узла.

Настройка и запуск Patroni через systemd

  • Создаётся юнит-файл для systemd, чтобы можно было управлять сервисом Patroni как обычным демоном.
  • После этого производится перезагрузка демонов systemd для учёта нового сервиса.

Старт Patroni и остановка PostgreSQL

  • Сначала останавливается сервис PostgreSQL, так как теперь за его управление будет отвечать Patroni.
  • Patroni запускается и активируется для автозапуска при загрузке системы.

Конфигурация PgBouncer

  • Устанавливается и настраивается PgBouncer — это пулер соединений для PostgreSQL:
     
  • Создаётся конфигурационный файл для PgBouncer:
     
  • Этот файл определяет параметры подключения к базам данных PostgreSQL и настройки самого PgBouncer, такие как режим пула соединений, тип аутентификации и максимальное количество подключений.
  • {{ pgbouncer_listen_addr }}, {{ pgbouncer_listen_port }} и другие — это переменные, которые могут быть заданы в Ansible для динамического управления параметрами PgBouncer.
  • Добавляются пользователи для PgBouncer:
  • Этот файл содержит список пользователей PostgreSQL и их пароли для аутентификации через PgBouncer.
  • Создаётся юнит-файл systemd для PgBouncer:
     
  • И наконец, перезагружается systemd и запускается PgBouncer:
     

Этот плейбук Ansible полностью автоматизирует процесс развертывания кластера PostgreSQL с Patroni и PgBouncer:

  • Устанавливаются необходимые пакеты для PostgreSQL, Patroni и PgBouncer.
  • Конфигурируются Patroni и PgBouncer, обеспечивая высокую доступность и пул соединений.
  • Настраивается управление через systemd для Patroni и PgBouncer, что упрощает управление сервисами.

 

Развертывание Haproxy

Этот плейбук Ansible предназначен для автоматизации установки и настройки HAProxy на узлах, указанных в группе haproxy_nodes. Плейбук выполняет три основные задачи: установка HAProxy, настройка конфигурационного файла и перезапуск службы HAProxy.

1. Хосты и привилегии

  • hosts: haproxy_nodes — плейбук выполняется на всех хостах, указанных в группе haproxy_nodes в инвентаре Ansible.
  • become: yes — все команды будут выполняться с правами суперпользователя (root), что необходимо для установки пакетов и изменения системных конфигураций.

2. Установка HAProxy

  • Эта задача устанавливает пакет haproxy через пакетный менеджер apt (для систем на основе Debian/Ubuntu).
  • state: present — гарантирует, что HAProxy установлен на всех узлах (если он еще не установлен).

3. Настройка конфигурации HAProxy

  • Эта задача использует модуль template для копирования файла конфигурации HAProxy на каждый узел.
  • src: haproxy.cfg.j2 — путь к шаблону Jinja2, который хранится в локальной директории templates Ansible. Шаблон конфигурации динамически генерируется, подставляя переменные Ansible.
  • dest: «/etc/haproxy/haproxy.cfg» — целевой путь для конфигурационного файла HAProxy на узлах.
  • mode: ‘0644’ — устанавливает разрешения на файл, что позволяет чтение всем пользователям, но запись только владельцу.

4. Перезапуск HAProxy

  • Эта задача перезапускает сервис haproxy с помощью systemd после изменения конфигурационного файла.
  • state: restarted — сервис будет перезапущен, что позволяет применить новые настройки.

Заключение

Этот плейбук выполняет следующие действия:

  1. Устанавливает HAProxy на узлах.
  2. Загружает шаблон конфигурации haproxy.cfg.j2 и генерирует окончательный файл конфигурации на основе переменных.
  3. Перезапускает HAProxy, чтобы применить новую конфигурацию.

Такой плейбук автоматизирует развёртывание HAProxy, что полезно для настройки балансировки нагрузки в кластере.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *