Важно: Данный раздел актуален для Платформы данных On-Premise.
Данный документ содержит описание действий и условий необходимых для установки программного обеспечения RT.ClusterManager.
В настоящем документе использованы и определены следующие термины и сокращения:
Термин/Сокращение |
Определение |
---|---|
Ansible (software) | Система управления конфигурациями. Используется в работе RT.ClusterManager для запуска ansible-ролей |
ansible (user) | (как пользователь) – фиксировано заданный (в данном документе) пользователь для корректной работы ansible-ролей из контейнера rtcm на хосты. При необходимости имя данного пользователя можно заменить везде на другое, но новый пользователь должен уметь подключаться к хостам посредством ключевой пары без пароля (в том числе при выполнении sudo). |
CM-server | Главный (управляющий) виртуальный или физический сервер, на котором будет развёрнута сама Система, посредством запуска docker-контейнеров и доступен веб-интерфейс. |
Docker | Платформа, которая упрощает процесс сборки, запуска, управления и распространения приложений с помощью механизма контейнеризации. |
On-Premise | Модель локального развертывания программного обеспечения, которая предполагает использование инфраструктуры, принадлежащей непосредственно компании, — серверов, хранилищ данных и другого оборудования. В этом случае ПО находится под контролем организации, в отличие от использования облачной платформы, где обслуживание и управление ресурсами происходит на стороне провайдера. |
Интрасеть | Внутренняя сеть организации или предприятия, обычно построечная на базе семейства протоколов TCP/IP и предоставляющая возможность абонентам обмениваться данными с одним или несколькими веб-серверами, на которых сосредоточены основные информационные ресурсы. В отличие от Internet такая сеть, как правило, обеспечивает повышенную надежность и имеет ограниченный доступ. |
ОС | Операционная система. |
Рабочая_директория /opt/rtcm |
Фиксировано заданная рабочая директория, откуда будут производиться все необходимые действия. Для примера /opt/rtcm, при необходимости можно изменить на другую (но использовать ее везде, в том числе и в конфигурационных файлах). Важно отметить, что конечная директория обязательно должна быть “rtcm” |
Резолвить | (от английского resolve, resolving) Применяется для обозначения процедуры получения IP-адреса по имени (прямой резолвинг) или имени по IP-адрес (обратный). |
Репозито́рий | Место, где хранятся и откуда поставляются установочные пакеты. Чаще всего в репозитории хранятся файлы, доступные для дальнейшего распространения по сети. |
Система | Система «RT.ClusterManager». |
СУБД | Система управления базами данных. |
Хост | от англ. Host – «владелец, принимающий гостей») – любое устройство, предоставляющее сервисы формата «клиент-сервер» в режиме сервера по каким-либо интерфейсам и уникально определённое на этих интерфейсах. В более широком смысле под хостом могут понимать любой компьютер, подключённый к локальной или глобальной сети. |
Вам понадобится пул виртуальных (можно и физических) машин в интрасети или хосты арендованные у хостинг-провайдера, находящиеся в одной подсети, имеющие статический MAC и IPv4 адреса (IPv6 hadoop не поддерживает), а именно:
Предполагается использование следующих дистрибутивов Linux:
Примечание: Для продукта RT.Streaming на данный момент поддерживаются только операционные системы: Centos 7, RHEL 7
Минимальные требования к оборудованию для установки RT.ClusterManager:
Требования к оборудованию для развертывания базовой конфигурации кластеров, создаваемых с помощью RT.ClusterManager представлены в п.4.4.2 документа «RT.ClusterManager.Общее описание».
Сетевые требования для установки RT.ClusterManager и корректной работы:
Важно: Для корректной работы кластеров, управляемых RT.ClusterManager, необходимо использование DNS-сервера, обеспечивающего прямой и обратный резолв всех хостов кластера, в том числе хоста, на котором установлен RT.ClusterManager.
Перед выполнением инсталляции необходимо выполнить данные проверки для соответствия хостов предъявляемым к ним требованиям.
1. Системные требования
Достаточное количество ОЗУ | free -m, top | Убедиться, что доступно не менее 8Gb |
Место на диске | lsblk, df -h | Убедиться, что имеется не менее 100Gb |
2. Сетевые требования
Проверка системного времени, даты, часового пояса | date, timedatectl | Время и часовой пояс в норме, а так же синхронизированы с AD, freeIPA (если используется Kerberos). Убедиться что включена синхронизация по протоколу NTP. |
FQDN Имя: <server-name.domain.com> | hostname -f | Имя показывает имя сервера и домен |
Короткое имя: <server-name> | hostname -s | Отображает только короткое имя - имя сервера |
Только доменное имя: <domain.com> | hostname -d | Отображает только доменное имя |
В hosts не прописано имя хоста, только localhost |
cat /etc/hosts | нет упоминания названия сервера в файле hosts: 127.0.0.1 server.exemple.domain.ru |
ipv6 отключен (актуально для Hadoop и Greenplum) | ip -6 a | В выводе команды нет упоминания inet6 |
Резолв короткого и FQDN имени | ping <server> | Пакеты пересылаются, сетевая связанность есть |
Обратный резолв имени | nslookup <server> | yum install bind-utils nslookup возвращает корректное имя нет строки ** server can't find <server_name>: NXDOMAIN как альтернатива можно использовать утилиту dig |
Проверка поискового домена и адреса DNS-сервера | cat /etc/resolv.conf | в выводе есть упоминание домена search <my_domain> |
iptables нет лишних правил | iptables -L | Все 3-и цепочки (INPUT, FORWARD, OUTPUT) имеют разрешительную политику по умолчанию (policy ACCEPT) |
nftables нет лишних правил | nft list ruleset | Команда ничего не выдаёт в консоль |
Проверка порта. Например ssh порта | nc -vz <server> 22 | yum install nc (если не установлен по умолчанию) Если порт открыт: Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds. Если порт закрыт: Ncat: Connection refused. |
Проверка работы порта на самом сервисе | ss -tulpn | grep 22 | Порт должен быть в состоянии LISTEN |
Безпарольный доступ по ssh | ssh <server> | Подключение проходит нормально, по командам (ip a) и (hostname) мы понимаем что подключились к нужному хосту |
Безпарольный доступ по sudo | sudo su | После ввода команды, пароль не запрашивается и команда whoami выдаёт: root |
3. Требования файловой системы
Дескрипторы больше 12 000 | ulimit -Sn, ulimit -Hn | Если в выводе команды 1024, то поднимаем лимиты с помощью команды: ulimit -n 12000 |
Примечание: Предполагается, что рабочая директория проекта - /opt/rtcm, а директория локального репозитория - /opt/localrepo
если планируется использование других директорий - учитывайте это при выполнении команд.
Установку RT.ClusterManager возможно произвести двумя способами:
Для доступа к архивам со всеми необходимыми компонентами RT.ClusterManager и других систем предлагаемых ПАО Ростелеком своим клиентам используется Личный Кабинет. Также отдельные компоненты можно скачать в репозиториях (см. описание Nexus).
В случае использования метода локального репозитория, перед установкой RT.ClusterManager необходимо выполнить запуск и настройку локального репозитория (см. п.2.2). Локальный репозиторий предоставляет доступ внутри интрасети организации к архиву с инсталляционными файлами для серверов кластера (Master и Slave nodes) и сервера, на который будет устанавливаться RT.ClusterManager (CM-server).
1. RT.ClusterMahager
Тип файла |
Название файла в архиве |
Действие |
---|---|---|
Архив с установочными пакетами для формирования локального rpm репозитория | /opt/localrepo/archives/rt.ca.repo_rpm.tar.gz | Установка репозитория (см. п. 2.2 настоящего документа). |
Архив с установочными пакетами для формирования локального deb репозитория | /opt/localrepo/archives/rt.ca.repo_deb.tar.gz | |
Директория с установочными пакетами сервиса prometheus для формирования локального репозитория | /opt/localrepo/archives/rt.prometheus.repo | |
Docker образ RT.ClusterManager | /opt/localrepo/archives/rtcm/images_docker/rtcm_версия.tar.gz | Загрузка doсker-образов из архивов (см. п. 3.2 шаг 2 настоящего документа). |
Docker образ Prometheus | /opt/localrepo/archives/rtcm/images_docker/prometheus_версия.tar.gz | |
Docker образ Blackbox | /opt/localrepo/archives/rtcm/images_docker/blackbox_версия.tar.gz | |
Docker образ Postgres | /opt/localrepo/archives/rtcm/images_docker/postgres_версия.tar.gz | |
Скрипт для автоматизации загрузки docker-образов load_images | /opt/localrepo/archives/rtcm/images_docker/load_images.sh | Подгрузка образов командой ./load_images.sh (см. п. 3.2 шаг 1 настоящего документа). |
Файл конфигурации сервиса Blackbox | /opt/localrepo/archives/blackbox/blackbox.yml | Редактирование файлов конфигурации |
Файл конфигурации сервиса RT.ClusterManager | /opt/localrepo/archives/rtcm_conf/rtcm.properties | Редактирование файлов конфигурации |
Файл конфигурации сервиса prometheus для оповещений | /opt/localrepo/archives/config/alert.rules.yml | Редактирование файлов конфигурации |
Файл конфигурации сервиса prometheus для сбора метрик | /opt/localrepo/archives/config/prometheus.yml | Редактирование файлов конфигурации |
Скрипт для автоматизации операций администрирования сервиса RT.ClusterManager | /opt/localrepo/archives/images/docker/topgun.sh | Запуск скрипта Параметры запуска описаны в п. 6 документа “API для работы с RT.ClusterManager”. |
docker-compose.yaml Файл описывающий параметры запускаемых контейнеров |
/opt/localrepo/archives/rtcm/docker-compose.yaml | Конфигурирование и запуск (см. п. 3.3 и п. 3.4 настоящего документа). |
Плагины: RT.System |
/opt/localrepo/archives/RT.System-версия.tar.gz |
Данные файлы в не распакованном виде подгружаются: 1. При создании кластера с помощью wizard (см. п. 6 шаг 4, Руководства администратора) 2. В UI RT.ClusterManager при загрузке плагинов вручную (см. п. 7.1 Руководства администратора). |
2. Плагин приложения на примере RT.DataLake
Тип файла |
Название файла в архиве |
Действие |
---|---|---|
Архив с установочными пакетами для формирования локального репозитория | rt.datalake.repo.tar.gz | Установка репозитория см. п. 2.2 настоящего документа |
Плагины: RT.DataLake |
RT.DataLake-версия.tar.gz |
Данные файлы в не распакованном виде подгружаются: 1. При создании кластера с помощью wizard (см. п. 6 шаг 4, Руководства администратора) 2. В UI RT.ClusterManager при загрузке плагинов вручную (см. п. 7.1 Руководства администратора). |
Примечание: В именах файлов, в место “версия” должен присутствовать код версии данного файла который обычно состоит из нескольких частей разделённых точками.
Примечание: Состав системных плагинов и плагинов приложений зависит от комплекта поставки программного обеспечения. Плагины понадобятся при создании провайдера и кластеров в веб-интерфейсе RT.ClusterManager, на этапе подготовке к установке RT.ClusterManager они не нужны.
Обратите внимание, что начиная с шага 6 команды отличаются для разных ОС
Сервер, на который будет установлен локальный репозиторий должен быть доступен для Master-nodes, Slave-nodes и CM-server.
Для установки локального репозитория необходимо выполнить следующие операции:
1. Создаём директорию проектируемого локального репозитория и необходимые вложенные директории, например:
mkdir -p /opt/localrepo/archives
2. Заходим в директорию с будущими архивами локального репозитория:
cd /opt/localrepo/archives/
3. Скачиваем инсталляционные архивы на CM-server:
wget --user=пользователь --ask-password --no-check-certificate ссылка_на_архив_Ростелеком
вводим пароль, предоставленный компанией Ростелеком
4. Распаковываем скаченный архив командой:
tar zxf RT.ClusterManager_версия*.tar.gz
tar zxf RT.DataLake_версия*.tar.gz
tar zxf RT.WareHouse_версия*.tar.gz -C /opt/localrepo/archives/RT.WareHouse/
tar zxf RT.WideStore_версия*.tar.gz -C /opt/localrepo/archives/RT.WideStore/
5. Распаковываем архив с проектом в созданных директориях проектов /opt/localrepo/archives/* :
tar -zxf название архива (например, RT.ClusterManager_версия.tar.gz)
6. После распаковки удаляем изначальные архивы для сохранения места:
rm /opt/localrepo/archives/RT.ClusterManager_версия.tar.gz
rm /opt/localrepo/archives/RT.DataLake_версия.tar.gz
Далее команды в зависимости от ОС.
1. Создаем директорию packages для инсталляционных пакетов, переносим в нее архивы c названием *.repo (локальный репозиторий rt.ca.repo находится в архиве RT.ClusterManager, остальные находятся в одноименных архивах продуктов из ЛК)
mkdir /opt/localrepo/packages
# общие репозитории - нужны всегда
mv /opt/localrepo/archives/rtcm/rt.ca.repo_rpm.tar.gz /opt/localrepo/packages/
mv /opt/localrepo/archives/rtcm/rt.prometheus_exporter.repo /opt/localrepo/packages/
# репозитории продуктов - зависят от поставки
mv /opt/localrepo/archives/RT.DataLake/rt.datalake.repo.tar.gz /opt/localrepo/packages/
mv /opt/localrepo/archives/RT.StreamingKafka/rt.streamingkafka.repo.tar.gz /opt/localrepo/packages/
mv /opt/localrepo/archives/RT.StreamingNiFi/rt.streamingnifi.repo.tar.gz /opt/localrepo/packages/
mv /opt/localrepo/archives/RT.WareHouse/rt.warehouse.repo.tar.gz /opt/localrepo/packages/
mv /opt/localrepo/archives/RT.Monitoring/rt.monitoring.repo.tar.gz /opt/localrepo/packages/
2. Распаковываем перемещенные архивы:
cd /opt/localrepo/packages
tar -xzvf rt.ca.repo_rpm.tar.gz
tar -xzvf rt.datalake.repo.tar.gz
tar -xzvf rt.streaming.repo.tar.gz
# Репозиторий prometheus не заархивирован, поэтому нет необходимости в его распаковывании
3. Удаляем изначальные архивы локальных репозиториев для сохранения места:
rm rt.ca.repo_rpm.tar.gz rt.datalake.repo.tar.gz rt.streaming.repo.tar.gz rt.prometheus_exporter.repo.tar.gz
ls
4. Внутри каждого репозитория удалим пакеты, не относящиеся к CentOS/RedOS для избегания коллизий
# для warehouse
cd rt.warehouse.repo
# java
rm -rf ./java-*-alt0*
# rt.wh
rm -rf ./rt.wh-*.alt10.*
cd ../
Примечание: В результате директория должна содержать репозитории для работы RT.ClusterManager - rt.ca.repo и rt.prometheus_exporter.repo, а также репозитории самих сервисов, например, rt.datalake.repo или rt.streaming.repo.
5. Если на сервере не установлен artifactory/nexus/nginx/apache, альтернативные хранилища репозиториев или web-серверы для создания локального репозитория, устанавливаем nginx:
sudo yum install nginx
Если пакетный менеджер yum не может найти пакет, возможно нужно установить epel или его аналог репозиторий командой:
yum install epel-release
6. Настраиваем nginx:
sudo vi /etc/nginx/conf.d/localrepo.conf
Примечание: Для работы с vi в режиме редактирования необходимо нажать клавишу i
В нижней левой части экрана отобразится приглашение к вводу --INSERT--, затем, с помощью стрелок необходимо переместиться на нужную строку, изменить ее и после редактирования нажать клавишу ESC (для выхода из данного режима). Затем напечатать :wq для сохранения и выхода из файла.
Пример файла конфигурации:
Примечание: В примере необходимо изменить имя_сервера на имя хоста (из вывода команды ‘hostname -f’ или его ip-адрес)
server {
listen 1337 default_server; # порт, на котором будет отдаваться репозиторий
listen [::]:1337 default_server; # порт, на котором будет отдаваться репозиторий
server_name имя_сервера; # ip адрес или hostname сервера
root /opt/localrepo; # путь до репозитория
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
# расположение, по которому будет доступен репозиторий
location / {
allow all;
sendfile on;
sendfile_max_chunk 1m;
autoindex on;
autoindex_exact_size off;
autoindex_format html;
autoindex_localtime on;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
7. Добавляем nginx в автозагрузку и последующий запуск:
service nginx enable
service nginx start
8. После переконфигурации nginx репозитории будут доступны по ссылкам:
http://полный_адрес_сервера_с_репозиторием:1337/packages/rt.ca.repo/
http://полный_адрес_сервера_с_репозиторием:1337/packages/rt.datalake.repo/
http://полный_адрес_сервера_с_репозиторием:1337/packages/rt.streaming.repo/
http://полный_адрес_сервера_с_репозиторием:1337/packages/rt.prometheus.repo/
9. В дальнейшем в web-интерфейсе RT.ClusterManager во вкладке Настройки → repos необходимо поменять репозитории на:
http://полный_адрес_машины_с_репозиторием:1337/packages/название_репозиториев
(п. 8.2.1 шаг 4, документа «RT.ClusterManager. Руководство администратора»).
1. Создаем директорию packages для инсталляционных пакетов, переносим в нее архивы c названием *.repo (локальный репозиторий rt.ca.repo находится в архиве RT.ClusterManager, остальные находятся в одноименных архивах продуктов из ЛК)
export REPO_DIR=/opt/localrepo
export arch=x86_64
export REPO_NAME_CA=rt.ca.repo
export REPO_NAME_WH=rt.warehouse.repo
mkdir -p $REPO_DIR/$arch/base
# общие репозитории - нужны всегда
mv /opt/localrepo/archives/rtcm/rt.ca.repo.tar.gz $REPO_DIR/$arch/
# пакеты прометея на самом деле простые бинари и не требуют лежать в общей структуре репозитория
mv /opt/localrepo/archives/rtcm/rt.prometheus.repo $REPO_DIR/
# репозитории продуктов - зависят от поставки
mv /opt/localrepo/archives/RT.WareHouse/rt.warehouse.repo.tar.gz $REPO_DIR/$arch/
2. Распаковываем перемещенные архивы и меняем имена директорий в соответствии со структурой репозитория:
cd $REPO_DIR/$arch
tar -xzvf rt.ca.repo.tar.gz
tar -xzvf rt.warehouse.repo.tar.gz
# Репозиторий prometheus не заархивирован, поэтому нет необходимости в его распоковывании
mv ./rt.warehouse.repo ./RPMS.rt.warehouse.repo/
mv ./rt.ca.repo ./RPMS.rt.ca.repo/
3. Удаляем изначальные архивы локальных репозиториев для сохранения места:
rm rt.ca.repo.tar.gz rt.warehouse.repo.tar.gz
ls
4 Внутри каждого репозитория удалим пакеты, не относящиеся к Altlinux 10 для избегания коллизий
# для warehouse
cd rt.warehouse.repo
# java
rm -rf ./java-*.el7*
# rt.wh
rm -rf ./rt.*.el7.*
rm -rf ./rt.*.r73c.*
# прочие пакеты
rm -rf ./*.el7*
cd ../
Примечание: В результате директория должна содержать репозитории для работы RT.ClusterManager - rt.ca.repo и rt.prometheus.repo, а также репозитории самих сервисов, например, rt.warehouse.repo.
5. Если на сервере не установлен artifactory/nexus/nginx/apache, альтернативные хранилища репозиториев или web-серверы для создания локального репозитория, устанавливаем nginx:
sudo apt-get install nginx
6. Настраиваем nginx:
sudo vim /etc/nginx/sites-available.d/repo.conf
Примечание: Для работы с vi в режиме редактирования необходимо нажать клавишу i
В нижней левой части экрана отобразится приглашение к вводу --INSERT--, затем, с помощью стрелок необходимо переместиться на нужную строку, изменить ее и после редактирования нажать клавишу ESC (для выхода из данного режима). Затем напечатать :wq для сохранения и выхода из файла.
Пример файла конфигурации:
Примечание: В примере необходимо изменить имя_сервера на имя хоста (из вывода команды ‘hostname -f’ или его ip-адрес)
server {
listen 1337 default_server; # порт, на котором будет отдаваться репозиторий
listen [::]:1337 default_server; # порт, на котором будет отдаваться репозиторий
server_name имя_сервера; # ip адрес или hostname сервера
root /opt/localrepo; # путь до репозитория
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
# расположение, по которому будет доступен репозиторий
location / {
allow all;
sendfile on;
sendfile_max_chunk 1m;
autoindex on;
autoindex_exact_size off;
autoindex_format html;
autoindex_localtime on;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
7. Добавляем nginx в автозагрузку и последующий запуск:
sudo systemctl enable --now nginx
8. Генерируем метаданные для репозиториев
sudo apt-get install apt-repo-tools
genbasedir --bloat --progress --topdir=$REPO_DIR $arch $REPO_NAME_CA
genbasedir --bloat --progress --topdir=$REPO_DIR $arch $REPO_NAME_WH
9. Проверим работоспособность репозитория
sudo apt-repo add "rpm file:/opt/localrepo x86_64 rt.ca.repo"
sudo apt-repo update
sudo apt-repo list
sudo apt-get install --download-only rt.ca
10. После переконфигурации nginx репозитории будут доступны по ссылкам:
http://полный_адрес_сервера_с_репозиторием:1337/x86_64/RPMS.rt.ca.repo/
http://полный_адрес_сервера_с_репозиторием:1337/x86_64/RPMS.rt.warehouse.repo/
http://полный_адрес_сервера_с_репозиторием:1337/rt.prometheus.repo/
11. В дальнейшем в web-интерфейсе RT.ClusterManager во вкладке Настройки → repos необходимо поменять репозитории на:
Для репозиториев, которые вам не нужны (например art-centos), их значение нужно очистить либо сделать равным ${
# для репозиториев ca и продуктов
rpm http://полный_адрес_машины_с_репозиторием:порт/ x86_64 название_репозиториев_без_RPMS
# для репозитория prometheus
http://полный_адрес_машины_с_репозиторием:порт
(п. 8.2.1 шаг 4, документа «RT.ClusterManager. Руководство администратора»).
1. Создаем директорию packages для инсталляционных пакетов, переносим в нее архивы c названием *.repo (локальный репозиторий rt.ca.repo находится в архиве RT.ClusterManager, остальные находятся в одноименных архивах продуктов из ЛК)
mkdir /opt/localrepo/packages
# общие репозитории - нужны всегда
mv /opt/localrepo/archives/rtcm/rt.ca.repo_deb.tar.gz /opt/localrepo/packages/
mv /opt/localrepo/archives/rtcm/rt.prometheus_exporter.repo /opt/localrepo/packages/
# репозитории продуктов - зависят от поставки
mv /opt/localrepo/archives/RT.DataLake/rt.datalake.repo.tar.gz /opt/localrepo/packages/
mv /opt/localrepo/archives/RT.Streaming/rt.streaming.repo.tar.gz /opt/localrepo/packages/
2. Распаковываем перемещенные архивы:
cd /opt/localrepo/packages
tar -xzvf rt.ca.repo_deb.tar.gz
tar -xzvf rt.datalake.repo.tar.gz
tar -xzvf rt.streaming.repo.tar.gz
# Репозиторий prometheus не заархивирован, поэтому нет необходимости в его распаковывании
3. Удаляем изначальные архивы локальных репозиториев для сохранения места:
rm rt.ca.repo_deb.tar.gz rt.datalake.repo.tar.gz rt.streaming.repo.tar.gz rt.prometheus_exporter.repo.tar.gz
ls
Примечание: В результате директория должна содержать репозитории для работы RT.ClusterManager - rt.ca.repo и rt.prometheus_exporter.repo, а также репозитории самих сервисов, например, rt.datalake.repo или rt.streaming.repo.
4. Если на сервере не установлен artifactory/nexus/nginx/apache, альтернативные хранилища репозиториев или web-серверы для создания локального репозитория, устанавливаем nginx:
sudo apt install nginx
Если пакетный менеджер apt не может найти пакет, возможно нужно установить его вручную по инструкции - https://wiki.astralinux.ru/pages/viewpage.action?pageId=71832638
5. Настраиваем nginx:
sudo vi /etc/nginx/conf.d/localrepo.conf
Примечание: Для работы с vi в режиме редактирования необходимо нажать клавишу i
В нижней левой части экрана отобразится приглашение к вводу -INSERT-, затем, с помощью стрелок необходимо переместиться на нужную строку, изменить ее и после редактирования нажать клавишу ESC (для выхода из данного режима). Затем напечатать :wq для сохранения и выхода из файла.
Пример файла конфигурации:
Примечание: В примере необходимо изменить имя_сервера на имя хоста (из вывода команды ‘hostname -f’ или его ip-адрес)
server {
listen 1337 default_server; # порт, на котором будет отдаваться репозиторий
listen [::]:1337 default_server; # порт, на котором будет отдаваться репозиторий
server_name имя_сервера; # ip адрес или hostname сервера
root /opt/localrepo; # путь до репозитория
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
# расположение, по которому будет доступен репозиторий
location / {
allow all;
sendfile on;
sendfile_max_chunk 1m;
autoindex on;
autoindex_exact_size off;
autoindex_format html;
autoindex_localtime on;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
}
6. Добавляем nginx в автозагрузку и последующий запуск:
systemctl enable nginx
systemctl start nginx
7. После переконфигурации nginx репозитории будут доступны по ссылкам:
http://полный_адрес_сервера_с_репозиторием:1337/packages/rt.ca.repo/
http://полный_адрес_сервера_с_репозиторием:1337/packages/rt.datalake.repo/
http://полный_адрес_сервера_с_репозиторием:1337/packages/rt.streaming.repo/
http://полный_адрес_сервера_с_репозиторием:1337/packages/rt.prometheus.repo/
8. В дальнейшем в web-интерфейсе RT.ClusterManager во вкладке Настройки → repos необходимо поменять репозитории на:
# для репозитория art-general-os (обязательно нужно указать base репозиторий астры, потому что из него устанавливаются необходимые java-пакеты)
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-base/ 1.7_x86-64 main contrib non-free
# для репозитория prometheus
http://полный_адрес_сервера_с_репозиторием:порт/rt.prometheus.repo/
# для остальных репозиториев
deb [trusted=true] http://полный_адрес_машины_с_репозиторием:порт/название_репозиториев 1.7_x86-64 main
ВНИМАНИЕ: Если используется ReOS версии 7.3.5, то необходимо на всех серверах кластера установить пакет yum
Это касается случаев, когда RedOS 7.3.5 ставится с нуля и не относиться к случаям, когда было произведено обновление например с 7.3.4 на 7.3.5
dnf install yum -y
Необходимо чтобы хосты соответствовали требованиям изложенным в п. 1.3.4.
Для подготовки хостов необходимо:
1. На всех серверах и контейнере rtcm (о контейнерах ниже по тексту, а также позже в п. 3) должны быть синхронизированы часовые пояса и время.
2. Переименовать все хосты в удобном порядке.
Пример hostname FQDN:
Назначение хоста |
hostname fqdn |
CM-server (cm) | rt-cm.corp.local |
Kerberos-server (dc) | rt-dc.corp.local |
Master-node 1 (m1) | rt-m1.corp.local |
Master-node 2 (m2) | rt-m2.corp.local |
Slave-node 1 (s1) | rt-s1.corp.local |
Slave-node 2 (s2) | rt-s2.corp.local |
Slave-node 3 (s3) | rt-s3.corp.local |
Убедиться, что в FQDN нет упоминания о localhost командой:
hostname -f
3. Отключение IPv6
CentOS 7, RedOS 7.3 (на RedOS 7.2 процедура может быть иной)
Важно! Если IPv6 используется в качестве доступа по SSH, то что бы не потерять доступ необходимо, в /etc/ssh/sshd_config contains добавить
# vi /etc/ssh/sshd_config
....
AddressFamily inet
....
Для включения Xforwarding необходимо перезапустить сервис:
systemctl restart sshd
Проверить включён ли IPv6 можно командой:
ip a | grep inet6
Для отключения, необходимо отредактировать конфигурационный файл:
vi /etc/sysctl.conf
Добавить строки:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
(если требуется только на одном интерфейсе, то вместо all можно указать своё название сетевого интерфейса)
sysctl -p
Проверить, что IPv6 отключился можно командой (вывод будет пустой, не должен найти строки с упоминанием inet6)
ip a | grep inet6
4. На всех linux-хостах необходимо создать пользователя с паролем для корректной работы ansible-ролей (в нашем примере везде будет пользователь ansible).
При необходимости к этой команде можно добавить нужные ключи.
Важно: Если используется Astra Linux, то необходимо использовать команду написанную ниже, вместо команды 'useradd ansible'
(это создаст домашнюю директорию, добавит пользователя в группу astra-admin, для sudo и задаст оболочку по умолчанию bash вместо sh, которая идёт по умолчанию у вновь созданных)
useradd -m -G astra-admin -s /bin/bash ansible
Для rpm-like Linux (RedOS, CentOS)
useradd ansible
Выполните команду:
passwd ansible
Задайте пароль для пользователя.
5. На CM-server (находясь под пользователем ansible) необходимо сгенерировать ключевую пару асинхронного шифрования
Во всех параметрах, которые будет запрашивать команда - нажимаем Enter, ничего не вводя.
ssh-keygen -t rsa -b 2048 -m PEM
Примечание: Поддерживаются только ключи в первой строке которых указан формат RSA, не короче 2048b
6. Добавить запись открытой части ключа на хосты, и на CM-server:
Примечание: Необходимо выполнить команду на каждом хосте, в том числе CM-server
ssh-copy-id fqdn_hostname
После этого на всех хостах в файле /home/ansible/.ssh/authorized_keys появится запись открытой части ключа пользователя ansible со стороны CM-server.
7. На всех хостах разрешить sudo без запроса пароля для пользователя ansible:
visudo # открываем конфигурационный файл “sudo” редактором vi
8. В конце файла находим по тексту строку:
root ALL=(ALL) ALL
9. Под ней добавляем строку:
ansible ALL=(ALL) NOPASSWD: ALL
10. Сохраняем изменения.
11. Предпочтительно использовать DNS интрасети, имеющий сетевую связность с подсетью контура и контроллером домена (в случае с kerberos), чтобы все машины кластера умели резолвить друг друга и DC.
Важно: Использование файла hosts вместо DNS допустимо только на тестовых кластерах. При использовании в продуктивном контуре для сохранения полной работоспособности рекомендуем использовать выделенный DNS-сервер, обеспечивающий прямой и обратный резолв.
В противном случае в конец файла /etc/hosts (не затирая существующие записи) добавить все машины кластера в следующем формате:
Пример записей в файле hosts:
192.168.180.100 rt-cm.corp.local rt-cm # MyCluster RTCM docker-host server
192.168.180.101 rt-m1.corp.local rt-m1 # MyCluster m1
192.168.180.102 rt-m2.corp.local rt-m2 # MyCluster m2
192.168.180.103 rt-s1.corp.local rt-s1 # MyCluster s1
192.168.180.104 rt-s2.corp.local rt-s2 # MyCluster s2
192.168.180.105 rt-s3.corp.local rt-s3 # MyCluster s3
192.168.180.120 rt-dc.corp.local rt-dc DC # DC AD Kerberos principals
Примечание: Для правильной работы компонент необходимо чтобы в файле hosts были представлены как короткие (например, rt-cm), так и полные имена (например, rt-cm.corp.local) с указанием домена
12. После запуска контейнеров (см п. 3.4 шаг 1) необходимо скопировать ключевую пару пользователя ansible (id_rsa, id_rsa.pub)в необходимую директорию:
cp дир_пользователя/.ssh/id_rsa* Рабочая_директория/rtcm_data/
Например,
cp /home/ansible/.ssh/id_* /opt/rtcm/rtcm_data/
13. Часовой пояс в контейнере rtcm должен соответствовать часовым поясам на других хостах кластера.
Для изменения часового пояса в контейнере rtcm требуется внести необходимый часовой пояс в файле docker-compose.yaml в переменной TZ, находящейся в блокеservices → rtcm → environment
Например, Europe/Moscow.
Затем запустить контейнеры (см п. 3.4 шаг 1)
Примечание: Для выполнения команд, на сервере должно быть установлено программное обеспечение для выполнения HTTP запросов, например, утилита командной строки сurl.
При использовании операционной системы Astra Linux, при использовании кластеров создаваемых с помощью плагина RT.WereHouse на всех хостах необходимо настроить pam-kiosk, для чего:
Используя команду:
sudo pam-auth-update
В “PAM profiles to enable” выберите "Unix authentication":
pam-auth-update
debconf: не удалось инициализировать интерфейс: Dialog
debconf: (Ни одна из dialog-подобных программ не установлена, поэтому вы не можете использовать dialog-интерфейс. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 78.)
debconf: будет использован интерфейс: Readline
Настройка PAM
-------------
Через подключаемые модули аутентификации (PAM) указывается как нужно проводить аутентификацию, авторизацию и смену пароля в системе, а также можно
назначать запуск дополнительных действий при старте пользовательского сеанса.
Некоторые пакеты модулей PAM предоставляют профили, которые можно использовать для автоматического регулирования поведения всех использующих PAM программ
в системе. Выберите профили, которые нужно применить.
1. Cracklib password strength checking 5. Unix authentication
2. Kiosk2 user confinement 6. Register user sessions in the systemd control group hierarchy
3. pam tally 7. Create home directory on login
4. Last login inactivity days (Default 90 days) 8. ни один из предложенных выше
(Укажите цифры, соответствующие выбранным вариантам, разделяя их пробелами.)
Активируемые профили PAM: 5
Основные конфиги pam лежат в /etc/pam.d/
Примечание: Установка RT.ClusterManager может быть выполнена в автоматическом режиме с помощью скрипта install-rtcm.sh, достаточно задать значения переменных в скрипте и запустить скрипт, как указано в п. 5.2.1 документа “API для работы с RT.ClusterManager”.
Примечание: Для управлением RT.ClusterManager, в том числе запуском, остановом, созданием резервной копии можно воспользоваться скриптом topgun.sh (см. п. 6 документа “API для работы с RT.ClusterManager”).
Вне зависимости от типа репозитория перед началом выполнения всех работ необходимо убедиться, что в Рабочую_директорию (в нашем случае «/opt/rtcm») скопированы (или созданы, если их нет в архиве) нужные директории и файлы из архивов репозитория:
На все указанные директории с вложенными в них файлами должны быть предоставлены полные права:
chmod 777 -R blackbox
chmod 777 -R config
chmod 777 -R prometheus_config
chmod 777 -R prometheus_data
chmod 777 -R postgres_data
chmod 777 -R rtcm_conf
Данные команды необходимо выполнить, так как директории монтируются в контейнер, где файлы читает другой пользователь (пользователь контейнера).
В противном случае необходимо создать вышеуказанного пользователя на машине с таким же UID как у пользователя в контейнере.
Важно: В файле docker-compose.yaml необходимо указать нужный часовой пояс.
Для установки Docker выполните команды на CM-server из рабочей директории:
1. Устанавливаем, запускаем и добавляем в автозапуск docker:
sudo yum install -y docker docker-compose
sudo systemctl start docker
sudo systemctl enable docker
2. Проверьте текущее состояние docker:
sudo systemctl status docker
В случае репозитория «из коробки» (скачивание пакетов через интернет) необходимо:
3. Создать файл /etc/docker/daemon.json:
{
"debug": true,
"registry-mirrors": [
"https://myrepo_adress.ru",
"https://ip_repo"
],
"insecure-registries" : ["myrepo_adress.ru","ip_repo"],
"experimental": false
}
Примечание: Если по дефолтному пути установки (var/lib/docker или /opt/docker) меньше 50 ГБ места, рекомендуется создать отдельный раздел для докера, например, /docker и добавить его использование в файл daemon.json "data-root": "/docker".
4. Перезагрузите сервис:
sudo systemctl reload docker
Для загрузки docker-образов из архива можно воспользоваться двумя способами:
1. Запуск скрипта автоматической подгрузки образов:
./load_images.sh
2. Загрузка образов вручную.
Для этого на CM-server выполните следующие команды:
sudo docker load -i путь_до_дир_с_образами/образ_докер-контейнера_rtcm.tar.gz
sudo docker load -i путь_до_дир_с_образами/образ_докер-контейнера_postgres.tar.gz
sudo docker load -i путь_до_дир_с_образами/образ_докер-контейнера_prometheus.tar.gz
sudo docker load -i путь_до_дир_с_образами/образ_докер-контейнера_blackbox.tar.gz
Примечание: На хосте c RT.ClusterManager убедитесь, что команда
echo $HOSTNAME
возвращает непустое значение - а именно DNS имя машины, которое резолвится с соседних хостов
Перед запуском RT.ClusterManager необходимо выполнить следующие действия:
Если используется репозиторий РТК:
Примечание: Данные учетной записи должны быть указаны без кавычек
https://USER:PASS@REPO_URL
(список см. ниже).Перечень переменных для заполнения:
ВНИМАНИЕ! Если вы устанавливаете продукт на ОС Альт, то нужно разворачивать локальный репозиторий с пакетами по инструкции из раздела 2.2. этого документа (пакеты для репозитория поставляются в архиве продукта). Доступного в интернете репозитория РТК в формате Альт пока нет
Значения этих переменных при использовании репозитория РТК (логин и пароль указываются в отдельных переменных - см. выше):
Имя переменной |
Значение |
Примечание |
---|---|---|
PROMETHEUS_REPO | https://repo.data.rt.ru/repository/rt.clustermanager/prometheus/ | |
CHECKERAGENT_REPO | https://repo.data.rt.ru/repository/rt.checkeragent_rpm_stable/ | |
CENTOS_REPO |
https://mirror.yandex.ru/centos/7/os/x86_64/ http://repo.red-soft.ru/redos/7.3c/x86_64/os/ |
можно использовать любую внешнюю или свою Если установка производится на хосты с RedOS использовать второе значение |
DATALAKE_REPO | https://repo.data.rt.ru/repository/rt.datalake_distr3.0.0_rpm_stable/ https://repo.data.rt.ru/repository/rt.datalake_distr3.2.2_rpm_stable/ |
ссылка зависит от версии плагина |
STREAMINGKAFKA_REPO |
https://repo.data.rt.ru/repository/rt.streamingkafka_rpm_stable/ https://repo.data.rt.ru/repository/rt.streamingkafka_redos7.3_rpm_stable/ |
для установки на ОС CentOS для установки на ОС RedOS |
STREAMINGNIFI_REPO |
https://repo.data.rt.ru/repository/rt.streamingnifi_rpm_stable/ https://repo.data.rt.ru/repository/rt.streamingnifi_redos7.3_rpm_stable/ |
для установки на ОС CentOS для установки на ОС RedOS |
WAREHOUSE_REPO | https://repo.data.rt.ru/repository/rt.warehouse_rpm/v1/ | для установки 6й версии |
WAREHOUSE_REPO | https://repo.data.rt.ru/repository/rt.warehouse_rpm/v4/ | для установки 5й версии |
WIDESTORE_REPO | https://repo.data.rt.ru/repository/rt.widestore_rpm/v1/ |
Порт графического интерфейса RT.ClusterManager не рекомендуется менять. Но в случае, если всё-таки требуется изменить порт по умолчанию, его необходимо вписать в двух местах:
- "8080:8080" (только в левой части изменить на требуемый. В правой части - порт внутри контейнера, его изменять не следует).
- CM_HOST=server_name (изменить адрес хоста на тот, на котором запущен RT.ClusterManager).
- CM_PORT=8080 (изменить адрес порта на необходимый).
- При отсутствии DNS серверов можно прописать имена и адреса всех хостов (по аналогии с файлом hosts, редактируемым выше) в блоке extra_hosts.
Например:
Для запуска контейнеров с RT.ClusterManager необходимо выполнить следующие действия:
1. Из рабочей директории выполнить:
sudo docker-compose -p rtcm up -d --remove-orphans
Имя группы контейнеров «rtcm» должно присутствовать. В эту группу входит три контейнера (одноимённый rtcm, blackbox и prometheus).
2. Проверьте состояние контейнеров:
sudo docker ps
В случае если контейнеры запущены – можно зайти в web-интерфейс для проверки RT.ClusterManager (см. п. 3.5).
3. Дополнительные команды для работы с docker:
Для остановки всех контейнеров необходимо использовать команду:
sudo docker-compose -p rtcm stop
Для удаления всех контейнеров необходимо использовать команду:
sudo docker-compose -p rtcm down
Для просмотра загруженных образов контейнеров (в том числе их id) необходимо использовать команду:
sudo docker images
Для удаления образов контейнеров необходимо использовать команду:
sudo docker image rm [id_контейнера]
Для просмотра сетей докера необходимо использовать команду:
sudo docker network ls
Примечание: В случае перезапуска контейнеров, далее в веб-интерфейсе Системы необходимо выйти из учётной записи и обновить страницу.
1. Сервис будет доступен с любого компьютера с установленным браузером и имеющим маршруты до CM-server по hostname (если резолвиться по имени) или ip адресу по необходимому порту (по умолчанию 8080. Или любой другой, который задали перед запуском контейнеров в файле docker-compose.yaml).
Например:
http://CM:8080
http://192.168.150.150:8080
Примечание: На данном этапе рекомендуем сделать снимки (снапшоты) всех виртуальных машин кластера на которые будет устанавливаться программное обеспечение, в том числе RT.ClusterManager.
Это позволит сократить время при тестировании различных вариаций установки программного обеспечения благодаря отсутствию необходимости проведения этапов предварительной настройки, описанных в данном документе.
ВНИМАНИЕ!
пп.2 , 3 актуальны только для версии 2.7.0 и выше,
на версиях ниже логин rtcm@rt.ru пароль test.
2. Для безопасной инициализации нужно отредактировать файл single-user-providers.xml расположенный по адресу: /opt/app/rtcm/conf:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<loginIdentityProviders>
<provider>
<identifier>single-user</identifier>
<class>single-user.class</class>
<property name="Rtcm user">rtcm@rt.ru</property>
<property name="Password">test0000</property>
<property name="Secret key">super-secret-key</property>
</provider>
</loginIdentityProviders>
В файле вы можете изменить значения:
3. Первый вход выполняется с учётными данными указанными в файле single-user-providers.xml
4. В браузере должна отобразиться страница первого входа в Систему, с предложением создать администратора RT.ClusterManager:
Заполните поля на форме и нажмите кнопку “Создать”. В Системе будет создан пользователь с ролью “Супер администратор”.
В дальнейшем, проходя авторизацию под созданным пользователем можно будет создавать других пользователей с ролями соответствующими их функциональным обязанностям. Подробнее о создании пользователей смотрите п. 9.2 в документе “RT.ClusterManager. Руководство администратора”.
Примечание: Поля “Имя” и “Фамилия” могут содержать до 16 символов русского или английского алфавита, а также символы точки и тире.
Примечание: Пароль пользователя должен содержать не менее 8 символов, должен состоять из латинских букв, чисел от 0 до 9 и следующих спецсимволов «!@-_+#».
Поддерживаемые ОС:
Перед установкой желательно обновить ОС:
dnf update
Если нет понимания в какой директории расположить RT.ClusterManager, то в соответствии с FHS (Filesystem Hierarchy Standard) логично расположить новое ПО rtcm в /opt:
cd /opt
Скачиваем архив с Nexus сайта:
https://repo.data.rt.ru/#browse/browse:rt.clustermanager_arch
Можно использовать wget, curl (с ключами -L и -o) или любой удобный вам способ.
Распаковываем архив:
tar xvf RT.ClusterManager_*.gz
Переходим в директорию:
cd rtcm
Примечание: Если требуется можно донастроить параметры в docker-compose.yaml, перед началом установки
Запускаем установку (он установит docker, docker-compose, запустит docker, подгрузит docker-образы, пошлёт сигнал запуска на topgun.sh):
./install-rtcm.sh install
После этого приблизительно через 20 сек (если диск HDD, а не SSD, то чуть дольше) можно проверять web-интерфейс:
http://<server>:8080
Примечание: Стоит отметить, что если требуется вносить правки в docker-compose.yaml, то необходимо будет останавливать и запускать RTCM.
./topgun.sh down
./topgun.sh up