Контекстные данные
Контекстные данные конфигурации (или «контексты конфигурации») — это мощная функция, позволяющая пользователям определять произвольные данные, применимые к устройствам и виртуальным машинам на основе определённых характеристик. Например, предположим, что вы хотите определить серверы 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) сохраняется.
Локальные контекстные данные
Устройства и виртуальные машины также могут иметь определённые локальные контекстные данные. Этот локальный контекст всегда имеет приоритет над любыми отдельными объектами контекста конфигурации, применимыми к устройству/ВМ. Это полезно в ситуациях, когда нужно указать специфическое отклонение в данных для конкретного объекта.
Внимание
Если вы обнаружите, что регулярно определяете локальные контекстные данные для многих отдельных устройств или виртуальных машин, пользовательские поля могут предложить более эффективное решение.