5. Резервное копирование и восстановление
5.1. Основные понятия
Задачи резервного копирования разделяются на 2 типа:
Создание резервных копий Datamart Platform Studio (Оркестратора Витрин данных)
При этом производится сохранение всех данных, содержащихся в папке Datamart Platform Studio, включающих в себя настройки доступа к инфраструктуре, конфигурацию Услуг со всеми настройками и настроечными файлами, данные бандлов и приложений, используемых в Datamart Platform Studio и хранящихся в папке DMS-DIRS и в БД Студии, настройки доступа к БД, глобальные параметры.
Важно
При создании резервной копии Datamart Platform Studio не производится резервное копирование данных Витрин и прочих Услуг!
Размер файла резервной копии Datamart Platform Studio зависит от объема данных, хранимых в Datamart Platform Studio и не зависит от объема данных Витрин и прочих Услуг, добавленных в Datamart Platform Studio.
Создание резервных копий услуг типа Витрина данных
При создании резервных копий Витрин данных производится полное сохранение статуса Витрины - всех данных, содержащихся в Витрине на момент копирования (в СУБД Витрины и сервисах потоковой обработки данных).
Важно
При создании резервной копии Витрины, происходит сохранение данных Витрины, но не настроек приложений.
Размер файла резервной копии Витрины зависит от объема данных, хранимых в Витрине. Для обеспечения процесса непрерывности функционирования Витрин в процессе резервного копирования и консистентности данных, сначала создается копия Витрины, потом происходит её упаковка в файл архива. В связи с этим, при расчете требуемого места необходимо учитывать, что помимо места для хранения файлов архивов резервных копий, необходимо предусмотреть достаточный объем диска для хранения еще одной копии данных Витрины для обеспечения процесса резервного копирования.
5.2. Резервное копирование из веб-интерфейса
Примечание
Выполнение процедур бэкап из интерфейса Datamart Platform Studio разрешено только пользователям с ролями superadmin, admin, backup (см. раздел «Права ролей в Datamart Platform Studio»)
5.2.1. Резервное копирование и восстановление Datamart Platform Studio
Для вызова задачи резервного копирования данных Студии в меню пользователя Студии необходимо выбрать пункт «Резервное копирование», затем «Создать резервную копию».
Для восстановления Студии из резервной копии в меню пользователя необходимо выбрать пункт «Резервное копирование», выбрать требуемый файл для восстановления и выбрать опцию «Восстановить».
При восстановлении веб-интерфейс Студии будет отключен, доступ к нему возобновится после восстановления.
5.2.2. Резервное копирование и восстановление услуг типа Витрин данных НСУД
Для выполнения резервного копирования и восстановления Витрин данных, Datamart Platform Studio использует утилиту Типового ПО Витрин данных Backup Manager.
Для вызова утилиты в разделе Бекапы Витрины в интерфейсе Datamart Platform Studio необходимо выбрать опцию «Создать».
Для восстановления в разделе Бекапы Витрины в интерфейсе Datamart Platform Studio необходимо у файла резервной копии, из которого необходимо выполнить восстановление, выбрать пункт «Резервное копирование», выбрать опцию «Восстановить».
5.3. Резервное копирование и восстановление Datamart Platform Studio из консоли
5.3.1. При установке на сервере или ВМ
Для создания файла резервной копии в папке, в которой установлена Datamart Platform Studio необходимо от имени пользователя datamart остановить программу и выполнить команду backup:
./datamart-studio stop
./datamart-studio backup
После выполнения процедуры бекапирования, в директории ./backup будет создан архив с отметкой о версии и времени бэкапа. При неудаче или отмене частично созданный бэкап удаляется.
После окончания процедуры бэкапа необходимо снова запустить программу:
./datamart-studio start
Восстановление из резервной копии или запуск упакованного дистрибутива в новом месте, соответственно, осуществляется последовательным выполнением распаковки архива в домашней директории Datamart Platform Studio и запуска программы:
tar -zxvf <backup_file_name>.tgz
./datamart-studio start
5.3.2. При установке в среде Kubernetes
Подключитесь SSH-клиентом к серверу управления, с которого производилась установка и на котором расположены скрипты для управления Datamart Platform Studio в Kubernetes.
Перейдите в папку Datamart Studio командой:
cd /opt/datamart_studio
Выполните действия создания резервной копии (в процессе бэкапа ПО будет остановлено, бэкап-файлы будут сохранены в архив /opt/datamart_studio/backup/datamart-studio-<version>-backup.tgz и ПО будет вновь запущено):
./datamart-studio backup-k8s
Успешный процесс создания резервной копии завершается сообщением:
Datamart Studio status: 'Backup completed successfully'
Проверьте факт создания файла резервной копии командой:
ls /opt/datamart_studio/backup/
Восстановление из резервной копии осуществляется последовательным выполнением команды, с указанием файла, из которого нужно произвести восстановление данных для контейнеров (в процессе восстановления ПО будет остановлено, данные восстановлены из архива и ПО будет вновь запущено):
./datamart-studio restore-k8s /opt/datamart_studio/backup/datamart-studio-<version>-backup.tgz
, где datamart-studio-<version>-backup.tgz - имя файла архива для восстановления, <version> - версия Datamart Platform Studio, которая автоматически выставляется скриптом бэкапа.
6. Обновление Datamart Platform Studio
6.1. Определение версии сборки
Версия текущей сборки ПО Datamart Platform Studio отображается в заголовке на странице сводной панели во всплывающем окне (см. Рисунок 6.1):
Рисунок 6.1 Версия сборки Datamart Platform Studio
6.2. Обновление из веб-интерфейса Datamart Platform Studio
В конфигурационном файле Datamart Platform Studio указываются адреса хранилищ, используемых по умолчанию для проверки наличия обновлений и проведения обновления контейнеров Программы, а также бандлов и приложений Витрин данных ( см. Раздел 12.1 Настройка параметров в файле конфигурации).
# адрес хранилища для обновления Docker-контейнеров Студии (используется для проверки наличия обновлений для контейнеров Программы)
DOCKER_REGISTRY=nexus.datamart.ru/dms -
# настройки доступа к Nexus - хранилищу объектов
GLOBAL_VALUES='{"nexus":"http://127.0.0.1:8881", "nexus_registry":"127.0.0.1:8882"}' - назначаются глобальные настройки по умолчанию
# настройки подключения к хранилищу репозиториев Gitea
GITEA_HOST=http://gitea
GITEA_PORT=3000
По умолчанию, эти настройки указывают на доступные хранилища контейнеров Датамарт и на локальные версии Nexus и Gitea. Данные настройки могут быть изменены системным администратором в зависимости от потребностей и условий эксплуатации. Например, в закрытом контуре, для хранилища контейнеров может использоваться собственное хранилище, в которое будут вручную или автоматически добавляться свежие версии контейнеров для обновления.
При обнаружении более свежих контейнеров в хранилище, в шапке интерфейса включается индикатор наличия обновлений (см. Рисунок 6.2):
Рисунок 6.2 Индикатор наличия обновлений
При нажатии на кнопку «Обновить» будет запущена процедура обновления контейнеров Программы.
После успешного обновления контейнеров, необходимо запустить процедуру обновления бандлов из хранилищ(а) репозиториев. Для этого в разделе «Хранилища репозиториев» необходимо нажать на кнопку «Обновить» для каждого из хранилищ.
Примечание
Как правило, в Программе используется одно хранилище, и процесс обновления Программы логически завершается обновлением бандлов. Однако, могут потребоваться и другие конфигурации обновлений, например, обновить Программу и только одно из хранилищ, если их несколько.
6.3. Обновление из консоли для Datamart Platform Studio, установленной на сервере (ВМ)
Примечание
В зависимости от мощности сервера и скорости каналов связи процесс обновления может занять от 30 до 60 минут.
Для обновления Datamart Studio установленной на сервере необходимо произвести следующие действия в консоли от имени пользователя datamart:
Перейти в папку с установленной Datamart Platform Studio (в текущем примере /home/datamart)
# cd /home/datamart
Остановить текущую версию, выполнив команду
stop:
# ./datamart-studio stop
Рисунок 6.3 Остановка Datamart Platform Studio
Создать бэкап текущей версии Datamart Studio
Перед созданием бэкапа желательно удалить из папки старые архивы, если они там есть (например, файл datamart-studio-xxx.tgz мог остаться после установки), так как они будут занимать лишнее место в папке бэкапа.
Для запуска процедуры архивации бэкап копии текущей версии выполняем команду:
# sudo ./datamart-studio backup
Примечание
Созданный бэкап-файл будет помещен по умолчанию в подпапку ./backup
Если требуется применить дополнительные опции бэкапирования, см. раздел Раздел 5 Резервное копирование и восстановление
Процесс архивации достаточно длительный и, в зависимости от размера программы и мощности сервера, может занимать 10 минут или более.
Скачать архив с обновлением для новой версии
Например, для скачивания архива в папку /tmp, необходимо выполнить команды:
# cd /tmp
# sudo wget https://dms-demo.datamart.ru/datamart/dtms-builds/datamart-studio-NEW_VERSION.tar.gz
Распаковать архив
Для этого необходимо создать новый каталог в папке, в которую был скачен архив на предыдущем шаге (в примере папка /tmp) и распаковать в него скачанный архив:
# mkdir datamart_studio_upgrade
# tar zxvf datamart-studio-NEW_VERSION.tar.gz -C datamart_studio_upgrade
Запустить процедуру обновления
Для запуска процедуры обновления, необходимо зайти в каталог, в котором было распаковано обновления ( в примере каталог /tmp/datamart_studio_upgrade/ ) и запустить процесс обновления (c sudo), указав в команде каталог, в котором установлена текущая версия Программы (/home/datamart/):
# cd /tmp/datamart_studio_upgrade/
# sudo ./datamart-studio upgrade /home/datamart
Примечание
Процесс обновления достаточно длительный и в зависимости от размера программы и мощности сервера может занимать 10 минут или более.
В случае успешного обновления, процесс завершается сообщением:
Datamart Studio updated to version <NEW_VERSION>
Программа Datamart Studio будет запущена автоматически. В шапке веб-интерфейса программы должен быть отображён номер новой версии:
Рисунок 6.4 Версия Datamart Platform Studio после обновления
Обновить бандлы приложений из хранилища репозиториев
После проведения обновления и запуска программы необходимо обновить бандлы и приложения из хранилищ(а) репозиториев.
Вариант 1: Обновить из консоли
Обновить все хранилища репозиториев можно командой:
docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails runner "Rephub.all.each { |r| r.grab_repositories }"
Обновить отдельное хранилище репозиториев по ID:
docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails runner "Rephub.find(:id).grab_repositories"
Вариант 2: Обновить из веб-интерфейса |prod|
Обновить данные хранилищ в веб-интерфейсе Datamart Platform Studio можно в разделе «Репозитории». В указанном разделе необходимо нажать на кнопку «Обновить все» ( см. Рисунок 6.5):
Рисунок 6.5 Обновление данных хранилищ в веб-интерфейсе Datamart Platform Studio
Примечание
Если у вас подключено несколько хранилищ репозиториев (реп-хабов), можно обновить бандлы из репозиториев для каждого из подключенных хранилищ.
6.4. Обновление c консоли сервера управления для Datamart Platform Studio установленной в среде в Kubernetes (K8s)
Для проведения процедуры обновления Datamart Platform Studio работающей в среде K8s требуется на управляющем сервере (ВМ) последовательно произвести следующие действия:
Удалить данные старой версии (за исключением бэкап-файлов):
rm -rf /opt/datamart-studio/datamart-studio{,-k8s}
Распаковать новую версию (вместо datamart-studio-NEW.tgz подставьте имя нового архива):
tar zxf datamart-studio-NEW.tgz -C /opt/
Удалить старую версию из K8s (все POD и все хранилища persistentVolumeClaims):
./datamart-studio destroy-k8s
kubectl -n dms get persistentvolumeclaims
Установить новую версию:
./datamart-studio deploy-k8s
Примечание
В процессе обновления данные Datamart Platform Studio будут сохранены, обновится только контейнер Datamart Platform Studio, который будет функционировать с кодом новой версии.
Обновить бандлы из репозитория
После проведения обновления и запуска программы необходимо обновить бандлы и приложения из репозитория. Для этого в разделе «Репозитории» необходимо нажать на кнопку «Обновить все» (см. Рисунок 6.5):
6.5. Особенности обновлений
6.5.1. Концепция обновления для группы Cтудий
При обслуживании группы отдельно развернутых версий Datamart Platform Studio для удобства единовременного обновления и соблюдения единообразного содержания хранилищ репозиториев, версий бандлов и версий доступного для разворачивания и реконфигурирования Витрин данных ПО, может применяться схема со служебной мастер-Студией тех. поддержки и дочерними Студиями (клиентскими версиями).
В этом случае, обновление происходит в 2 этапа:
Сначала, обычным образом, обновляется мастер-Студия.
После обновления мастер-Студии, для каждой дочерней запускается скрипт обновления из мастера.
При этом, в файле конфигураций дочерних студий, настройки хранилища Nexus и Gitea настраиваются таким образом, чтобы они смотрели не на собственные хранилища, а на централизованный Nexus и Gitea в мастер-Студии (см. Раздел 12.1 Настройка параметров в файле конфигурации настройка параметров DOCKER_REGISTRY, GLOBAL_VALUES, GITEA_HOST).
6.5.2. Обнаружение ошибок миграции
Если после обновления в заголовке Datamart Platform Studio выводится предупреждающее сообщение об ошибках миграции, то это значит, что какая-то часть скриптов миграции при обновлении версии выполнена некорректно. Необходимо проверить статус прохождения процессов миграции данных командой rails data:migrate:status и схемы данных командой rails db:migrate:status:
# docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails data:migrate:status
# docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails db:migrate:status
В случае обнаружения ошибочного статуса (down) в одной из миграций, попробовать повторить процесс миграции командой rails db:migrate для схемы данных:
# docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails db:migrate
и миграции данных командой rails data:migrate :
# docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails data:migrate
запустить обе миграции сразу можно командой rails db:migrate:with_data :
# docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails db:migrate:with_data
В случае повторения ошибок, прислать данные ошибок в службу технической поддержки Datamart Platform Studio для выяснения причин и оперативного устранения проблемы.
6.5.3. Особенности обновления на версию 2.0.1 с более ранних
В версиях до 2.0.1 происходила частично ошибочная интерпретация булевых настроек в статусе false. После процедуры обновления значения настроек автоматически не меняются. Если вы обнаружили, что у приложений некорректно интерпретированы настройки (в файлах бандлов указаны булевые значения false), а в Студии вместо false стоит пустая строка, то вы можете запустить в консоли скрипт автоматической корректировки:
# docker-compose -f docker-compose.datamart.yaml exec app bundle exec rake after_release:fix_false_vars
Все некорректно интерпретированные значения будут исправлены автоматически.
6.5.4. Особенности обновления с версии 1.4.x
После обновления до 1.9.4 на сервере с Datamart Platform Studio требуется выполнить следующие команды в консоли для корректного завершения процесса связывания интерфейсов приложений:
Необходимо перейти в папку, где установлена Datamart Platform Studio:
# cd /home/datamart
Последовательно выполнить набор из 7 команд:
# docker-compose -f docker-compose.datamart.yaml exec app bundle exec rake after_release:update_from_1_4
# for name in {pgsql-cluster-lb,pgsql-cluster-db,pgsql-cluster-dcs}; do NAME_UNDER=$(echo ${name} | tr "-" "_"); grep -rl ${name} dms-clusters/FMBA301/*/*/roles/*/ | xargs -I {} sed -i "s/${name}/${NAME_UNDER}/g" {}; done
# grep -lr "failed_when: ansible" dms-installations/*/playbooks/roles/*/tasks/check.yaml | xargs -I {} sed -i '/failed_when:\ ansible/d' {}
# grep -lr "failed_when: ansible" dms-clusters/*/*/*/roles/*/tasks/check.yaml | xargs -I {} sed -i '/failed_when:\ ansible/d' {}
# grep -rl "postgresql" dms-installations/dtm_query_execution_core_*/playbooks/roles/dtm_query_execution_core/vars/ | xargs -I {} sed -i "s/postgresql/postgresql_write/g" {}
# grep -rl "'dtm_service_port'" dms-installations/dtm_query_execution_core_*/playbooks/roles/dtm_query_execution_core/vars/ | xargs -I {} sed -i "s/'dtm_service_port'/'^dtm$'/g" {}
# grep -rl "'dtm-status-monitor'" dms-installations/dtm_query_execution_core_*/playbooks/roles/dtm_query_execution_core/vars/ | xargs -I {} sed -i "s/'dtm-status-monitor'/'dtm_status_monitor'/g" {}
7. Восстановление после сбоев
7.1. Восстановление Datamart Platform Studio, установленной на сервере (ВМ)
Примечание
Все действия в примере ниже проводятся в директории /home/datamart-studio
Проверить, что все контейнеры Datamart Platform Studio запущены и имеют статус
running(см. Рисунок 7.1):
# docker-compose -f docker-compose.datamart.yaml ps
Рисунок 7.1 Контейнеры Datamart Platform Studio
Проверить логи на наличие ошибок у контейнеров не в статусе running
# docker-compose -f docker-compose.datamart.yaml logs <имя сервиса>
Устранить проблемы в соответствии с ошибками из предыдущего пункта
Перезапустить Datamart Platform Studio
./datamart-studio stop
./datamart-studio start
7.2. Восстановление Datamart Platform Studio в Kubernetes (K8s)
Примечание
Для версии Datamart Platform Studio Kubernetes все действия производятся с kubectl, настроенным для подключения к нужному контексту и NameSpace (по умолчанию dms). В примере ниже, действуем в директории с управляющим скриптом datamart-studio.
Проверить, что запущены все сервисы студии:
deployments - все, кроме dms-backup должны быть READY 1/1 pods - все должны быть в статусе RUNNING, в идеале 0 рестартов у всех
# kubectl -n dms get deployments.apps
# kubectl -n dms get pods
Рисунок 7.2 Имена сервисов Datamart Platform Studio в K8s
Рисунок 7.3 Контейнеры POD Datamart Platform Studio в K8s
Проверить логи на наличие ошибок у компонентов (deployments) студии не в статусе running
# kubectl logs deployments/<имя сервиса>
Устранить проблемы в соответствии с ошибками из предыдущего пункта
Перезапустить Datamart Platform Studio
# ./datamart-studio stop-k8s
# ./datamart-studio start-k8s
8. Управление доступом
8.1. Назначение пользователя и пароля по умолчанию Datamart Platform Studio
Имя и пароль пользователя Datamart Platform Studio указывается в переменных
окружения (см. файл .env). Чтобы изменить имя пользователя и пароль,
измените соответствующие параметры в файле:
STUDIO_SEED_USER_USERNAME="datamart"
STUDIO_SEED_USER_PASSWORD="datamart"
AUTH=DATABASE
Назначенный таким образом единственный пользователь будет иметь роль Администратор студии (superadmin).
8.2. Настройка аутентификации по протоколу LDAP
Для настройки аутентификации по протоколу LDAP (Active Directory)
необходимо в переменных окружения (см. файл .env) изменить способ аутентификации
на AUTH=AD и внести параметры сервера Active Directory; пользователя, который
будет осуществлять проверку; группы AD, для которой будет разрешен доступ к Datamart Platform Studio.
Пример настроек переменных окружения для аутентификации по LDAP:
AD_HOST=<ip адрес или имя хоста сервера AD>
AD_PORT=389
AD_ATTRIBUTE=sAMAccountName
AD_BASE=OU=users_group,DC=datamart,DC=ru
AD_ADMIN_USER=CN=datamart_user,CN=Users,DC=datamart,DC=ru
AD_ADMIN_PASS=password
AD_SSL=false
AUTH=AD
, где:
users_group - группа пользователей домена, которой мы хотим разрешить доступ к Datamart Platform Studio;
datamart - учетная запись домена AD;
datamart_user - техническая учетная запись для аутентификации в домене;
password - пароль технической учетной записи datamart_user;
sAMAccountName — имя входа, которое поддерживает предыдущую версию Windows.
Для справки см. документацию на Атрибуты именования пользователей в Active Directory
8.3. Настройка аутентификации с использованием Keycloak (Platform V IAM)
Для настройки аутентификации через с использованием Keycloak (сервис Platform V IAM) необходимо в переменных окружения (см. файл .env) изменить способ авторизации на AUTH=IAM и указать параметры подключения к сервису Keycloak.
Пример:
AUTH=IAM
KEYCLOAK_CLIENT_NAME=datamart-studio
KEYCLOAK_CLIENT_SITE=https://kc.your-server.ru
KEYCLOAK_CLIENT_REALM=dtms-realm
KEYCLOAK_CLIENT_BASE_URL=/auth
Настройки Keycloak должны быть указаны в соответствии с рекомендациями по настройке сервиса для Platform V IAM.
Примечание
При использовании данного метода аутентификации (через Keycloak) в Datamart Platform Studio ограничено время жизни сессии аутентификации. Менять пользователя системы (делать logout и login) можно не чаще раза в минуту.
8.3.1. Настройка пользователей Keycloak
Добавление пользователей в Keycloak производится в соответствии с рекомендациями по настройке сервиса в разделе Ведение внутренних привилегированных пользователей.
8.3.2. Настройка Keycloak для передачи данных об организации
Если из Keycloak планируется передавать не только роль пользователя, но и данные об организации, на которую эта роль назначена, то необходимо смапировать и настроить передачу атрибута organization_ogrn в токене:
Рисунок 8.1 Мапирование атрибута organization_ogrn
Рисунок 8.2 Настройка передачи атрибута organization_ogrn в токене
Примечание
Для ролей Администратор студии (superadmin) и Резервное копирование (backup) передача данных об организации не требуется.
8.4. Управление ресурсами организаций
Пользователь с ролью Администратор студии (superadmin) из меню пользователя имеет возможность посмотреть список добавленных в Datamart Platform Studio организаций, добавить новые и отслеживать ресурсы, используемые организациями в Datamart Platform Studio.
Рисунок 8.3 Просмотр списка организаций и добавление новых
Пользователь с ролью Администратор (admin) из меню пользователя имеет возможность посмотреть список только назначенных ему организаций, редактировать и мониторить их ресурсы, соответственно.
8.4.1. Список пользователей организаций
В карточке организации во вкладке «Пользователи» отображается список пользователей, получивших доступ к ресурсам данной организации в Datamart Platform Studio с их именами, ролями, данными о количестве авторизаций и времени последнего входа (см. Рисунок 8.4).
Рисунок 8.4 Просмотр списка пользователей организации
8.4.2. Настройка ОГРН для организаций в Datamart Platform Studio
В карточке организации в Datamart Platform Studio есть возможность указать ОГРН. По этому полю будет осуществляться привязка доступа пользователей (согласно ролям пользователей) к информации внутри Datamart Platform Studio о ресурсах данной организации:
Витринам;
Инсталляциям приложений;
Датацентрам (ЦОД);
Серверам;
Базам данных;
Гипервизорам;
Рисунок 8.5 Настройка ОГРН для организаций
Примечание
Добавление новых организаций и доступ к ресурсам всех организаций в Datamart Platform Studio доступно только пользователю с ролью Администратор студии (superadmin).
8.4.3. Мониторинг ресурсов, управление лицензиями для организаций
В карточке каждой организации есть раздел «Мониторинг ресурсов», в котором отображается отчет об утилизации ресурсов, предоставленных согласно полученной лицензии на Datamart Platform Studio для данной организации (см. Рисунок 8.6).
В рамках отчета предоставляется отдельно данные по каждой Витрине данных, утилизация ресурсов на Типовое ПО Витрин считается отдельно и в лимит лицензии не входит.
Рисунок 8.6 Отчет об утилизации ресурсов
8.5. Описание ролей и матрица доступа к информационным ресурсам Datamart Platform Studio
8.5.1. Описание ролевой модели
В Datamart Platform Studio используется ролевая модель доступа. При авторизации по типу «Database» и «LDAP» пользователю по умолчанию назначается роль «Администратор студии» (superadmin).
Примечание
Для использования ролевой модели требуется настройка подключения к внешнему сервису Keycloak, в котором пользователям могут быть назначены роли и переданы в Datamart Platform Studio при авторизации пользователя в содержимом JWT-токена.
Роли подразделяются на:
Основные - пользователю с ролью данного типа предоставляевляется доступ интерфейсу Программы к разделам, относящимся к организации, назначенной пользователю;
Служебные - вспомогательные роли добавляют дополнительные права пользователю с основной ролью. Если назначить пользователю только служебную роль, он сможет авторизоваться, но у него не будет доступа к списку компонентов Datamart Platform Studio;
Технические - роли, предназначенные для взаимодействия с API.
8.5.1.1. Основные роли:
Администратор студии (superadmin)
Пользователь с ролью «Администратор студии» имеет доступ к настройкам всех объектов Datamart Platform Studio, вне зависимости от того, к какой организации принадлежит объект. Администратор студии может добавлять записи о новых организациях.
Администратор (admin)
Пользователь с ролью «Администратор» назначается на уровне организации и полностью управляет всеми объектами на уровне организации, может редактировать данные о своей организации (одной или более).
Девопс (devops)
Пользователь с ролью «Девопс» имеет доступ к следующему функционалу Datamart Platform Studio:
запуск тасков для объектов услуг и Datamart Platform Studio;
обновление бандлов и приложений;
редактирование связей интерфейсов инсталляций;
установка готовой услуги на сервера;
управление настройками доступа к виртуальным ресурсам (IP-адреса, имена хостов, параметры сетевого доступа);
экспорт профиля услуги.
Пользователю с ролью «Девопс» недоступно конфигурирование услуги. Девопс может установить, деинсталлировать, применить настройки конфигураций, перезапустить уже сконфигурированную услугу.
Аналитик (analytic)
Пользователь с ролью «Аналитик» имеет доступ к следующему функционалу Datamart Platform Studio:
создание услуг из интерфейса Datamart Platform Studio;
добавление и настройка инсталляций услуги;
управление настройками услуги;
управление настройками интерфейсов инсталляций услуги;
создание услуги из профиля;
управление настройками Баз данных;
экспорт профиля услуги.
Пользователю с ролью «Аналитик» не разрешено запускать таски. Аналитик не может установить услугу, только подготовить, настроить, определить связи инсталляций.
Просмотр (viewer)
Пользователю с ролью «Просмотр» доступен исключительно просмотр информации об услугах, их настройках и о других компонентах Datamart Platform Studio (бандлах, приложениях, БД).
8.5.1.2. Служебные роли:
Загрузка файлов настроек (uploader)
Пользователю, имеющему служебную роль «Загрузка файлов инсталляций» uploader, доступно добавление и редактирование приложенных файлов-настроек инсталляций.
Доступ к web-интерфейсам (web_interface)
Пользователю, имеющему служебную роль «Доступ к web-интерфейсам» web_interface, разрешен доступ к web-интерфейсам инсталляций приложений при помощи средства наложенной защиты Datamart Platform Studio.
Администратор резервного копирования (backup)
Пользователю, имеющему служебную роль «Администратор резервного копирования» backup, разрешено создание резервной копии и восстановление из резервной копии Datamart Platform Studio, включая все настройки витрин, а также резервное копирование и восстановление данных Витрин. Роль «Администратор резервного копирования», назначенная для пользователя с привязкой к организации позволяет выполнять резервное копирование услуг в рамках организации. Роль без привязки к организации позволяет выполнять резервное копирование и восстановление услуг всех организаций и Datamart Platform Studio.
Техподдержка (support)
Служебная роль «Техподдержка» support выдается учетным записям для доступа к специфическим функциям техподдержки (например, редактор данных кластера Zookeeper).
Администратор гипервизора (hv_admin)
Пользователю, имеющему служебную роль «Администратор гипервизора» hv_admin, разрешено добавлять новые подключения к платформам виртуализации (гипервизорам), выполнять подключение Датацентров Витрин данных к инфраструктуре гипервизора и создавать в гипервизоре требуемые для Витрин данных ресурсы.
Управление организацией (org_manager)
Служебная роль «Управление организацией» org_manager предоставляет права на редактирование данных об организациях и на добавление новых организаций.
Редактор системных сценариев (scenario_system_editor)
Служебная роль «Редактор системных сценариев» scenario_system_editor предоставляет право на создание, редактирование шаблонов сценариев в каталоге сценариев.
Редактор сценариев (scenario_editor)
Служебная роль «Редактор сценариев» scenario_editor предоставляет право на создание, редактирование пользовательских сценариев и добавление пользовательских сценариев в библиотеку сценариев;
8.5.1.3. Технические роли:
Доступ к Proxy API (proxy_api)
Техническая роль «Доступ к Proxy API» proxy_api предоставляет право на доступ к инсталляциям Услуг, предоставляющим API интерфейс, через Proxy API в Datamart Platform Studio.
Примечание
Роли superadmin, org_manager, backup могут действовать вне зависимости от назначенной организации. Остальные роли требуют обязательной привязки к организации (одной или нескольким).
Если пользователю предоставлена роль в рамках организации, то она будет действовать только для этой организации. Компоненты других организаций данный пользователь не увидит.
Одному пользователю может быть назначена одна или несколько ролей и предоставлен доступ к одной или более организациям. Все назначенные пользователю роли действуют для всех предоставленных пользователю организаций.
Компоненты всех организаций без ограничения видит только Администратор Студии (superadmin).
8.5.2. Права ролей в Datamart Platform Studio
Действия |
superadmin |
admin |
devops |
org_manager |
|---|---|---|---|---|
Обновление Datamart Studio |
Y |
N |
N |
N |
Обновление (бандлов, приложений) |
Y |
Y |
Y |
N |
Выполнение процедур резервного копирования Datamart Studio |
Y |
N |
N |
N |
Выполнение процедур восстановления Datamart Studio |
Y |
N |
N |
N |
Просмотр информации о резервных копиях Datamart Studio |
Y |
Y |
N |
N |
Добавление организаций |
Y |
N |
N |
Y |
Редактирование данных организации |
Y |
Y |
N |
Y |
Примечание
Права ролей admin, analytic, uploader, viewer, proxy_api распространяются только в рамках компонентов, привязанных к учетной записи организации, назначенной пользователю.
Действия |
superadmin |
admin |
devops |
analytic |
uploader |
viewer |
backup |
support |
|---|---|---|---|---|---|---|---|---|
Редактирование настроек доступа к виртуальным ресурсам (IP-адреса, имена хостов, параметры сетевого доступа) |
Y |
Y |
Y |
Y |
N |
N |
N |
N |
Управление персональными SSH-ключами доступа к серверам |
Y |
N |
N |
N |
N |
N |
N |
N |
Редактирование интерфейсов инсталляций |
Y |
Y |
Y |
Y |
N |
N |
N |
N |
Экспорт профиля Услуги |
Y |
Y |
Y |
Y |
N |
N |
N |
N |
Импорт профиля Услуги |
Y |
Y |
N |
Y |
N |
N |
N |
N |
Просмотр настроек Услуги |
Y |
Y |
Y |
Y |
Y |
Y |
N |
N |
Редактирование настроек Услуги |
Y |
Y |
N |
Y |
N |
N |
N |
N |
Просмотр настроек инсталляций |
Y |
Y |
Y |
Y |
Y |
Y |
N |
N |
Редактирование настроек инсталляций |
Y |
Y |
N |
Y |
N |
N |
N |
N |
Редактирование приложенных файлов пользовательских настроек инсталляций |
Y |
Y |
N |
N |
Y |
N |
N |
N |
Просмотр защищённых настроек инсталляций |
Y |
N |
N |
N |
N |
N |
N |
N |
Просмотр конфигурационных YAML файлов инсталляций |
Y |
N |
N |
N |
N |
N |
N |
N |
Выполнение действий управления для инсталляций |
Y |
Y |
Y |
N |
N |
N |
N |
N |
Редактирование настроек компонента «Базы данных» |
Y |
Y |
N |
Y |
N |
N |
N |
N |
Выполнение процедур бэкапа услуги типа Витрина данных |
Y |
Y |
N |
N |
N |
N |
Y |
N |
Выполнение процедур восстановления услуги типа Витрина данных из резервной копии |
Y |
Y |
N |
N |
N |
N |
Y |
N |
Просмотр информации о резервных копиях Витрин данных |
Y |
Y |
Y |
Y |
N |
Y |
Y |
N |
Просмотр информации в кластере Zookeeper |
Y |
Y |
Y |
Y |
Y |
Y |
N |
Y |
Редактирование информации в кластере Zookeeper |
Y |
N |
N |
N |
N |
N |
N |
Y |
Действия |
proxy_api |
|---|---|
Доступ к Proxy API Витрины |
Y |
Категории прав, предоставляемые для ролей на компоненты Datamart Platform Studio описаны в разделе «Дополнительная информация».
8.6. Назначение ролей пользователям
8.6.1. Назначение роли и организации пользователю в Keyсloak (IAM)
Для того, чтобы назначить роль пользователя в рамках организации, требуется в настройках Keyсloak выполнить следующие действия:
Добавить соответствующую роль в карточке пользователя;
Для организации создать группу;
Группе назначить атрибут organization_ogrn. Значение должно совпадать с ОГРН организации в Datamart Platform Studio (см. Рисунок 8.7)
Добавляем в эту группу пользователей, которые должны иметь доступ к данной организации;
Рисунок 8.7 Предоставление доступа к выделенной организации
8.6.2. Назначение роли и организации пользователю из консоли (для LDAP)
В случае отсутствия внешнего инструмента управления назначением ролей (сейчас для LDAP не предусмотрен инструмент управления ролевой моделью в Datamart Platform Studio), системный администратор может назначить или убрать роли пользователя командами из консоли сервера управления Datamart Platform Studio.
Примечание
Назначение ролей и доступ к организациям из консоли можно выдавать только тем пользователям (username), которые хотя бы раз прошли авторизацию в Datamart Platform Studio
Команда назначения роли <role> пользователю <username>:
docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails runner "User.find_by_username('<username>').add_role(:<role>)"
Команда убрать роль <role> пользователя <username>:
docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails runner "User.find_by_username('<username>').remove_role(:<role>)"
Команда добавления организации по ОГРН <ogrn>, указанному в параметрах организации в Datamart Platform Studio пользователю <username>:
docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails runner "User.find_by_username('<username>').organizations << Organization.find_by(ogrn: '<ogrn>')"
Если требуется назначить только одну организацию:
docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails runner "User.find_by_username('<username>').organizations = Organization.find_by(ogrn: '<ogrn>')"
Если требуется сбросить все назначенные организации:
docker-compose -f docker-compose.datamart.yaml exec app bundle exec rails runner "User.find_by_username('<username>').organizations = []"
9. Журналирование, аудит, мониторинг
9.1. Логирование в Datamart Platform Studio
Логи Datamart Platform Studio сохраняются в папку ./log в следующих файлах:
.log/production.log - логи работы Datamart Platform Studio в построчном формате;
.log/production_gostech.log - логи работы Datamart Platform Studio в формате, готовом для считывания FluentBit и logstash;
.log/watchtower.log - логи обновления Datamart Platform Studio;
.log/production_resque.log - логи очередей задач Resque.
9.1.1. Настройка формата журнала логов Datamart Platform Studio
Настройка типа лог-файл данных мониторинга производится путем указания в переменных окружения (файл .env) значения параметра LOG_FORMAT
По умолчанию, используется построчный формат логов:
LOG_FORMAT=default
Логи пишутся построчно в файл: .log/production.log.
Для сбора данных в формате построчный JSON (требование сервиса Platform V Monitor платформы ГосТех), нужно указать параметр:
LOG_FORMAT=gostech
Логи будут сохранятся в формате построчный JSON в файл: .log/production_gostech.log, готовый для считывания FluentBit и logstash.
Примечание
При указании в переменной окружения LOG_FORMAT значений отличных от вышеперечисленных, Datamart Platform Studio не запустится и выдаст ошибку.
9.2. Настройка сбора логов инсталляций приложений
По умолчанию вывод логов инсталляций производится в консоль Docker (Параметр инсталляции LOGBACK_APPENDER_REF установлен в значения CONSOLE).
При необходимости, пользователь Datamart Platform Studio может настроить сбор логов инсталляций в указанное место.
Для этого в переменной инсталляции LOGBACK_APPENDER_REF необходимо значения CONSOLE изменить на FILE и в переменной LOGS_DIRECTORY указать путь на ВМ с Datamart Platform Studio, куда будут выводиться логи, например:
/opt/logs
а сами логи запишутся по такому шаблону:
/opt/logs/<datamart-id>/<app_name>-<app_id>.log
При помощи настройки глобальных переменных, пользователь может задать директорию, для записи логов глобально для всей Студии, для определенного ДЦ или Услуги.
Формат пути сохранения логов указывается в переменной LOGBACK_FILE (Путь до лог-файла). Значение по умолчанию:
{{ logs_directory.value }}/{{ DTMS_DATAMART_ID | default('datamart-000') }}/{{ container_name }}.log
Предупреждение
Настройка LOGBACK_FILE является системной и ее изменение разрешено только после консультации со службой техподдержки Datamart Platform Studio.
9.3. Метрики мониторинга
В процессе работы Datamart Platform Studio происходит сбор следующих бизнес-метрик мониторинга:
метрики использования системных ресурсов (CPU, RAM);
время исполнения входящих запросов;
количество успешных/неуспешных выполнений входящих запросов;
время исполнения исходящих запросов или обращений к СПО (учитываются обращения к Resque);
количество успешных/неуспешных выполнений исходящих запросов.
Метрики собираются по адресу http://<адрес сервера |prod|>:8089/metrics/ в формате Prometheus, готовом для считывания сервисом Platform V Metrix.
Настройка интервала сбора метрик мониторинга задается в параметре PROMETHEUS_DATA_UPDATE_INTERVAL в конфигурационном файле. По умолчанию 2 сек.
9.4. События аудита
В процессе работы Datamart Platform Studio происходит регистрация следующих типов событий аудита для всех компонентов Datamart Platform Studio:
Авторизация (login, logout)
Создание компонента Datamart Platform Studio (create);
Удаление компонента Datamart Platform Studio (destroy);
Изменение настроек компонента Datamart Platform Studio (update);
Запуск задач для компонента Datamart Platform Studio (выполнение Ansible playbook) (task);
Резервное копирование/восстановление Datamart Platform Studio (studio_backuped, studio_restored);
Резервное копирование/восстановление услуг типа Витрина данных (datamart_backuped, datamart_restored);
Прочие события, приводящие к изменениям в БД Datamart Platform Studio.
Событие аудита содержит следующие данные:
Атрибут |
Описание |
|---|---|
request |
Уникальный идентификатор события аудита |
tags |
Идентификатор цепочки события |
createdAt |
Время создания события |
name |
Тип события |
module |
Наименование источника события» |
session |
Идентификатор сессии пользователя |
userLogin |
Логин пользователя |
userName |
Имя пользователя |
userNode |
ip адрес пользователя |
metamodelVersion |
Версия метамодели |
params |
Массив параметров события, таких как тип изменяемого объекта, идентификатор объекта в БД и т. д. |
9.4.1. Список событий аудита
В процессе сбора событий аудита происходит сбор стандартных действий:
Create (C) - создание;
Update (U) - обновление;
Delete (D) - удаление.
Помимо этого происходит сбор специфических действий для объектов Datamart Platform Studio.
Объект |
Стандартные |
Специфические действия |
|---|---|---|
Услуга |
(C),(U),(D) |
Создание тиражируемой услуги (профиля) |
Профиль |
(C),(D) |
Использование профиля для создания услуги; Экспорт; |
Сервер |
(C),(U),(D) |
Загрузка SSH Ключа пользователя; Выполнене действий API гипервизора |
Датацентр |
(C),(U),(D) |
Выполнене действий API гипервизора |
Аккаунт подключения к гипервизору |
(C),(U),(D) |
Выполнене действий API гипервизора |
Маршрут SSH |
(C),(U),(D) |
|
Сеть |
(C),(U),(D) |
|
Инсталляции |
(C),(U),(D) |
|
Интерфейсы |
(C),(U),(D) |
|
Файлы инсталляции |
(C),(U),(D) |
|
Настройки инсталляций |
(C),(U),(D) |
|
Бандл |
(C),(U),(D) |
|
Приложение |
(C),(U),(D) |
|
База данных |
(C),(U),(D) |
|
Репозиторий |
(C),(U),(D) |
|
Хранилище репозиториев |
(C),(U),(D) |
|
SSH Ключи пользователя |
(C),(U),(D) |
9.4.2. Настройка сбора и отправки событий аудита
События аудита Datamart Platform Studio собираются и агрегируются для отправки в систему аудита в Resque очереди audit (см. Рисунок 9.1):
Рисунок 9.1 Очередь событий аудита в Resque
Настройка отправки событий происходит в файле переменных окружения .env, где требуется разрешить отправку и указать адрес, по которому Resque будет отправлять события:
SEND_AUDIT_EVENTS=true
AUDIT_SERVICE_HOST=http://audit.datamart.ru
Для выполнения mTLS подключения, требуется добавить в .env Студии переменную AUDIT_SERVICE_MTLS. Если переменная не указана, считаем = NO:
Если для отправки событий аудита требуется сертификат, то расположение сертификата в контейнере Datamart Platform Studio должно быть указано в файле переменных окружения .env в параметре AUDIT_SERVICE_CERT:
AUDIT_SERVICE_MTLS = yes/no
AUDIT_SERVICE_CERT=${STORAGE_VOL}/mtls.p12
Внутри контейнера сертификат необходимо поместить в STORAGE_VOL, по умолчанию это /opt :
Рисунок 9.2 Расположение сертификата в контейнере
10. Настройка количества обработчиков заданий
В Datamart Platform Studio есть возможность настроить количество обработчиков заданий Resque workers (воркеров), которые будут параллельно запускать выполнение задач инсталляций, обновления приложений, других скриптов Ansible, требуемых для обслуживания Витрин данных.
Если при помощи Datamart Platform Studio планируется параллельно запускать задачи обновления и установки приложений в нескольких Услугах, то имеет смысл установить количество воркеров, как минимум в 1/3 от количества обслуживаемых Услуг (в т.ч. Витрин данных). Если есть необходимость, чтобы процессы обновления шли строго параллельно, то количество воркеров необходимо настроить равным количеству Услуг.
Настройка производится путем указания в переменной окружения:
RESQUE_QUEUE_POOL_SIZE=1
По умолчанию, или если значение не указано, в Datamart Platform Studio будет запущен только 1 обработчик. После установки Datamart Platform Studio изменить количество обработчиков можно при помощи команды (в зависимости от платформы):
для версии на ВМ:
./datamart-studio resque-pool <число>
для версии, развернутой в среде Kubernetes (K8s):
./datamart-studio resque-pool-k8s <число>
Если не задать явное количество требуемых воркеров в параметре вызова команды, то оно будет сброшено в 1.
В интерфейсе Datamart Platform Studio в меню «Очереди задач» выводится информация об общем количестве очередей и обработчиков заданий, куда выводятся и воркеры услуг и системные воркеры. Команда resque-pool и настройка RESQUE_QUEUE_POOL_SIZE влияет только на количество воркеров услуг. Количество системных воркеров Datamart Platform Studio определяет самостоятельно, настройки на это не влияют.
Примечание
Важно, чтобы параллельно работающие Ansible playbook не выполняли свои действия одновременно на одном и том же сервере. Если на одном и том же сервере установлены несколько приложений разных услуг, то в этом случае не рекомендуется запускать их одновременную параллельную установку или обновление.
11. Структура служебных директорий
При установке Datamart Platform Studio в каталоге установки программы будут по умолчанию созданы следующие папки (см. Рисунок 11.1):
containets - контейнеры для оффлайн установки
dms-dirs - директория со служебными папками dms-* внутри
fluent-bit - конфиги для контейнера fluent-bit для отправки логов Datamart Platform Studio в opensearch (используется в ГосТех)
log - логи студии
volumes - вольюмы redis (nexus, gitea и БД если они нужны)
Рисунок 11.1 Структура директорий Datamart Platform Studio
В служебной директории dms-dirs расположены папки:
dms-bundles — локальные репозитории бандлов
dms-apps — дистрибутивы и конфигурации приложений
dms-installations — папка с установками компонентов
dms-clusters — папка с установками для кластеров
dms-data_centers — папка с SSH ключами для ЦОД (применяется для всех серверов ЦОД)
dms-servers — папка с серверами
dms-networks — папка с настройками сетей для серверов и датацентров
studio — запускаемое приложение