Перейти к содержанию

Работа с внешним PostgreSQL

Данная инструкция описывает подготовку внешнего PostgreSQL (Postgres Pro, DBaaS, managed PG) и настройку AppSec.Hub для работы с ним при развертывании через Docker Compose.

Область применения: новая установка AppSec.Hub на внешнем PostgreSQL. Для обновления существующей установки — см. раздел «Обновление существующей установки».

Обозначения

В инструкции используются следующие параметры. Замените их реальными значениями вашего окружения:

Параметр Описание Пример
<PG_HOST> Хост/DNS PostgreSQL (endpoint для read/write) pg-master.example.com
<PG_PORT> Порт PostgreSQL для read/write 5432, 5000, 6432
<HUBADM_PWD> Пароль роли hubadm
<HUBAPP_PWD> Пароль роли hubapp
<HUBAUTH_PWD> Пароль роли hubauth
<HUBBI_PWD> Пароль роли hubbi
<SCHEDULER_PWD> Пароль роли scheduler (для модуля метрик)
<METRICS_USER_PWD> Пароль роли metrics_user (для модуля метрик)
<HUB_VERSION> Версия AppSec.Hub 2026.1.2

Порт: в разных контурах порт может отличаться (5432, 5000 и т.д.). Убедитесь, что используете порт, который ведёт к primary (read/write). Если перед PostgreSQL стоит PgBouncer — используйте порт PgBouncer, который ведёт к primary-инстансу.

Требования к PostgreSQL

Параметр Значение
Версия PostgreSQL 13.5+ / Postgres Pro 13+
Кодировка UTF-8
max_connections 400+ (рекомендация)
Расширения plpgsql (предустановлен), postgres_fdw (если используется модуль метрик)

Часть 1. Подготовка БД (выполняет DBA)

DBA - администратор БД.

Все SQL-команды ниже выполняются от имени администратора БД (пользователь с правами CREATEROLE, CREATEDB).

1.1. Создание ролей

-- Основные роли приложения
CREATE ROLE hubadm  WITH PASSWORD '<HUBADM_PWD>'  LOGIN;
CREATE ROLE hubapp  WITH PASSWORD '<HUBAPP_PWD>'  LOGIN;
CREATE ROLE hubbi   WITH PASSWORD '<HUBBI_PWD>'   LOGIN;
CREATE ROLE hubauth WITH PASSWORD '<HUBAUTH_PWD>' LOGIN;

-- hubadm должен наследовать права hubapp.
-- WITH ADMIN OPTION обязателен — без него автоматические миграции
-- не смогут повторно выполнить GRANT при обновлениях.
GRANT hubapp TO hubadm WITH ADMIN OPTION;

Если используется модуль метрик (Superset) — дополнительно:

CREATE ROLE scheduler    WITH PASSWORD '<SCHEDULER_PWD>'    LOGIN;
CREATE ROLE metrics_user WITH PASSWORD '<METRICS_USER_PWD>' LOGIN;

1.2. Создание баз данных

-- Основная БД
CREATE DATABASE hubdb WITH TEMPLATE = template0 ENCODING = 'UTF8' OWNER = hubadm;

-- Микросервисы
CREATE DATABASE pipeline_db  WITH TEMPLATE = template0 ENCODING = 'UTF8';
CREATE DATABASE scheduler_db WITH TEMPLATE = template0 ENCODING = 'UTF8';

Если используется модуль метрик:

CREATE DATABASE metrics_data WITH TEMPLATE = template0 ENCODING = 'UTF8' OWNER = scheduler;

1.3. Гранты на hubdb

GRANT CONNECT ON DATABASE hubdb TO hubapp;
GRANT CONNECT ON DATABASE hubdb TO hubbi;
GRANT CONNECT ON DATABASE hubdb TO hubauth;

-- Схемы НЕ создавать вручную — их создаст dump.pgdata (шаг 1.6)

1.4. Гранты на pipeline_db и scheduler_db

-- pipeline_db
GRANT ALL PRIVILEGES ON DATABASE pipeline_db TO hubapp;
\connect pipeline_db
GRANT ALL ON SCHEMA public TO hubapp;
GRANT CREATE ON SCHEMA public TO hubapp;
GRANT USAGE ON SCHEMA public TO hubapp;

-- scheduler_db
GRANT ALL PRIVILEGES ON DATABASE scheduler_db TO hubapp;
\connect scheduler_db
GRANT ALL ON SCHEMA public TO hubapp;
GRANT CREATE ON SCHEMA public TO hubapp;
GRANT USAGE ON SCHEMA public TO hubapp;

1.5. Настройка metrics_data (если используется модуль метрик)

\connect metrics_data

GRANT CONNECT ON DATABASE metrics_data TO metrics_user;

-- Схема для метрик
CREATE SCHEMA hub AUTHORIZATION scheduler;
GRANT USAGE ON SCHEMA hub TO metrics_user;
ALTER DEFAULT PRIVILEGES FOR ROLE scheduler IN SCHEMA hub
    GRANT SELECT ON TABLES TO metrics_user;

-- Foreign Data Wrapper — для доступа к данным hubdb из metrics_data
CREATE EXTENSION IF NOT EXISTS postgres_fdw;

CREATE SERVER remote_hub
    FOREIGN DATA WRAPPER postgres_fdw
    OPTIONS (host '<FDW_HOST>', port '<FDW_PORT>', dbname 'hubdb');

ALTER SERVER remote_hub OWNER TO scheduler;

CREATE USER MAPPING FOR scheduler
    SERVER remote_hub
    OPTIONS (user 'hubadm', password '<HUBADM_PWD>');

Выбор <FDW_HOST> и <FDW_PORT>:

FDW-соединение устанавливается изнутри PostgreSQL-сервера к hubdb на том же кластере.

Сценарий <FDW_HOST> <FDW_PORT>
PG доступен напрямую (без PgBouncer) localhost 5432 (или порт PG)
PG за PgBouncer Адрес PgBouncer primary Порт PgBouncer primary
PG за балансировщиком (roundrobin primary+replica) НЕ использовать! —

Почему нельзя использовать балансировщик для FDW: если балансировщик распределяет трафик между primary и replica, FDW-запросы будут случайно попадать на реплику и падать с ошибкой cannot execute ... in a read-only transaction.

Примечание: CREATE EXTENSION postgres_fdw может потребовать повышенных привилегий. В некоторых DBaaS-системах расширения устанавливаются через веб-консоль или обращение в поддержку. Уточните процедуру у вашего провайдера.

1.6. Восстановление baseline (КРИТИЧНО для новой установки!)

Этот шаг обязателен при новой установке. Без него Flyway не найдёт базовые таблицы и миграции не пройдут.

# 1. Извлечь dump.pgdata из Docker-образа hub-db
docker create --name tmp-hub-db registry.appsec.global/appsechub/hub-db:<HUB_VERSION>
docker cp tmp-hub-db:/opt/sql/dump.pgdata ./dump.pgdata
docker rm tmp-hub-db

# 2. Восстановить от имени hubadm
#    Подключение должно вести к PRIMARY (read/write)!
PGPASSWORD='<HUBADM_PWD>' psql -h <PG_HOST> -p <PG_PORT> -U hubadm -d hubdb -f dump.pgdata

Что создаст dump.pgdata:

  • 5 схем: hub, external, auth, audit, bi (owner = hubadm).
  • ~ 146 таблиц с индексами и ограничениями.
  • Функции, триггеры.
  • Все GRANT для hubapp, hubauth, hubbi.

Ожидаемое предупреждение (не фатальная ошибка): 

ERROR: must be owner of extension plpgsql
Это нормально — комментарий к расширению plpgsql не влияет на работу. Все остальные объекты создадутся успешно.

Если нет psql на рабочей машине: dump.pgdata — это обычный SQL-файл. Его можно выполнить любым клиентом PostgreSQL (DBeaver, pgAdmin и т.д.), подключившись как hubadm к базе hubdb. Главное — выполнить все команды из файла последовательно.

1.7. Проверка

После выполнения шагов 1.1–1.6 проверьте, что всё создано корректно:

-- Проверить роли
SELECT rolname, rolcanlogin
FROM pg_roles
WHERE rolname IN ('hubadm', 'hubapp', 'hubbi', 'hubauth', 'scheduler', 'metrics_user');

-- Проверить что hubadm наследует hubapp с admin option
SELECT member::regrole, roleid::regrole, admin_option
FROM pg_auth_members
WHERE member = 'hubadm'::regrole;
-- Ожидается: member=hubadm, roleid=hubapp, admin_option=true

-- Проверить базы данных
SELECT datname, pg_catalog.pg_get_userbyid(datdba) AS owner
FROM pg_database
WHERE datname IN ('hubdb', 'pipeline_db', 'scheduler_db', 'metrics_data');

-- Проверить схемы в hubdb
\connect hubdb
SELECT schema_name, schema_owner FROM information_schema.schemata
WHERE schema_name IN ('hub', 'external', 'auth', 'audit', 'bi');
-- Ожидается: owner = hubadm для всех пяти

-- Проверить количество таблиц (должно быть ~146)
SELECT count(*) FROM information_schema.tables
WHERE table_schema IN ('hub', 'external', 'auth', 'audit');

Если используется модуль метрик — дополнительно:

\connect metrics_data

-- Проверить FDW
SELECT srvname, srvowner::regrole,
       (SELECT option_value FROM pg_options_to_table(srvoptions) WHERE option_name = 'host') AS fdw_host,
       (SELECT option_value FROM pg_options_to_table(srvoptions) WHERE option_name = 'port') AS fdw_port
FROM pg_foreign_server;
-- Ожидается: remote_hub, owner = scheduler, host и port — к primary

Часть 2. Настройка AppSec.Hub (выполняет DevOps)

2.1. Изменения в .env

Изменения относительно стандартного .env:

# ============================================================
# PostgreSQL — внешний сервер (вместо встроенного контейнера)
# ============================================================
pgsql_url=<PG_HOST>
pgsql_port=<PG_PORT>
pgsql_admin_password=<HUBADM_PWD>

hub_db_name=hubdb
hub_adm_password=<HUBADM_PWD>
hub_app_password=<HUBAPP_PWD>
hub_auth_password=<HUBAUTH_PWD>
hub_bi_password=<HUBBI_PWD>

# ============================================================
# Managed Database — пропуск автоматического CREATE DB/ROLE
# ============================================================
IS_DATABASE_MANAGED=True

# ============================================================
# Метрики — внешний PG (вместо встроенного metrics-db)
# ============================================================
metrics_pg_user=scheduler
metrics_pg_password=<SCHEDULER_PWD>
metrics_pg_url=<PG_HOST>
metrics_pg_port=<PG_PORT>
metrics_db_password=<METRICS_USER_PWD>
metrics_scheduler_db_password=<SCHEDULER_PWD>
metrics_host=http://hub-superset
metrics_port=8088
metrics_username=admin
metrics_password=<SUPERSET_ADMIN_PWD>
metrics_database_url=postgresql+psycopg2://metrics_user:%s@<PG_HOST>:<PG_PORT>/metrics_data

2.2. Изменения в docker-compose.yml

2.2.1. Удалить или закомментировать встроенный PostgreSQL

    # ЗАКОММЕНТИРОВАТЬ или удалить:
    # postgresql:
    #     image: registry.appsec.global/public/sfs-postgresql:13.2.2-alpine
    #     ...

2.2.2. Удалить или закомментировать встроенный metrics-db

    # ЗАКОММЕНТИРОВАТЬ или удалить:
    # metrics-db:
    #     image: registry.appsec.global/public/sfs-postgresql:13.2.2-alpine
    #     ...

Вместо metrics-db и postgresql используется внешний PostgreSQL.

2.2.3. Контейнер flyway-db — миграции

    flyway-db:
        image: registry.appsec.global/appsechub/hub-db:${hub_db_version}
        container_name: flyway-db
        networks:
            - net-hub
        environment:
            - hubadmPassword=${hub_adm_password}
            - hubappPassword=${hub_app_password}
            - hubbiPassword=${hub_bi_password}
            - hubauthPassword=${hub_auth_password}
            - hubdbName=${hub_db_name}
            - PGPASSWORD=${pgsql_admin_password}
            - PGUSER=hubadm                          # ← было: postgres
            - PG_URL=${pgsql_url}
            - PG_PORT=${pgsql_port}
            - IS_DATABASE_MANAGED=${IS_DATABASE_MANAGED}  # ← ДОБАВИТЬ
            - REPAIR_DB_ENABLE=disable
            - REPAIR_DW_ENABLE=disable
        # depends_on postgresql удалить — PG внешний

Ключевые изменения:

  • PGUSER=hubadm вместо postgres — на внешнем PG нет роли postgres.
  • IS_DATABASE_MANAGED=True — скрипт migrate.sh пропустит CREATE ROLE/DATABASE/dump и сразу перейдёт к Flyway-миграциям.

2.2.4. Контейнер hub-pipeline

    hub-pipeline:
        # ...
        environment:
            - PG_USER=hubapp                             # ← было: postgres
            - PGPASSWORD=${hub_app_password}             # ← было: ${pgsql_admin_password}
            - PG_URL=${pgsql_url}
            - IS_DATABASE_MANAGED=${IS_DATABASE_MANAGED}  # ← ДОБАВИТЬ
            # ... остальные переменные без изменений

2.2.5. Контейнер scheduler

    scheduler:
        # ...
        environment:
            - PG_USER=hubapp                             # ← было: postgres
            - PGPASSWORD=${hub_app_password}             # ← было: ${pgsql_admin_password}
            - PG_URL=${pgsql_url}
            - IS_DATABASE_MANAGED=${IS_DATABASE_MANAGED}  # ← ДОБАВИТЬ
            # ... остальные переменные без изменений

2.2.6. Контейнер metrics-appsechub-bridge

    metrics-appsechub-bridge:
        container_name: 'metrics-appsechub-bridge'
        image: registry.appsec.global/appsechub/hub-metrics-bridge:${hub_metrics_bridge_version}
        networks:
            - net-hub
        # depends_on metrics-db удалить — PG внешний
        environment:
            PG_USER: ${metrics_pg_user}                  # scheduler
            PGPASSWORD: ${metrics_pg_password}
            PG_URL: ${metrics_pg_url}                    # <PG_HOST>
            PG_PORT: ${metrics_pg_port}                  # <PG_PORT>  ← ДОБАВИТЬ
            IS_DATABASE_MANAGED: ${IS_DATABASE_MANAGED}  # ← ДОБАВИТЬ
            SCHEDULER_DB_PASSWORD: ${metrics_scheduler_db_password}
            METRICS_DB_PASSWORD: ${metrics_db_password}
            REMOTE_HOST_DB: ${pgsql_url}
            REMOTE_PORT_DB: ${pgsql_port}
            REMOTE_DB: ${hub_db_name}
            REMOTE_USER_DB: hubadm
            REMOTE_PASSWORD_DB: ${hub_adm_password}
            METRICS_HOST: ${metrics_host}
            METRICS_PORT: ${metrics_port}
            METRICS_USERNAME: ${metrics_username}
            METRICS_PASSWORD: ${metrics_password}
            METRICS_DATABASE_URL: ${metrics_database_url}
            CHRON: "0 0 * * * *"
            CONSUL_HOST: http://consul
            CONSUL_PORT: 8500
            CONSUL_TOKEN: ${CONSUL_TOKEN}
        restart: on-failure:5
        deploy:
            resources:
                limits:
                    memory: 600M
                    pids: 400

2.2.7. Контейнеры metrics и metrics-init (Superset)

Superset хранит свои метаданные в metrics_data на внешнем PG. Нужно обновить docker/.env (файл для Superset):

# docker/.env — конфигурация Superset
DATABASE_DB=metrics_data
DATABASE_HOST=<PG_HOST>
DATABASE_PORT=<PG_PORT>
DATABASE_USER=scheduler
DATABASE_PASSWORD=<SCHEDULER_PWD>
DATABASE_DIALECT=postgresql
POSTGRES_DB=metrics_data
POSTGRES_USER=scheduler
POSTGRES_PASSWORD=<SCHEDULER_PWD>

В docker-compose.yml у metrics и metrics-init удалить depends_on: metrics-db.

2.2.8. Контейнеры, подключающиеся к hubdb (без изменений PG_USER)

Следующие контейнеры подключаются к hubdb как hubapp/hubauth через JDBC URL и не требуют переменных PG_USER/IS_DATABASE_MANAGED. Они не создают БД/роли — только подключаются. Убедитесь, что DB_URL указывает на внешний PG:

Контейнер DB_URL Пользователь
hub-core Через app.properties → db.hub.url hubapp / hubauth
hub-sso jdbc:postgresql://${pgsql_url}/${hub_db_name} hubapp + hubauth
hub-issue jdbc:postgresql://${pgsql_url}/${hub_db_name} hubapp
issue-rule jdbc:postgresql://${pgsql_url}/${hub_db_name} hubapp
hub-defect-sync jdbc:postgresql://${pgsql_url}/${hub_db_name} hubapp

Эти контейнеры возьмут хост из ${pgsql_url}, который уже указывает на внешний PG. Порт: в стандартном docker-compose.yml порт в JDBC URL не параметризован — он берётся как часть хоста. Убедитесь, что DB_URL содержит правильный порт:

    # Если порт ≠ 5432, нужно явно указать его в DB_URL:
    - DB_URL=jdbc:postgresql://${pgsql_url}:${pgsql_port}/${hub_db_name}

Важно: в стандартном docker-compose.yml у issue-rule, hub-issue, hub-sso, hub-defect-sync переменная DB_URL записана как jdbc:postgresql://${pgsql_url}/${hub_db_name} — без порта. Если порт PG отличается от 5432, добавьте :${pgsql_port} после ${pgsql_url}.

2.2.9. hub-core — app.properties и auth.properties

Файлы монтируются через volume. Убедитесь, что JDBC URL указывает на внешний PG:

config/hub-core/app.properties: 

db.hub.url=jdbc:postgresql://<PG_HOST>:<PG_PORT>/hubdb?currentSchema=hub
db.hub.username=hubapp
db.hub.password=<HUBAPP_PWD>

config/hub-core/auth.properties: 

db.auth.url=jdbc:postgresql://<PG_HOST>:<PG_PORT>/hubdb?currentSchema=auth
db.auth.username=hubauth
db.auth.password=<HUBAUTH_PWD>

2.3. Сводка изменений

Что Было (встроенный PG) Стало (внешний PG)
pgsql_url postgresql (имя контейнера) <PG_HOST> (DNS/IP внешнего PG)
pgsql_port 5432 <PG_PORT> (порт контура)
pgsql_admin_password пароль postgres пароль hubadm
Контейнер postgresql Включён Удалён/закомментирован
Контейнер metrics-db Включён Удалён/закомментирован
PGUSER в flyway-db postgres hubadm
PG_USER в pipeline/scheduler postgres hubapp
IS_DATABASE_MANAGED отсутствует True
metrics_pg_url metrics-db (контейнер) <PG_HOST>
metrics_pg_user metrics scheduler
JDBC URL (порт) порт не указан (5432 по умолч.) :<PG_PORT> добавлен явно

Часть 3. Запуск и проверка

3.1. Порядок запуска

Внешний PostgreSQL ←── уже работает, БД подготовлена (Часть 1)
       │
       ▼
flyway-db ──► pg_isready OK → IS_DATABASE_MANAGED=True
              → пропуск CREATE ROLE/DATABASE/dump
              → Flyway migrate (647 миграций) → afterMigrate.sql
              → Flyway migrate (bi/DWH)
              → exit 0 (service_completed_successfully)
       │
       ├──────┬──────┬──────┬──────┬──────┬──────────────────┐
       ▼      ▼      ▼      ▼      ▼      ▼                  ▼
    hub-sso  hub-   hub-   hub-   hub-   scheduler    metrics-bridge
             issue  issue  defect pipel             → IS_DATABASE_MANAGED
                    rule   sync   ine               → пропуск CREATE
                                 → IS_              → Liquibase migrate
                                 DATABASE           → FDW-таблицы
                                 MANAGED
                                 → пропуск
                                   CREATE
                                 → Liquibase
       │                    │      │      │              │
       ▼                    ▼      ▼      ▼              ▼
    hub-core ◄── depends_on     OK     OK          superset
    (main app)                                     (metrics UI)

3.2. Проверка после запуска

# 1. flyway-db завершился успешно
docker logs flyway-db 2>&1 | tail -20
# Ожидается: "Successfully applied N migrations", exit code 0

# 2. hub-core стартовал
docker logs hub-core 2>&1 | grep -E "CoreDaoPool|CoreAuthPool|deployed"
# Ожидается: "Start completed" для обоих пулов

# 3. pipeline создал таблицы
docker logs hub-pipeline 2>&1 | grep -E "IS_DATABASE_MANAGED|Liquibase"
# Ожидается: "IS_DATABASE_MANAGED=True → skipping DB init", Liquibase changesets

# 4. scheduler создал таблицы
docker logs scheduler 2>&1 | grep -E "IS_DATABASE_MANAGED|Liquibase"
# Ожидается: аналогично pipeline

# 5. metrics-bridge (если используется)
docker logs metrics-appsechub-bridge 2>&1 | grep -E "IS_DATABASE_MANAGED|Liquibase|foreign"
# Ожидается: "IS_DATABASE_MANAGED=True → skipping DB init", Liquibase, foreign tables created

Обновление существующей установки

Если AppSec.Hub уже работает (таблицы, данные и Flyway-история существуют) и вы переходите на внешний PG или обновляете версию:

Что делает DBA

-- Убедиться что грант есть (идемпотентно):
GRANT hubapp TO hubadm WITH ADMIN OPTION;

-- Проверить наличие всех БД:
SELECT datname FROM pg_database
WHERE datname IN ('hubdb', 'pipeline_db', 'scheduler_db', 'metrics_data');

-- Если какой-то БД нет — создать (см. шаги 1.2, 1.4, 1.5)

Что делает DevOps

Применить изменения из Части 2 (.env, docker-compose.yml, app.properties).

Что НЕ нужно делать

  • НЕ восстанавливать dump.pgdata — таблицы и Flyway-история уже есть.
  • НЕ пересоздавать схемы — они уже существуют.

Известные особенности

1. Балансировщик и read-only ошибки

Если единый endpoint (<PG_HOST>:<PG_PORT>) ведёт к балансировщику, который распределяет трафик между primary и replica — write-операции будут случайно падать:

ERROR: cannot execute INSERT in a read-only transaction
ERROR: cannot execute TRUNCATE TABLE in a read-only transaction

Решение: убедитесь, что endpoint для AppSec.Hub ведёт только к primary. Если есть отдельные readonly-инстансы — они не должны использоваться для write-трафика Hub.

2. FDW через балансировщик

FDW устанавливает соединение изнутри PostgreSQL-сервера. Если в CREATE SERVER указан endpoint балансировщика, FDW-запросы могут попадать на реплику. Убедитесь, что FDW указывает на primary.

Если FDW уже создан с неправильным адресом: 

\connect metrics_data
ALTER SERVER remote_hub OPTIONS (SET host '<CORRECT_HOST>');
ALTER SERVER remote_hub OPTIONS (SET port '<CORRECT_PORT>');

3. PgBouncer — добавить все БД и роли

Если приложения подключаются через PgBouncer, убедитесь что все БД и роли добавлены в конфигурацию PgBouncer:

pgbouncer.ini ([databases]): 

hubdb        = host=<PG_PRIMARY> port=5432 dbname=hubdb
pipeline_db  = host=<PG_PRIMARY> port=5432 dbname=pipeline_db
scheduler_db = host=<PG_PRIMARY> port=5432 dbname=scheduler_db
metrics_data = host=<PG_PRIMARY> port=5432 dbname=metrics_data

userlist.txt — MD5-хеши: 

"hubadm"       "<md5hash>"
"hubapp"       "<md5hash>"
"hubauth"      "<md5hash>"
"hubbi"        "<md5hash>"
"scheduler"    "<md5hash>"
"metrics_user" "<md5hash>"

Генерация MD5-хешей: 

SELECT 'md5' || md5('<PASSWORD>' || '<USERNAME>');
-- Пример: SELECT 'md5' || md5('mypassword' || 'hubapp');

После изменений — перечитать конфиг PgBouncer: 

# Через сигнал:
kill -HUP <pgbouncer_pid>
# Или через admin-консоль PgBouncer:
# RELOAD;

4. TLS/SSL для подключений к PostgreSQL

Статус: в текущей версии AppSec.Hub (2026.1) JDBC URL и psql-подключения не содержат параметров sslmode. Если внешний PostgreSQL требует TLS, необходимо:

  1. Добавить ?sslmode=require (или verify-full) к JDBC URL в app.properties, auth.properties и DB_URL всех микросервисов.
  2. При sslmode=verify-full — подложить CA-сертификат в Java truststore (cacerts) контейнеров hub-core и микросервисов.
  3. Для psql-подключений (flyway-db, pipeline, scheduler) — задать PGSSLMODE=require в environment.

Детали конфигурации TLS уточняйте у команды поддержки AppSec.Hub.

5. COMMENT ON EXTENSION plpgsql

При восстановлении dump.pgdata появляется ошибка: 

ERROR: must be owner of extension plpgsql
Это не фатально. Комментарий к встроенному расширению не влияет на работу. Все остальные объекты создаются успешно.

6. ADMIN option cannot be granted back to your own grantor

На PostgreSQL 16+ при повторном выполнении GRANT hubapp TO hubadm WITH ADMIN OPTION может появиться предупреждение: 

WARNING: role "hubadm" is already a member of role "hubapp"
или: 
ERROR: ADMIN option cannot be granted back to your own grantor
Это не фатально — грант уже существует. Скрипт migrate.sh продолжит работу.

Чеклист

Новая установка

DBA:

  • [ ] Создать 4 роли: hubadm, hubapp, hubbi, hubauth.
  • [ ] GRANT hubapp TO hubadm WITH ADMIN OPTION.
  • [ ] Создать 3 БД: hubdb (owner=hubadm), pipeline_db, scheduler_db.
  • [ ] Гранты CONNECT на hubdb для hubapp, hubbi, hubauth.
  • [ ] Гранты на public schema в pipeline_db и scheduler_db для hubapp.
  • [ ] Восстановить dump.pgdata в hubdb от hubadm.
  • [ ] Проверка (шаг 1.7).
  • [ ] (метрики) Создать роли scheduler, metrics_user.
  • [ ] (метрики) Создать БД metrics_data (owner=scheduler).
  • [ ] (метрики) Схема hub, расширение postgres_fdw, foreign server, user mapping.
  • [ ] (PgBouncer) Добавить все БД и роли в конфигурацию PgBouncer.

DevOps:

  • [ ] Обновить .env (Часть 2.1).
  • [ ] Обновить docker-compose.yml (Часть 2.2).
  • [ ] Обновить app.properties и auth.properties (Часть 2.2.9).
  • [ ] (метрики) Обновить docker/.env для Superset (Часть 2.2.7).
  • [ ] Запуск и проверка (Часть 3).

Обновление существующей установки

DBA:

  • [ ] GRANT hubapp TO hubadm WITH ADMIN OPTION (если ещё не выдан).
  • [ ] Проверить наличие pipeline_db, scheduler_db, metrics_data.

DevOps:

  • [ ] Применить изменения из Части 2.
  • [ ] dump.pgdata НЕ восстанавливать.
  • [ ] Запуск и проверка (Часть 3).
К началу