Перейти к содержанию

Контекстные данные

Контекстные данные конфигурации (или «контексты конфигурации») — это мощная функция, позволяющая пользователям определять произвольные данные, применимые к устройствам и виртуальным машинам на основе определённых характеристик. Например, предположим, что вы хотите определить серверы syslog для устройств, назначенных площадкам в определённом регионе. В InfraVision вы можете создать экземпляр контекста конфигурации, содержащий эти данные, и применить его к нужному региону. Все устройства в этом регионе теперь будут включать эти данные при получении через API.

{
    "syslog-servers": [
        "192.168.43.107",
        "192.168.48.112"
    ]
}

Контекстные данные могут потребляться удалёнными API-клиентами или использоваться нативно для рендеринга шаблонов конфигурации.

Контексты конфигурации могут вычисляться для объектов на основе следующих критериев:

Тип Устройства Виртуальные машины
Регион
Группа площадок
Площадка
Местоположение
Тип устройства
Роль
Платформа
Тип кластера
Группа кластеров
Кластер
Группа арендаторов
Арендатор
Тег

Нет ограничений на то, какие данные могут храниться в контексте конфигурации, если они могут быть выражены в JSON.

Иерархический рендеринг

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

Например, предположим, мы хотим указать набор серверов syslog и NTP для всех устройств в регионе. Мы могли бы создать экземпляр контекста конфигурации с весом 1000, назначенный региону, со следующими JSON-данными:

{
    "ntp-servers": [
        "172.16.10.22",
        "172.16.10.33"
    ],
    "syslog-servers": [
        "172.16.9.100",
        "172.16.9.101"
    ]
}

Но предположим, что на одной конкретной площадке в этом регионе есть проблема, препятствующая достижению трафиком регионального сервера syslog. Устройствам там нужно использовать локальный сервер syslog вместо двух определённых выше. Мы создадим второй контекст конфигурации, назначенный только этой площадке, с весом 2000 и следующими данными:

{
    "syslog-servers": [
        "192.168.43.107"
    ]
}

Когда контекстные данные для устройства на этой площадке рендерятся, второй контекст с более высоким весом перезаписывает первый, в результате чего получается:

{
    "ntp-servers": [
        "172.16.10.22",
        "172.16.10.33"
    ],
    "syslog-servers": [
        "192.168.43.107"
    ]
}

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

Локальные контекстные данные

Устройства и виртуальные машины также могут иметь определённые локальные контекстные данные. Этот локальный контекст всегда имеет приоритет над любыми отдельными объектами контекста конфигурации, применимыми к устройству/ВМ. Это полезно в ситуациях, когда нужно указать специфическое отклонение в данных для конкретного объекта.

Внимание

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