Важно: Данный раздел актуален для Платформы данных On-Premise.
¶ 1. Введение
¶ 1.1 Назначение документа
Данный документ содержит описание действий и условий необходимых для установки программного обеспечения RT.ClusterManager.
¶ 1.2 Термины, определения и сокращения
В настоящем документе использованы и определены следующие термины и сокращения:
|
Термин/Сокращение |
Определение |
|---|---|
| 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 – «владелец, принимающий гостей») – любое устройство, предоставляющее сервисы формата «клиент-сервер» в режиме сервера по каким-либо интерфейсам и уникально определённое на этих интерфейсах. В более широком смысле под хостом могут понимать любой компьютер, подключённый к локальной или глобальной сети. |
¶ 1.3 Эксплуатационные требования
Вам понадобится пул виртуальных (можно и физических) машин в интрасети или хосты арендованные у хостинг-провайдера, находящиеся в одной подсети, имеющие статический MAC и IPv4 адреса (IPv6 hadoop не поддерживает), а именно:
- CM-server (Linux) – сервер управления Системой (RT.ClusterManager), а также локальный репозиторий для установки Системы;
- Master-node (Linux) – серверы управления slave-нодами. Необходимо 1-2 сервера (минимум 2 в отказоустойчивом режиме);
- Slave-node (Linux) – серверы хранения и обработки данных. Необходимо 2-3 сервера;
- Kerberos-server (Windows) – Domain Controller (DC) (MS Windows Server 2016) с развёрнутой службой каталогов Active Directory и настроенным доменом (можно тестовым).
¶ 1.3.1 Требования к ОС
Предполагается использование следующих дистрибутивов Linux:
- Centos 7,
- Redos 7.2/Redos7.3,
- RHEL 7,
- Ubuntu 20.04.
Примечание: Для продукта RT.Streaming на данный момент поддерживаются только операционные системы: Centos 7, RHEL 7
¶ 1.3.2 Минимальные требования к оборудованию
Минимальные требования к оборудованию для установки RT.ClusterManager:
- Центральный процессор: 4 ядра;
- Оперативная память: 8 Гб.;
- Жесткий диск: 120 Гб.
Требования к оборудованию для развертывания базовой конфигурации кластеров, создаваемых с помощью RT.ClusterManager представлены в п.4.4.2 документа «RT.ClusterManager.Общее описание».
¶ 1.3.3 Сетевые требования
Сетевые требования для установки RT.ClusterManager и корректной работы:
- Все хосты должны находиться в одной сети;
- Должен быть обеспечен прямой и обратный резолв;
Важно: Для корректной работы кластеров, управляемых RT.ClusterManager, необходимо использование DNS-сервера, обеспечивающего прямой и обратный резолв всех хостов кластера, в том числе хоста, на котором установлен RT.ClusterManager.
¶ 1.3.4 Чек-лист для проверки стенда перед инсталляцией
Перед выполнением инсталляции необходимо выполнить данные проверки для соответствия хостов предъявляемым к ним требованиям.
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) |
| Проверка порта. Например 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 |
¶ 2. Подготовка к работе
Примечание: Предполагается, что рабочая директория проекта - /opt/rtcm, а директория локального репозитория - /opt/localrepo
если планируется использование других директорий - учитывайте это при выполнении команд.
Установку RT.ClusterManager возможно произвести двумя способами:
- Через стандартные репозитории компании Ростелеком, доступные через интернет (см. описание Nexus);
- Посредством установки и настройки локального репозитория в интрасети Вашей компании.
Для доступа к архивам со всеми необходимыми компонентами RT.ClusterManager и других систем предлагаемых ПАО Ростелеком своим клиентам используется Личный Кабинет. Также отдельные компоненты можно скачать в репозиториях (см. описание Nexus).
В случае использования метода локального репозитория, перед установкой RT.ClusterManager необходимо выполнить запуск и настройку локального репозитория (см. п.2.2). Локальный репозиторий предоставляет доступ внутри интрасети организации к архиву с инсталляционными файлами для серверов кластера (Master и Slave nodes) и сервера, на который будет устанавливаться RT.ClusterManager (CM-server).
¶ 2.1 Состав дистрибутивного архива
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 они не нужны.
¶ 2.2 Настройка локального репозитория (при необходимости)
Обратите внимание, что начиная с шага 6 команды отличаются для разных ОС
¶ 2.2.1 Общие команды для любых ОС
Сервер, на который будет установлен локальный репозиторий должен быть доступен для Master-nodes, Slave-nodes и CM-server.
Для установки локального репозитория необходимо выполнить следующие операции:
1. Создаём директорию проектируемого локального репозитория и необходимые вложенные директории, например:
mkdir -p /opt/localrepo/archives2. Заходим в директорию с будущими архивами локального репозитория:
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Далее команды в зависимости от ОС.
¶ 2.2.2 для CentOS, RedOS (для других ОС смотри ниже)
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.Streaming/rt.streaming.repo.tar.gz /opt/localrepo/packages/
mv /opt/localrepo/archives/RT.WareHouse/rt.warehouse.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
ls4. Внутри каждого репозитория удалим пакеты, не относящиеся к 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-release6. Настраиваем 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 start8. После переконфигурации 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. Руководство администратора»).
¶ 2.2.3 для Altlinux 10
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
ls4 Внутри каждого репозитория удалим пакеты, не относящиеся к 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 nginx6. Настраиваем 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 nginx8. Генерируем метаданные для репозиториев
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_WH9. Проверим работоспособность репозитория
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.ca10. После переконфигурации 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. Руководство администратора»).
¶ 2.2.4 для Astra Linux
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¶ 2.3 Подготовка хостов
Необходимо чтобы хосты соответствовали требованиям изложенным в п. 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 -f3. Отключение 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 inet64. На всех linux-хостах необходимо создать пользователя с паролем для корректной работы ansible-ролей (в нашем примере везде будет пользователь ansible).
При необходимости к этой команде можно добавить нужные ключи.
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” редактором vi8. В конце файла находим по тексту строку:
root ALL=(ALL) ALL9. Под ней добавляем строку:
ansible ALL=(ALL) NOPASSWD: ALL10. Сохраняем изменения.
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)
¶ 3. Установка RT.ClusterManager
Примечание: Установка RT.ClusterManager может быть выполнена в автоматическом режиме с помощью скрипта install-rtcm.sh, достаточно задать значения переменных в скрипте и запустить скрипт, как указано в п. 5.2.1 документа “API для работы с RT.ClusterManager”.
Примечание: Для управлением RT.ClusterManager, в том числе запуском, остановом, созданием резервной копии можно воспользоваться скриптом topgun.sh (см. п. 6 документа “API для работы с RT.ClusterManager”).
Вне зависимости от типа репозитория перед началом выполнения всех работ необходимо убедиться, что в Рабочую_директорию (в нашем случае «/opt/rtcm») скопированы (или созданы, если их нет в архиве) нужные директории и файлы из архивов репозитория:
- blackbox/
- config/
- prometheus_config/
- prometheus_data/
- rtcm_conf/
- rtcm_data/
- rtcm_db/
- postgres_data/
- docker-compose.yaml
На все указанные директории с вложенными в них файлами должны быть предоставлены полные права:
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 необходимо указать нужный часовой пояс.
¶ 3.1 Установка и настройка докера CentOS/RHEL
Для установки Docker выполните команды на CM-server из рабочей директории:
1. Устанавливаем, запускаем и добавляем в автозапуск docker:
sudo yum install -y docker docker-compose
sudo systemctl start docker
sudo systemctl enable docker2. Проверьте текущее состояние 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¶ 3.2 Загрузка doсker-образов из архивов
Для загрузки docker-образов из архива можно воспользоваться двумя способами:
1. Запуск скрипта автоматической подгрузки образов:
./load_images.sh2. Загрузка образов вручную.
Для этого на 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¶ 3.3 Подготовка настроек
Примечание: На хосте c RT.ClusterManager убедитесь, что команда
echo $HOSTNAMEвозвращает непустое значение - а именно DNS имя машины, которое резолвится с соседних хостов
Перед запуском RT.ClusterManager необходимо выполнить следующие действия:
- Убедиться, что файл docker-compose.yaml находится в рабочей директории CM-server.
- В файле docker-compose.yaml необходимо внести следующие изменения:
- В блоке services→rtcm→environment заполнить значения переменных *_REPO полными урлами репозиториев - эти строки в неизменном виде попадут в .repo файлы на узлах кластера.
Если используется репозиторий РТК:
- При наличии в файле docker-compose.yaml переменных REPO_USER, REPO_PASS заполнить их данными учётной записи для подключения к репозиториям, а сами строки подключения к репозиториям заполнять без учётных данных
Примечание: Данные учетной записи должны быть указаны без кавычек
- При отсутствии этих переменных, указать учётные данные для подключения в самой строке подключения к репозиториям в формате
https://USER:PASS@REPO_URL(список см. ниже).
Перечень переменных для заполнения:
- Обязательные записи:
- PROMETHEUS_REPO - путь до директории, в которой лежит нод экспортер прометея (если используется архив для оффлайн установки здесь указать путь до репозитория чекер агента).
- CHECKERAGENT_REPO - репозиторий rt.ca, пакеты поставляются вместе с CM.
- CENTOS_REPO - заполняется при наличии у заказчика собственного репозитория пакетов для centos, если его нет - оставить пустым.
- Записи для отдельных продуктов (строки неиспользуемых на данном кластере продуктов можно оставить исходными):
- DATALAKE_REPO
- STREAMINGKAFKA_REPO
- STREAMINGNIFI_REPO
- WAREHOUSE_REPO
- WIDESTORE_REPO
ВНИМАНИЕ! Если вы устанавливаете продукт на ОС Альт, то нужно разворачивать локальный репозиторий с пакетами по инструкции из раздела 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 не рекомендуется менять. Но в случае, если всё-таки требуется изменить порт по умолчанию, его необходимо вписать в двух местах:
- в блоке services→rtcm→ports:
- "8080:8080" (только в левой части изменить на требуемый. В правой части - порт внутри контейнера, его изменять не следует).
- в блоке services→rtcm→environment:
- CM_HOST=server_name (изменить адрес хоста на тот, на котором запущен RT.ClusterManager).
- CM_PORT=8080 (изменить адрес порта на необходимый).
- В блоке services→rtcm→extra_hosts:
- При отсутствии DNS серверов можно прописать имена и адреса всех хостов (по аналогии с файлом hosts, редактируемым выше) в блоке extra_hosts.
Например:
- “rt-m1.local.domain:192.168.150.15”
- “rt-m2.local.domain:192.168.150.16”
¶ 3.4 Запуск/перезапуск контейнера
Для запуска контейнеров с 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
Примечание: В случае перезапуска контейнеров, далее в веб-интерфейсе Системы необходимо выйти из учётной записи и обновить страницу.
¶ 3.5 Запуск web-интерфейса RT.ClusterManager
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>
В файле вы можете изменить значения:
- Rtcm user - логин для первого входа ,
- Password - пароль для авторизации,
- Secret key - alias ключа в хранилище RT.CM для расшифровки пароля.
3. Первый вход выполняется с учётными данными указанными в файле single-user-providers.xml
4. В браузере должна отобразиться страница первого входа в Систему, с предложением создать администратора RT.ClusterManager:
Заполните поля на форме и нажмите кнопку “Создать”. В Системе будет создан пользователь с ролью “Супер администратор”.
В дальнейшем, проходя авторизацию под созданным пользователем можно будет создавать других пользователей с ролями соответствующими их функциональным обязанностям. Подробнее о создании пользователей смотрите п. 9.2 в документе “RT.ClusterManager. Руководство администратора”.
Примечание: Поля “Имя” и “Фамилия” могут содержать до 16 символов русского или английского алфавита, а также символы точки и тире.
Примечание: Пароль пользователя должен содержать не менее 8 символов, должен состоять из латинских букв, чисел от 0 до 9 и следующих спецсимволов «!@-_+#».
¶ 4. Автоматическая установка RT.ClusterManager
Поддерживаемые ОС:
- CentOS 7.9 (Примечание: docker-compose будет скачен из интернета),
- RedOS 7.3c,
- RedOS 7.3.x,
- RedOS 8.0,
- Alt Linux 10p.
Перед установкой желательно обновить ОС:
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