Справочник

Архитектура Cloudlink
scheme architecture
Список сервисов CloudLINK

  1. Auditor – сервис аудита.

  2. Budget – сервис бюджетов.

  3. Calculator – сервис подсчета расхода.

  4. Checker – сервис проверки параметров продукта.

  5. Feed Service – сервис событий.

  6. IAM – сервис управления организационной структурой и правами доступа.

  7. Order Service – сервис управления заказами.

  8. Portal Back – сервис управления информационными системами и SSH ключами пользователей.

  9. Product Catalog – продуктовый каталог.

  10. References – сервис справочников.

  11. Restriction Service – сервис ограничений.

  12. Resource Manager – сервис организационной структуры.

  13. Tarifficator – сервис расчёта стоимостей продуктов.

  14. State Service – сервис состояний.

  15. Cloudlink Analyze – сервис аналитики.

Создание RPC-модулей

Предварительные требования

Для использования внешнего сервиса или приложения совместно с конструктором Cloudlink:

  1. Разработать rpc-модуль для интеграции с конструктором Cloudlink.

  2. Добавить разработанный модуль в качестве шаблона узла в Конструктор Cloudlink.

  3. Создать граф для продукта.

Разработка RPC-модуля

RPC (Remote Procedure Call) - это протокол или технология для выполнения процедур или функций на другой машине (удаленном сервере),так как если бы они выполнялись локально для своего программного обеспечения. Это позволяет разрабатывать распределенные, масштабируемые приложения, где различные компоненты могут взаимодействовать друг с другом, находясь на разных серверах или в разных сетевых средах.

RPC модуль - это специально разработанный компонент, который действует как посредник между сервисом Cloudlink и внешним сервисом. Он общается с внешним сервисом, используя RPC для вызова удаленных функций или процедур.

RPC-модуль выступает в роли прослойки между системой Cloudlink и сторонним сервисом. RPC-модуль подключается к определённой очереди RabbitMQ внутри Kubernetes (k8s) кластера. После разработки и деплоя модуля его функционал можно интегрировать с Конструктором Cloudlink, позволяя использовать сторонний сервис как узел в графе.

Развертывание RPC-модуля может осуществляться:

  • внутри Kubernetes кластера Cloudlink

    RPC-модуль размещается и работает в том же кластере Kubernetes, где находятся все необходимые сервисы.

    kuber11

  • вне Kubernetes кластера

    RPC-модуль размещается вне кластера Kubernetes. Важно настроить связь с RabbitMQ, State Service и остальными сервисами, которые находятся внутри кластера, для обеспечения корректной работы.

    kuber22
    В качестве Service 1,2,3 может выступать любой компонент инфраструктуры Cloudlink.

Реализация RPC - модулей

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

Основные компоненты:

  1. Adapter

    • Базовый класс для адаптеров.

    • Используется для инициализации, выбора и выполнения методов интерфейса.

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

  2. BaseTaskReceiver

    • Класс для приема и обработки задач.

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

  3. TaskReceiver

    • Расширяет BaseTaskReceiver , интегрируя пользовательские адаптеры.

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

  4. RetryRequestByStatus

    • Декоратор для повторных попыток HTTP-запросов.

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

      Пример использования
      from app.adapter import NovaAdapter
from app.settings import APP_NAME, TASK_EXECUTION_TIMEOUT
from cld_rpc_utils.utils import TaskReceiver
task_receiver = TaskReceiver(NovaAdapter, APP_NAME,
TASK_EXECUTION_TIMEOUT)
task_receiver.get_messages()
Процесс исполнения задачи с помощью данной библиотеки на примере NovaAdapter

  1. Получение Сообщения из RabbitMQ

    TaskReceiver начинает с прослушивания очереди RabbitMQ. Когда появляется новое сообщение (задача), TaskReceiver извлекает его из очереди.

  2. Обработка сообщения

    После получения сообщения TaskReceiver анализирует его содержимое для определения, какой именно задаче оно соответствует. Это включает в себя разбор входных данных и определение необходимых действий.

  3. Инициализация адаптера TaskReceiver инициализирует экземпляр соответствующего адаптера (в вашем случае NovaAdapter ) и передает ему необходимые входные данные и параметры логирования.

  4. Выбор метода интерфейса

    В адаптере NovaAdapter вызывается метод obtain_interface_method() , который определяет, какой метод интерфейса следует использовать на основе входных данных. Это может зависеть от типа действия, указанного в сообщении.

  5. Выполнение задачи

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

  6. Логирование и Обработка Ошибок

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

  7. Возвращение результата

    После выполнения задачи результат возвращается обратно в TaskReceiver. В зависимости от конфигурации, результат может быть отправлен обратно в очередь RabbitMQ или обработан иным образом.

  8. Ожидание следующей задачи

    После обработки задачи TaskReceiver продолжает прослушивание очереди RabbitMQ для получения следующего сообщения.

Примеры использования библиотеки

  1. Создание адаптера

    Адаптер должен наследоваться от базового класса Adapter. Инициализация адаптера включает базовую настройку и подготовку к работе с RPC-модулем.

    Ниже пример инициализации адаптера для Nova Adapter.
    pythonCopy code
# app/adapter.py
from cld_rpc_utils import Adapter
from typing import Union
from logging import Logger, LoggerAdapter
from cld_py_logging.log_extra import ExtraLogger
class NovaAdapter(Adapter):
def __init__(self, inputs: dict, logger: Union[Logger, LoggerAdapter, ExtraLogger]):
super().__init__(inputs, logger)
# Здесь можно инициализировать внутренние переменные и состояние
# Инициализация и настройка для работы с Nova
async def create_nova(self):
# Логика создания Nova
# Другие специфические методы

  2. Инициализация клиента

    Клиент представляет собой компонент, который управляет взаимодействием с внешними сервисами или API. В этом контексте, клиент используется для отправки запросов и получения данных от сервиса AWX.

    Пример кода для AWX Client:
    # rpc-awx/aioawxclient/client.py
import logging
from aiohttp import ClientSession, TCPConnector
from cld_rpc_utils import RetryRequestByStatus
from aioawxclient import api
from .exceptions import AWXException
from .settings import *
from .utils import response_handler
class Client:
_REQUIRED_HEADERS = {"Content-type": "application/json"}

def __init__(self, url: str, port: int, usern
ame: str, password: str, organization_name, api_version="v2", logger=logging):
  self.logger = logger
  self.api_version = api_version
  self.api_root = f"{url}:{port}"
  self.username = username
  self.password = password
  self.organization_name = organization_name
  # Другие начальные настройки
async def __aenter__(self):
# Инициализация асинхронной сессии и аутентификации
# ...
# Другие методы для взаимодействия с AWX API

    Клиент может быть интегрирован с адаптером через метод _init_client . Этот метод позволяет установить соединение с внешним сервисом (в данном случае AWX) и инициализировать все необходимые для работы клиента компоненты.

    Пример интеграции:
    class MyCustomAdapter(Adapter):
def _init_client(self):
self.client = AWXClient(
  RPC_AWX_SETTINGS.awx_api_endpoint,
  RPC_AWX_SETTINGS.awx_api_port,
  RPC_AWX_SETTINGS.awx_username,
  RPC_AWX_SETTINGS.awx_password,
  RPC_AWX_SETTINGS.awx_organization,
logger=self.logger,
)
return self.client
# Дополнительные настройки клиента, если необходимо

    В этом примере MyCustomAdapter инициализирует клиент AWX в методе _init_client . Это обеспечивает разделение логики инициализации адаптера и клиента, делая код более читаемым и поддерживаемым.

  3. Реализация специфических функций

    Реализуйте методы для выполнения конкретных действий, например, создание, обновление или удаление кластера Nova.

    Пример кода:
    async def create_nova(self):
# Логика для создания Nova
async def update_nova(self):
# Логика для обновления Nova
# ... другие методы ...

  4. Интеграция с TaskReceiver

    Используйте TaskReceiver для приема и обработки задач. Инициализируйте его с вашим адаптером ( NovaAdapter ) и настройками приложения.

    Пример кода ( rpc_nova.py ):
    # rpc_nova.py
from app.adapter import NovaAdapter
from cld_rpc_utils.utils import TaskReceiver
from app.settings import APP_NAME, TASK_EXECUTION_TI
MEOUT
task_receiver = TaskReceiver(NovaAdapter, APP_NAME,
TASK_EXECUTION_TIMEOUT)
task_receiver.get_messages()

  5. Обработка задач

    В TaskReceiver реализован метод get_messages() , который начинает прослушивание и обработку входящих сообщений.

  6. Обработка и логирование

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

    Пример кода:
    async def create_nova(self):
self.logger.info("Начало процесса создания Nova...")
# Логика создания
self.logger.info("Завершение процесса создания Nova...")

  7. Взаимодействие с внешними сервисами

    Внедрите логику для взаимодействия с внешними сервисами, такими как базы данных, веб-сервисы или облачные провайдеры, внутри методов вашего адаптера.

    Пример кода:
    async def create_nova(self):
# Вызов внешнего сервиса или API
external_service_result = await some_external_service_call()
# Обработка результатов

Шаблон узла для rpc-модуля

RPC-модуль в к конструктору Cloudlink подключается через настроенный узел в "Шаблонах Узлов". Этот узел обеспечивает связь с нужной очередью RabbitMQ для обработки запросов. Модуль можно развернуть как в Kubernetes, так и в другой среде, главное — обеспечить доступ к очереди RabbitMQ, State Service и остальным сервисам, с которыми ему необходимо работать.

Порядок действий

  1. Перейдите в Перейдите в Конструктор > Шаблоны узлов> нажмите +

  2. Во вкладке Основное укажите следующие параметры:

    • Наименование

    • Код шаблона

    • Описание

    • Название очереди для старта задачи

    • Название очереди для отката

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

    • Время ожидания

    • Тип

      new template1

      Названия очереди для старта и отката задачи должны быть согласованы между разработчиком RPC-модуля и разработчиком продукта или графа. Для предварительного создания очереди, необходимо подключиться к RabbitMQ по ссылке https://rabbitmq.FQDN_Cloudlink/ и выполнить следующие действия:

      1. Перейти во вкладку Queues → найти пункт Add a new queue

      2. В качестве параметра Virtual host выбрать корневой каталог /

      3. Выбрать значение параметра Type из следующих вариантов:

        • Default for virtual host

        • Classic

        • Quorum

        • Stream

      4. Параметр Name должен совпадать с названием очереди в шаблоне.

      5. Указать длительность сохранения очереди в параметре Durability.

      6. При необходимости указать дополнительные параметры в поле Arguments.

        queue1

  3. Во вкладке Параметры укажите входные и выходные параметры, которые вам нужно для работы вашего RPC-модуля

    Указанные параметры передаются в виде сообщения при обмене данными между RPC-модулем и приложением.

    new template2

    Активируйте при необходимости опции, разрешающие переопределение входных и выходных параметров, уровня логирования и приоритет.

    new template3

Созданный шаблон узла может быть использован в графе.

Использование RPC-модуля в качестве узла в графе

Порядок действий

  1. Перейдите в Конструктор > Графы

  2. Нажмите +

  3. В вкладке Общая информация ввести следующие параметры:

    1. Код графа - уникальный символьный идентификатор продукта, может содержать только прописные латинские символы, цифры, нижнее подчеркивание, тире, двоеточие и точку.

    2. Наименование - символьное название продукта

      Код графа, наименование и автор необходимы для идентификации и управления графом в системе.

    3. Тип - указывается один из двух типов acting или creating.

    4. Описание - текстовое поле для указания отличительных особенностей или функционала продукта.

    5. Автор - текстовое поле для указания автора продукта.

    6. При необходимости активировать опции, отрабатывающие в случае некорректного проигрывания графа.

      • Переводить заказ в статус Ошибка

      • Блокировать заказ при ошибке

    grap for new app1

  4. Добавить узлы графа

    1. Перейдите во вкладку Узлы и нажмите кнопку +

    2. Укажите следующие параметры:

      • Название

      • Описание

      • Выберите ранее созданный шаблон узла с RPC-модулей

        grap for new app2

      • Перейдите во вкладку Параметры и укажите необходимые параметры в поле Static data

        Параметры, заданные в поле Static data могут быть использованы во всем графе.

      • Определите входные и выходные переменные в полях Input и Output.

        grap for new app3

      • Задайте дополнительные параметры, касающиеся запуска узла и нажмите Сохранить

        new template4

        Узел будет добавлен в граф.

  5. Настроить параметры заказа графа.

    • Для определения структуры данных и параметров заказа, которые будут отображены, в вкладке Форма заказа опишите структуру в JSON-формате.

      new template5

      В данном примере, создается новый обьект с наименование New app, для которого в форме заказа должны быть заданы поля vars, credentials,net_segment. Поля vars, credentials имеют строковый тип, для задания значений используется шаблон (pattern) содержащий строчные и прописные буквы латинского алфавита и цифры от 0 до 9 ("^$), максимальное количесво символов в данном поле равно 64 ("maxLength": 64), минимальное - 3 ("minLength": 3). Параметр *net_segment имеет тип обьект и позволяет выбирать значения из списка.

    • Для создания пользовательского интерфейса формы заказа используется UI схема.

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

      new template6

      Для полей vars и credentials cвойство ui:widget переопределяет реализацию виджета, используемую для отображения любого поля в иерархии формы. В данном случае свойству присвоено значение "ProductLabelWidget", что в пользовательском интерфейсе будет выглядеть как текстовая метка с названием продукта. Для поля net_segment определено свойство ui:field, которое реализует интерфейс по работе с прикреплением дополнительных полей к объектам и управления ими. В данном случае свойству присвоено значение DirectoryUiListField, что в пользовательском интерфейсе будет выглядеть как поле со списком значений в качестве которых будут выступать имеющиеся на платформе шаблоны.

  6. После задания параметров формы заказов, во вкладке Детализация цены выберите продукт для расчета стоимости и получите детализацию заказа.

  7. Во вкладке Модификаторы можно выбрать тип среды для исполнения графа:

    • dev

    • prod

    • test

Развертывание продукта с использованием AWX

Для создания и развертывания своего продукта может быть использовано ПО централизованного управления плейбуками - AWX.

В качестве продукта выбрана система управления секретами Vault.

Для развертывания собственного продукта на базе конструктора Cloudlink необходимо:

  • Cоздать шаблон в AWX

    1. Для подключения перейдите по ссылке https://awx.FQDN_Cloudlink/

    2. Перейдите во вкладку Templates → нажмите Add → выберите Add job template

      a0

    3. Укажите следующие параметры нового Job template

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

  • Job Type - тип шаблона указать RUN

  • Project - указать имя git-репозитория.

  • Playbook - наименование плейбука, который будет запускать развертывание продукта

    a1

    Репозиторий с плейбуками может быть размещен во встроенном инструменте Gitea или подключен извне.

    Для добавления репозитория перейдите в AWX → откройте вкладку Projects →нажмите Add.

    a2

    Укажите имя (Name), организацию (Organization), тип источника (Source Control Type), URL источника (Source Control URL), имя ветки репозитория (Source Control Branch) и учетные данные для подключения(Source control credential).

    a3

  • Cоздать плейбук

    Рассмотрим на примере плейбука для развертывания продукта Vault.

    Основным файлом для исполнения является файл hashicorp-vault.yaml, указанный в параметре Playbook для шаблона в AWX.

    В данном случае данный файл содержит описание ролей, которые будут исполняться:

    b1

    • Роль configure-load-vars - импортирует параметры для подключения к средам исполнения продукта, которые заданы в виде Credentials в AWX.

      b3

    • Роль hashicorp-vault - собирает информацию о типе ОС (т.е. на базе Debian или RHEL) на базе которой необходимо развернуть Vault и в зависимости от нее запускает задачи по разворачиванию.

      Например если при заказе продукта на базе ОС Alma будет запущена задача task rhel.yaml, в результате выполнения которой будет устанавливает пакет Vault при помощи пакетного менеджера dnf из подключенного репозитория.

      В результате выполнения плейбука необходимо вывести параметры для подключения к развернутому экземпляру Vault - токен, ключ и URL.

      Рекомендуется использовать модуль set_stats.

      b4

      Полученные параметры будут использованы в графе.

      Перед созданием любого продукта автоматически выполняется плейбук fist-logon.yml.

      Содержащий следующие роли:

      1. configure-load-vars - импортирует переменные для подключения к средам исполнения продукта, которые заданы в виде Credentials в AWX

      2. configure-first-logon - проверяет доступность среды для развертывания продукта и добавляет ключи для доступа к виртуальной машине с продуктом.

      3. configure-repositories - настраивает доступ к репозиторию с пакетами для установки, по умолчанию используется встроенный на базе Nexus. При необходимости можно добавить внешний репозиторий.

      4. configure-ntp - настраивает NTP-сервер.

      5. linux_disk - создает дополнительные диски при указании в заказе продукта точки монтирования.

        b2

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

    В качестве встроенного репозитория для пакетов используется Nexus.

  • Создать граф

    p0

    Структура графа будет включать в себя 6 узлов, которые используют встроенные шаблоны или подграфы:

    1. Узел Создать ВМ отвечает за создание виртуальной машины на базе которой будет развернут продукт Vault.

    2. Узел Создаем UUID отвечает за генерацию уникального идентификатора item.

    3. Узел Создаем inventory отвечает за получение параметров.

    4. Узел Настройка ВМ отвечает за выполнение плейбуков по развертыванию Vault на виртуальной машине

    5. Узел Создаем item приложения отвечает за генерацию уникального идентификатора item.

    6. Узел Создаем связь parent-child отвечает за создание формы отображения заказа, в примере с Vault в форме будет отображаться версия Vault, точка подключения, а также Root Token и Unseal Keys развёрнутого Vault.

    7. Перейдите в Конструктор > Графы → Нажмите +

    8. В вкладке Общая информация ввести следующие параметры:

      1. Код графа - уникальный символьный идентификатор продукта, может содержать только прописные латинские символы, цифры, нижнее подчеркивание,тире двоеточие и точку.

      2. Наименование - символьное название продукта

        Код графа,наименование и автор необходимы для идентификации и управления графом в системе.

      3. В параметре Тип выбрать указать creating.

      4. Описание - текстовое поле для указания отличительных особенностей или функционала продукта.

      5. Автор - текстовое поле для указания автора продукта.

      6. При необходимости активировать опции, отрабатывающие в случае некорректного проигрывания графа.

  • Переводить заказ в статус Ошибка

  • Блокировать заказ при ошибке

    p1

    1. Добавить узлы графа

      Для создания узлов будут использоваться стандартные шаблоны.

      1. Перейдите во вкладку Узлы и нажмите кнопку +

      2. В окне Добавление нового узла создайте 1-вый узел со следующими свойствами:

  • Название - create_vm

  • Описание - Создаем ВМ

  • Подграф - create_vm_general

    p2

  • Во вкладке параметры опишите статические данные, которые могу быть использованы во всем графе, входящие и исходящие данные.

    В примере с Vault в качестве статических данных указаны:

    {
  "tenant": {},
  "ssh_keys": [],
  "extra_nics": [],
  "vault_port": "8200",
  "credentials": [
    "Cloud",
    "nexus"
  ],
  "extra_disks": [],
  "job_template": "hashicorp-vault",
  "business_line": "general",
  "vault_version": "1.15.5",
  "os_local_users": [],
  "ntp_server_data": {
    "host": "",
    "port": ""
  },
  "inventory_status": "native",
  "uuidgen_template": "{{ uuidgen() }}",
  "inventory_template": "{% set inventory = {'all': {'hosts': {}, 'vars': {'vault_port': vault_port, 'vault_version': vault_version}}} %}{% set _ = inventory.all.hosts.update({item_config.hostname: {'ansible_host': item_config.default_v4_address, 'machine': item_config}}) %}{% set _ = inventory.all.vars.update({}) %}{{ inventory | tojson }}"
}

    Среди стандартных переменных были указаны переменные для самого Vault, в том числе:

  • vault_port, этот порт в примере используется для WEB UI Vault

  • vault_version, этот параметр используется при загрузке Vault из локального репозитория

    Также в inventory_template в шаблоне Jinja указываются 'vars': {'vault_port': vault_port, 'vault_version': vault_version}. Они будут сохранены во временном инвентарном файле при запуске Job

    Static data могут быть использованы во всем графе и их можно указать 1 раз.

    В качестве входящий данных укажите:

     "name": "name",
  "image": "image",
  "flavor": "flavor",
  "is_code": "is_code",
  "platform": "platform",
  "ssh_keys": "ssh_keys",
  "boot_disk": "boot_disk",
  "data_center": "data_center",
  "default_nic": "default_nic",
  "extra_disks": "extra_disks",
  "extra_mounts": "extra_mounts",
  "business_line": "business_line",
  "resource_pool": "resource_pool",
  "ntp_server_url": "ntp_server_data['host']",
  "os_local_users": "os_local_users",
  "environment_type": "environment_type"

    В качестве исходящий данных укажите:

      "item_id": "item_id",
  "item_config": "item_config"
    p3

    1. Перейдите во вкладку Узлы и нажмите кнопку +

    2. В окне Добавление нового узла создайте 2-ой узел со следующими свойствами:

  • Название - ge_uuid

  • Описание - Создаем UUID

  • Шаблон - jinja2_format

    p4

    В качестве входящий данных укажите:

       "template": "uuidgen_template"

    В качестве исходящий данных укажите:

      "formatted": "app_uuid"

    Static data наследуются из первого узла в графе.

    p5

    1. Перейдите во вкладку Узлы и нажмите кнопку +

    2. В окне Добавление нового узла создайте 3-тий узел со следующими свойствами:

  • Название - make_inventory

  • Описание - Создаем inventory

  • Шаблон - jinja2_format

    p6

    В качестве входящий данных укажите:

       {
  "item_id": "item_id",
  "template": "inventory_template",
  "from_json": "True",
  "vault_port": "vault_port",
  "item_config": "item_config",
  "vault_version": "vault_version"
}

    В данном узле графа мы не указываем значения vault_port и vault_version, а указываем названия самих переменных, так как ранее версия и порт были указаны в статичных данных.

    В качестве исходящий данных укажите:

    {
  "formatted": "inventory"
}

    Static data наследуются из первого узла в графе.

    p7

    1. Перейдите во вкладку Узлы и нажмите кнопку +

    2. В окне Добавление нового узла создайте 4-тый узел со следующими свойствами:

  • Название - configuration_vm

  • Описание - Настройка ВМ

  • Шаблон - ansible_awx

    p8

    В качестве входящий данных укажите:

    {
  "inventory": "inventory",
  "extra_vars": "{'environment_type':environment_type}",
  "vault_port": "vault_port",
  "credentials": "credentials",
  "net_segment": "environment_type",
  "job_template": "job_template",
  "vault_version": "vault_version",
  "environment_type": "environment_type"
}

    В качестве исходящий данных укажите:

    {
  "vault_keys": "vault_keys",
  "vault_token": "vault_token",
  "connection_url": "connection_url"
}

    Важно, что исходящие данные должны совпадать с артефактами запуска Playbook. Для того, чтобы в результате запуска Playbook в AWX остались артефакты, в роли необходимо использовать модуль set_stats. В примере с Vault модуль используется следующим образом:

    - set_stats:
    data:
      vault_token: "{{ vault_init_result.json.root_token }}"
      vault_keys: "{{ vault_init_result.json.keys_base64 }}"
      connection_url: "{{ 'http://' + ansible_host | string + ':' + vault_port | string }}"

    В данном модуле мы устанавливаем в качестве артефактов root_token Vault и unseal_keys, а также указываем составной connection_url. Ключи артефактов (stats), которые вы указываете, должны совпадать с исходящими данными узла графа.

    Static data наследуются из первого узла в графе.

    p10

    1. Перейдите во вкладку Узлы и нажмите кнопку +

    2. В окне Добавление нового узла создайте узел со следующими свойствами:

  • Название - create_app_item

  • Описание - Cоздаем item приложения

  • Подграф - create_item_box

    p8

    Во вкладке Параметры качестве входящий данных укажите:

    {
  "type": "enums.EventType.APP.value",
  "config": "{'connection_url': connection_url, 'vault_version': vault_version, 'vault_token': vault_token, 'vault_keys': vault_keys}",
  "status": "enums.EventState.ON.value",
  "item_id": "app_uuid",
  "provider": "enums.EventProvider.HASHICORP_VAULT.value",
  "environment_type": "environment_type",
  "inventory_status": "inventory_status"
}

    В config мы указываем значения из предыдущих узлов, которые будут использоваться при настройке отображения продукта. Для отображения используются версия, url подключения, а также токен и ключи Vault. В provider указывается провайдер, который был создан в справочнике.

    Исходящие параметры не заполняются.

    Static data наследуются из первого узла в графе.

    p11

    1. Перейдите во вкладку Узлы и нажмите кнопку +

    2. В окне Добавление нового узла создайте узел со следующими свойствами:

  • Название - create_parent_chain

  • Описание - Cоздаем связь parent-child

  • Шаблон - add_event

    p12

    Во вкладке Параметры качестве входящий данных укажите:

    {
  "type": "enums.EventType.VM.value",
  "status": "app_uuid",
  "item_id": "item_id",
  "subtype": "enums.EventSubType.PARENT.value"
}

    Исходящие параметры не заполняются. Static data наследуются из первого узла в графе.

    p13

  • Создать шаблон отображения

    1. Перейдите во вкладку Конструктор → Шаблоны отображения→ нажмите +

    2. Во вкладке Основное задайте следующие параметры:

      • Наименование

      • Код шаблона

      • Состояние

      • Тип

      • Провайдер

        tem ot1

    3. Во вкладке Полное отображение опишите шаблон отображения необходимых вкладок, меток и других элементов в формате JSON.

      tem ot2