Параметры СУБД

Параметры СУБД#

На этом шаге отредактируйте описание узла PostgreSQL, если он развертывается средствами платформы, или реквизиты доступа к внешней СУБД.

../../../../_images/general-green1.svg ../../../../_images/gateway-green1.svg ../../../../_images/autoexec-green1.svg ../../../../_images/content-green1.svg ../../../../_images/eda-green1.svg ../../../../_images/tls-green1.svg ../../../../_images/postgres-blue1.svg ../../../../_images/redis-white1.svg ../../../../_images/redis-dark1.svg

В составе платформы Astra Automation используются две СУБД:

  • PostgreSQL – реляционная, используется для хранения данных компонентов платформы;

  • Redis – нереляционная, используется для кеширования данных.

PostgreSQL#

СУБД PostgreSQL необходима для хранения данных компонентов платформы. Возможно использование уже существующего кластера PostgreSQL, например, развернутого в одном из облачных сервисов управляемых баз данных. Если отдельного кластера PostgreSQL нет, можно развернуть одиночный сервер СУБД средствами платформы на одном из узлов, выделенных для Astra Automation.

Примечание

СУБД PostgreSQL используется платформой для хранения данных, но не является ее частью. Настройка отказоустойчивой конфигурации PostgreSQL в этом руководстве не рассматривается. Для получения соответствующих инструкций обращайтесь к документации PostgreSQL.

Развертывание средствами платформы#

Для развертывания СУБД на отдельном узле средствами платформы выполните следующие действия:

  1. В описании инвентаря создайте группу database и добавьте в нее сведения об узле, например:

    [database]
database.example.com

    database:
  hosts:
    database.example.com:

  2. В глобальных переменных укажите значения параметров подключения к СУБД.

При развертывании СУБД средствами платформы в систему автоматически устанавливается расширение hstore. Дополнительные действия не требуются.

Внешняя СУБД#

При наличии существующего кластера PostgreSQL выполните следующие действия:

  1. Создайте в кластере PostgreSQL пользователей и принадлежащие им базы данных для используемых компонентов платформы.

  2. Убедитесь, что в описании инвентаря группа database существует, но не содержит узлов.

  3. В глобальных переменных укажите значения параметров подключения к СУБД.

  4. Проверьте, установлено ли расширение hstore для базы данных Private Automation Hub:

    psql -d <pah_database> -c "SELECT * FROM pg_available_extensions WHERE name='hstore';"

    Здесь <pah_database> – название базы данных.

Если расширение не установлено, выполните следующие действия:

  1. Установите дополнительные пакеты для PostgreSQL:

    sudo apt install postgresql-contrib

  2. Создайте расширение hstore в базе данных Private Automation Hub:

    psql -d <pah_database> -c "CREATE EXTENSION hstore;"

  3. Проверьте доступность расширения с помощью запроса:

    psql -d <pah_database> -c "SELECT * FROM pg_available_extensions WHERE name='hstore';"

    Если расширение установлено и настроено, в терминал выводится таблица следующего вида:

    name   | default_version | installed_version | comment
-------+-----------------+-------------------+------------------------------------------------------
hstore |      1.7        |       1.7         | data type for storing sets of (key, value) pairs
(1 row)

Использование отказоустойчивого внешнего кластера PostgreSQL#

При использовании отказоустойчивого внешнего кластера PostgreSQL значения automationgateway_pg_host, pg_host, automationhub_pg_host и automationedacontroller_pg_host должны указывать не на адрес конкретного узла СУБД, а на стабильную точку подключения к основному узлу PostgreSQL (stable writer endpoint).

В качестве стабильной точки подключения можно использовать:

  • виртуальный IP-адрес (VIP);

  • FQDN балансировщика;

  • другой плавающий (floating) адрес, который всегда указывает на текущий основной узел PostgreSQL.

Предупреждение

Если в параметрах подключения указан адрес конкретного основного узла PostgreSQL, то после переключения на другой узел потребуется вручную изменить соответствующие значения *_pg_host.

При использовании стабильной точки подключения ручное изменение этих параметров после переключения не требуется.

Даже при использовании стабильной точки подключения переключение не является полностью бесшовным. В момент переключения возможны кратковременные ошибки UI или API и разрывы уже открытых соединений с СУБД.

Для снижения окна деградации рекомендуется использовать pgBouncer в режиме session pooling. Ручной перезапуск компонентов платформы после переключения основного узла не является обязательным штатным действием, но должен быть предусмотрен как резервный сценарий, если автоматическое восстановление не уложилось в допустимое окно.

Параметры подключения к PostgreSQL#

Параметры подключения Platform Gateway, Automation Controller, Private Automation Hub и контроллера Event-Driven Automation к СУБД задаются в глобальных переменных:

# ...
[all:vars]
# Platform Gateway
automationgateway_pg_host='pg-ha.example.com'
automationgateway_pg_port=5432
automationgateway_pg_database='automationgateway'
automationgateway_pg_username='automationgateway'
automationgateway_pg_password='gateDBpaS$12345'
automationgateway_pg_sslmode='verify-full'

# Automation Controller
pg_host='pg-ha.example.com'
pg_port=5432
pg_database='awx'
pg_username='automationcontroller'
pg_password='ctrlDBpaS$123456'
pg_sslmode='verify-full'

# Automation Hub
automationhub_pg_host='pg-ha.example.com'
automationhub_pg_port=5432
automationhub_pg_database='automationhub'
automationhub_pg_username='automationhub'
automationhub_pg_password='hUbPa55I2345b'
automationhub_pg_sslmode='verify-full'

# Event-Driven Automation controller
automationedacontroller_pg_host='pg-ha.example.com'
automationedacontroller_pg_port=5432
automationedacontroller_pg_database='automationedacontroller'
automationedacontroller_pg_username='automationedacontroller'
automationedacontroller_pg_password='edapassword'
automationedacontroller_pg_sslmode='verify-full'

# Корневой сертификат УЦ, выпустившего сертификат сервера внешней СУБД.
# Обязателен для режимов require, verify-ca и verify-full.
# Переменная действует на весь инвентарь и принимает одно значение:
# если она уже задана на шаге настройки TLS, объедините сертификаты
# в один файл, а не заменяйте значение.
custom_ca_cert='/path/to/corporate-root-ca.crt'

---
# ...
all:
  vars:
    # Platform Gateway
    automationgateway_pg_host: pg-ha.example.com
    automationgateway_pg_port: 5432
    automationgateway_pg_database: automationgateway
    automationgateway_pg_username: automationgateway
    automationgateway_pg_password: gateDBpaS$12345
    automationgateway_pg_sslmode: verify-full

    # Automation Controller
    pg_host: pg-ha.example.com
    pg_port: 5432
    pg_database: awx
    pg_username: automationcontroller
    pg_password: ctrlDBpaS$123456
    pg_sslmode: verify-full

    # Automation Hub
    automationhub_pg_host: pg-ha.example.com
    automationhub_pg_port: 5432
    automationhub_pg_database: automationhub
    automationhub_pg_username: automationhub
    automationhub_pg_password: hUbPa55I2345b
    automationhub_pg_sslmode: verify-full

    # Event-Driven Automation controller
    automationedacontroller_pg_host: pg-ha.example.com
    automationedacontroller_pg_port: 5432
    automationedacontroller_pg_database: automationedacontroller
    automationedacontroller_pg_username: automationedacontroller
    automationedacontroller_pg_password: edapassword
    automationedacontroller_pg_sslmode: verify-full

    # Корневой сертификат УЦ, выпустившего сертификат сервера внешней СУБД.
    # Обязателен для режимов require, verify-ca и verify-full.
    # Переменная действует на весь инвентарь и принимает одно значение:
    # если она уже задана на шаге настройки TLS, объедините сертификаты
    # в один файл, а не заменяйте значение.
    custom_ca_cert: /path/to/corporate-root-ca.crt

Предупреждение

Пароли в примере являются демонстрационными. При использовании в продуктовой среде замените их на собственные.

Здесь:

  • automationgateway_pg_host, pg_host, automationhub_pg_host и automationedacontroller_pg_host – IP-адреса или FQDN серверов СУБД для Platform Gateway, Automation Controller, Private Automation Hub и контроллера Event-Driven Automation соответственно.

    Предупреждение

    Если переменная *_pg_host не задана, пуста или содержит 127.0.0.1, утилита развертывания считает, что компонент использует СУБД, развертываемую средствами платформы. При развертывании СУБД на выделенном узле группы [database] в переменных *_pg_host необходимо указать адрес этого узла. Для внешней СУБД указание адреса сервера обязательно.

    Для отказоустойчивого внешнего PostgreSQL используйте стабильную точку подключения к основному узлу PostgreSQL. При использовании стабильной точки подключения ручное изменение значений *_pg_host после переключения на другой узел не требуется.

  • automationgateway_pg_port, pg_port, automationhub_pg_port и automationedacontroller_pg_port – порты для подключения к СУБД для Platform Gateway, Automation Controller, Private Automation Hub и контроллера Event-Driven Automation соответственно.

    Значение по умолчанию: 5432.

  • automationgateway_pg_database, pg_database, automationhub_pg_database и automationedacontroller_pg_database – названия БД для Platform Gateway, Automation Controller, Private Automation Hub и контроллера Event-Driven Automation соответственно.

    Значения по умолчанию:

    • automationgateway_pg_database: automationgateway;

    • pg_database: awx;

    • automationhub_pg_database: automationhub;

    • automationedacontroller_pg_database: automationedacontroller.

  • automationgateway_pg_username, pg_username, automationhub_pg_username и automationedacontroller_pg_username – названия учетных записей пользователей БД Platform Gateway, Automation Controller, Private Automation Hub и контроллера Event-Driven Automation соответственно.

    Значения по умолчанию:

    • automationgateway_pg_username: automationgateway;

    • pg_username: awx;

    • automationhub_pg_username: automationhub;

    • automationedacontroller_pg_username: automationedacontroller.

  • automationgateway_pg_password, pg_password, automationhub_pg_password и automationedacontroller_pg_password – пароли пользователей БД Platform Gateway, Automation Controller, Private Automation Hub и контроллера Event-Driven Automation соответственно.

    Значения по умолчанию:

    • automationgateway_pg_password: automationgateway;

    • pg_password: awx;

    • automationhub_pg_password: automationhub;

    • automationedacontroller_pg_password: automationedacontroller.

  • custom_ca_cert – полный путь к файлу корневого сертификата удостоверяющего центра, выпустившего сертификат сервера внешней СУБД. Обязателен для режимов require, verify-ca и verify-full, так как без него библиотека libpq не признает сертификат сервера доверенным и подключение не установится. Подробности – в разделе Проверка сертификата сервера СУБД.

    Переменная действует на все описание инвентаря и принимает одно значение. Ее же задает шаг настройки сертификатов TLS, поэтому в одном разделе [all:vars] действующим остается последнее присваивание. Если переменная уже задана, укажите в ней файл, содержащий сертификаты всех нужных удостоверяющих центров сразу, а не заменяйте значение, потому что иначе компоненты платформы потеряют доверие к цепочке, заданной на шаге TLS.

Важно

Приведенный пример описывает подключение к внешней СУБД. Переменные postgres_use_ssl, postgres_ssl_cert и postgres_ssl_key настраивают сервер СУБД, развертываемый средствами платформы, на подключение к внешней СУБД не влияют и в этом примере не используются. Их описание приведено в справочнике переменных описания инвентаря. Режим защиты подключения к внешней СУБД задается только переменными *_pg_sslmode.

Режим защиты подключения к СУБД#

Режим защиты подключения задается отдельно для каждого компонента платформы:

Компонент

Переменная

Platform Gateway

automationgateway_pg_sslmode

Automation Controller

pg_sslmode

Private Automation Hub

automationhub_pg_sslmode

Контроллер Event-Driven Automation

automationedacontroller_pg_sslmode

Примечание

У Automation Controller переменная не имеет префикса с названием компонента – используется pg_sslmode. Переменная automationcontroller_pg_sslmode не поддерживается.

Значение по умолчанию для всех компонентов – prefer. Переменные принимают значения режима sslmode библиотеки libpq:

Значение

Поведение

disable

Подключение выполняется без шифрования.

allow

Сначала выполняется попытка подключения без шифрования. Если сервер отклоняет такое подключение, выполняется попытка подключения с шифрованием.

prefer

Сначала выполняется попытка подключения с шифрованием. Если сервер не поддерживает шифрование, подключение выполняется без шифрования.

require

Подключение выполняется только с шифрованием. В Astra Automation дополнительно проверяется цепочка сертификата сервера (см. проверку сертификата сервера СУБД). Соответствие названия узла в сертификате адресу подключения не проверяется.

verify-ca

Подключение выполняется только с шифрованием. Проверяется, что сертификат сервера выпущен доверенным удостоверяющим центром.

verify-full

Подключение выполняется только с шифрованием. Дополнительно к проверке режима verify-ca проверяется соответствие названия узла в сертификате сервера адресу, указанному в переменной *_pg_host.

Режимы allow и prefer не гарантируют шифрование: при отказе одной из сторон подключение выполняется в открытом виде.

В продуктовой среде рекомендуется использовать режим verify-full для всех четырех компонентов – то же требование предъявляет раздел о безопасности соединений. Отсутствие у сервера СУБД сертификата, выпущенного доверенным удостоверяющим центром, поводом для понижения режима не является: см. работу с самозаверенным сертификатом PostgreSQL.

Режим require шифрует канал и проверяет цепочку сертификата, но не связывает сертификат с адресом подключения, поэтому от подмены сервера СУБД не защищает. По фактическому поведению он совпадает с verify-ca, а не дает подключение без проверки сертификата.

Подробности о поддерживаемых параметрах шифрования см. в документации PostgreSQL.

Проверка сертификата сервера СУБД#

Во всех режимах, кроме disable, утилита развертывания передает библиотеке libpq параметр sslrootcert, указывающий на системное хранилище доверенных сертификатов узла (файл /etc/ssl/certs/ca-certificates.crt). Этот файл на узлах платформы существует всегда, а библиотека libpq при наличии файла корневых сертификатов проверяет цепочку сертификата сервера и в режиме require, что документация PostgreSQL описывает как совпадение поведения require с verify-ca.

Отсюда следуют требования к сертификату внешней СУБД:

  • В режимах require, verify-ca и verify-full удостоверяющий центр, выпустивший сертификат сервера PostgreSQL, должен быть доверенным на всех узлах платформы. Его корневой сертификат указывают в переменной custom_ca_cert – утилита развертывания добавляет этот сертификат в системное хранилище узлов – либо добавляют в хранилище вручную до запуска утилиты развертывания.

  • В режимах disable, allow и prefer подготовка удостоверяющего центра не требуется, так как disable подключается без шифрования, а allow и prefer при неудачном подключении с шифрованием переходят на подключение без шифрования.

Якорем доверия всегда остается системное хранилище узла целиком, а не отдельный сертификат сервера СУБД. Поэтому режимы require и verify-ca подтверждают лишь то, что сертификат выпущен каким-либо доверенным на узле удостоверяющим центром, включая публичные, но не то, что он принадлежит нужному серверу. Подлинность сервера СУБД подтверждает только режим verify-full, потому что он дополнительно требует совпадения адреса из переменных *_pg_host с полем Subject Alternative Name (SAN) предъявленного сертификата.

Примечание

Для Private Automation Hub действует исключение: если задана переменная custom_ca_trust_bundle, в параметре sslrootcert передается путь к указанному в ней набору сертификатов, а не к системному хранилищу. На остальные компоненты платформы переменная custom_ca_trust_bundle в этой части не влияет.

Для аутентификации по клиентскому сертификату в режимах verify-ca и verify-full дополнительно используют переменные *_pgclient_sslcert и *_pgclient_sslkey (см. справочник переменных описания инвентаря).

Работа с самозаверенным сертификатом PostgreSQL#

Если внешний сервер PostgreSQL использует самозаверенный сертификат, режимы require, verify-ca и verify-full завершаются ошибкой проверки цепочки доверия, так как такой сертификат не выпущен ни одним удостоверяющим центром из системного хранилища узлов платформы.

Доступны два варианта решения.

Примечание

Понижение режима до require выходом не является, потому что в Astra Automation этот режим тоже проверяет цепочку сертификата и с самозаверенным сертификатом завершается той же ошибкой. Подключиться без подготовки сертификатов позволяют только режимы allow и prefer, которые не гарантируют шифрование, и режим disable, который его не выполняет.

Выпуск сертификата PostgreSQL корпоративным удостоверяющим центром#

Рекомендуемый вариант. Для его применения выполните следующие действия:

  1. Выпустите для сервера PostgreSQL сертификат, подписанный корпоративным удостоверяющим центром. В поле Subject Alternative Name (SAN) укажите адрес, заданный в переменных *_pg_host.

  2. Настройте сервер PostgreSQL на использование выпущенного сертификата.

  3. В описании инвентаря укажите корневой сертификат удостоверяющего центра и режим защиты подключения.

    Если переменная custom_ca_cert уже задана на шаге настройки сертификатов TLS, объедините сертификаты обоих удостоверяющих центров в один файл и укажите его, так как значение у переменной одно на все описание инвентаря:

    [all:vars]
custom_ca_cert=/path/to/corporate-root-ca.crt
automationgateway_pg_sslmode='verify-full'
pg_sslmode='verify-full'
automationhub_pg_sslmode='verify-full'
automationedacontroller_pg_sslmode='verify-full'

    all:
  vars:
    custom_ca_cert: /path/to/corporate-root-ca.crt
    automationgateway_pg_sslmode: verify-full
    pg_sslmode: verify-full
    automationhub_pg_sslmode: verify-full
    automationedacontroller_pg_sslmode: verify-full

  4. Выполните ту же команду, что используется в процедуре развертывания платформы.

Добавление самозаверенного сертификата в хранилище доверенных сертификатов#

Быстрое решение для сред, в которых корпоративный удостоверяющий центр отсутствует. Самозаверенный сертификат сервера PostgreSQL сам выступает корневым сертификатом, поэтому его добавляют в системное хранилище доверенных сертификатов узлов платформы.

Для этого выполните следующие действия:

  1. Убедитесь, что в поле Subject Alternative Name (SAN) сертификата сервера PostgreSQL указан адрес, заданный в переменных *_pg_host. Если адреса там нет, перевыпустите самозаверенный сертификат с этим полем: без него режим verify-full неприменим, а режима verify-ca для проверки подлинности сервера недостаточно (см. предупреждение ниже).

  2. Скопируйте сертификат сервера PostgreSQL на установочный узел.

  3. Объедините его в один файл с сертификатом, заданным в переменной custom_ca_cert:

    cat /path/to/corporate-root-ca.crt /path/to/postgresql-server.crt > /path/to/ca-with-postgresql.crt

    Здесь:

    • /path/to/corporate-root-ca.crt – файл, ранее заданный в переменной custom_ca_cert;

    • /path/to/postgresql-server.crt – самозаверенный сертификат сервера PostgreSQL;

    • /path/to/ca-with-postgresql.crt – объединенный файл.

    Если переменная custom_ca_cert ранее не использовалась, объединение не требуется – в качестве значения переменной укажите файл с сертификатом сервера PostgreSQL.

  4. Укажите объединенный файл и режим защиты подключения в описании инвентаря:

    [all:vars]
custom_ca_cert=/path/to/ca-with-postgresql.crt
automationgateway_pg_sslmode='verify-full'
pg_sslmode='verify-full'
automationhub_pg_sslmode='verify-full'
automationedacontroller_pg_sslmode='verify-full'

    all:
  vars:
    custom_ca_cert: /path/to/ca-with-postgresql.crt
    automationgateway_pg_sslmode: verify-full
    pg_sslmode: verify-full
    automationhub_pg_sslmode: verify-full
    automationedacontroller_pg_sslmode: verify-full

  5. Выполните ту же команду, что используется в процедуре развертывания платформы.

Утилита развертывания копирует файл, заданный в переменной custom_ca_cert, в каталог /usr/local/share/ca-certificates/ на всех узлах платформы и обновляет системное хранилище доверенных сертификатов. После этого библиотека libpq считает сертификат сервера PostgreSQL доверенным.

Предупреждение

Добавление сертификата в системное хранилище не сужает якорь доверия, так как в параметре sslrootcert по-прежнему передается файл /etc/ssl/certs/ca-certificates.crt целиком. Поэтому общее правило действует и здесь, и подлинность сервера подтверждает только режим verify-full.

Сертификат, добавленный в системное хранилище, становится доверенным для всех приложений на узлах платформы, а не только для подключения к СУБД. При смене сертификата сервера PostgreSQL необходимо повторить процедуру.