Развертывание системы Колибри-АРМ в российском облаке

Представьте: в вашей организации сотни, а то и тысячи компьютеров под управлением Windows и разных дистрибутивов Linux. Управлять этим зоопарком классическими средствами вроде Microsoft SCCM становится невозможно, особенно с учётом тренда на импортозамещение. Здесь на сцену выходит система для централизованного управления устройствами и приложениями в гетерогенной инфраструктуре из «единого окна» Колибри-АРМ.

А теперь усложним задачу: мы не хотим держать сервер в душном серверном помещении и тратить бюджет на его железо и обслуживание. Мы хотим получить отказоустойчивую, масштабируемую и безопасную инфраструктуру в аренду за разумные деньги, что может предложить российское публичное облако Cloud.ru.

В этой статье покажу, как правильно подойти к развертыванию Колибри-АРМ в облаке, избежав типичных ошибок новичков. Мы развернем:

1. Головной сервер — центр управления всей инфраструктурой.

2. Интернет-шлюз — для управление устройствами вне сетевого контура компании.

3. Клиентскую машину с GUI для проверки работы агентов.

Так мы получим управляемый PostgreSQL от провайдера, мощные и гибкие группы безопасности, интеграцию с DNS и, что самое важное, возможность управлять всей этой инфраструктурой из единого окна.

Важное отступление: статья предполагает, что вы уже обладаете дистрибутивами Колибри-АРМ. Я буду использовать заглушки для специфичных для вашей организации данных (IP-адреса, имена, ключи).

Часть 1. Планирование и архитектура

Прежде чем бежать создавать ресурсы, давайте набросаем архитектуру. Чтобы защитить управляющий контур (головной сервер и СУБД) от потенциальной угрозы из интернета, мы применим сегментацию сети и разделим наше VPC на три изолированные подсети в рамках одной зоны доступности (маршрутизация между подсетями внутри одного VPC в Cloud.ru разрешена по умолчанию, но мы жестко ограничим её на уровне межсетевого экрана):

1. VPC (Virtual Private Cloud): Сеть с CIDR-блоком 10.10.0.0/16.

2. Подсети (зона ru.AZ-1):

   — subnet-dmz (10.10.1.0/24) — Демилитаризованная зона. Здесь живет только шлюз.

   — subnet-app (10.10.2.0/24) — Защищенный бэкенд-сегмент. Тут находятся головной сервер и управляемая БД.

   — subnet-clients (10.10.3.0/24) — Внутренняя подсеть для обслуживаемых АРМ и проверки агентов.

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

4. Управляемый PostgreSQL — сервис Evolution Managed PostgreSQL от Cloud.ru, развернутый внутри subnet-app.

5. Объектное хранилище (S3): бакет для постоянного хранения общих пакетов, скриптов и образов (packagesshare).

6. Внутренний DNS Cloud.ru для маршрутизации внутри VPC.

7. VPN-подключение: для production-среды обязательным шагом является организация Site-to-Site VPN (через IPsec VPN-шлюз в облако) между приватной подсетью subnet-app и вашим офисным сегментом сети.

Виртуальные машины:

Что важно на схеме:

• Головной сервер colibri-arm не имеет публичного IP-адреса. Доступ к нему снаружи закрыт. Администраторы подключаются через корпоративный VPN или Бастион-хост.

• Интернет-шлюз colibri-gate выставлен наружу, но жестко изолирован на уровне групп безопасности: ему запрещено «гулять» по внутренней сети, кроме как отправлять трафик на конкретные порты colibri-arm.

• Дополнительный быстрый диск 100 ГБ (SSD) у colibri-arm используется для хранения данных Колибри.

Часть 2. Подготовка облачной инфраструктуры (IaaS)

2.1. Создание VPC и подсетей

Рекомендации:

• Для production-нагрузок никогда не используйте группы безопасности по умолчанию.

• Следуйте принципу наименьших привилегий.

• Избегайте открытия SSH наружу для 0.0.0.0/0.

В консоли Cloud.ru переходим в разделе Подсети создаем три подсети в зоне ru.AZ-1:

1. subnet-dmz — CIDR 10.10.1.0/24

2. subnet-app — CIDR 10.10.2.0/24

3. subnet-clients — CIDR 10.10.3.0/24

2.2. Группы безопасности

Группы безопасности привязываются к сетевым интерфейсам ВМ. Вместо текстового полотна ниже приведена матрица сетевых доступов, настроенная согласно официальной матрице Колибри-АРМ.

2.3. Создание управляемого кластера PostgreSQL

Переходим в сервис Evolution Managed PostgreSQL.

Параметры:

• Название кластера: Colibri_bd

• Версия PostgreSQL: 17 (всегда сверяйте с актуальной документацией Колибри)

• Локаль сортировки (LC_COLLATE) и набора символов (LC_CTYPE): ru_RU.utf8

• Класс ВМ: 4core-8ram (для пилота), 8core-16ram (для продакшена до 5000 управляемых устройств), 16core-32ram (для продакшена до 10 000 управляемых устройств)

• Размер диска: 50 ГБ SSD

• Сеть: Выбираем приватную подсеть subnet-app (10.10.2.0/24).

На выходе провайдер выделит приватный IP кластера внутри вашей подсети (например, 10.10.2.8) и внутреннее DNS-имя.

Часть 3. Виртуальные машины в деталях

3.1. Интернет-шлюз colibri-gate (Граница сети)

• Размещение: subnet-dmz (10.10.1.0/24)

• Образ: debian-12

• Флейвор: low-2-4 (2 vCPU, 4 ГБ RAM)

• Загрузочный диск: 50 ГБ SSD

• Группы безопасности: sg-bastion-ssh, sg-colibri-gate.

• Сетевые интерфейсы: Привязан публичный IP адрес для доступности из интернета.

3.2. Головной сервер colibri-arm (Ядро системы)

• Размещение: subnet-app (10.10.2.0/24)

• Образ: debian-12 (чистый)

• Флейвор: low-8-16 (8 vCPU, 16 ГБ RAM для пилота), 8 vCPU, 32 ГБ RAM для продакшена до 5000 управляемых устройств, 16 vCPU, 64 ГБ RAM для продакшена до 10 000 управляемых устройств. Для большего количества управляемых устройств рекомендуем создавать кластер с предварительной консультацией производителя Колибри-АРМ.

• Загрузочный диск: 30 ГБ SSD

• Дополнительный диск: 100 ГБ SSD (монтируем в /opt под служебные файлы системы)

• Группы безопасности: sg-bastion-ssh, sg-colibri-server.

• Сетевые интерфейсы: Только приватный IP 10.10.2.5. Никаких публичных адресов!

3.3. Тестовый клиент client1

• Размещение: subnet-clients (10.10.3.0/24)

• Образ: Ubuntu-24.04 (с GUI)

• Группы безопасности: Локальные правила для получения пакетов с сервера (порты 443, 5001-5005) и правила для RDP/Xrdp.

На этой ВМ мы развернем графическую оболочку, чтобы наглядно проверить, как агент осуществляет инвентаризацию и управление рабочим столом.

Часть 4. Настройка внутреннего DNS (Cloud.ru)

Чтобы компоненты в разных подсетях беспрепятственно находили друг друга по именам, развернем приватную DNS-зону.

1. В консоли Cloud.ru переходим в Сеть → DNS-серверы:

   — Название: colibri-dns

   — VPC: colibri-vpc

   — Подсеть: Выбираем subnet-app (10.10.2.0/24).

2. В разделе Сеть → DNS-зоны создаем приватную зону:

   — Домен: cloudru.local.

   — VPC: colibri-vpc

3. Внутри зоны добавляем строго структурированные A-записи:

   — colibri-arm.cloudru.local -> 10.10.2.5 (Головной сервер)

   — colibri-gate.cloudru.local -> 10.10.1.5 (Шлюз в DMZ)

   — db.colibri-arm.cloudru.local -> 10.10.2.8 (Управляемая БД)

   — Wildcard-запись: имя *, тип A, значение 10.10.2.5 (необходимо для веб-сервисов и динамических поддоменов Колибри).

   
   Нюанс для Linux-клиентов: Использование Wildcard-записей в приватных зонах иногда специфически обрабатывается локальными резолверами (например, systemd-resolved). Если Агенты на Linux не могут разрешить внутренние поддомены, убедитесь, что в конфигурации сети или в /etc/resolv.conf присутствует корректная директива search cloudru.local. ## Часть 5. Установка Колибри-АРМ: пошаговая инструкция

Дальше идёт магия. На сервере colibri-arm мы развернём саму систему, используя официальный установщик, внешний управляемый PostgreSQL и объектное хранилище S3 для пакетов.

5.1. Доставляем дистрибутив на сервер

Дистрибутив установщика (файл вроде colibriARM_installer_26.02.2.tar.gz) нужно загрузить на colibri-arm.

• Вариант 1 (рабочий): через WinSCP (SCP). Самый простой и доступный вариант — SCP, копирование архива с установщиком сразу на сервер через SSH. Однако на практике оказалось, что скорость передачи мала и соединение рвётся. На помощь пришёл WinSCP, через эту утилиту архив загрузился успешно.

• Вариант 2: через S3 bucket.
  Если доступа извне нет, можно залить архив в бакет, а на сервере скачать смонтированный диск (настройка s3fs рассмотрена ниже в статье). Но в нашем случае проще оказался WinSCP.

# После загрузки архива перекладываем его в /optsudo mv ~/colibriARM_installer_26.02.2.tar.gz /opt/cd /opt

5.2. Подготовка окружения: пакеты, docker, пользователь

Параллельно с загрузкой файлов готовим систему:

# Ставим необходимые пакетыsudo apt updatesudo apt install -y s3fs postgresql-client docker.io docker-compose  # или docker-ce# Добавляем текущего пользователя в группу docker (опционально, но удобно)sudo usermod -aG docker $USERnewgrp docker

Почему s3fs? Он понадобится позже, чтобы примонтировать бакет с общими пакетами Колибри (packagesshare). А postgresql-client нужен для ручных миграций и проверок.

5.3. Дополнительный диск: разметка, форматирование, монтирование в /opt/colibri

У colibri-arm есть дополнительный диск 100 ГБ SSD (/dev/vdb). Отдадим его под данные Колибри.

# Смотрим, что у нас естьlsblk # Размечаем диск (один раздел на весь диск)sudo fdisk /dev/vdb# В fdisk: n (new), p (primary), 1 (первый раздел), Enter (начало), Enter (конец), w (write) # Создаём файловую систему ext4 на разделе /dev/vdb1sudo mkfs.ext4 /dev/vdb1 # Узнаём UUID нового разделаsudo blkid /dev/vdb1# Пример: UUID="2ac025e5-76c7-48c8-a2c4-9b9992f47cc6"

Добавляем автоматическое монтирование в /etc/fstab:

echo 'UUID=2ac025e5-76c7-48c8-a2c4-9b9992f47cc6 /opt/colibri ext4 defaults 0 0' | sudo tee -a /etc/fstab

Перезагружаем systemd и монтируем:

sudo systemctl daemon-reloadsudo mount -adf -h /opt

Теперь весь каталог /opt изолирован на быстром отдельном диске — это защитит корневой раздел ОС от переполнения логами, образами Docker и тяжелыми пакетами ПО.

5.4. Распаковка установщика и генерация скриптов для внешней БД

cd /opttar xvzf colibriARM_installer_26.02.2.tar.gzcd colibriARM_installer# Генерируем конфигурационные скрипты для внешней БД (флаг -e)sudo ./install.sh -e

В результате выполнения появятся:

• Файл ответов file.rsp со сгенерированными паролями для пользователей БД;

• Каталог ./external_db со SQL-скриптами первичных миграций.

5.5. «Причёсываем» пароли и имена пользователей

Политика безопасности Cloud.ru Managed PostgreSQL требует более сложных паролей, в отличии от тех, которые генерирует скрипт установщика на данный момент: цифры, спецсимволы, разный регистр.

Редактируем file.rsp:

nano file.rsp

Ищем все переменные, оканчивающиеся на DATABASEPASSWORD, и меняем их на надёжные пароли (например, MyStr0ng#P@ssw0rd_2025!).

Также меняем имя пользователя report-test-ro-user на report_test_ro_user — Cloud.ru не поддерживает дефисы в именах пользователей, только буквы, цифры и подчёркивания.

После правок запускаем генератор ещё раз, чтобы обновить скрипты в ./external_db:

sudo ./install.sh -e

На заметку: в будущих версиях планируется научить установщик генерировать пароли с настраиваемой сложностью — пока делаем ручками.

5.6. Создаём пользователей и БД в Managed PostgreSQL

Переходим в веб-интерфейс Cloud.ru → Evolution Managed PostgreSQL → ваш кластер.

1. Пользователи

   Создаём учётные записи с теми именами и паролями, что мы прописали в file.rsp. Назначаем им роли: можно всем выдать read_write_all_data (упрощённо) или в соответствии со скриншотом.

2. Базы данных

Создаём следующие БД и назначаем владельцев (owner):

• audit

• cachemetadata

• colibri

• conjur

• grafana

• keycloak

• meshdb

• superset

Для каждой БД при создании выберите локаль ru_RU.UTF-8 (или en_US.UTF-8).

3. Проверяем подключение

psql -h 10.10.2.8 -U admin -d colibri

IP кластера 10.10.2.8 берём из настроек Managed PostgreSQL. Пароль от admin задавали при создании кластера.

5.7. Миграции схем

Переходим в каталог external_db:

cd /opt/colibriARM_installer/external_db

Выполняем миграции в правильном порядке:

psql -h 10.10.2.8 -U admin -d colibri -f base_migration.sqlpsql -h 10.10.2.8 -U admin -d colibri -f colibri_reporting_migration.sql

В процессе будут сыпаться предупреждения вроде WARNING: no privileges were granted. Это ожидаемое поведение, потому что в Managed PostgreSQL назначение прав через CLI ограничено. Необходимые роли мы уже назначили в интерфейсе портала.

5.8. Правка скрипта Superset (чтобы установка не падала)

Чтобы избежать ошибок во время установки Superset, редактируем scripts/superset.sh:

cd /opt/colibriARM_installersed -i '    s|POSTGRE_SQL_ADDRESS="db${DOMAINDELIMITER}${DOMAINPREFIX}.${DOMAINNAME}"|POSTGRE_SQL_ADDRESS="10.10.2.8"|g    s|^[[:space:]]*setAccessRightsUser|#\tsetAccessRightsUser|g    /err "Не удалось выполнить запрос на сервере базы данных $POSTGRE_SQL_ADDRESS:$POSTGRE_SQL_PORT"/{        N        s/err /warn /        s/\n\s*exit 1//    }    /err "Не удалось выполнить запрос на сервере базы данных $POSTGRE_SQL_ADDRESS:$POSTGRE_SQL_PORT - элемент массива $ARRAY_ITEM"/{        N        s/err /warn /        s/\n\s*exit 1//    }' ./scripts/superset.sh

Что мы сделали:

• подставили реальный IP PostgreSQL;

• закомментировали попытку назначения прав;

• превратили фатальные ошибки в предупреждения.

5.9. Финальный запуск установки

Сначала проверим совместимость:

sudo ./install.sh -C

Если всё зелёное, запускаем установку:

sudo ./install.sh

Установщик попросит сохранить file.rsp в надёжное место.

Важнейший шаг ИБ: Файл file.rsp содержит все пароли от вашей инфраструктуры в открытом виде. Скопируйте его в корпоративный менеджер паролей (Vault/KeePass), удалите его с сервера или зашифруйте. Очистите историю терминала командой history -c. На данный момент ведется разработка по автоматической выгрузке секретов в Vault используемый в вашей инфраструктуре.

Поздравляю! Колибри-АРМ установлен и подключён к внешней управляемой БД.

Далее идем на клиент, где мы можем открыть браузер и перейти по адресу http://colibri-arm.cloudru.local:5001/service_repo/agent/ca/. Cохраним файл colibriCA.crt и установим сертификат в доверенное хранилище сертификатов машины оператора (для Firefox установка происходит в хранилище сертификатов Firefox). Это необходимо для того, чтобы использовать протокол https без предупреждений о небезопасном сайте.

Далее можем выполнить вход в Систему по адресу https://colibri-arm.cloudru.local с логином colibri_admin и паролем из переменной COLIBRIADMINPASSWORD из файла с учетными данными file.rsp в каталоге установки.

Первое действие в Системе: обязательно перейдите в настройки и создайте Границу обслуживания на вашу целевую подсеть (например, 10.10.3.0/24) с указанием точки распространения сервера. Без этого Агенты не поймут, откуда им забирать конфигурации.

Установка агента Колибри на client1.

1. Создайте компьютер в инвентаризации
   Инвентаризация → Компьютеры → «Создать».

— Укажите FQDN. Для Windows — верхний регистр, для Linux — нижний. (Можно вместо имени указать ip, если есть проблемы с поиском по имени)

— Если компьютер сейчас в локальной сети и виден серверу, можно не указывать UUID, а MAC-адрес заполнить заглушкой 00-00-00-00-00-00.

2. Установите агент
Конфигуратор → Развертывания агента → создайте развертывание для нужной ОС.

3. Создайте коллекцию
Коллекции → создайте коллекцию, например Linux. Добавьте в неё компьютер.

Проверьте управление:

• Удалённо установите пакет xrdp на client1 через интерфейс.

• Запустите инвентаризацию.

5.10. Подключение Object Storage для каталога packagesshare

По умолчанию Колибри-АРМ забирает дистрибутивы и образы ОС локально в /opt/colibri/packagesshare/. Чтобы сэкономить дисковое пространство ВМ и обеспечить централизованное хранение, смонтируем туда S3-бакет Cloud.ru через s3fs.

Шаги:

• В консоли облака → Object Storage создаём бакет, например colibri-share.

• В профиле аккаунта → Ключи доступа создаём новый ключ. Сохраняем key_id и key_secret.

• В настройках бакета копируем tenant_id.

• На сервере colibri-arm создаём файл с учётными данными:

sudo nano /opt/.passwd-s3fs# Формат: <имя_бакета>:<tenant_id>:<key_id>:<key_secret># Пример: colibri-share:abc123def456:AKIAIOSFODNN7EXAMPLE:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYsudo chmod 600 /opt/.passwd-s3fs

5. Важно: каталог packagesshare уже содержит файлы. Если смонтировать поверх него бакет, исходное содержимое станет недоступно. Делаем бэкап:

cp -r /opt/colibri/packagesshare /opt/colibri/packagesshare_backup

6. Добавляем строку монтирования в /etc/fstab:

echo 's3fs#colibri-share /opt/colibri/packagesshare fuse _netdev,nofail,x-systemd.automount,allow_other,nonempty,use_path_request_style,url=https://s3.cloud.ru,endpoint=ru-central-1,passwd_file=/opt/.passwd-s3fs 0 0' | sudo tee -a /etc/fstab

7. Перезагружаем systemd и монтируем:

sudo systemctl daemon-reloadsudo mount -a

Теперь бакет colibri-share доступен в /opt/colibri/packagesshare/. При необходимости исходные файлы можно скопировать обратно из бэкапа.

Часть 6. Интернет-шлюз Колибри: подключение удалённых АРМ

Зачем нужен интернет-шлюз? Он обеспечивает возможность подключения удалённых АРМ к системе через интернет для:

• сбора инвентарной информации;

• установки и удаления ПО;

• подключения к удалённым АРМ с помощью средств удалённого доступа системы и остальных возможностей системы (кроме развертывания ОС).

Два сценария использования:

1. АРМ находится в зоне сетевой доступности сервера системы (например, в локальной сети компании). Тогда шлюз нужен для того, чтобы после отправки АРМ удалённому сотруднику он автоматически переключился на работу через интернет.

2. АРМ изначально вне корпоративной сети компании (сетевой доступ к серверу системы отсутствует). Тогда шлюз служит единственной точкой входа.

В нашем проекте мы настроим шлюз для первого сценария, используя уже созданную ВМ colibri-gate.

6.1. Требования к компьютеру-шлюзу (colibri-gate)

Прежде чем создавать шлюз, убедимся, что colibri-gate соответствует требованиям:

• ОС: Debian 12 (или любая другая ОС с поддержкой Docker Engine).

• Установлен Docker Engine (≥24.0.9) и Docker Compose (≥2.21.0) .

• Настроен файрвол (группа безопасности), разрешающий входящий трафик на порт шлюза. В группе colibri-gate открыт порт 4433.

• На компьютере установлен агент Колибри, и его статус в интерфейсе — «В сети».

• Компьютер не является точкой распространения (отдельная роль).

Как установить агент на colibri-gate? Так же, как на client1 — через раздел «Конфигуратор → Развертывания агента». Дождёмся статуса «В сети».

6.2. Создание интернет-шлюза в интерфейсе Колибри-АРМ

Заходим в веб-интерфейс. Переходим в Конфигуратор → Интернет-шлюз → нажимаем «Создать».

Заполняем форму:

Нажимаем «Сохранить». Шлюз появится в списке.

6.3. Настройка АРМ, находящегося в зоне доступности сервера

Этот сценарий идеально подходит, когда вы предварительно настраиваете компьютер в офисе, а потом отправляете сотруднику на удалёнку.

Пошаговая инструкция:

• Создайте компьютер в инвентаризации
  Инвентаризация → Компьютеры → «Создать».

  — Укажите FQDN. Для Windows — верхний регистр, для Linux — нижний.

  — Если компьютер сейчас в локальной сети и виден серверу, можно не указывать UUID, а MAC-адрес заполнить заглушкой 00-00-00-00-00-00.

• Установите агент
  Конфигуратор → Развертывания агента → создайте развертывание для нужной ОС. Дождитесь статуса «В сети».

• Создайте (или используйте готовую) коллекцию
  Коллекции → создайте коллекцию, например Удалённые АРМ. Добавьте в неё компьютер.

• Привяжите шлюз к коллекции
  При создании шлюза (п. 6.2) выберите эту коллекцию. Если шлюз уже создан — отредактируйте его и укажите нужную коллекцию.

• Система автоматически распространит конфигурацию
  Агент на компьютере получит настройки шлюза и при следующем подключении (даже из интернета) будет использовать его.

Важные замечания:

• Автоматическое распространение конфигурации работает только для компьютеров со статусом «В сети».

• Для Windows 11 необходим опциональный компонент WMIC.

• Конфигурация шлюза обновляется по расписанию. Для немедленного применения выделите шлюз и нажмите «Форсированный запуск» (доступно при статусе «Успех» или «Ошибка»).

6.4. Проверка работы шлюза

1. Убедитесь, что на colibri-gate запущен.

2. Отключите клиентский АРМ от локальной сети (имитация удалёнки).

3. Подключите его к интернету через любой канал. Агент должен самостоятельно найти шлюз по публичному IP PublicIP:4433 и установить соединение.

4. В веб-интерфейсе Колибри статус компьютера должен оставаться «В сети».

Поздравляю! Ваша инфраструктура готова к управлению удалёнными АРМ через облачный шлюз.

Резюме и рефлексия

Мы развернули масштабируемую, защищенную инфраструктуру Колибри-АРМ в облаке, и использование управляемых сервисов (Managed PostgreSQL, Cloud DNS, Object Storage) снимает головную боль по администрированию инфраструктурного слоя бэкенда, позволяя сфокусироваться на управлении конечными устройствами.

В качестве вектора дальнейшего развития развернутой инфраструктуры на платформе вендора можно внедрить комплекс Production-ready практик для повышения безопасности и отказоустойчивости: защитить публичный периметр интернет шлюза Колибри-АРМ от DDoS-атак и сканирования с помощью сервисов Cloud.ru Anti-DDoS, полностью отказаться от парольного доступа по SSH в пользу SSH ключей с организацией единого Бастион-хоста (Jump Server), а также масштабировать вычислительный слой за счет подключения облачного балансировщика нагрузки перед несколькими нодами Колибри-АРМ и настройки автоматического резервного копирования конфигураций.

Если вам интересна тема импортозамещения систем управления и облачной архитектуры — пишите в комментариях. В следующий раз можем рассмотреть развертывание Колибри-АРМ в кластер Docker Swarm на Cloud.ru.