Tytuł oryginału: Network Programmability and Automation ...Ewolucja płaszczyzny zarządzania od SNMP do API urządzeń 45 Interfejs programowania aplikacji (API) 45 Wpływ open

Tytuł oryginału: Network Programmability and Automation: Skills for the Next-Generation Network Engineer

Tłumaczenie: Jacek Litka

ISBN: 978-83-283-5045-8

© 2019 Helion S.A.Authorized Polish translation of the English edition of Network Programmability and Automation ISBN 9781491931257 © 2018 Jason Edelman, Matt Oswalt, Scott S. Lowe

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletn i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Helion SA nie ponoszą równieżżadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Helion SAul. Kościuszki 1c, 44-100 Gliwicetel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku!Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/prausiMożesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Pliki z przykładami omawianymi w książce można znaleźć pod adresem: ftp://ftp.helion.pl/przyklady/prausi.zip

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

http://helion.pl/rt/prausi

http://helion.pl/rf/prausi

http://helion.pl/ro/prausi

http://helion.pl

http://ebookpoint.pl/r/4CAKF

7

Spis treści

Wstęp ....................................................................................................................... 13

1. Trendy inżynierii sieciowej ........................................................................................ 19Sieci sterowane programowo 19

OpenFlow 19Czym są sieci sterowane programowo? 23

Podsumowanie 34

2. Automatyzacja sieci .................................................................................................. 35Po co automatyzować sieci? 36

Uproszczone architektury 36Deterministyczny rezultat 37Biznesowa swoboda działania 37

Typy automatyzacji sieci 38Zaopatrywanie urządzeń 38Zbieranie danych 40Migracje 41Zarządzanie konfiguracją 42Zgodność 43Raportowanie 43Rozwiązywanie problemów 44

Ewolucja płaszczyzny zarządzania od SNMP do API urządzeń 45Interfejs programowania aplikacji (API) 45Wpływ open networkingu 49

Automatyzacja sieci w erze SDN 50Podsumowanie 50

3. Linux ........................................................................................................................ 51Linux w kontekście automatyzacji sieci 51Krótka historia Linuxa 52

Poleć książkęKup książkę



8 Spis treści

Dystrybucje Linuxa 52Red Hat Enterprise Linux, Fedora i CentOS 53Debian, Ubuntu i inne pochodne 54Inne dystrybucje Linuxa 55

Interakcja z Linuxem 56Nawigacja w systemie plików 57Manipulowanie plikami i katalogami 61Uruchomianie programów 67Praca z demonami 69

Sieci oparte na Linuxie 74Praca z interfejsami 74Routing jako host końcowy 83Routowanie jako router 87Mostkowanie (przełączanie) 89

Podsumowanie 94

4. Nauka wykorzystania Pythona w sieci ........................................................................ 95Czy inżynierowie sieciowi powinni nauczyć się programować? 96Korzystanie z interaktywnego interpretera Pythona 98Zrozumienie typów danych w Pythonie 100

Nauka użycia typu tekstowego 101Nauka użycia typów liczbowych 109Nauka użycia typów logicznych 111Nauka użycia list Pythona 114Nauka użycia słowników Pythona 119Nauka o zbiorach i krotkach Pythona 123

Dodawanie logiki warunkowej do Twojego kodu 125Zrozumienie przynależności 127Wykorzystanie pętli w Pythonie 128

Zrozumienie pętli while 128Zrozumienie pętli for 129

Funkcje 132Praca z plikami 136

Odczytywanie z pliku 136Zapisywanie do pliku 138

Tworzenie programów Pythona 140Tworzenie podstawowego skryptu Pythona 140Zrozumienie shebang 141Migrowanie kodu z interpretera Pythona do skryptu Pythona 142




Spis treści 9

Praca z modułami Pythona 143Przekazywanie argumentów do skryptu Pythona 145Wykorzystanie pip i instalowanie paczek Pythona 146Dodatkowe rady, sztuczki i informacje dotyczące Pythona 148Podsumowanie 153

5. Formaty i modele danych .........................................................................................155Wprowadzenie do formatów danych 155

Typy danych 157YAML 158

Omówienie podstaw formatu YAML 158Praca z formatem YAML w Pythonie 161Modele danych w YAML 162

XML 163Omówienie podstaw formatu XML 163Wykorzystanie XML Schema Definition (XSD) dla modeli danych 164Transformacja XML z XSLT 166Przeszukiwanie XML z wykorzystaniem XQuery 169

JSON 170Omówienie podstaw formatu JSON 170Praca z formatem JSON w Pythonie 172Wykorzystanie schematu JSON dla modeli danych 173

Modele danych YANG 174Przegląd YANG 174Zagłębienie się w model YANG 175

Podsumowanie 178

6. Szablony konfiguracji sieciowej ................................................................................179Narodziny współczesnych języków szablonów 180

Wykorzystanie szablonów w programowaniu sieciowym 181Więcej o wykorzystaniu szablonów 181

Przydatność szablonów w automatyzacji sieci 182Jinja dla szablonów konfiguracji sieciowej 183

Dlaczego Jinja? 183Dynamiczne wprowadzanie danych do podstawowego szablonu języka Jinja 184Renderowanie pliku szablonu Jinja w Pythonie 185Instrukcje warunkowe i pętle 187Filtry Jinja 192Dziedziczenie szablonów w języku Jinja 195Tworzenie zmiennych w języku Jinja 197

Podsumowanie 197




10 Spis treści

7. Praca z sieciowymi API ............................................................................................ 199Zrozumienie sieciowych API 200

Zapoznanie się z API bazującymi na HTTP 200Zgłębianie NETCONF 203

Praktyka z sieciowymi API 211Praktyka z API bazującymi na HTTP 211Praktyka z NETCONF 218

Automatyzacja z wykorzystaniem sieciowych API 226Wykorzystanie biblioteki Pythona requests 226Wykorzystanie biblioteki Pythona ncclient 253Wykorzystanie netmiko 275

Podsumowanie 280

8. Kontrola wersji z Git ................................................................................................ 283Scenariusze użycia systemu kontroli wersji 283Korzyści z zastosowania kontroli wersji 284

Śledzenie zmian 284Odpowiedzialność 284Proces i przepływ pracy 284

Korzyści z systemu kontroli wersji w środowisku sieciowym 285Poznaj Gita 285

Krótka historia systemu Git 286Terminologia Git 287Przegląd architektury systemu Git 287

Praca z systemem Git 289Instalacja systemu Git 289Tworzenie repozytorium 289Dodawanie plików do repozytorium 290Zatwierdzanie zmian w repozytorium 291Zmienianie i zatwierdzanie śledzonych plików 294Usuwanie plików z przechowalni 297Wykluczanie plików z repozytorium 299Przeglądanie dodatkowych informacji na temat repozytorium 303Odnajdywanie różnic pomiędzy wersjami plików 307

Zarządzanie gałęziami w systemie Git 311Tworzenie gałęzi Git 315Przełączanie się na gałąź 316Scalanie i usuwanie gałęzi 318

Wykorzystanie systemu Git do współpracy 322Współpraca pomiędzy wieloma systemami z uruchomionym systemem Git 323Współpraca za pomocą serwisów online bazujących na systemie Git 338

Podsumowanie 343




Spis treści 11

9. Narzędzia automatyzacji ..........................................................................................345Przegląd narzędzi do automatyzacji 345Wykorzystanie Ansible 347

Podstawy działania Ansible 348Konstrukcja pliku inwentarza 349Wykonanie scenariusza Ansible 356Wykorzystanie plików zmiennych 360Tworzenie scenariuszy Ansible do automatyzacji sieci 362Wykorzystanie modułów stron trzecich 379Podsumowanie Ansible 382

Automatyzacja za pomocą narzędzia Salt 382Architektura Salt 383Pierwsze kroki z narzędziem Salt 386Zarządzanie konfiguracjami sieci za pomocą narzędzia Salt 401Zdalne wykonywanie funkcji narzędzia Salt 409Salt: infrastruktura sterowana zdarzeniami 411Dodatkowe informacje o narzędziu Salt 416Podsumowanie Salt 419

Automatyzacja sterowana zdarzeniami za pomocą narzędzia StackStorm 419Pojęcia związane ze StackStormem 420Architektura StackStorm 422Akcje i przepływy pracy 423Sensory i wyzwalacze 432Reguły 434Podsumowanie StackStorm 437

Podsumowanie 437

10. Ciągła integracja ......................................................................................................439Istotne wymagania wstępne 441

Proste jest lepsze 441Ludzie, proces i technologia 441Naucz się programować 442

Wprowadzenie do ciągłej integracji 442Podstawy ciągłej integracji 443Ciągłe dostarczanie 444Programowanie sterowane testami 446Po co ciągła integracja w sieciach? 447

Potok ciągłej integracji dla sieci 448Ocena przez osoby równorzędne 449Automatyzacja budowy 454Środowisko testowe, rozwojowe i przechowujące 459




12 Spis treści

Narzędzia wdrażania 462Narzędzia testowania i automatyzacja sieci sterowana testami 463

Podsumowanie 465

11. Budowa kultury dla automatyzacji sieci ................................................................... 467Strategia organizacyjna i swoboda pracy 468

Transformowanie skostniałej organizacji 468Uzyskanie zgody najwyższego kierownictwa 469Zbudować czy kupić 470

Akceptacja porażki 472Rozwijanie umiejętności i kształcenie się 473

Ucz się nowych rzeczy 473Skup się na podstawach 474Certyfikaty? 475Czy automatyzacja odbierze mi pracę?! 476

Podsumowanie 476

A Sieci w Linuxie. Zagadnienia zaawansowane ........................................................... 479

B Wykorzystanie biblioteki NAPALM ........................................................................... 507

Skorowidz ............................................................................................................... 521




35

ROZDZIAŁ 2.

Automatyzacja sieci

W rozdziale tym skupimy się na przedstawieniu podstaw dotyczących koncepcji wysokopozio-mowej automatyzacji sieci, abyś był lepiej wyposażony w wiedzę potrzebną do pełnego zrozumie-nia materiału prezentowanego w następnych rozdziałach.

W tym celu podzieliliśmy ten rozdział na poniższe podrozdziały:

Po co automatyzować sieci?Przedstawiamy tu różne powody adaptacji automatyzacji poprawiającej wydajność operacjisieciowych, jednocześnie podkreślając, że automatyzacja to coś więcej niż tylko szybsze do-starczanie konfiguracji do urządzeń sieciowych.

Typy automatyzacji sieciPrzegląd różnego typu automatyzacji, od tradycyjnego zarządzania konfiguracją po automa-tyzację diagnostyki i rozwiązywanie problemów. Przypominamy raz jeszcze, że automatyza-cja sieci to coś więcej niż tylko skrócenie czasu potrzebnego na zastosowanie zmian w konfi-guracji urządzenia.

Ewolucja płaszczyzny zarządzania od SNMP do API urządzeńKrótkie wprowadzenie do API sieciowych dostępnych w starszych i współczesnych urządze-niach sieciowych.

Automatyzacja sieci w erze SDNKrótkie podsumowanie, wyjaśniające, dlaczego automatyzacja narzędzi sieciowych jest wciążwarta stosowania mimo wdrażania rozwiązań SDN. Mamy tutaj na myśli przede wszystkimarchitektury oparte na kontrolerach.

Rozdział ten nie jest rozdziałem technicznym. Jego zadaniem jest wprowadzenie doidei i koncepcji automatyzacji sieci. Stanowi jedynie podstawę i kontekst kolejnychrozdziałów.




36 Rozdział 2. Automatyzacja sieci

Po co automatyzować sieci?Automatyzacja sieci, tak jak automatyzacja ogólnie, została opracowana jako metoda przyspie-szenia pracy. Mimo że szybkie wykonywanie pracy jest wygodne, to redukcja czasu potrzebnegona wdrożenia i zmiany w konfiguracji w wielu organizacjach IT nie zawsze jest problemem ko-niecznym do rozwiązania.

Mając na uwadze oszczędność czasu, rzucimy okiem na kilka powodów, dla których różnej wiel-kości organizacje IT powinny zacząć stopniowo wprowadzać automatyzację sieci. Zwróć uwagę,że przyczyny wprowadzania automatyzacji w innych dziedzinach (aplikacje, systemy, przecho-wywanie danych, telefonia itd.) były identyczne.

Uproszczone architekturyDzisiaj w większości przypadków żadne dwa urządzenia sieciowe nie mają identycznej konfigura-cji. Różnią się między sobą niczym dwa unikalne płatki śniegu (posiadają wiele unikatowych, nie-standardowych konfiguracji). Wielu inżynierów sieciowych ma powód do dumy, gdy udaje się imrozwiązać problemy dotyczące transportu i aplikacji, wynikające z dokonywania jednorazowychzmian w sieci, które w ostatecznym rozrachunku prowadzą do tego, że sieci stają się nie tylkotrudniejsze w zarządzaniu i utrzymaniu, ale też i trudniejsze do zautomatyzowania.

Zamiast traktować automatyzację sieci i zarządzania jako drugorzędny projekt lub jako „dodatek”,powinno się ją traktować jako kluczowy element nowo tworzonej architektury. Powinno się uwzględ-niać zarezerwowanie budżetu zarówno na personel, jak i narzędzia automatyzacji. Niestety, na-rzędzia automatyzacji często jako pierwsze padają ofiarą cięć budżetowych.

Architektura od końca do końca i powiązane z nią operacje dnia drugiego powinny być jednakowe.Przed wdrożeniem architektury należy znaleźć odpowiedź na poniższe pytania:

Jakie funkcje działają niezależnie od dostawców?

Jakie rozszerzenia działają niezależnie od platform?

Jakie rodzaje API lub narzędzi automatyzacji działają z danymi platformami urządzeńsieciowych?

Czy API zostało solidnie udokumentowane?

Jakie biblioteki programistyczne można wykorzystać w danym projekcie?

Jeżeli odpowiedzi na te pytania zostaną znalezione na wczesnym etapie projektu, wynikowa ar-chitektura będzie prosta, łatwa do powielenia oraz utrzymania i automatyzacji, a to wszystko przyzmniejszonej liczbie działających w sieci rozszerzeń zależnych od dostawców.

Nawet przy tak uproszczonej architekturze, z poprawnym zarządzaniem i narzędziami automaty-zacji, należy pamiętać o tym, aby zminimalizować liczbę jednorazowych zmian, by zapewnić, żekonfiguracje urządzeń sieciowych nie staną się ponownie różnorodne jak płatki śniegu.




Po co automatyzować sieci? 37

Deterministyczny rezultatW firmach organizuje się spotkania w celu oceny proponowanych zmian w sieci, ich wpływu nazewnętrzne systemy i plany przywrócenia poprzedniego stanu. W świecie, w którym jeden czło-wiek sięga po wiersz poleceń w celu wprowadzenia jednej zmiany, niepoprawnie wpisana ko-menda może być katastrofalna w skutkach. Wyobraź sobie zespół składający się z 3, 4, 5 lub 50inżynierów. Każdy z tych inżynierów może mieć własny pomysł na zrealizowanie planowanejzmiany. Ponadto zdolność do wykorzystania wiersza poleceń albo nawet i GUI nie eliminuje aninie redukuje możliwości wystąpienia błędu w trakcie okna czasowego przeznaczonego na wpro-wadzenie potrzebnych zmian.

Używanie sprawdzonych i przetestowanych narzędzi automatyzacji sieci w celu dokonywaniazmian pomaga uzyskać bardziej przewidywalny wynik niż w przypadku manualnych zmian i dajezespołowi je wykonującemu większą szansę na deterministyczny rezultat, co przybliża go do pew-ności, że zadanie zostanie wykonane bez wystąpienia błędu ludzkiego. Może to być dowolne za-danie, od zmiany w wirtualnej sieci lokalnej VLAN do wykonania szeregu zmian w sieci u klienta.

Biznesowa swoboda działaniaWiemy, że automatyzacja sieci gwarantuje szybkość i swobodę działania przy wdrażaniu zmian,ale umożliwia ona również pozyskiwanie danych od urządzeń sieciowych tak szybko, jak wyma-gają tego potrzeby biznesowe, lub ujmując to w sposób bardziej praktyczny, tak szybko, jak jest topotrzebne, aby w dynamiczny sposób rozwiązywać zaistniałe w sieci problemy.

Wraz z nadejściem wirtualizacji serwerów administratorzy serwerów i wirtualizacji otrzymalimożliwość niemal natychmiastowego wdrażania nowych aplikacji. Z szybszym wdrażaniem apli-kacji pojawiają się pytania o to, dlaczego tyle czasu zajmuje konfigurowanie zasobów sieciowych,takich jak sieci VLAN, trasy, zasady filtrowania ruchu, zasady równoważenia ruchu lub wszystkiepowyższe naraz w przypadku wdrażania aplikacji trzeciego poziomu.

Powinno być w miarę oczywiste, że wraz z adaptacją automatyzacji sieci zespoły inżynierów sie-ciowych i zespoły operacyjne mogą reagować szybciej od swoich odpowiedników IT przy wdra-żaniu aplikacji, jednak co ważniejsze, pomaga ona biznesowi uzyskać większą swobodę działania.Z perspektywy adaptacji krytyczne jest zrozumienie istniejących, a do tego często manualnychprzepływów pracy przed podjęciem jakiejkolwiek próby automatyzacji, aby Twój biznes otrzymałwięcej swobody działania.

Jeżeli nie masz pojęcia, co dokładnie chcesz zautomatyzować, skomplikuje to i wydłuży proces.Nasza rada numer jeden — kiedy zaczniesz swoją pracę z automatyzacją sieci, powinieneś zawszerozumieć istniejące ręczne przepływy pracy, dokumentować je i rozumieć ich wpływ na biznes.Wtedy proces wprowadzenia technologii automatyzacji narzędzi stanie się dużo prostszy.

W sekcji tej przedstawiliśmy ważne powody, dla których powinieneś rozważyć automatyzację sieci(od uproszczonej architektury do swobody działania biznesu). W następnym podrozdziale przyj-rzymy się różnym rodzajom automatyzacji sieci.





Typy automatyzacji sieciAutomatyzacja powszechnie utożsamiana jest z szybkością, a skoro nie każde działanie w sieciwymaga szybkości, łatwe do zrozumienia staje się, dlaczego niektóre zespoły IT nie dostrzegająw niej wartości. Konfiguracja sieci VLAN może być świetnym tego przykładem, ponieważ możnapomyśleć: „Jak szybko powinno się tak naprawdę tworzyć te sieci VLAN? Jak dużo sieci VLAN zo-staje utworzonych każdego dnia? Czy ja naprawdę potrzebuję tej całej automatyzacji?”. Wszystkiete pytania są zasadne.

W tej sekcji skupimy się na szeregu innych zadań, przy których automatyzacja ma sens, takich jakzaopatrywanie urządzeń, zbieranie danych, rozwiązywanie problemów, raportowanie i zachowy-wanie zgodności. Pamiętaj jednak, że jak zaznaczyliśmy wcześniej, automatyzacja to dużo więcejniż tylko szybkość i swoboda działania; oferuje ona też Tobie, Twojemu zespołowi i Twojemubiznesowi bardziej przewidywalne i bardziej deterministyczne rezultaty.

Zaopatrywanie urządzeńJedną z najprostszych i najszybszych metod na rozpoczęcie pracy z automatyzacją sieci jest auto-matyzacja tworzenia plików konfiguracji urządzeń, które wykorzysta się do wstępnego zaopatry-wania urządzeń, oraz automatyzacja przesyłania ich do urządzeń sieciowych.

W celu zautomatyzowania procesu tworzenia plików konfiguracyjnych należy oddzielić danewejściowe (parametry konfiguracyjne) od podległej im zależnej od dostawcy składni konfigura-cyjnej (wiersza poleceń). Oznacza to, że skończymy z oddzielnymi plikami, z których każdy za-wierać będzie wartości i parametry konfiguracyjne dotyczące różnych zagadnień, takich jak sieciVLAN, informacje o domenie, interfejsy, routing i wszystkie inne rzeczy wchodzące w skład kon-figuracji oraz, rzecz jasna, szablon konfiguracji. Jest to temat, któremu poświęcimy dużo więcejuwagi w rozdziale 6.

Na razie traktuj szablon konfiguracji jako ekwiwalent standardowego złotego szablonu (ang. goldentemplate), który wykorzystuje się dla wszystkich wdrażanych urządzeń. Stosując technikę zwanąszablonami konfiguracji sieciowej, uzyskujesz w szybki sposób spójne pliki konfiguracyjne dla wszyst-kich urządzeń w Twojej sieci. Oznacza to również, że już nigdy więcej nie uruchomisz Notatnikaw celu skopiowania i wklejenia konfiguracji z pliku do pliku — nie najwyższa na to pora?

Dwoma narzędziami, które upraszczają korzystanie z szablonów konfiguracji ze zmiennymi(danymi wejściowymi), są Ansible i Salt. W mniej niż kilka sekund narzędzia te są zdolne wyge-nerować setki plików konfiguracyjnych w sposób przewidywalny i niezawodny.

Budowanie i generowanie plików konfiguracyjnych zostało przedstawione szczegó-łowo w rozdziale 6., a wykorzystanie narzędzi Ansible i Salt zostało opisane w roz-dziale 9. Ten rozdział jedynie przedstawia wysokopoziomowy, podstawowy przykład.

Spójrzmy na przykład przerobienia istniejącej konfiguracji na szablon i oddzielny plik ze zmien-nymi (danymi wejściowymi).




Typy automatyzacji sieci 39

Oto przykład wycinka z pliku konfiguracyjnego:

hostname leaf1ip domain-name ntc.com!vlan 10name web!vlan 20name app!vlan 30name db!

Jeżeli oddzielimy dane od komend wiersza poleceń, plik zostanie przetransformowany na dwapliki: szablon i plik danych (zmiennych).

Spójrzmy na plik YAML (YAML opisujemy szczegółowo w rozdziale 5.) ze zmiennymi:

---hostname leaf1domain_name: ntc.comvlans:- id: 10name: web- id: 20name: app- id: 30name: db

Zwróć uwagę, że plik YAML to nasze jedyne dane.

W tym przykładzie pokazujemy język szablonowania Jinja oparty na Pythonie.Jinja jest opisana w rozdziale 6.

Wynikowy szablon, który zostanie utworzony wraz z plikiem danych, ma nazwę leaf.j2 i wyglądanastępująco:

!hostname {{ inventory_hostname }}ip domain-name {{ domain_name }}!!{% for vlan in vlans %}vlan {{ vlan.id }}name {{ vlan.name }}{% endfor %}!

W tym przykładzie podwójny nawias klamrowy wskazuje na zmienną języka Jinja. Innymi sło-wy, jest to miejsce, w którym dane o zmiennych zostają wprowadzone, kiedy szablon jest stwo-rzony wraz z danymi. Skoro podwójne nawiasy klamrowe wskazują na zmienne i widzimy, że ichwartości nie znajdują się w szablonie, to znaczy, że musiały zostać przechowane gdzieś indziej.





Przechowane zostały w pliku YAML. Zamiast wykorzystywać płaskie pliki YAML, mógłbyś takżewykorzystać skrypt, który sięgnąłby po te informacje z zewnętrznego systemu, takiego jak systemzarządzania siecią (ang. Network Management System — NMS) lub system zarządzania adresamiIP (ang. IP address management system — IPAM).

Jeżeli w tym przykładzie zespół kontrolujący sieci VLAN zechce dodać VLAN do urządzeń sie-ciowych, to nie będzie to stanowić żadnego problemu. Wystarczy, że zespół wprowadzi zmianyw pliku ze zmiennymi i utworzy na nowo plik konfiguracyjny, wykorzystując Ansible lub silnikrenderujący swojego wyboru (Salt, czysty Python itp.).

W rozdziale 6. opisujemy również, jak wykorzystać czysty Python z szablonamijęzyka Jinja w celu utworzenia skryptu Pythona, który może działać jako podsta-wowy silnik renderujący.

Teraz w naszym przykładzie wygenerowaną konfigurację należy przesłać do urządzenia sieciowego.Procesu przesłania i wykonania tutaj nie przedstawiamy — istnieje mnóstwo sposobów na zro-bienie tego, wliczając w to zamknięte automatyczne rozwiązania zaopatrywania i kilka innychmetod, o których wspomnimy w rozdziałach 7. i 9.

Wszystko to miało posłużyć wyłącznie jako wysokopoziomowe wprowadzenie do szablonów;nie martw się, jeśli coś jeszcze nie jest jasne. Jak wspomnieliśmy, praca z szablonami jest opisanaszczegółowo w rozdziale 6.

Obok budowania konfiguracji i wysyłania ich do urządzeń ważne jest zbieranie danych, co sta-nowi nasz następny temat.

Zbieranie danychNarzędzia do monitorowania zazwyczaj wykorzystują Simple Network Management Protocol(SNMP). Narzędzia te pobierają pewne bazy informacji zarządzania (ang. management informa-tion base — MIB) i zwracają informacje do narzędzia monitorowania. Pozyskanych danych możebyć więcej lub mniej, niż faktycznie potrzebujesz. A jeżeli pozyskiwane są statystyki interfejsów?Możesz otrzymać każdy licznik, który jest przedstawiony przez polecenie show interface. Ale co,jeśli potrzebujesz wyłącznie informacji o liczbie resetów interfejsu, a nie wszystkie te informacjeo błędach CRC, ramkach typu jumbo, błędach wyjściowych itd.? Co więcej, co, jeżeli chcesz zobaczyćliczbę resetów interfejsu w korelacji do interfejsów posiadających sąsiadów CDP/LLDP i chcesz towszystko zobaczyć teraz, a nie przy następnym cyklu pozyskiwania danych? Jak automatyzacjasieci w tym pomaga?

Biorąc pod uwagę to, że naszym celem jest danie Ci więcej możliwości i kontroli, możesz wyko-rzystać narzędzia i technologie open source, aby dopasować dokładnie do swoich potrzeb, co chceszotrzymać i kiedy, jak to ma być sformatowane i jak dane mają być wykorzystane, gdy już zostanązebrane, sprawiając w ten sposób, aby uzyskać z tych danych jak najwięcej.

Zamieszczamy tutaj bardzo prosty przykład zbierania danych z urządzenia IOS z wykorzystaniembiblioteki Pythona netmiko, której przyjrzymy się uważniej w rozdziale 7.





from netmiko import ConnectHandlerdevice = ConnectHandler(device_type='cisco_ios', ip='csr1',username='ntc',password='ntc123')output = device.send_command('show version')print(output)

Najlepsze w tym wszystkim jest to, że wyjście zawiera odpowiedź na show version, a Ty otrzy-mujesz możliwość przetworzenia tego wszystkiego według własnych potrzeb.

W przedstawionym przykładzie opisujemy pozyskiwanie danych z urządzeń, co niemusi być idealnym rozwiązaniem we wszystkich środowiskach, lecz dla wielu możebyć użyteczne. Miej na uwadze, że nowsze urządzenia zaczynają obsługiwać takżeprzepychanie danych, często nazywane streamowaniem telemetrii, w którym toprzypadku samo urządzenie streamuje dane w czasie rzeczywistym, takie jak staty-styki interfejsów, do serwera aplikacji, który wybrałeś.

Rzecz jasna, wiele z tego wymaga wykonania nieco pracy z dostosowaniem wszystkiego do wła-snych potrzeb, jednak w ostatecznym rozrachunku jest to gra warta świeczki, ponieważ pozysku-jesz dane, których potrzebujesz, a nie dane, które dostarcza Ci określone narzędzie lub określonydostawca. Czyż jest to nie jest powód, dla którego czytasz tę książkę?

Urządzenia sieciowe są wyposażone w ogromne ilości statycznych i efemerycznych danych za-grzebanych gdzieś w ich głębi, a korzystanie z narzędzi open source i opracowywanie ich samemuumożliwia Ci do nich dostęp. Przykładem takich danych są aktywne wpisy w tablicy BGP,sąsiedztwo OSPF, aktywni sąsiedzi, statystyki interfejsów, szczegółowe liczniki, liczniki rese-tów, a nawet liczniki ze specjalizowanych układów scalonych ASIC w przypadku nowszych plat-form. Dodatkowo istnieje nieco faktów i charakterystyk urządzeń, które można zebrać, takich jaknumer seryjny, nazwa hosta, czas pracy, wersja systemu operacyjnego i platformy sprzętowej.Lista jest niemal nieskończona.

Kiedy rozpoczynasz projekt automatyzacji, zawsze rozważ następujące pytania:„Czy ma sens zbudowanie tego, kupienie tego lub dostosowanie tego?” i „Czy ma senskorzystanie z tego i operowanie tym?”.

MigracjeMigracja z jednej platformy na drugą nigdy nie jest prostym zadaniem, niezależnie od tego, czymigruje się pomiędzy platformami od tego samego dostawcy, czy od różnych. Dostawca możeoferować skrypt lub narzędzie pomocne przy migracji na jego platformę, za to różnego rodzajeautomatyzacje mogą zostać wykorzystane do zbudowania szablonów konfiguracji, takich jak naszwcześniejszy przykładowy szablon, dla wszystkich rodzajów urządzeń sieciowych i systemów ope-racyjnych w taki sposób, że mógłbyś wygenerować plik konfiguracyjny dla każdego dostawcy, podwarunkiem że wykorzystywaliby wspólny zestaw danych wejściowych (wspólny model danych).

Oczywiście nie można przy tym zapomnieć o unikalnych dla dostawcy rozszerzeniach. Pięknew tym wszystkim jest to, że narzędzia migracyjne takie jak te są dużo prostsze do zbudowaniasamemu niż przez dostawcę, gdyż dostawca musi wziąć pod uwagę całą funkcjonalność oferowaną





przez swoje rozwiązanie w przeciwieństwie do organizacji, która jest zainteresowana wyłączniepewnym jej zbiorem. W rzeczywistości jest to jedna z rzeczy, które nie zaprzątają głowy dostaw-com; skupieni są na swoim własnym ekwipunku, a nie na tym, abyś Ty, operator sieci, miał uła-twioną pracę w środowisku złożonym z elementów od różnych dostawców.

Posiadanie tego typu swobody działania pomaga nie tylko przy migracjach, ale też w środowi-skach odtwarzania zniszczeń DR. Powszechną praktyką jest posiadanie różnych przełącznikóww centrach danych w produkcji i w DR, często różnych dostawców. Jeżeli urządzenie zawiedziez jakiegoś powodu, a jego zastępstwem będzie inna platforma, uzyskasz możliwość szybkiego wy-korzystania wspólnego modelu danych (mamy tutaj na myśli dane wejściowe) i natychmiastowegowygenerowania nowej konfiguracji. Zaczynamy luźno wykorzystywać termin model danych, lecznie martw się, w rozdziale 5. poświęcimy nieco miejsca na wyjaśnienie, czym są modele danych.

Kiedy wykonujesz migrację, myśl o niej na bardziej abstrakcyjnym poziomie i przemyśl zadanianiezbędne do przejścia z jednej platformy na drugą. Następnie sprawdź, co można by zrobić, abyzautomatyzować te zadania, ponieważ tylko Ty, a nie wielcy dostawcy sieciowi, masz motywacjędo tego, aby automatyzacja wykorzystująca sprzęt wielu różnych dostawców stała się rzeczywistością.Na przykład pomyśl o dodaniu sieci VLAN jak o abstrakcyjnym kroku — potem możesz się mar-twić o niskopoziomowe komendy na każdej platformie. Ważne jest to, że gdy rozpoczniesz adap-tację automatyzacji, niesłychanie istotne stanie się to, abyś myślał o zadaniach i dokumentował jew zrozumiałym dla człowieka formacie, który jest niezależny od dostawców, zanim sięgniesz poklawiaturę, aby wprowadzić komendy wiersza poleceń lub napisać program (na każdą z platform).

Zarządzanie konfiguracjąJak wspomnieliśmy wcześniej, zarządzanie konfiguracją jest najpospolitszym rodzajem automaty-zacji, dlatego też nie poświęcimy tutaj na to zbyt wiele miejsca. Powinieneś być świadom, że kiedywspominamy o zarządzaniu konfiguracją, mamy na myśli jej wdrażanie i wysyłanie do urządzeńoraz zarządzanie jej stanem. Wliczamy w to zarówno rzeczy tak podstawowe, jak zaopatrywaniesieci VLAN, jak i skomplikowane przepływy pracy, które konfigurują przełączniki na szczyciestojaka, firewalle, równoważniki ruchu i zaawansowane infrastruktury bezpieczeństwa w celuwdrożenia aplikacji trzeciopoziomowych.

Jak już widziałeś w kilku przypadkach automatyzacji sieci, które służą tylko do odczytu, musiszrozpocząć swoją podróż przez automatyzację sieci od wysyłania konfiguracji. Jeżeli spędzasz nie-zliczone godziny na przesyłaniu tych samych zmian na przestrzeni wielu routerów lub przełącz-ników, możesz być temu pomysłowi przychylny!

W rzeczywistości liczba sposobów na rozpoczęcie podróży przez automatyzację sieci jest duża,lecz pamiętaj, że z wielką mocą wiąże się wielka odpowiedzialność. Co ważniejsze, nie zapomnijo tym, by uważnie przetestować swoje narzędzia automatyzacji przed ich wdrożeniem do środo-wiska produkcyjnego.

Następne typy automatyzacji sieci, o których opowiemy, wyrosły z automatyzacji procesu zbiera-nia danych. Wybraliśmy kilka z nich w celu przedstawienia szerszego kontekstu, a zaczniemy odautomatyzacji testów zgodności.





ZgodnośćTak jak w wielu formach automatyzacji, wprowadzanie zmian w konfiguracji z zastosowaniemjakiegokolwiek narzędzia automatyzacji postrzegane jest jako ryzyko. Choć wprowadzanie ręcz-nych zmian można uznać za ryzykowniejsze, o czym mogłeś przeczytać lub czego mogłeś sam do-świadczyć, to możesz zacząć zbierać dane, monitorować je i budować konfigurację — są to dzia-łania jedynie czytające dane i akcje niskiego ryzyka. Jedynym scenariuszem niskiego ryzyka,w którym wykorzystywane są zebrane dane, są testy zgodności konfiguracji i weryfikacja konfigu-racji. Czy wdrożona konfiguracja spełnia wymagania bezpieczeństwa? Czy wymagane sieci zostałyskonfigurowane? Czy protokół XYZ został wyłączony? Jeżeli masz kontrolę nad wdrożonymi na-rzędziami, to łatwe staje się zweryfikowanie, co jest prawdą, a co fałszem. Proste jest rozpoczęcieod jednokrotnego sprawdzenia zgodności, a potem dokonywanie dodatkowych sprawdzeń w ra-zie potrzeby.

Opierając się na poprawności tego, co sprawdzasz, możesz określić, co stanie się później — możezostanie to tylko zapisane w logach, a może zostanie przeprowadzona kompleksowa operacja,czyniąc Twoją aplikację zdolną do automatycznego radzenia sobie z problemami. Są to formyautomatyzacji sterowanej zdarzeniami, o której opowiemy przy omówieniu narzędzi StackStormi Salt w rozdziale 9. Przy automatyzacji sieci najlepiej jest zawsze zacząć od podstaw, ale trzebabyć świadomym pełni jej możliwości. Na przykład, jeżeli po prostu zapisujesz w logach i drukujeszwiadomości, aby zobaczyć, jaka jest maksymalna jednostka transmisji (ang. maximum transmis-sion unit — MTU), to jesteś też gotowy, kiedy tylko zechcesz, do jej automatycznej rekonfiguracji,jeżeli ta wartość jest dla Ciebie niezadowalająca. Wystarczyłoby tylko dodać kilka dodatkowychlinijek do kodu odpowiedzialnego za zapisywanie do logów (wyświetlanie) wiadomości. Należyzacząć ostrożnie, ale zawsze trzeba myśleć o tym, co może przydać się w przyszłości.

RaportowanieGdy już zaczniesz zbierać dane, to może zechcesz też zacząć budować dostosowane przez siebiedynamiczne raporty. Może zwrócone dane staną się danymi wejściowymi w innych zadaniach za-rządzania konfiguracją (zarówno opartą na zdarzeniach, jak i prostszą konfiguracją warunkową)lub może przydadzą Ci się w tworzeniu raportów.

Biorąc pod uwagę, że raporty można łatwo generować z szablonów połączonych z faktycznymiefemerycznymi danymi z urządzenia, które zostaną wprowadzone do szablonu, to proces tworze-nia i wykorzystywania raportów jest tym samym procesem co ten używany do tworzenia szablo-nów konfiguracji, o którym wspominaliśmy wcześniej w tym rozdziale (z szablonami zapoznaszsię szczegółowo w rozdziale 6.).

Z powodu mało złożonej natury korzystania z szablonów opartych na tekście możliwe jest two-rzenie raportów w dowolnym formacie, np.:

prostych plików tekstowych,

plików ze znacznikami, które z łatwością przejrzysz w serwisie GitHub lub jakimś czytnikuz obsługą znaczników,

raportów HTML, które wdrażane są na serwerze sieciowym w celu łatwego przejrzenia.





Wszystko zależy od Twoich wymagań. Wspaniałą rzeczą jest to, że automat sieciowy jest zdolnydo wygenerowania dokładnie takiego raportu, jakiego sobie zażyczysz. W rzeczy samej, możeszwykorzystać jeden zestaw danych do wygenerowania różnego rodzaju raportów, może nawet ja-kichś raportów technicznych i raportów wysokiego poziomu dla zarządu.

Teraz przyjrzymy się zautomatyzowanemu rozwiązywaniu problemów.

Rozwiązywanie problemówKtóż nie lubi być angażowany do spraw związanych z problemem zepsutego sprzętu, zwłaszczakiedy powinien spać lub skupić się na czymś innym?

Gdy już uzyskasz dostęp do danych w czasie rzeczywistym i nie będziesz musiał ich przetwarzaćręcznie, automatyzacja rozwiązywania problemów stanie się rzeczywistością.

Pomyśl nad tym, jak rozwiązujesz problemy. Czy masz własną metodologię? Czy metodologiawszystkich członków Twojego zespołu jest spójna? Czy każdy sprawdza warstwę łącza danych przedrozwiązaniem problemów w warstwie sieci? Jakie kroki podejmujesz, aby rozwiązać dany problem?

Przyjrzyjmy się rozwiązywaniu problemów z OSPF:

Czy wiesz, co jest wymagane, aby nawiązać sąsiedztwo pomiędzy dwoma urządzeniami?

Czy jesteś zdolny odpowiedzieć na powyższe pytanie o drugiej nad ranem lub w trakcie urlo-pu na plaży?

Może pamiętasz, że urządzenia muszą być w tej samej podsieci, mieć takie samo MTU, miećspójne zegary, ale zapomniałeś, że muszą należeć do sieci OSPF tego samego typu.

Czy naprawdę musimy pamiętać to wszystko i powiązane z tym komendy wiersza poleceń,aby odzyskać wszystkie dane?

A to jedynie kilka z rzeczy, które muszą pasować w przypadku routingu OSPF.

W każdym środowisku tego typu muszą być przeprowadzone testy kompatybilności. Możesz wy-obrazić sobie uruchomienie skryptu lub wykorzystanie narzędzia do weryfikacji sąsiada OSPFzamiast przeprowadzenia całego tego procesu ręcznie? Co byś preferował?

OSPF to jedynie wierzchołek góry lodowej. Pomyśl o pozostałych pytaniach, też będących tylkotakim wierzchołkiem:

Czy potrafisz skorelować ze sobą odpowiednie wiadomości w logach, aby wiedzieć, co zaszłow sieci?

Co z sąsiedztwem BGP? Jak formuje się to sąsiedztwo?

Czy widzisz wszystkie trasy, które Twoim zdaniem powinny być w tablicy routingu?

Co z konfiguracjami VPC i MLAG?

Co z kanałami portów? Czy występują tutaj jakieś nieścisłości?

Czy sąsiedzi pasują do konfiguracji kanałów portów (aż do poziomu vSwitcha)?

Co z okablowaniem? Czy wszystkie przewody są poprawnie podłączone?




Ewolucja płaszczyzny zarządzania od SNMP do API urządzeń 45

Nawet z tymi pytaniami jedynie delikatnie ocieramy się o możliwości, które dają zautomatyzo-wana diagnostyka i rozwiązywanie problemów.

Kiedy zaczniesz rozważać wszystkie możliwe rodzaje automatyzacji, wyobraź sobiesystem zamkniętej pętli, w którym dane są gromadzone przetwarzane i analizowanew sposób zautomatyzowany. Kiedy zacznie się to dziać jednocześnie, stanie się za-mkniętą pętlą, całkowicie zmieniającą sposób, w jaki operujemy siecią i zarządzamynią wewnątrz organizacji.

Jeżeli jesteś gwiazdą w swoim zespole inżynierów, to możesz pomyśleć o nawiązaniu współpracyz programistą lub przynajmniej zacząć dokumentować swoje przepływy pracy, dzięki czemuprostsze stanie się przekazywanie wiedzy i jej pozyskiwanie.

Gdy już rozpoczniesz swoją podróż przez automatyzację, będziesz mógł wreszcie porządnie sypiać.Zaznajom wszystkich ze zautomatyzowanymi przepływami pracy diagnostycznej.

Jak widzisz, automatyzacja sieci to dużo więcej niż tylko szybsze wdrażanie konfiguracji. Po przyj-rzeniu się kilku różnym rodzajom automatyzacji zajmiemy się nowym tematem i rzucimy okiemna kilka różnych metod, którymi narzędzia automatyzacji i aplikacje komunikują się z urządze-niami sieciowymi, zaczynając od SSH, a kończąc na API NETCONF i API bazujących na HTTP.

Ewolucja płaszczyzny zarządzania od SNMP do API urządzeńJeżeli chcesz poprawić codzienną operacyjność i zarządzanie swoimi sieciami, ulepszeniu należypoddać interfejs, który stosujesz do komunikacji z zarządzanymi przez Ciebie urządzeniami. Teninterfejs to sposób, w jaki komunikujesz się zarówno Ty, jak i komunikują się narzędzia automa-tyzacji z urządzeniami sieciowymi w celu przeprowadzenia zautomatyzowanych akcji, takich jakgromadzenie danych i zarządzanie konfiguracją.

W tej sekcji przedstawimy przegląd różnych metod łączenia się z płaszczyzną zarządzania urzą-dzeń sieciowych, zaczynając od SNMP, a potem przesuwając się w stronę metod znacznie nowo-cześniejszych, takich jak NETCONF i RESTful API. Później rzucimy okiem na wpływ ruchu opennetworking na operacyjność i automatyzację sieci.

Interfejs programowania aplikacji (API)Jako inżynier sieci, wraz z kolejnymi krokami doskonalenia się musisz zaznajamiać się z API,a nie się ich obawiać. Pamiętaj, że API to tylko mechanizm, który wykorzystywany jest przez opro-gramowanie komputerowe na jednym urządzeniu do tego, aby „rozmawiać” z oprogramowaniemkomputerowym na innych urządzeniach. API są dzisiaj wykorzystywane praktycznie wszędziew internecie — dostawcy sieciowi wreszcie poświęcają im więcej uwagi. Wkrótce zobaczymy, żeAPI staną się podstawową metodą zarządzania urządzeniami sieciowymi.

API w szczegółach opisujemy w rozdziale 7.; ta sekcja dostarcza wyłącznie wysokopoziomowegoprzeglądu różnych rodzajów API, które występują w dzisiejszych urządzeniach sieciowych.





SNMP

Protokół SNMP był szeroko wdrażany przez ostatnie 20 lat w urządzeniach sieciowych. Nie po-winien stanowić dla Ciebie nowości. Jest to protokół powszechnie wykorzystywany do pozyski-wania danych z urządzeń sieciowych, takich jak informacje o czasie działania czy wyłączenia, ob-ciążeniu procesora, wykorzystaniu pamięci i interfejsów.

Aby korzystać z SNMP, wymagana jest obecność agenta SNMP na zarządzanym urządzeniui system zarządzania siecią NMS, który służy jako serwer monitorujący i (lub) kontrolujący zarzą-dzane urządzenia.

Każde z zarządzanych urządzeń udostępnia zestaw danych, który można zebrać i skonfigurowaćz wykorzystaniem agenta SNMP. Zestaw danych zarządzany przez SNMP jest opisywany i mo-delowany za pomocą baz informacji zarządzania. Jedynie kiedy MIB udostępnia pewną funkcjo-nalność, może ona być monitorowana lub zarządzana, wliczając w to zmiany konfiguracyjne poprzezSNMP. Jest to często przeoczana funkcjonalność; SNMP nie tylko wspiera żądania typu GetRequestdla monitoringu, lecz wspiera także żądania typu SetRequest do manipulowania obiektami i zmien-nymi udostępnianymi przez MIB. Problemem jest to, że nie wszyscy dostawcy oferują pełnewsparcie dla zarządzania konfiguracją za pomocą SNMP; kiedy to robią, często wykorzystują wła-sne, odpowiednio dostosowane MIB, spowalniając w ten sposób proces integracji z platformamizarządzania siecią.

Jak wspominaliśmy, SNMP istnieje od dziesięcioleci, lecz nie został zbudowany jako działającyw czasie rzeczywistym programistyczny interfejs do urządzeń sieciowych. Już teraz słychać o do-stawcach, którzy zapowiadają nadciągającą śmierć SNMP w kontekście zarządzania następnej ge-neracji i narzędzi automatyzacji. Mimo to SNMP występuje na praktycznie każdym urządzeniusieciowym, a do tego istnieją biblioteki Pythona do obsługi SNMP. Tak że jeśli musisz zebraćpodstawowe informacje z dużej grupy różnego typu urządzeń sieciowych, użycie SNMP możewciąż stanowić rozsądne rozwiązanie.

Tak jak SNMP od lat wykorzystywano do monitoringu sieci, tak SSH/Telnet i wiersz poleceń odlat wykorzystywano do zarządzania konfiguracją. Spójrzmy teraz na SSH/Telnet i wiersz poleceń.

SSH/Telnet i wiersz poleceń

Jeżeli kiedykolwiek zarządzałeś jakimś urządzeniem sieciowym, to z pewnością wykorzystywałeświersz poleceń do wysyłania komend w celu przeprowadzania jakichś akcji na urządzeniu. Naj-pewniej wprowadzałeś polecenia przez konsolę i w ramach sesji Telnet i SSH. Jak wspomnieliśmyw rozdziale 1., rzeczywistość jest taka, że migracja z protokołu Telnet na SSH jest największązmianą, która zaszła w ciągu ostatniej dekady w operacyjności sieciowej, a przecież sama zmiananie dotyczyła bezpośrednio operowania urządzeniem. Zmiana miała za zadanie zwiększenie bez-pieczeństwa, gdyż wprowadzała szyfrowanie do komunikacji z urządzeniem sieciowym.

Najistotniejszą rzeczą do zrozumienia w odniesieniu do zarządzania urządzeniami poprzez wierszpoleceń jest to, że wiersze poleceń stworzono dla ludzi. Osadzono je w urządzeniach, aby poprawićwygodę użytkowania dla ludzkich operatorów. Wiersz poleceń nie był przeznaczony do komuni-kacji maszyna-maszyna (tzn. do automatyzacji i oskryptowania sieci).





Jeżeli wywołasz polecenie show w wierszu poleceń urządzenia, otrzymasz surowy tekst. Nie ma w nimżadnej struktury. Najlepszą opcją przetworzenia odpowiedzi jest wykorzystanie przetwarzaniapotokowego (|) i słów kluczowych, takich jak grep, include i begin, do wyszukania odpowiedniejlinijki w konfiguracji. Przykładem tego jest sprawdzenie opisu interfejsu za pomocą poleceniashow interface Eth1 | include description. Oznacza to, że jeżeli chcesz wiedzieć, ile błędówCRC wystąpiło w interfejsie po wywołaniu show interface w ramach skryptu, zmuszony jesteś dowykorzystania tych samych typów wyrażeń regularnych lub przetworzenia ich w celu znalezieniatej informacji. Jest to nie do zaakceptowania.

Jeżeli jednak wiersz poleceń to jedyna dostępna opcja, to trzeba z niej korzystać. Dlatego też istniejemnóstwo platform zarządzania siecią i skryptów zbudowanych w ostatnich dwóch dekadach. Na-rzędzia te służą do zarządzania operacjami i automatyzują operacje poprzez umożliwienie wyko-rzystania wiersza poleceń w ramach sesji SSH do radzenia sobie ze skryptami pobierającymi in-formacje lub ręcznym przetwarzaniem. To nie jest tak, że SSH (wiersz poleceń) czyni automatyzacjęniemożliwą; raczej czyni automatyzację niezwykle pracochłonną i podatną na błędy.

Dostawcy sieciowi zaczęli zdawać sobie z tego sprawę i teraz większość nowych platform sprzęto-wych posiada jakiś rodzaj API, który upraszcza komunikację maszyna-maszyna (wiele z nich jestniekompletnych, dlatego przetestuj uważnie API swojego ulubionego urządzenia). Uzyskuje się w tensposób dużo prostsze podejście do automatyzacji, które jest bardziej dostosowane do powszechnychzałożeń wytwarzania oprogramowania.

Po krótkim przejrzeniu powszechnych protokołów, takich jak SSH i SNMP, zwrócimy uwagę naprotokół NETCONF, który jest coraz popularniejszy, gdyż odnosi się do automatyzacji sieci.

NETCONF

NETCONF to protokół warstwy zarządzania siecią. Na najwyższym poziomie może być porów-nywany do SNMP, jako że oba protokoły wykorzystywane są do wprowadzania zmian w konfigu-racji i do pozyskiwania danych od urządzeń sieciowych.

Różnice dotyczą szczegółów, rzecz jasna. Kilku najistotniejszym sprawom przyjrzymy się tutaj,więcej miejsca przeznaczymy na NETCONF w rozdziale 7.

NETCONF to protokół połączeniowy; często wykorzystuje SSH do transportu.

Dane wymieniane pomiędzy klientem NETCONF (narzędzie, skrypt automatyzacji) a serweremNETCONF (urządzenie sieciowe) kodowane są w formacie XML. Nie martw się, jeżeli nie za-poznałeś się dotąd z formatem XML; opiszemy go w rozdziale 5.

Zdalne wywołania procedur (ang. remote procedure calls — RPC) kodowane są w ramachdokumentu XML wysyłanego do urządzenia, a urządzenie procedury te przetwarza. Element<rpc> jest wykorzystywany do enkapsulacji żądania NETCONF wysyłanego z klienta do ser-wera. W kontekście tego pomyśl o tych zdalnych wywołaniach procedur jak o wykonywaniuopracowanych zawczasu operacji na urządzeniu. RPC są dla klienta metodą na zakomuniko-wanie serwerowi, jakiej struktury i jakiego typu żądania się wykonuje.

Wspierane RPC dopasowywane są bezpośrednio do wspieranych operacji i możliwości NETCONF dladanych urządzeń. Dla przykładu, dokonując zmiany w urządzeniu, wykonujesz operację edit-config.Jeżeli pozyskujesz dane, to wykonujesz operację get lub get-config. Operacje te zostają osa-dzone wewnątrz dokumentu XML, wewnątrz elementu <rpc> wysyłanego do urządzenia.





Dodatkowo NETCONF ma swoją wartość w tym, że wspiera zmiany opierające się na transak-cjach. Oznacza to, że jeżeli wprowadzasz więcej niż jedną zmianę w trakcie danej sesji NETCONFlub w ramach jednego dokumentu XML i wprowadzenie jednej z tych zmian zawiedzie, to całykomplet zmian nie zostanie zastosowany na urządzeniu (rzecz jasna, tego typu ustawienia możnatakże zmienić). Stoi to w opozycji do sekwencyjnego wysyłania komend przez wiersz poleceń,kończącego się tylko częściową zmianą konfiguracji, czego przyczyną jest literówka lub niepo-prawna komenda.

Było to proste wprowadzenie do protokołu NETCONF; jak wspomnieliśmy wcześniej, zagłębimysię w temat protokołu NETCONF w rozdziale 7.

Warto zwrócić uwagę na to, że samo wsparcie protokołu NETCONF (lub jakiej-kolwiek innej powszechnej metody transportu) przez dwa różne urządzenia nieoznacza, że są one kompatybilne z perspektywy narzędzia lub programisty. Nawetprzy założeniu, że oba urządzenia wspierają tę samą funkcjonalność i możliwościNETCONF, to niestety sposób, w jaki dane są modelowane, i tak zazwyczaj jest za-leżny od dostawcy. Modelowanie danych to sposób, w jaki urządzenie reprezentujedane i status konfiguracji. O powszechnych metodach reprezentacji danych w for-macie JSON i XML oraz o modelach YANG i powszechnym języku modelowaniadanych będzie mowa w rozdziale 5.

API typu RESTful

REST (skrót od REpresentational State Transfer) jest stylem wykorzystywanym do projektowaniai wytwarzania aplikacji sieciowych. Dlatego też systemy, które implementują zasady architekturopartych na REST i im podlegają, nazywane są systemami RESTful.

Z perspektywy sieciowej najpowszechniejsze urządzenia, które udostępniają API i podlegają sty-lowi architektury REST, to kontrolery sieciowe. Istnieją też urządzenia sieciowe, które opróczRESTful udostępniają powszechne API bazujące na HTTP.

Mimo że terminy REST i RESTful API są nowe z punktu widzenia sieci, to tak naprawdę wcho-dzisz w interakcję z wieloma systemami RESTful codziennie, kiedy przeglądasz internet z wyko-rzystaniem przeglądarki internetowej. Powiedzieliśmy, że REST jest stylem wykorzystywanym dowytwarzania aplikacji sieciowych. Styl ten opiera się na bezstanowym modelu klient-serwer,w którym klient śledzi postęp sesji i żadna informacja o stanie lub kontekście nie jest przetrzy-mywana na serwerze. A najlepsze w tym wszystkim jest to, że podległy protokół transportowy tozazwyczaj HTTP. Czyż nie jest to system, jakich wiele w internecie?

Oznacza to, że API RESTful operują podobnie jak systemy bazujące na HTTP. Najpierw potrzebujeszserwera sieciowego dostępnego przez URL (może to być np. kontroler SDN lub urządzenie sieciowe,z którym chcesz się komunikować), a następnie musisz wysłać odpowiednie żądanie HTTP na ten URL.

Na przykład, jeżeli chcesz pozyskać listę urządzeń z kontrolera SDN, wystarczy, że wyślesz żądanieHTTP GET na odpowiedni URL urządzenia, który może przyjąć taką postać: http://1.1.1.1/v1/devices.Odpowiedź, którą uzyskasz, będzie jakiegoś typu ustrukturyzowanymi danymi, takimi jak formatyXML lub JSON (o których powiemy w rozdziale 5.).





Istnieje jeszcze kilka spraw, których nie poruszyliśmy, takich jak uwierzytelnienie, kodowanie danychi to, jak wysłać żądanie HTTP, jeżeli wprowadzasz zmianę konfiguracyjną (HTTP PUT/POST/PATCH).Ta sekcja to jedynie krótkie, wysokopoziomowe wprowadzenie do REST i RESTful API, któreomówimy szczegółowo w rozdziale 7.

Następnie spojrzymy pokrótce na wpływ open networkingu na zarządzanie urządzeniami.

Wpływ open networkinguIstnieje rosnący trend robienia wszystkiego open (otwartym) — open source, open networking,otwarte API, OpenFlow, Open Compute, Open vSwitch, OpenDaylight, OpenConfig — lista jestdługa. Co prawda definicja otwartości jest wciąż dyskutowana, ale jedna rzecz jest pewna: ruch opennetworkingu stara się usprawnić, co tylko się da, w przypadku operacyjności i automatyzacji sieci.

Wraz z działaniami tego ruchu zaczęliśmy dostrzegać drastyczne zmiany w urządzeniach siecio-wych, a jest to przecież podstawowy powód, dla którego piszemy tę książkę.

Po pierwsze, obecnie wiele urządzeń wspiera Pythona wewnątrz pudełka. Oznacza to, że możeszod razu sięgnąć po dynamiczny interpreter Pythona (ang. Python Dynamic Interpreter) i wykonywaćskrypty Pythona lokalnie na każdym urządzeniu sieciowym. Pythona opisujemy szczegółowo w roz-dziale 4., gdzie dokładnie dowiesz się, o co nam chodzi.

Po drugie, wiele urządzeń wspiera teraz bardziej rozbudowane API, inne niż SNMP i SSH. Wśródnich na przykład dopiero co przez nas przedstawione NETCONF i RESTful API bazujące naHTTP. Większość urządzeń sieciowych (nie starszych niż 24 miesiące i wyposażonych w nowesystemy operacyjne) wspiera oba lub przynajmniej jedno z wymienionych API. O API urządzeńwięcej piszemy w rozdziale 7.

Na koniec — urządzenia sieciowe udostępniają wiele wewnętrznych zasobów Linuxa, które byływ przeszłości skrywane przed administratorami sieci. Obecnie możesz sięgnąć po powłokę bashna urządzeniach sieciowych i wywoływać polecenia, takie jak ifconfig, pisać skrypty bash i in-stalować narzędzia zarządzania i konfiguracji poprzez menedżery pakietów, takie jak apt i yum.Dowiesz się o tych rzeczach w rozdziale 3.

Co prawda open networking nie zawsze oznacza intensywniejszą współpracę pomiędzy różnymirozwiązaniami, ale oczywiste jest, że urządzenia sieciowe i kontrolery otwierają się na operowaniena nich w dużo bardziej programowalny sposób, lepiej dostosowany do ulepszonej automatyzacjisieci. Jeszcze wiele lat temu rzeczy takie jak API NX-API firmy Cisco czy eAPI firmy Arista, IOS-XERESTCONF/NETCONF firmy Cisco lub jakikolwiek inny nowoczesny kontroler SDN wyposa-żone w API nie istniały. Zysk dla operatorów jest taki, że dzięki zastosowaniu API mogą przejąćkontrolę nad swoimi sieciami i zredukować nieefektywność związaną z operacyjnością.





Automatyzacja sieci w erze SDNTeraz spojrzymy na to, jak istotna jest automatyzacja sieci mimo wdrażania kontrolerów, takichjak OpenDaylight czy nawet produkty komercyjne, np. Cisco ACI lub VMware NSX. Operacje,które kontrolery przeprowadzają w sieci, np. w obrębie sterowania lub zarządzania zasadamii konfiguracjami, nie są istotne w tej sekcji.

Kontrolery coraz częściej stają się częścią architektur następnej generacji. Dostawcy, tacy jakCisco, Juniper, VMware, Big Switch, Plexxi, Nuage, Viptela, oferują platformy kontrolerów dlarozwiązań następnej generacji; są także dostępne kontrolery open source, takie jak OpenDaylighti OpenContrail.

Niemal każdy kontroler dostępny na rynku udostępnia północny (ang. nortbound) interfejsRESTful API, czyniąc kontrolery niesamowicie proste w automatyzacji. Mimo że kontrolery samew sobie upraszczają zarządzanie i zwiększają widoczność urządzeń, to wciąż możesz wprowadzaćzmiany ręcznie poprzez GUI kontrolera, co jest podatne na błędy. Jeżeli zostało wdrożonych kilkakontrolerów, bez względu na to, czy od tego samego dostawcy, czy od różnych dostawców, toproblem ręcznych zmian, rozwiązywania problemów i zbierania danych i tak nie znika.

Na zakończenie tego rozdziału trzeba zauważyć, że nawet w tej nowej erze architektur SDN i roz-wiązań sieciowych opartych na kontrolerach wciąż potrzebne są automatyzacja, lepsza operacyj-ność i bardziej przewidywalne rezultaty.

PodsumowanieRozdział ten przedstawił przegląd korzyści wynikających z różnych rodzajów automatyzacji sieci;wprowadzenie do powszechnych API urządzeń, takich jak SNMP, wiersz poleceń/SSH, a co waż-niejsze, API NETCONF i RESTful oraz krótką wzmiankę o języku modelowania sieci YANG,który opiszemy szczegółowo w rozdziale 5.

Zakończyliśmy krótkim przejrzeniem wpływu ruchu open networking na operacyjność i auto-matyzację sieci. Na koniec poruszyliśmy temat zalet automatyzacji sieci, które są oczywiste, mimoże są wdrażane kontrolery SDN.

W następnych rozdziałach zgłębimy wspomniane technologie, pokażemy praktyczne, z życia wzięteprzykłady i przyjrzymy się zasobom ludzkim i kulturze organizacji wymaganym do przeprowadze-nia automatyzacji. Ludziom i kulturze organizacji jest poświęcony przede wszystkim Rozdział 11.




307

Skorowidz

Aadres IP, 487akceptacja porażki, 472Ansible, 347

biblioteka NAPALM, 516generowanie raportów, 376grupa all, 353grupy urządzeń, 351instalacja modułów, 381moduł, 358

config, 368debug, 372facts, 371

modułysieciowe, 362stron trzecich, 379

plik inwentarza, 349polecenie show, 373priorytet zmiennej, 353przeglądanie danych sieciowych, 371scenariusz, 356sprawdzenia zgodności, 375tryby weryfikacji, 369tworzenie scenariuszy, 362wykonywanie scenariusza, 359zarządzanie zmiennymi

grup, 352hosta, 353

zmienne, 352API, 45

bazujące na HTTP, 200, 211RESTCONF, 244, 248, 251Salt, 409sieciowe, 199, 211

automatyzacja, 226

typu RESTful, 48urządzeń, 27, 45

aplikacja Postman, 213architektura

OpenDaylight, 33Salt, 383StackStorm, 422

atrybut zadania register, 373automatyzacja, 226, 345

budowy, 454ciągła integracja, 440narzędzie

Ansible, 347Salt, 382StackStorm, 419

serwerów linuxowych, 348sieci, 28, 35, 38, 50, 182, 467sieci sterowana testami, 463sterowana zdarzeniami, 419urządzeń sieciowych, 349

Bbash, 56biblioteka

Jinja2, 185NAPALM, 507ncclient, 253–259, 263, 268, 272requests, 226

BLOB, 292

CCentOS, 53CentOS 7.1, 73certyfikaty, 475




522 Skorowidz

ciągła integracja, CI, 442, 439, 447ciągłe dostarczanie, CD, 444Cisco IOS-XE, 266Cisco IOS-XR, 272Cisco NX-API, 229cURL, 211

Ddane poufne, 300Debian, 54, 70demon, 69, 73Django, 181Docker, 494drzewo rozpinające, 93duże obiekty binarne, 292dynamiczne wprowadzanie danych, 184dystrybucje Linuxa, 52, 55dziedziczenie szablonów, 195

EeAPI

autokonfiguracja opisów interfejsów, 242Command Explorer, 239skrypt, 239

FFedora, 53filtr zapytania, 261filtry Jinja, 192, 194, 195format

JSON, 170, 172, 235SLS, 386, 398XML, 163YAML, 158, 161

formaty danych, 155funkcja enumerate(), 132funkcje, 132

sieciowe, 24

Ggałęzie, 311, 315generowanie

konfiguracji interfejsów, 191plików konfiguracyjnych, 405raportów, 376, 408

Git, 283architektura, 287gałęzie, 315indeks, 287informacje

o gałęzi, 317o użytkownikach, 291o zatwierdzeniach, 305

instalacja systemu, 289katalog roboczy, 287klonowanie repozytoriów, 328łańcuch zatwierdzeń, 312naprawa zatwierdzeń, 294przeglądanie zmian, 308przełączanie się na gałąź, 316przewijanie scaleń, 319repozytorium, 287–290, 303rozwidlanie repozytoriów, 339scalanie

gałęzi, 318informacji, 325

serwisy online, 338synchronizowanie repozytoriów, 340usuwanie

gałęzi, 318, 320niescalonej gałęzi, 322plików, 297

wersje plików, 307wiązanie zdalnych repozytoriów, 324współdzielone repozytorium, 331, 335współpraca z systemami, 323wykluczanie plików, 299, 301zarządzanie gałęziami, 311zatwierdzanie

śledzonych plików, 294scalenia, 320zmian, 287, 291, 292, 293

zdalne repozytoria, 327żądania wciągnięcia, 341

grupa all, 353

HHEAD, 313HTTP, 200

kody odpowiedzi, 202




Skorowidz 523

Iinformacje

o gałęzi, 317o repozytorium, 303o zatwierdzeniach, 305z logu, 304

instalacjamodułów, 381OVS, 496paczek, 146

instrukcje warunkowe, 187, 188interakcja z Linuksem, 56interfejs, 74, 76

adres IP, 77ipvlan, 495konfigurowanie, 78macvlan, 479

konfigurowanie, 480tworzenie, 480usuwanie, 480

macvtap, 485programowania aplikacji, Patrz APIustawienie MTU, 77VLAN, 81, 83wyłączanie, 76

interpreter Pythona, 98, 142inżynierowie sieciowi, 96IOS-XE, 244, 251, 255

Jjednolity interfejs, 201język

Jinja, 184XSLT, 166YANG, 174

języki szablonów, 180Jinja, 183

dziedziczenie szablonów, 195filtry, 192, 194zmienne, 197

JSON, 170, 235Juniper vMX Junos, 269

Kkatalog, 61Klient-Serwer, 201klonowanie repozytoriów, 328

komenda show, 236komunikacja bezstanowa, 201konfiguracja

interfejsu, 74, 78mostków Linux, 91OVS, 497portów przełącznika, 187, 188sieci Docker, 494sieciowa, 179urządzenia

Cisco IOS-XE, 255, 266Cisco IOS-XR, 272Juniper vMX Junos, 263, 269

VRF, 487kontenery, 501kontrola

rewizji, 283wersji, Patrz system kontroli wersji, 283, Patrz

także GITkontrolery, 33krotka, 123

LLinux, 51, 479lista, 114

interfejsów, 75logika

biznesowa, 414warunkowa, 125

LXC, 494

Łłańcuch

zatwierdzeń, 312filtrów Jinja, 193

Mmaszyna wirtualna, 482metoda

append(), 115count(), 105, 116endswith(), 103format(), 106get, 255get(), 120index(), 117insert(), 116




524 Skorowidz

metodaisdigit(), 105items(), 122join(), 107keys(), 121lower(), 103pop(), 117, 121sort(), 118split(), 107startswith(), 103strip(), 104update(), 121upper(), 103values(), 121

metodyHTTP, 202typu tekstowego, 101wbudowane list, 115

migracje, 41modele danych, 155

danych w YAML, 162schemat JSON, 173XSD, 164YANG, 174

moduł, 143config, 368debug, 372facts, 371test, 395

modułyAnsible, 358NAPALM, 380NTC, 380wykonawcze, 392

mostek Linux, 90mostkowanie, 89

maszyn wirtualnych, 482MTU, 77

NNAPALM, 507

integrowanie biblioteki, 516pozyskiwanie danych, 514scalenie konfiguracji, 512zarządzanie konfiguracją, 508zastąpienia konfiguracji, 508

narzędziaautomatyzacji, 345testowania, 463wdrażania, 462

narzędzieeAPI Command Explorer, 239NX-API Developer Sandbox, 229Salt, 382StackStorm, 419

nasłuchiwanie magistrali, 413ncclient, 253, 257, 259, 263, 268, 272NETCONF, 47, 203, 218, 273

operacje, 206transport, 205wiadomości, 206zawartość, 210

netmiko, 275niezmienność, 368non-RESTful API, 203NX-API, 229, 231, 233, 235NX-API Developer Sandbox, 229

Oobiekt Manager, 254obiekty

drzew, 292zatwierdzenia, 293

odczytywanie z pliku, 136open networking, 49Open vSwitch, 496

instalacja, 496konfiguracja, 497kontenery, 501maszyny wirtualne, 503obciążenie pracą, 500wewnętrzne porty, 504

OpenFlow, 19, 21, 24operacja

delete, 268merge, 268replace, 268

operacje matematyczne, 109

Pparametryzacja nazw plików, 407pary wirtualnego Ethernetu, 491




Skorowidz 525

pętla, 128, 187, 188for, 129, 189while, 128

pip, 146planowanie wykonania stanu, 407plik, 61, 136

inwentarza, 349konfiguracyjny nadzorcy, 399

plikikonfiguracyjne, 88konfiguracyjne sieci, 405kopiowanie, 63przenoszenie, 63SLS, 398YAML, 360zmienianie nazw, 63zmiennych, 360, 361, 364

podkomenda, 70podwójny nawias klamrowy, 39polecenie netconfig, 403Postman, 213potok, 443

ciągłej integracji, 448programowanie

sieciowe, 181sterowane testami, TDD, 446

protokółNETCONF, 205, 257OpenFlow, 20SNMP, 46

przedsiębiorstwa IT, 468przekazywanie

argumentów, 145komend konfiguracyjnych, 237

przełączanie, 89przełącznik, 187

konfiguracja portów, 187, 188przestrzenie nazw, 486przynależność, 127

Rraportowanie, 43reaktor, 413Red Hat Enterprise Linux, 53reguły, 434renderowanie pliku szablonu, 185requests, 226REST, 48

RESTful API, 200router, 87routing, 83

pre-procesowy, 487rozszerzenie modelu pracy, 329rozwiązywanie problemów, 44rozwidlanie repozytoriów, 339rozwijanie umiejętności, 473RPM, 54

SSalt, 382

API, 409architektura, 383automatyzacja urządzeń sieciowych, 384biblioteka NAPALM, 518celowanie, 394dane o urządzeniu, 393dostęp do danych, 401format SLS, 386funkcje, 396generowanie raportów, 408informacje o narzędziu, 416infrastruktura sterowana zdarzeniami, 411moduł

stanu, 398test, 395

moduły wykonawcze, 392nasłuchiwanie magistrali, 413opcje wyjść dla modułów, 396pamięć podręczna, 417plik

górny, 389konfiguracyjny sługi, 400

przekierowywanie zdarzeń, 412rozszerzenia, 418salt-ssh, 383sługi pośredniczące, 384, 400wykonanie stanu, 407zależności stanów, 405zapisywanie informacji, 418zarządzanie konfiguracjami, 401zdalne wykonywanie funkcji, 409ziarna, 390, 392złożone dopasowanie, 394

scalanie informacji, 325scenariusz, 356, 362SDB, 416




526 Skorowidz

SDN, 50SD-WAN, 31sensory, 432shebang, 67, 141sieci

centrów danych, 31kontenerów Linuksa, 492maszyn wirtualnych, 482oparte na kontrolerach, 33oparte na Linuksie, 74programowalne, 21sterowane programowo, 19, 23

sieciowa przestrzeń nazw, 486, 487interfejsy, 488łączenie, 491OVS, 500polecenia, 490tworzenie, 487usuwanie, 487

silniki, 412skrypt, 67, 140, 236, 237

eAPI, 241startowy init, 69

SLS, 398słownik, 119, 189, 191SNMP, 45, 46sprzętowe przełączanie, 29SSH, 22, 46StackStorm, 419

akcje, 423architektura, 422biblioteka NAPALM, 519przypływy pracy, 423reguły, 434sensory, 432wyzwalacze, 432

strategia organizacyjna, 468struktury danych, 157sygnalizatory, 412system

IOS-XE, 251kontroli wersji, 283

środowisko sieciowe, 285plików, 57

systemd, 70szablony, 181

automatyzacja sieci, 182dziedziczenie, 195konfiguracji, 363

konfiguracji sieci, 38, 179, 183Jinja, 365, 401

programowanie sieciowe, 181XSLT, 166

Śścieżki wyszukiwania, 62śledzenie zmian, 284

Ttablice prawdy, 111TDD, Test-Driven Development, 446Telnet, 22, 46testowanie, 459, 463Thorium, 414tryb

hybrydowy, 20konfiguracyjny, 277limitu, 369weryfikacji, 369większej szczegółowości komunikatu, 369

tworzeniefiltrów Jinja, 194gałęzi Git, 315plików i katalogów, 61plików zmiennych, 364programów, 140scenariuszy, 362szablonów Jinja, 365zmiennych, 197

typcałkowity, 157tekstowy, 101, 157

typyautomatyzacji sieci, 38danych, 100, 157

liczbowe, 109logiczne, 111, 157

UUbuntu, 54, 71uprawnienia, 64uruchomianie programów, 67urządzenie

Cisco IOS-XE, 266Cisco IOS-XR, 272




Skorowidz 527

IOS-XE, 244Juniper vMX Junos, 263, 269

usługa, 69usługi w tle, 71, 73usuwanie

gałęzi, 318, 320interfejsów VLAN, 81niescalonej gałęzi, 322plików i katalogów, 62, 297sieciowych przestrzeni nazw, 487

użycie interfejsów macvlan, 480

VVLAN, 81VRF, virtual routing and forwarding, 32

Wwarunki stanów, 405wdrażanie, 462

konfiguracji, 367konfiguracji sieci, 406

wersje plików, 307wiersz poleceń, 46, 74wirtualizacja

funkcji sieciowych, 24sieci, 26

wirtualne przełączanie, 26wykluczanie plików, 299, 301wysyłanie komend, 277wyświetlanie listy interfejsów, 75wyzwalacze, 432

XXML, 163, 166, 169XML Schema Definition, 164XQuery, 169XSD, 164XSLT, 166

YYAML, 158YANG, 174

Zzapis symboliczny, 66zapisywanie do pliku, 138zapytania do baz danych, 416zarządzanie

konfiguracjami, 42, 251zmiennymi

grup, 352hosta, 353

zbieranie danych, 40zbiór, 123zgodność, 43ziarna, 390, 392zmienianie uprawnień, 64zmienne, 197znak zachęty urządzenia, 277

Żżądanie

GET, 248PATCH, 249scalenia, 452, 453

żądania HTTP, 202







http://program-partnerski.helion.pl

Documents

Tytuł oryginału: Network Programmability and Automation ...Ewolucja płaszczyzny zarządzania od SNMP do API urządzeń 45 Interfejs programowania aplikacji (API) 45 Wpływ open