[API] YANG — это имя для вождя
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Когда я впервые увидел эти символы, то подумал, что это имя индейского вождя: буква Y напомнила венец из перьев желтокожего вождя из книжек о Диком Западе. И даже произнесение “YANG” вслух произвело такой эффект, что мой далеко не прыткий английский бульдог Бучо вскочил на четыре лапы.
Конечно, YANG это не вождь и не индеец, и не бульдог. Но позвольте мне использовать этих персонажей, чтобы проиллюстрировать что такое YANG, при этом не прибегая к компьютерной терминологии.Когда вождь племени N покинул поутру свой вигвам, Бучо уже поджидал его: вилял хвостом и переминал передними лапами, живот его урчал. Вождь положил перед ним кусок копчёной индейки и сказал “Ешь, дружок”. Бучо принялся уминать свой завтрак. После вождь расположился в кресле рядом со своей хижиной, поглаживая голову бульдога, который довольный устроился в его ногах. Это всё YANG. Точнее, вся эта сцена произошла благодаря YANG, потому что YANG - это шаблон поведения.Другой пример.Умиротворение вождя и Бучо нарушил столб пыли, поднявшийся со стороны холма, за которым проживало другое индейское племя. Группа всадников достигла деревни, они спешились и подошли к вождю. Вождь знал этих людей и знал, что говорят они на разных с ним языках. Один из всадников вышел вперёд и произнёс что-то, чего вождь не понял, но он знал, что любой разговор начинается с приветствия, поэтому он, в свою очередь, тоже произнёс приветствие, но на своём языке. Всадник удовлетворился таким ответом, хотя он не понял что конкретно произнёс вождь, но он знал, что это был ответ на его приветствие, а значит начало диалога состоялось. Это тоже YANG. Потому что YANG - это шаблон языка. В первом примере Бучо знает, что хозяин каждое утро выходит к нему, чтобы покормить. Вождь, в свою очередь, знает, что Бучо ждёт от него еды в это время: что он там у порога его хижины, и что он не притронется к еде, пока он не скажет “Ешь дружок”. И они оба знают, что после будут сидеть вот так у хижины и вождь будет поглаживать Бучо. Это есть модель поведения, которая известна им обоим: определённый согласованный временем и привычкой порядок действий, условный код, если хотите.Во втором примере вождь и всадник находят понимание, хотя говорят на разных языках. Это происходит благодаря тому, что оба используют одну и ту же модель общения, в которой всегда на первом месте - приветствие!Теперь, если идея в её философском смысле ясна, то позвольте начать говорить более конкретно. Приведу ещё один пример уже без наших героев.Мой босс спускается ко мне и говорит: “Дай мне последние номера!”. Он не уточняет ни какие именно номера, ни в каком формате, ни для какого продукта, ничего. Просто без контекста извольте дать ему номера! Вряд ли на такой запрос я смогу ответить или единственным ответом будет: “Ответ невозможен - запрос неясен”.Когда компьютеры общаются друг с другом и отправляют данные туда и обратно, им нужен точный контекст, шаблон или форма для этого обмена. Если мы зайдём на коммутатор и применим команду “display ip int brief”, то мы отправим запрос в понятной для сетевого устройства форме и будем, соответственно, ожидать понятного для нашего восприятия, чтения и интерпретации ответа. В ответе на команду мы увидим некоторые вланы (VLANs) и логические адреса (ip addresses), статус (status) и протокол (protocol). Все они будут упорядочены по столбикам (colums), между столбиками будут пробелы, которые были построены специально для нашего понимания.Что произойдёт, если другой компьютер попытается подключиться к сетевому устройству? Скорей всего, для этой цели он не станет использовать Telnet, а задействует один из протоколов автоматизации сети (network automation protocols), такие как NETCONF или RESTCONF. В первом случае на устройство заходит человек и запрашивает информацию в виде, в котором он сможет прочитать её. Для компьютера данные тоже должны быть выражены в понятной для него форме. Для этого оба устройства должны заранее согласовать порядок (или структурирования) информации, чтобы сделать ее пригодной для обработки. Есть три вполне определенные вещи для согласования. Первое - это протокол (protocol). Он будет использоваться для транспортировки данных через сеть. Когда я подключился к коммутатору и использовал команду “display ip int brief”, то сделал это через протокол Telnet. Но когда компьютер подключается к коммутатору, то он, скорей всего, выберет протоколы RESTCONF, NETCONF или любой другой проприетарный протокол для конкретного производителя или устройства.Второе, что два компьютера должны согласовать между собой - это формат данных (Data format). NETCONF обычно использует XML (Extensible Markup Language), RESTCONF - JSON (JavaScript Object Notation). Тут-то и выступает на сцену модель данных (Data model). Она определяет какая структура данных будет использована.Видите ли... когда компьютер подключается к устройству сети, он имеет весьма определенную причину делать это. Может быть у него Python скрипт, который нацелен на то, чтобы получить лист интерфейсов в статусе “down”. Этот скрипт должен быть понятным для XML или JSON форматов, чтобы собрать точные данные из колонки статус интерфейсов. Так? Но как этот скрипт узнает, где именно искать эти колонки? Модель данных и скажет ему где и какие данные находятся!Давайте посмотрим на это с другой стороны. Вот небольшой JSON файл:
Если вам нужно отправить название модели другому компьютеру, используя JSON как формат, то это структура, скорей всего, будет выбрана вами, как структура по умолчанию. Но если другой компьютер ждет увидеть это в другой структуре, то коммуникации не случится:
Понимания между компьютерами не будет, потому что второй компьютер ожидает другую иерархию данных (структуру), более уточняющую, как вы видите.Поэтому первое, что сделает наш компьютер, соединяясь с сетевым устройством, это обменяется перечнем всех моделей данных, которые ему доступны. Устройство сети отправит свой перечень, после чего мы сможем выбрать какая модель нам интересна и сказать: отправь нам эти данные в этой модели данных или в той модели данных.Важно отметить, что YANG это не соглашение об использовании одного языка. Когда мы отправляем запрос на информацию, это не значит, что хотим увидеть JSON, например. Мы говорим какую именно структуру JSON хотим увидеть, а не сам JSON или XML.Теперь давайте взглянем откуда YANG реально появился (не из индейской резервации, конечно). NETCONG появился где-то в 2006, он был основан на XML. И после нескольких лет его использования возможность разбирать неструктурированные XML данные стало окончательной софистикой. Никто не имел возможности сказать устройству, что нужно использовать определенную структуру, и не мог понять какую структуру использует устройство, пока не получит от него данные. И около 2010 года рабочая группа NETMOD создала YANG, которую заточили специально для работы с NETCONF.Зайдем наhttp://netconfcentral.org/modules/ietf-interfaces, чтобы увидеть YANG модель, созданную для нас IETF. IETF (Internet Engineering Task Force) - это стандартизирующая организация, которая принесла нам много индустриально стандартизированных протоколов (и спасибо им за это!):
Этот документ содержит модуль интерфейсов, он опреде.ляет как данные интерфейсов структурируются. При этом это общий для всех вендоров модуль, то есть его могут использовать сетевые устройства любых производителей.
Модель не определяет каждый отдельный интерфейс, она определяет структуру данных для всех интерфейсов.Например, вот так строится иерархия для:Имени интерфейса (name)
Описания интерфейса (description)
Включен ли интерфейс (enabled) 
Для статуса линка интерфейса
Более подробно об этом лучше поговорить в отдельной статье. Сейчас важнее понять, что сетевые устройства точно так же хранят в себе эти модели данных. И когда мы запрашиваем статистику интерфейса, используя эту стандартизированную модель, то устройство точно знает, что нужно использовать именно эту модель (ietf-interfaces@2018-02-20, например, как в данном случае). Если сетевое устройство поддерживает YANG, то оно точно знает каким путем нужно идти. Красота YANG в том, что это язык шаблона и не только упорядочивает информацию для машин, но и делает ее удобной для интерпретации человеком.
===========
Источник:
habr.com
===========
Похожие новости:
- [JavaScript, Node.JS] Fastify.js — не только самый быстрый веб-фреймворк для node.js
- [Разработка под iOS, Разработка мобильных приложений, API, Браузеры, IT-компании] Инженер Google раскритиковал Apple за торможение развития веб-технологий
- [Программирование, C++, Qt, Геоинформационные сервисы] Создаём плагин Qt GeoServices на примере ОС Аврора, OpenStreetMap и Sight Safari
- [Тестирование IT-систем, API, Тестирование веб-сервисов, Тестирование мобильных приложений] Что такое JSON
- [Flutter] Решение задач позиционирования при просмотре карты во Flutter
- [C, Разработка под Linux, Звук] Анатомия LV2-плагина
- [JavaScript, Google Chrome, API, Google API] Content Indexing API: страницы, доступные в offline. Доклад с RamblerFront #9
- [Flutter] Решение задач позиционирования при просмотре карты во Flutter
- [CMS, Ненормальное программирование, JavaScript, API, Тестирование веб-сервисов] AEM Test Automation — Create Pages via HTTP Requests
- [API] Слабая связность
Теги для поиска: #_api, #_model_dannyh (модель данных), #_restful, #_netconf, #_api
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:06
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Когда я впервые увидел эти символы, то подумал, что это имя индейского вождя: буква Y напомнила венец из перьев желтокожего вождя из книжек о Диком Западе. И даже произнесение “YANG” вслух произвело такой эффект, что мой далеко не прыткий английский бульдог Бучо вскочил на четыре лапы.  Конечно, YANG это не вождь и не индеец, и не бульдог. Но позвольте мне использовать этих персонажей, чтобы проиллюстрировать что такое YANG, при этом не прибегая к компьютерной терминологии.Когда вождь племени N покинул поутру свой вигвам, Бучо уже поджидал его: вилял хвостом и переминал передними лапами, живот его урчал. Вождь положил перед ним кусок копчёной индейки и сказал “Ешь, дружок”. Бучо принялся уминать свой завтрак. После вождь расположился в кресле рядом со своей хижиной, поглаживая голову бульдога, который довольный устроился в его ногах. Это всё YANG. Точнее, вся эта сцена произошла благодаря YANG, потому что YANG - это шаблон поведения.Другой пример.Умиротворение вождя и Бучо нарушил столб пыли, поднявшийся со стороны холма, за которым проживало другое индейское племя. Группа всадников достигла деревни, они спешились и подошли к вождю. Вождь знал этих людей и знал, что говорят они на разных с ним языках. Один из всадников вышел вперёд и произнёс что-то, чего вождь не понял, но он знал, что любой разговор начинается с приветствия, поэтому он, в свою очередь, тоже произнёс приветствие, но на своём языке. Всадник удовлетворился таким ответом, хотя он не понял что конкретно произнёс вождь, но он знал, что это был ответ на его приветствие, а значит начало диалога состоялось. Это тоже YANG. Потому что YANG - это шаблон языка. В первом примере Бучо знает, что хозяин каждое утро выходит к нему, чтобы покормить. Вождь, в свою очередь, знает, что Бучо ждёт от него еды в это время: что он там у порога его хижины, и что он не притронется к еде, пока он не скажет “Ешь дружок”. И они оба знают, что после будут сидеть вот так у хижины и вождь будет поглаживать Бучо. Это есть модель поведения, которая известна им обоим: определённый согласованный временем и привычкой порядок действий, условный код, если хотите.Во втором примере вождь и всадник находят понимание, хотя говорят на разных языках. Это происходит благодаря тому, что оба используют одну и ту же модель общения, в которой всегда на первом месте - приветствие!Теперь, если идея в её философском смысле ясна, то позвольте начать говорить более конкретно. Приведу ещё один пример уже без наших героев.Мой босс спускается ко мне и говорит: “Дай мне последние номера!”. Он не уточняет ни какие именно номера, ни в каком формате, ни для какого продукта, ничего. Просто без контекста извольте дать ему номера! Вряд ли на такой запрос я смогу ответить или единственным ответом будет: “Ответ невозможен - запрос неясен”.Когда компьютеры общаются друг с другом и отправляют данные туда и обратно, им нужен точный контекст, шаблон или форма для этого обмена. Если мы зайдём на коммутатор и применим команду “display ip int brief”, то мы отправим запрос в понятной для сетевого устройства форме и будем, соответственно, ожидать понятного для нашего восприятия, чтения и интерпретации ответа. В ответе на команду мы увидим некоторые вланы (VLANs) и логические адреса (ip addresses), статус (status) и протокол (protocol). Все они будут упорядочены по столбикам (colums), между столбиками будут пробелы, которые были построены специально для нашего понимания.Что произойдёт, если другой компьютер попытается подключиться к сетевому устройству? Скорей всего, для этой цели он не станет использовать Telnet, а задействует один из протоколов автоматизации сети (network automation protocols), такие как NETCONF или RESTCONF. В первом случае на устройство заходит человек и запрашивает информацию в виде, в котором он сможет прочитать её. Для компьютера данные тоже должны быть выражены в понятной для него форме. Для этого оба устройства должны заранее согласовать порядок (или структурирования) информации, чтобы сделать ее пригодной для обработки. Есть три вполне определенные вещи для согласования. Первое - это протокол (protocol). Он будет использоваться для транспортировки данных через сеть. Когда я подключился к коммутатору и использовал команду “display ip int brief”, то сделал это через протокол Telnet. Но когда компьютер подключается к коммутатору, то он, скорей всего, выберет протоколы RESTCONF, NETCONF или любой другой проприетарный протокол для конкретного производителя или устройства.Второе, что два компьютера должны согласовать между собой - это формат данных (Data format). NETCONF обычно использует XML (Extensible Markup Language), RESTCONF - JSON (JavaScript Object Notation). Тут-то и выступает на сцену модель данных (Data model). Она определяет какая структура данных будет использована.Видите ли... когда компьютер подключается к устройству сети, он имеет весьма определенную причину делать это. Может быть у него Python скрипт, который нацелен на то, чтобы получить лист интерфейсов в статусе “down”. Этот скрипт должен быть понятным для XML или JSON форматов, чтобы собрать точные данные из колонки статус интерфейсов. Так? Но как этот скрипт узнает, где именно искать эти колонки? Модель данных и скажет ему где и какие данные находятся!Давайте посмотрим на это с другой стороны. Вот небольшой JSON файл:  Если вам нужно отправить название модели другому компьютеру, используя JSON как формат, то это структура, скорей всего, будет выбрана вами, как структура по умолчанию. Но если другой компьютер ждет увидеть это в другой структуре, то коммуникации не случится:  Понимания между компьютерами не будет, потому что второй компьютер ожидает другую иерархию данных (структуру), более уточняющую, как вы видите.Поэтому первое, что сделает наш компьютер, соединяясь с сетевым устройством, это обменяется перечнем всех моделей данных, которые ему доступны. Устройство сети отправит свой перечень, после чего мы сможем выбрать какая модель нам интересна и сказать: отправь нам эти данные в этой модели данных или в той модели данных.Важно отметить, что YANG это не соглашение об использовании одного языка. Когда мы отправляем запрос на информацию, это не значит, что хотим увидеть JSON, например. Мы говорим какую именно структуру JSON хотим увидеть, а не сам JSON или XML.Теперь давайте взглянем откуда YANG реально появился (не из индейской резервации, конечно). NETCONG появился где-то в 2006, он был основан на XML. И после нескольких лет его использования возможность разбирать неструктурированные XML данные стало окончательной софистикой. Никто не имел возможности сказать устройству, что нужно использовать определенную структуру, и не мог понять какую структуру использует устройство, пока не получит от него данные. И около 2010 года рабочая группа NETMOD создала YANG, которую заточили специально для работы с NETCONF.Зайдем наhttp://netconfcentral.org/modules/ietf-interfaces, чтобы увидеть YANG модель, созданную для нас IETF. IETF (Internet Engineering Task Force) - это стандартизирующая организация, которая принесла нам много индустриально стандартизированных протоколов (и спасибо им за это!):  Этот документ содержит модуль интерфейсов, он опреде.ляет как данные интерфейсов структурируются. При этом это общий для всех вендоров модуль, то есть его могут использовать сетевые устройства любых производителей.  Модель не определяет каждый отдельный интерфейс, она определяет структуру данных для всех интерфейсов.Например, вот так строится иерархия для:Имени интерфейса (name)  Описания интерфейса (description)  Включен ли интерфейс (enabled)  Для статуса линка интерфейса  Более подробно об этом лучше поговорить в отдельной статье. Сейчас важнее понять, что сетевые устройства точно так же хранят в себе эти модели данных. И когда мы запрашиваем статистику интерфейса, используя эту стандартизированную модель, то устройство точно знает, что нужно использовать именно эту модель (ietf-interfaces@2018-02-20, например, как в данном случае). Если сетевое устройство поддерживает YANG, то оно точно знает каким путем нужно идти. Красота YANG в том, что это язык шаблона и не только упорядочивает информацию для машин, но и делает ее удобной для интерпретации человеком. =========== Источник: habr.com =========== Похожие новости:
|
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 08:06
Часовой пояс: UTC + 5