Terminologia NetDevOps – prezentacja danych

Spis treści

Choć (Net)DevOps jest już pojęciem relatywnie dojrzałym, to dla wielu inżynierów sieciowych odnalezienie się w terminologi z nim związanej stanowi pewnego rodzaju wyzwanie. Zanim przejdziemy do bardziej zaawansowanych tematów, warto sobie usystematyzować i pogrupować kilka z kluczowych pojęć. W kolejnych artykułach przybliżę w skrócie te komponenty, z którymi będziemy spotykali się najczęściej na początku naszej przygody z automatyzacją. Każdy z nich zostanie zaprezentowany szerzej przy okazji omawiania związanych z nimi narzędzi.

Na początek zerknijmy na sposoby prezentacji danych. Powstały on głównie w celu zapisu informacji w sposób ustrukturyzowany i zrozumiały dla maszyn oraz języków programowania, a jednocześnie (w miarę) czytelny dla ludzi. Na przełomie lat powstało i rozwinęło się kilka z nich. Najczęściej spotykane (w świecie sieciowym) opisane zostały poniżej.

XML

XML (eXtensible Markup Language) to format zapisu danych, o strukturze bardzo podobnej do znanego nam HTMLa. Główna różnica jest taka, że HTML ma ściśle określony zestaw TAGów („nawiasów” definiujących typ danych, wraz z zawartymi w nich parametrów), a w XMLu to my sami tworzymy sobie TAGi, wraz z całą ich strukturą. Jest on najbardziej rozpowszechniony i dojrzały. Wykorzystywany jest między innymi do prezentowania danych pobieranych i wysyłanych do urządzeń, np. za pomocą API (REST, SOAP). Niektóre systemy i aplikacje przechowują też konfigurację w tym formacie. Wiele języków programowania (w tym Python) ma odpowiednie biblioteki do jego obsługi.

Strukturę XML bardzo łatwo przedstawić na przykładzie, jeżeli mamy dostęp np. do przełączników Cisco Nexus. Wystarczy sformatować wynik polecenia show poprzez przekierowanie go do silnika xml (wynik skrócony dla przejrzystości).

N5K-1# show interface ethernet 1/1 | xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<nf:rpc-reply xmlns:nf="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="http://www.cisco.com/nxos:7.3.0.N1.1.:if_manager">
 <nf:data>
  <show>
        <interface>Ethernet1/1</interface>
        <state>up</state>
        <eth_bundle>Po1</eth_bundle>
        <desc>Peer Link do N5K-2</desc>
        <eth_mtu>1500</eth_mtu>
        <eth_inbytes>216320698426</eth_inbytes>
        <eth_outbytes>111864553698</eth_outbytes>
  </show>
 </nf:data>
</nf:rpc-reply>

Więcej informacji:

JSON

JSON (JavaScript Object Notation), tak jak XML, wykorzystywany jest między innymi do prezentowania danych pobieranych za pomocą API (REST, SOAP). Pomimo tego, że związany jest natywnie z językiem JavaScript, obsługiwany jest przez wszystkie inne języki programowania. Zyskuje on coraz bardziej na popularności, ze względu na większą przejrzystość niż XML. Sposób zapisu przypomina trochę składnię języka C (klamerki), a same dane przedstawiane są w postaci (często zagnieżdżonych) słowników typu nazwa:wartość.

Strukturę JSON, podobnie jak XML, można przedstawić, parsując to samo polecenie, ale przekierowując je do silnika json (wynik skrócony dla przejrzystości).

N5K-1# show interface ethernet 1/1 | json 
{
      "interface": "Ethernet1/1", 
      "state": "up", 
      "eth_bundle": "Po1", 
      "desc": " Peer Link do N5K-2", 
      "eth_mtu": "1500", 
      "eth_inbytes": 216320566099, 
      "eth_outbytes": 111864511158
}

Dzięki formatowaniu XML i JSON mamy możliwość przetwarzania wyników poleceń (wydawanych z CLI lub za pomocą API) w sposób zunifikowany, bez konieczności parsowania surowego tekstu, co do tej pory często robiliśmy i co często było nie lada wyzwaniem (uwzględnianie spacji i tabulacji, formatowanie kolumn, ryzyko zmiany wyglądu po aktualizacji oprogramowania, itp.). Zestaw TAGów (XML), słowników (JSON) i ich parametrów jest z reguły ustandaryzowany przez każdego producenta, dla danego typu urządzeń. Po aktualizacji oprogramowania zostaje on w co najmniej takiej formie jak poprzednio, a dodanie nowych TAGów lub ich parametrów nie wpływa na działanie obecnych skryptów.

Więcej informacji:

YAML

YAML (YAML Ain’t Markup Language) został stworzony głównie do modelowania danych wsadowych i konfiguracyjnych (jest to główny składnik systemu Ansible). Zaletą YAMLa jest niesamowita przejrzystość i elastyczność w definiowaniu zmiennych, list i słowników. Wadą jest niestety uzależnienie od sposobu formatowania. W przypadku XML i JSON to TAGi definiują strukturę, zaś w YAMLu kluczowe są wcięcia (spacje) na początku każdej linii. Poniżej znajduje się przykład pliku, opisującego zmienne konfiguracyjne wykorzystywane do automatyzacji sieci.

---                                                                                                                                 
cli:
  username: "{{ansible_ssh_user}}"
  password: "{{ansible_ssh_pass}}"
  host: "{{ip|default(ansible_host)|default(inventory_hostname)}}"
  transport: cli

snmp:
  community: "public"

ntp:
  server: "10.10.20.1"

ping_target:
  - "10.10.20.1"
  - "10.10.20.22"

W przypadku automatyzacji, YAML pozwala nam na oderwanie rzeczywistej konfiguracji urządzeń od modelu danych, opisujących tą konfigurację. Chodzi o to, żeby model (czyt. opis biznesowy usług) był na tyle uniwersalny i abstrakcyjny, a jednocześnie szczegółowy i użyteczny, aby można było na jego podstawie przygotować docelową konfigurację w sposób agnostyczny, niezależenie od tego czy konfigurujemy fizyczne urządzenia (dowolnego producenta) czy przenosimy kawałek naszej sieci w świat kontenerów czy do chmury.

Więcej informacji:

YANG

YANG (Yet Another Next Generation Data Modeling Language) to format opisu danych, który jest w pełni ustandaryzowany, rozwijany i utrzymywany przez IEFT. Każdy z elementów konfiguracyjnych (interfejsy, acl, routing) opisany jest za pomocą jednolitej, spójnej i uniwersalnej struktury, dzięki czemu możliwe jest ich wykorzystanie do implementacji w środowisku heterogenicznym. Oprócz bardzo dużej ilości pól standardowych, każdy producent dodaje swoje elementy, charakterystyczne dla danego urządzenia. Format ten jest ściśle powiązany z takimi protokołami jak NETCONF i RESTCONF. Może być wykorzystywany zarówno do opisu, jak i pozyskiwania informacji z urządzeń. Cały ten framework można postrzegać jako ewolucja protokołu SNMP i definicji MIB (w uproszczeniu). Obecnie, coraz więcej producentów urządzeń sieciowych implementuje metodę konfiguracji opartą o te technologie, jednak ze względu na duży poziom skomplikowania nie jest ona jeszcze zbyt rozpowszechniona.

Przykładową strukturę YANG dla opisu interfejsów Cisco NXOS można znaleźć na stronie GitHub

Więcej informacji:

Podziel się z innymi:
Email this to someone
email
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin

Dodaj komentarz

3 + 14 =