Ctrl+K
Ctrl+K
PDF
Ctrl+K
PDF

Версии

Рекомендации по самостоятельной разработке сервисов

Содержание

Рекомендации по самостоятельной разработке сервисов#

Необходимо чтобы разрабатываемый PaaS-сервис был полностью совместим с подсистемой виртуализации и поддерживал автоматическую настройку через механизм контекстуализации. Сервис должен быть доступен через магазин приложений и предоставлять возможность развертывания по меньшей мере в одной из нескольких конфигураций (в зависимости от сервиса):

  • Single Node Service — один узел с минимальной настройкой;

  • Cluster Configuration — набор узлов с возможностью распределения нагрузки и высокой доступностью;

  • Multi-Node Configuration — сервис, состоящий из нескольких взаимосвязанных компонентов.

Для успешной разработки сервиса необходимо, чтобы сервис соответствовал перечисленным ниже функциональным и нефункциональным характеристикам.

Характеристики#

Функциональные характеристики#

Поддержка конфигураций#

Single Node Service:

  • один сервер, выполняющий все функции сервиса;

  • настраиваемые параметры:

    • имя сервиса;

    • IP-адрес;

    • логин/пароль администратора;

    • ресурсы сервера (CPU, RAM, диск);

  • сценарий использования: для небольших проектов или тестирования.

Cluster Configuration:

  • архитектура с ведущим узлом (master) и ведомыми узлами (replica);

  • настраиваемые параметры:

    • количество узлов в кластере;

    • IP-адрес ведущего узла;

    • пароль репликации;

    • настройки высокой доступности (HA);

  • сценарий использования: приложения с высокой доступностью или требующие распределения нагрузки.

Multi-Node Configuration:

  • несколько узлов с различными ролями (frontend, backend, database);

  • настраиваемые параметры:

    • роли узлов;

    • IP-адреса для каждого узла;

    • логин/пароль для взаимодействия между компонентами;

  • сценарий использования: сложные приложения с разделением ролей компонентов.

Контекстуализация#

Поддерживать автоматическую настройку узлов через метод контекстуализации подсистемы виртуализации:

  • использование пакетов opennebula-context для передачи данных конфигурации;

  • параметры контекстуализации:

    • роль узла (master, replica, frontend, backend);

    • сетевые настройки (IP-адреса, шлюзы);

    • учетные данные (логины, пароли);

    • дополнительные параметры (имя базы данных, порт, конфигурации HA).

Автоматическая настройка#

Скрипты настройки должны:

  • автоматически задавать роли узлов;

  • настраивать взаимодействие между узлами (например, репликация данных);

  • поддерживать установку пользовательских параметров;

  • обеспечивать полностью автоматизированное развертывание без вмешательства администратора.

Интеграция с подсистемой виртуализации#

Поддерживать работу с API подсистемы виртуализации для:

  • публикации образов в магазине приложений;

  • управления конфигурацией сервисов;

  • обновления существующих конфигураций.

Обновление и масштабирование#

Иметь возможность динамического изменения параметров конфигурации и добавления узлов:

  • горизонтальное масштабирование кластера;

  • подключение новых узлов без простоя системы.

Нефункциональные характеристики#

Совместимость:

  • совместимость с гипервизорами, поддерживаемыми подсистемой виртуализации (KVM);

  • образы ВМ должны быть доступны в формате Qcow2, или другом совместимом формате.

Безопасность:

  • использование защищенных каналов связи между узлами (TLS/SSL);

  • шифрование передаваемых данных (например, паролей);

  • ограничение доступа через брандмауэр.

Масштабируемость:

  • возможность изменения числа узлов в кластере без простоя;

  • поддержка горизонтального масштабирования.

Требования к разработке#

Образы:

  • базовый образ операционной системы (например, ALSE, Ubuntu, CentOS);

  • установка всех зависимостей для PaaS-сервиса (например, PostgreSQL, Nginx, Redis);

  • установка пакета opennebula-context для поддержки контекстуализации.

Шаблоны ВМ:

  • создание шаблонов для каждой конфигурации;

  • настройка в шаблонах всех необходимых параметров контекстуализации.

Скрипты автоматической настройки:

  • разработка скриптов для настройки ролей узлов и их взаимодействия;

  • скрипты должны автоматически:

    • инициализировать базовые компоненты;

    • настраивать подключение между узлами;

    • применять параметры контекстуализации.

Рекомендации по реализации#

Подготовка образов#

Для подготовки Шаблона ВМ для PaaS-сервиса минимально необходимо иметь подготовленные ISO-образы, с установленной ОС, настроенными зависимостями и установленным пакетом opennebula-context для работы контекстуализации. Образ должен быть загружен в подсистему виртуализации.

Предварительно подготавливаемый образ можно по необходимости модифицировать, например, при помощи утилиты virt-customize.

Примечание

virt-customize — утилита из пакета libguestfs-tools, позволяющая автоматизировать модификацию образов Qcow2. Она дает возможность устанавливать пакеты, копировать файлы, изменять конфигурацию и многое другое, не запуская виртуальную машину.

Работа с контекстуализацией#

В подсистеме виртуализации применяется метод :tef:`контекстуализации <ru_3.6.1_contextualization>` для отправки информации на ВМ во время загрузки. Эти настройки передаются в виде контекстного ISO-образа, который монтируется внутри ВМ при запуске. Скрипты контекстуализации обрабатывают этот ISO, применяют настройки и выполняют необходимые действия.

Контекстуализация позволяет:

  • конфигурировать параметры сети и имени гостевой ВМ;

  • настраивать учетные данные пользователя для доступа к ВМ;

  • определять часовой пояс систем;

  • изменять размер разделов диска по мере необходимости;

  • выполнять индивидуальные сценарии во время загрузки.

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

Работа контекстуализации:

../_images/paas_re_1.png

На схеме отображены следующие этапы:

  1. Создание ВМ из шаблона — при создании ВМ из шаблона подсистема виртуализации использует настройки из блока CONTEXT.

  2. Генерация контекстного ISO — на этапе запуска ВМ создается временный ISO-образ с указанными переменными контекстуализации (например, IP-адреса, SSH-ключи, скрипты).

  3. Передача ISO в ВМ — временный ISO-образ передается как виртуальный CD-ROM в виртуальную машину.

  4. Монтирование ISO-образа внутри ВМ — внутри ВМ система автоматически монтирует ISO-образ, обычно в директорию /mnt или /media.

  5. Запуск скриптов контекстуализации — скрипты, предоставленные в пакете opennebula-context, обрабатывают данные из контекстного ISO (настраивают сеть, добавляют SSH-ключи и запускают пользовательские команды и скрипты).

  6. Применение настроек — настраиваются параметры сети, hostname и выполняются команды из скриптов.

  7. Логирование ошибок — если скрипты завершаются с ошибкой, то журнал записывается в /var/log/one-context.log.

  8. Готовность системы — после завершения контекстуализации, ВМ становится доступной с настроенными параметрами.

Обработка ошибок в процессе контекстуализации#

В случае возникновения ошибок в процессе контекстуализации подсистема виртуализации записывает их в файл внутри ВМ (/var/log/one-context.log или /var/log/messages). Ошибки могут быть связаны с:

  1. Неправильными настройками в разделе CONTEXT.

  2. Проблемами с монтированием контекстного ISO.

  3. Ошибками в пользовательских скриптах.

Примечание

Примеры ошибок:

  • ошибка сети:

Failed to configure network: eth0 does not exist

  • ошибка пользовательского скрипта:

/var/lib/one-context/custom-script.sh: line 10: unexpected token

Для устранения ошибок:

  1. Проверить настройки в разделе CONTEXT шаблона ВМ.

  2. Тестировать пользовательские скрипты локально перед их добавлением.

Создание и управление сложными сервисами и приложениями с помощью OneFlow и OneGate#

OneGate и OneFlow — это службы подсистемы виртуализации, которые помогают управлять сложными сервисами и приложениями, обеспечивая поддержку динамических взаимодействий между компонентами, автоматизацию и масштабирование. Они играют ключевую роль в обеспечении высокоуровневой оркестрации в подсистеме виртуализации.

OneFlow#

Служба OneFlow осуществляет управление сервисом, реализованным в виде многозвенного (multi-tier) приложения. Каждое звено (tier) представляет собой приложение, функционирующее на отдельной ВМ.

Кроме того, службой OneFlow обеспечивается автоматическая перенастройка сервиса в соответствии с заданными правилами (политикой эластичности). Под перенастройкой сервиса подразумевается автоматическое изменение состояния виртуальных машин, логически объединенных в сервис (остановка, запуск, перезапуск и т.д.), а также автоматическое изменение количества виртуальных машин с заданной ролью.

Основные возможности OneFlow:

  1. Оркестрация многосоставных приложений:

  • управление запуском, остановкой, масштабированием и удалением многосоставных приложений;

  • определение ролей (например, frontend, backend, database) и зависимости между ними.

  1. Динамическое масштабирование:

  • добавление или удаление узлов в зависимости от нагрузки;

  • поддержка горизонтального масштабирования.

  1. Жизненный цикл сервиса:

  • управление стартом/остановкой групп узлов согласно определенным правилам;

  • создание сложных сценариев автоматизации.

  1. Шаблоны ролей (Role Templates):

  • каждая роль может использовать собственный шаблон ВМ с определенной конфигурацией.

Использование OneFlow при разработке сервисов дает следующие преимущества:

  • упрощенное управление — сервисы можно разворачивать как целостные единицы с четкими зависимостями;

  • повышенная отказоустойчивость — при сбое одной из ролей OneFlow может инициировать восстановление или перенаправить трафик;

  • легкость масштабирования — например, можно автоматически добавить несколько backend-узлов при увеличении нагрузки.

OneGate#

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

В подсистеме виртуализации служба сервера OneGate используется для обмена служебными данными между виртуальными машинами, логически объединенными в сервис. Таким образом обеспечивается автоматическая перенастройка сервиса в соответствии с заданными правилами.

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

Основные возможности OneGate:

  1. Мониторинг и передача метрик — ВМ могут отправлять данные (например, нагрузку ЦПУ, состояние приложений) в подсистему виртуализации через OneGate.

  2. Управление статусом — ВМ могут сообщать о своем статусе (например, READY, ERROR) для синхронизации с OneFlow.

  3. Обратная связь с OneFlow — OneGate позволяет ВМ взаимодействовать с сервисами OneFlow, например, инициировать события или сообщать о необходимости масштабирования.

Использование OneGate при разработке сервисов дает следующие преимущества:

  • динамическая адаптация — ВМ могут взаимодействовать с OneFlow, предоставляя актуальные данные для принятия решений о масштабировании;

  • повышенная информативность — обеспечивается обратная связь о состоянии приложений на уровне ВМ;

  • упрощение интеграции — через OneGate ВМ могут легко взаимодействовать с внешними системами, отправляя свои метрики и получая команды.

Взаимодействие OneFlow и OneGate#

  • OneFlow управляет жизненным циклом сервиса: создает, масштабирует и удаляет группы виртуальных машин.

  • OneGate предоставляет виртуальным машинам возможность передавать свои метрики, отправлять пользовательские переменные и получать команды для изменения состояния.

Пример сценария:

  1. OneFlow запускает сервис — создает группы ВМ для frontend, backend и базы данных.

  2. OneGate мониторит состояние — каждая ВМ отправляет текущие данные о своей нагрузке, состоянии, и данные переданные в рамках работы пользовательских скриптов.

  3. Масштабирование — OneFlow принимает решение о масштабировании backend-узлов на основе данных, полученных от OneGate.

Преимущества для работы сервисов:

  1. Автоматизация сложных сервисов — упрощается управление многосоставными приложениями с зависимостями.

  2. Масштабируемость — динамическое добавление или удаление узлов без прерывания работы сервиса.

  3. Повышение устойчивости — возможность реагировать на сбои компонентов в режиме реального времени.

  4. Интеграция — простая настройка обратной связи между ВМ и платформой.

Сравнение простых сервисов, основанных на контекстуализации и сложных сервисов управляемых OneFlow и OneGate#

При запуске простого сервиса, основанного на Qcow2-образах с использованием параметров контекстуализации, модули OneGate и OneFlow обычно не задействуются автоматически.

Это происходит по следующим причинам:

  1. Контекстуализация:

  • контекстуализация подсистемы виртуализации работает на уровне передачи заранее определенных параметров (например, IP-адресов, SSH-ключей, ролей) через ISO-образ, который монтируется в виртуальной машине при старте;

  • этот процесс не требует участия OneFlow или OneGate, так как все параметры уже статически определены в шаблоне ВМ (CONTEXT).

  1. OneFlow:

  • OneFlow используется, если требуется развернуть многосоставной сервис, состоящий из нескольких связанных виртуальных машин с четкими зависимостями между ними;

  • при простом развертывании одной ВМ или даже нескольких ВМ без необходимости управления их связями или сложного жизненного цикла, OneFlow не используется.

  1. OneGate:

  • OneGate применяется только если ВМ или приложение внутри нее должны динамически взаимодействовать с подсистемой виртуализации;

  • в простых сервисах, где ВМ просто запускаются с базовыми параметрами (например, IP-адреса и скрипты настройки), OneGate не нужен.

OneGate и OneFlow задействуются в следующих случаях:

  1. Используется OneFlow для управления сервисом — например, создается шаблон сервиса в OneFlow, который управляет ролями (Frontend, Backend) и обеспечивает последовательное развертывание, балансировку нагрузки или отказоустойчивость.

  2. Динамическое взаимодействие через OneGate:

  • ВМ отправляют в подсистему виртуализации метрики нагрузки (например, использование ЦПУ);

  • сервис должен масштабироваться в ответ на определенные события, переданные через OneGate.

Сравнение контекстуализации и OneFlow + OneGate:

Характеристика

Контекстуализация

OneFlow + OneGate

Интерактивность

Нет: ВМ просто получает параметры из контекста

Да: ВМ взаимодействует с подсистемой виртуализации через OneGate API

Поддержка зависимостей

Нет

Да: роли и зависимости между компонентами описаны в OneFlow

Масштабирование

Статическое (указано в шаблоне)

Динамическое (решение принимает OneFlow)

Назначение

Передача статических параметров при старте ВМ

Динамическое управление сервисами и взаимодействие между ВМ

Пример

Один сервер с Nginx

Кластер Frontend и Backend с динамическим масштабированием

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

Простое развертывание ВМ, настройка через скрипты

Сложные приложения с балансировкой нагрузки, кластеры

Для простых сервисов, построенных на Qcow2-образах и статической контекстуализации, OneGate и OneFlow не нужны.

При необходимости автоматического масштабирования сервисов, оркестрации сложных приложений и реагирования на метрики или события в реальном времени следует использовать OneFlow и OneGate.

API для работы с OneGate и OneFlow#

В подсистеме виртуализации используется XML-RPC API для управления базовыми объектами: ВМ, шаблоны, сети, образы, пользователи и др. OneFlow, отвечающий за оркестрацию многокомпонентных сервисов, управляется через REST API и CLI (oneflow-template, oneflow).

Сравнение XML-RPC API и OneFlow REST API

Подход

Одиночная ВМ с контектстуализацией

Сервис = набор ролей (frontend, backend, db)

Зависимости

Не поддерживаются

Явно задаются в шаблоне

Масштабирование

Вручную

Автоматическое (политика эластичности)

Мониторинг

Ограниченный

Через OneGate с отправкой метрик

Самоочистка

Нет

есть (undeploy, recover)

API

XML-RPC

REST API OneFlow / CLI

Пример XML-RPC методов:

  • one.vm.allocate, one.vm.deploy, one.vm.info — управление виртуальными машинами;

  • one.template.allocate, one.template.info — управление шаблонами ВМ.

API реализован через стандартный XML-RPC, что позволяет интегрировать его с любыми языками программирования.

Описание методов API в подсистеме виртуализации.

OneFlow REST API#

OneFlow API используется для управления сервисами и их ролями.

Основные возможности:

  • создание, изменение и удаление сервисов;

  • запрос информации о сервисах, их статусе и составе;

  • масштабирование ролей (добавление или удаление ВМ).

REST-интерфейс для:

  • управления шаблонами сервисов;

  • запуска, масштабирования, удаления сервисов.

Примеры запросов:

  • GET /service — список сервисов;

  • GET /service_template — список шаблонов;

  • POST /service_template/{id}/action {"action": {"perform": "instantiate"}} — создать шаблон;

  • DELETE /service/{id} — удалить сервис.

Документация:

OneGate REST API#

Основные возможности:

  • сбор и отправка метрик в OneGate;

  • взаимодействие между ролями сервиса (через GET /service);

  • самомасштабирование ролей изнутри ВМ;

  • самостоятельный resched или terminate ВМ из ВМ (при наличии корректного токена).

REST-интерфейс внутри ВМ для:

  • обмена метриками;

  • получения параметров ВМ и сервиса;

  • инициирования масштабирования или перезапуска ВМ.

Заголовки:

  • X-ONEGATE-TOKEN;

  • X-ONEGATE-VMID.

Примеры запросов:

  • PUT /vm — отправка метрик;

  • GET /service — информация о всем сервисе;

  • PUT /service/{ID}/scale — масштабирование ролей;

  • POST /vms/{VMID}/action — действия с ВМ.

Документация:

Сценарии использования OneGate API:

  1. Сбор и отправка метрик в OneGate.

  2. Взаимодействие между ролями сервиса (через GET /service).

  3. Самомасштабирование ролей изнутри ВМ.

  4. Самостоятельный resched или terminate ВМ из ВМ (при наличии корректного токена).

Примеры реализации#

Ниже приведены примеры шагов создания различных сервисов с применением приведенных рекомендаций.

Развертывание веб-приложения в подсистеме виртуализации#

В этом примере показан процесс создания и автоматического развертыванию простого веб-приложения в подсистеме виртуализации.

При развертывании учитывались следующие требования:

  • обязательные:

    • виртуальная машина с Astra Linux, подготовленная для автоматической контекстуализации;

    • веб-сервер (Nginx), автоматически устанавливаемый при запуске ВМ;

    • простой веб-сайт (с текстом «Welcome to Web Server»);

    • автоматическое получение внутреннего IP-адреса через DHCP;

  • желательные:

    • возможность привязки публичного IP-адреса;

    • поддержка автоматической настройки межсетевого экрана для доступа извне;

  • дополнительные:

    • автоматическая настройка HTTPS (например, с Let’s Encrypt).

Архитектура процесса#

Процесс состоит из следующих этапов:

  1. Подготовка базового образа с ОС Astra Linux.

  2. Создание шаблона ВМ с поддержкой контекстуализации.

  3. Автоматическое развертывание веб-сервера и веб-приложения.

  4. Настройка сети для внутреннего и внешнего доступа.

Диаграмма процесса:

../_images/paas_re_2.png

Шаги реализации#

  1. Создать образ с ОС Astra Linux.

  2. Загрузить его в хранилище подсистемы виртуализации.

  3. Создать шаблон ВМ с необходимыми параметрами контекстуализации.

Примечание

В данном примере:

CONTEXT = [
NETWORK = "YES",
SSH_PUBLIC_KEY = "$USER[SSH_PUBLIC_KEY]",
START_SCRIPT = "path/to/nginx-setup.sh"
]

Где используемый скрипт nginx-setup.sh:

bash #!/bin/bash
# Обновление системы
echo "Updating system..." apt update && apt upgrade -y

# Установка Nginx
echo "Installing Nginx..." apt install -y nginx

# Настройка веб-приложения
echo "Deploying web application..."
echo "<h1>Welcome to Web Server</h1>" > /var/www/html/index.html

# Перезапуск веб-сервера echo "Restarting Nginx..." systemctl restart nginx

# Завершение
echo "Setup complete. Web server is ready."

  1. Развернуть виртуальную машину, используя шаблон.

  2. Проверить доступ к веб-сервису по внутреннему IP-адресу.

Примечание

Если необходим внешний доступ:

  • привязать публичный IP-адрес в веб-интерфейсе подсистемы виртуализации;

  • настроить межсетевой экран для разрешения входящих соединений.

Развертывание сервиса с использованием готового Qcow2-образа#

В этом примере показан процесс развертывания веб-сервиса в подсистеме виртуализации с использованием готового образа Qcow2. Предполагается, что образ уже загружен и содержит установленную ОС Astra Linux.

При развертывании учитывались следующие требования:

  • обязательные:

    • готовый базовый образ в формате Qcow2 с ОС Astra Linux;

    • настроенный шаблон ВМ с параметрами контекстуализации;

    • автоматическая установка веб-сервера (Nginx) и простого веб-приложения;

  • желательные:

    • возможность привязки публичного IP-адреса;

    • настройка межсетевого экрана для разрешения доступа по HTTP и SSH;

  • дополнительные:

    • автоматическая настройка HTTPS (например, с Let’s Encrypt);

    • поддержка автоматического масштабирования.

Архитектура процесса#

Процесс состоит из следующих этапов:

  1. Импорт образа Qcow2 в подсистеме виртуализации.

  2. Создание шаблона ВМ.

  3. Настройка автоматической контекстуализации.

  4. Развертывание и проверка веб-сервиса.

  5. Настройка публичного доступа (при необходимости).

Диаграмма процесса:

../_images/paas_re_3.png

Шаги реализации#

  1. Импортировать Qcow2-образ с ОС Astra Linux в подсистему виртуализации.

  2. Создать шаблон ВМ с необходимыми параметрами контекстуализации.

Примечание

В данном примере:

CONTEXT = [
NETWORK = "YES",
SSH_PUBLIC_KEY = "$USER[SSH_PUBLIC_KEY]",
START_SCRIPT = "path/to/nginx-setup.sh"
]

Где используемый скрипт nginx-setup.sh:

bash #!/bin/bash
# Обновление системы
echo "Updating system..." apt update && apt upgrade -y

# Установка Nginx
echo "Installing Nginx..." apt install -y nginx

# Настройка веб-приложения
echo "Deploying web application..."
echo "<h1>Welcome to Web Server</h1>" > /var/www/html/index.html

# Перезапуск веб-сервера echo "Restarting Nginx..." systemctl restart nginx

# Завершение
echo "Setup complete. Web server is ready."

  1. Развернуть виртуальную машину, используя шаблон.

  2. Проверить доступ к веб-сервису по внутреннему IP-адресу.

Примечание

Если необходим внешний доступ:

  • привязать публичный IP-адрес в веб-интерфейсе подсистемы виртуализации;

  • настроить межсетевой экран для разрешения входящих соединений.

Настройка кластера PostgreSQL из 2-х узлов в подсистеме виртуализации#

В этом примере описан процесс создания двухузлового кластера PostgreSQL, развернутого в подсистеме виртуализации. Для подготовки образа используется утилита virt-customize, а динамические IP-адреса, выдаваемые подсистемой виртуализации, конфигурируются через автоматическую контекстуализацию.

При развертывании учитывались следующие требования:

  • обязательные:

    • два узла PostgreSQL (Primary и Replica);

    • использование динамически назначаемых IP-адресов;

    • автоматическая настройка кластера при старте;

  • желательные:

    • репликация на уровне базы данных (PostgreSQL Streaming Replication);

    • логирование ошибок в процессе настройки.

Архитектура процесса#

  1. Используются два подготовленных образа с ОС Astra Linux.

  2. Образы модифицируются с помощью virt-customize для установки PostgreSQL.

  3. Виртуальные машины получают IP через DHCP подсистемы виртуализации.

  4. Автоматическая контекстуализация передает IP-адреса между узлами для настройки репликации.

Шаги реализации#

  1. Подготовка базового образа с ОС Astra Linux, PostgreSQL и скриптами настройки.

Примечание

Примеры скриптов.

Скрипт для Primary узла primary-setup.sh:

bash #!/bin/bash
# Установка параметров PostgreSQL
echo "Configuring PostgreSQL as Primary..."
cat >> /etc/postgresql/13/main/postgresql.conf <<EOF listen_addresses = '*'
wal_level = replica max_wal_senders = 10 wal_keep_size = 64MB EOF

cat >> /etc/postgresql/13/main/pg_hba.conf <<EOF host replication all 0.0.0.0/0 trust
EOF

# Перезапуск PostgreSQL systemctl restart postgresql echo "Primary node configured."

Скрипт для Replica узла replica-setup.sh:

bash #!/bin/bash
# Получение IP Primary из контекста
PRIMARY_IP=$(cat /mnt/context.sh | grep PRIMARY_IP | cut -d'=' -f2)

# Настройка PostgreSQL как Replica
echo "Configuring PostgreSQL as Replica..."
pg_basebackup -h $PRIMARY_IP -D /var/lib/postgresql/13/main -P -U postgres --wal-method=stream

cat >> /etc/postgresql/13/main/postgresql.conf <<EOF standby_mode = 'on'
primary_conninfo = 'host=$PRIMARY_IP user=postgres' EOF

# Перезапуск PostgreSQL systemctl restart postgresql echo "Replica node configured."

  1. Создание двух шаблонов ВМ (Primary и Replica) с использованием контекстуализации.

Примечание

Примеры шаблонов.

Шаблон ВМ для Primary узла:

CONTEXT = [ NETWORK = "YES",
SSH_PUBLIC_KEY = "$USER[SSH_PUBLIC_KEY]",
START_SCRIPT = "bash /root/primary-setup.sh",
SET_HOSTNAME = "postgresql-primary"
]

Шаблон ВМ для Replica узла:

CONTEXT = [ NETWORK = "YES",
SSH_PUBLIC_KEY = "$USER[SSH_PUBLIC_KEY]",
START_SCRIPT = "bash /root/replica-setup.sh",
SET_HOSTNAME = "postgresql-replica",
PRIMARY_IP = "$VM[IP, VM_NAME='postgresql-primary']"
]

  1. Запуск виртуальных машин и проверка настройки кластера.

Пример реализации веб-приложения с тремя ролями (Frontend, App (Backend), Database)#

Архитектура процесса#

  • Frontend — веб-сервер Nginx;

  • App (Backend) — микрофреймворк Flask:

  • Database — система управления базами данных PostgreSQL;

  • Зависимости ролей — Frontend → App → Database.

Шаги реализации#

  1. Создание шаблонов ВМ.

  2. Настройка контекстуализации (REPORT_READY, TOKEN, переменные).

  3. Создание шаблона OneFlow в YAML или JSON.

Примечание

Пример шаблона:

{
  "name": "webapp-brest",
  "deployment": "straight",
  "roles": [
    {
      "name": "frontend",
      "vm_template_id": 101,
      "cardinality": 2
    },
    {
      "name": "app",
      "vm_template": 102,
      "cardinality": 2,
      "parents": ["frontend"]
    },
    {
      "name": "database",
      "vm_template_id": 103,
      "cardinality": 1,
      "parents": ["app"]
    }
  ]
}
Содержание