SDCM się skończył, ale niekontrolowane pragnienie pisania pozostało.

Przez długie lata nasz brat cierpiał z powodu rutynowej pracy, skrzyżował palce przed commitem i niedosypiał z powodu nocnych rollbacków.
Ale ciemne czasy dobiegną końca.

Tym artykułem rozpocznę serię o tym, jak do mnie widzi się automatyzację.
Po drodze przyjrzymy się etapom automatyzacji, przechowywaniu zmiennych, formalizacji projektu, RestAPI, NETCONF, YANG, YDK i będziemy programować naprawdę dużo.
Dla mnie oznacza, że a) to nie jest obiektywna prawda, b) nie jest to bezwzględnie najlepsze podejście c) moje zdanie nawet w trakcie przechodzenia od pierwszego do ostatniego artykułu może się zmienić — szczerze mówiąc, od etapu roboczego do publikacji wszystko przepisywałem dwukrotnie.

Spis treści

1. Cele
   1. Sieć — jak jeden organizm
   2. Testowanie konfiguracji
   3. Wersjonowanie
   4. Monitorowanie i samonaprawa usług

2. Narzędzia
   1. System inwentaryzacji
   2. System zarządzania przestrzenią IP
   3. System opisu usług sieciowych
   4. Mechanizm inicjalizacji urządzeń
   5. Model konfiguracyjny niezależny od dostawcy
   6. Interfejs dostawcy specyficzny dla sterownika
   7. Mechanizm dostarczania konfiguracji na urządzenie
   8. CI/CD
   9. Mechanizm tworzenia kopii zapasowej i wykrywania odchyleń
   10. System monitorowania

3. Podsumowanie

W ADCSM spróbuję prowadzić format nieco różniący się od SDCM. Nadal będą się pojawiały obszerne artykuły numerowane, a pomiędzy nimi będę publikować małe notatki z codziennego doświadczenia. Postaram się tutaj zmierzyć z perfekcjonizmem i nie dopracowywać ich nadmiernie.

Jak to zabawne, że po raz drugi muszę przechodzić tę samą drogę.

Na początku musiałem sam pisać artykuły o sieciach, ponieważ nie było ich w runecie.

Teraz nie mogłem znaleźć wszechstronnego dokumentu, który usystematyzowałby podejścia do automatyzacji i analizowałby powyższe technologie na prostych przykładach praktycznych.

Może się mylę, więc rzucajcie linki do przydatnych zasobów. Jednak to nie zmieni mojej determinacji do pisania, ponieważ głównym celem jest nauczenie się czegoś dla siebie, a ułatwienie życia innym to miły bonus, który podkreśla rozprzestrzenianie doświadczenia.

Spróbujemy wziąć średniej wielkości centrum danych LAN DC i opracować całą schemat automatyzacji.
Będę robić niektóre rzeczy praktycznie po raz pierwszy razem z Wami.

W opisywanych tutaj pomysłach i narzędziach nie będę oryginalny. Dmitrij Figol ma znakomity kanał ze streamingami na ten temat..
Artykuły w wielu aspektach będą z nimi pokrywać się.

W LAN DC 4 centra danych, około 250 przełączników, pół tuzina routerów i para zapór ogniowych.
Nie Facebook, ale wystarczająco, aby głęboko zastanowić się nad automatyzacją.
Panuje jednak pogląd, że jeśli masz więcej niż 1 urządzenie, już potrzebna jest automatyzacja.
W rzeczywistości trudno sobie wyobrazić, że ktoś teraz może żyć bez przynajmniej paczki prostych skryptów.
Chociaż słyszałem, że są takie firmy, gdzie ewidencja adresów IP prowadzona jest w Excelu, a każde z tysięcy urządzeń sieciowych konfiguruje się ręcznie i ma swoją unikalną konfigurację. Można to na pewno uznać za nowoczesną sztukę, ale uczucia inżyniera z pewnością byłyby zranione.

Cele

Teraz postawimy maksymalnie abstrakcyjne cele:

• Sieć — jak jeden organizm
• Testowanie konfiguracji
• Wersjonowanie stanu sieci
• Monitorowanie i samonaprawa usług

Później w tym artykule omówimy, jakie narzędzia będziemy stosować, a w następnych dokładnie cele i środki.

Sieć — jak jeden organizm

Określająca fraza cyklu, chociaż na pierwszy rzut oka może wydawać się niewielka: będziemy konfigurować sieć, a nie pojedyncze urządzenia..
Przez ostatnie lata obserwujemy przesunięcie akcentów w kierunku traktowania sieci jako jednego bytu, stąd przychodzące do naszego życia Software Defined Networking, Intent Driven Networks i Autonomous Networks.
W końcu, co globalnie wymagają aplikacje od sieci: łączność między punktami A i B (no czasami +B-J) i izolację od innych aplikacji i użytkowników.

I w ten sposób nasza zadanie w tej serii — zbudować system, który wspiera aktualną konfigurację całej sieci, która już dekomponuje się na aktualną konfigurację na każdym urządzeniu zgodnie z jego rolą i lokalizacją.
System Zarządzanie siecią oznacza, że aby wprowadzić zmiany, zwracamy się do niej, a ona z kolei oblicza potrzebny stan für każde urządzenie i konfiguruje je.
W ten sposób minimalizujemy prawie do zera ręczne korzystanie z CLI — wszelkie zmiany w konfiguracjach urządzeń lub projektach sieci muszą być sformalizowane i udokumentowane — i dopiero potem wprowadzane na odpowiednie elementy sieci.

Na przykład, jeśli zdecydowaliśmy, że od teraz przełączniki w Kazaniu powinny ogłaszać dwie sieci zamiast jednej, to

1. Najpierw udokumentujmy zmiany w systemach
2. Generujemy docelową konfigurację wszystkich urządzeń w sieci
3. Uruchamiamy program aktualizacji konfiguracji sieci, który oblicza, co należy usunąć na każdym węźle, co dodać i przywraca węzły do odpowiedniego stanu.

Ręcznie wprowadzamy zmiany tylko na pierwszym kroku.

Testowanie konfiguracji

Wiadomo,, że 80% problemów pojawia się podczas zmiany konfiguracji — pośrednim dowodem na to jest to, że w okresie noworocznych wakacji zwykle jest spokojnie.
Osobiście byłem świadkiem dziesiątek globalnych przestojów z powodu błędu ludzkiego: niewłaściwa komenda, wykonano ją w złej gałęzi konfiguracji, zapomniano o społeczności, globalnie usunięto MPLS na routerze, skonfigurowano pięć urządzeń, a na szóstym nie zauważono błędu, wprowadzono stare zmiany dokonane przez inną osobę. Scenariuszy jest mnóstwo.

Automatyzacja pozwoli nam popełniać mniej błędów, ale na większą skalę. Można zablokować nie tylko jedno urządzenie, ale całą sieć naraz.

Od zawsze nasi przodkowie sprawdzali poprawność wprowadzanych zmian wyostrzonym okiem, stalowymi nerwami i funkcjonalnością sieci po ich wdrożeniu.
Ci przodkowie, których prace prowadziły do przestojów i katastrofalnych strat, pozostawiali mniej potomstwa i z czasem powinni wyginąć, ale ewolucja jest procesem powolnym, dlatego do tej pory nie wszyscy wstępnie sprawdzają zmiany w laboratorium.
Jednak na czołowej linii postępu są ci, którzy zautomatyzowali proces testowania konfiguracji i jej dalszego zastosowania w sieci. Innymi słowy — przejęli procedurę CI/CD (Continuous Integration, Continuous Deployment) od programistów.
W jednej z części omówimy, jak zrealizować to za pomocą systemu kontroli wersji, prawdopodobnie Gita.

Gdy tylko zaakceptujesz myśl o sieciowym CI/CD, nagle metoda weryfikacji konfiguracji poprzez jej zastosowanie w sieci roboczej wyda ci się ciemnośredniowiecznym ignorancją. O mniej więcej tak, jakby uderzać młotkiem w głowicę bojową.

Organiczne rozwinięcie idei o systemu zarządzaniu siecią i CI/CD staje się pełnoprawnym wersjonowaniem konfiguracji.

Wersjonowanie

Będziemy zakładać, że przy jakichkolwiek zmianach, nawet najbardziej nieznaczących, nawet na jednym niedostrzegalnym urządzeniu, cała sieć przechodzi z jednego stanu do innego.
I zawsze nie wykonujemy komendy na urządzeniu, zmieniamy stan sieci.
Nazwijmy te stany wersjami?

Załóżmy, że bieżąca wersja to 1.0.0.
Zmienił się adres IP interfejsu Loopback na jednym z ToR? To wersja podrzędna — otrzyma numer 1.0.1.
Zrewidowaliśmy polityki importu tras w BGP — to już nieco poważniejsze — 1.1.0.
Postanowiliśmy pozbyć się IGP i przejść tylko na BGP — to już radykalna zmiana designu — 2.0.0.

Różne centra danych mogą mieć różne wersje — sieć się rozwija, wprowadza nowe sprzęty, gdzieś dodawane są nowe poziomy spine, a gdzieś nie, itp.

O semantyczne wersjonowanie Omówimy w osobnym artykule.

Powtórzę — każda zmiana (z wyjątkiem komend diagnostycznych) to aktualizacja wersji. O wszelkich odstępstwach od aktualnej wersji powinny być informowani administratorzy.

To samo dotyczy cofnięcia zmian — to nie anullowanie ostatnich komend, to nie rollback za pomocą systemu operacyjnego urządzenia — to doprowadzenie całej sieci do nowej (starej) wersji.

Monitorowanie i samonaprawa usług

To oczywiste zadanie w nowoczesnych sieciach staje się na nowym poziomie.
Często u dużych dostawców usług stosuje się podejście, że upadła usługa musi być bardzo szybko naprawiona i podniesiona nowa, zamiast rozwiązywać, co się stało.
„Bardzo” oznacza, że z każdej strony należy się obficie obkleić monitorowaniem, które w ciągu sekund wykryje najmniejsze odchylenia od normy.
I tutaj już niewystarczające są zwykłe metryki, takie jak obciążenie interfejsu czy dostępność węzła. Nie wystarcza też ręczne monitorowanie przez dyżurnego.
Dla wielu rzeczy powinno być w ogóle Self-Healing — monitorowania zapalają się na czerwono i same idą przyłożyć trochę liści, gdzie boli.

I tutaj również monitorujemy nie tylko pojedyncze urządzenia, ale i zdrowie sieci w całości, przy czym zarówno w boksie białym, co jest stosunkowo zrozumiałe, jak i w boksie czarnym, co już jest trudniejsze.

Co będziemy potrzebować do realizacji takich ambitnych planów?

• Mieć listę wszystkich urządzeń w sieci, ich lokalizację, role, modele, wersje oprogramowania.
  kazan-leaf-1.lmu.net, Kazan, leaf, Juniper QFX 5120, R18.3.
• Mieć system opisu usług sieciowych.
  IGP, BGP, L2/3VPN, Polityka, ACL, NTP, SSH.
• Umieć zainicjować urządzenie.
  Hostname, Mgmt IP, Mgmt Route, Users, RSA-Keys, LLDP, NETCONF
• Konfigurować urządzenie i przywracać konfigurację do wymaganej (w tym również starszej) wersji.
• Testować konfigurację
• Okresowo sprawdzać stan wszystkich urządzeń pod kątem odchyleń od aktualnych i informować odpowiednich.
  W nocy ktoś cicho dodał regułę w ACL.
• Monitorować niezawodność.

Narzędzia

Brzmi wystarczająco skomplikowanie, aby rozpocząć dekompozycję projektu na komponenty.

I będzie ich dziesięć:

1. System inwentaryzacji
2. System zarządzania przestrzenią IP
3. System opisu usług sieciowych
4. Mechanizm inicjalizacji urządzeń
5. Model konfiguracyjny niezależny od dostawcy
6. Interfejs dostawcy specyficzny dla sterownika
7. Mechanizm dostarczania konfiguracji na urządzenie
8. CI/CD
9. Mechanizm tworzenia kopii zapasowej i wykrywania odchyleń
10. System monitorowania

To zresztą przykład tego, jak zmieniał się pogląd na cele cyklu — w szkicu komponentów było 4.

Na ilustracji przedstawiłem wszystkie komponenty i samo urządzenie.
Przecinające się komponenty współdziałają ze sobą.
Im większy blok, tym więcej uwagi należy poświęcić temu komponentowi.

Komponent 1. System inwentaryzacyjny

Oczywiście chcemy wiedzieć, jakie urządzenie, gdzie się znajduje, do czego jest podłączone.
System inwentaryzacyjny jest nieodłączną częścią każdej firmy.
Najczęściej dla urządzeń sieciowych firma ma oddzielny system inwentaryzacyjny, który rozwiązuje bardziej specyficzne zadania.
W ramach cyklu artykułów będziemy nazywać to DCIM — Zarządzanie Infrastrukturą Centrum Danych. Choć termin DCIM w ścisłym znaczeniu obejmuje znacznie więcej.

Dla naszych celów będziemy w nim przechowywać następujące informacje o urządzeniu:

• Numer inwentarzowy
• Nazwa/opis
• Model (Huawei CE12800, Juniper QFX5120 itd.)
• Charakterystyczne parametry (płyty, interfejsy itd.)
• Rola (Leaf, Spine, Border Router itd.)
• Lokalizacja (region, miasto, centrum danych, szafka, jednostka)
• Interkoneksje między urządzeniami
• Topologia sieci

Jest jasne, że sami chcemy znać to wszystko.
Ale czy to pomoże w automatyzacji?
Z pewnością.
Na przykład, wiem, że w danym centrum danych na przełącznikach Leaf, jeśli to Huawei, ACL do filtrowania określonego ruchu powinny być stosowane na VLAN, a jeśli to Juniper — to na jednostkę 0 fizycznego interfejsu.
Albo trzeba rozłożyć nowy serwer Syslog na wszystkie bramy regionu.

Będziemy przechowywać w niej również wirtualne urządzenia sieciowe, na przykład wirtualne routery lub reflektory routingu. Możemy dodać serwery DNS, NTP, Syslog i w ogóle wszystko, co w ten czy inny sposób odnosi się do sieci.

Komponent 2. System zarządzania przestrzenią IP

Tak, nawet dzisiaj są grupy ludzi, które prowadzą rejestrację prefiksów i adresów IP w pliku Excel. Jednak nowoczesne podejście to baza danych z interfejsem na nginx/apache, API i szerokimi funkcjami do zarządzania adresami IP i sieciami z podziałem na VRF.
IPAM — Zarządzanie adresami IP.

W naszej bazie danych będziemy przechowywać następujące informacje:

• VLAN
• VRF
• Sieci/Podsieci
• adresy IP
• Przypisanie adresów do urządzeń, sieci do lokalizacji oraz numerów VLAN

Zrozumiałe jest, że chcemy mieć pewność, że przy przydzielaniu nowego adresu IP dla loopbacka ToR nie napotkamy na problem, że został on już komuś przypisany. Albo że ten sam prefiks użyliśmy dwa razy w różnych częściach sieci.
Ale jak to pomoże w automatyzacji?
Łatwo.
W systemie żądamy prefiksu z rolą Loopbacks, w którym dostępne są do przydzielenia adresy IP — jeśli się znajdzie, przydzielamy adres, jeśli nie, prosimy o utworzenie nowego prefiksu.
Lub przy tworzeniu konfiguracji urządzenia możemy z tego samego systemu dowiedzieć się, w jakim VRF powinien znajdować się interfejs.
A przy uruchamianiu nowego serwera skrypt sprawdza w systemie, w którym przełączniku serwerowym, w którym porcie i jaka podsieć jest przypisana do interfejsu — z niego będziemy przydzielać adres serwera.

Nasuwają się wnioski, że należy scalić DCIM i IPAM w jeden system, aby nie dublować funkcji i nie obsługiwać dwóch podobnych podmiotów.
Tak właśnie zrobimy.

Komponent 3. System opisu usług sieciowych

Jeśli pierwsze dwa systemy przechowują zmienne, które jeszcze jakoś muszą być wykorzystane, to trzeci opisuje dla każdej roli urządzenia, jak powinno być skonfigurowane.
Warto wyróżnić dwa różne typy usług sieciowych:

• Usługi infrastrukturalne
• Usługi klienckie.

Pierwsze mają na celu zapewnienie podstawowej łączności i zarządzania urządzeniem. Można tu wymienić VTY, SNMP, NTP, Syslog, AAA, protokoły routingu, CoPP itp.
Drugie organizują usługi dla klienta: MPLS L2/L3VPN, GRE, VXLAN, VLAN, L2TP itp.
Oczywiście istnieją też przypadki graniczne — gdzie zaklasyfikować MPLS LDP, BGP? Protokoły routingu również mogą być używane dla klientów. Ale to nie jest kluczowe.

Oba typy usług dzielą się na prymitywy konfiguracyjne:

• fizyczne i logiczne interfejsy (tag/untag, mtu)
• Adresy IP i VRF (IP, IPv6, VRF)
• ACL i polityki przetwarzania ruchu
• Protokoły (IGP, BGP, MPLS)
• Polityki routingu (listy prefiksów, społeczności, filtry ASN).
• Usługowe serwisy (SSH, NTP, LLDP, Syslog…)
• Itd.

Trudno mi na razie powiedzieć, jak dokładnie to zrobimy. Rozwiążemy to w osobnym artykule.

Jeśli podejdziemy do tego nieco bliżej życia, moglibyśmy opisać, co
Przełącznik Leaf musi mieć sesje BGP z wszystkimi podłączonymi przełącznikami Spine, importować do procesu podłączone sieci, akceptować od przełączników Spine tylko sieci z określonym prefiksem. Ograniczać CoPP IPv6 ND do 10 pps itd.
Z kolei spine'y utrzymują sesje ze wszystkimi podłączonymi leafami, działając jako root-reflectory, i akceptują od nich tylko trasy o określonej długości i z określoną społecznością.

Komponent 4. Mechanizm inicjalizacji urządzenia

Pod tym nagłówkiem łączę wiele działań, które muszą mieć miejsce, aby urządzenie pojawiło się na radarach i można było do niego zdalnie uzyskać dostęp.

1. Wprowadzenie urządzenia do systemu inwentaryzacyjnego.
2. Przydzielenie adresu IP zarządzania.
3. Skonfigurowanie podstawowego dostępu do niego:
   Nazwa hosta, adres IP zarządzania, trasa do sieci zarządzającej, użytkownicy, klucze SSH, protokoły — telnet/SSH/NETCONF

Istnieją trzy podejścia:

• Całkowicie ręcznie. Urządzenie jest przynoszone na stanowisko, gdzie zwykły człowiek wprowadza je do systemów, podłącza konsolą i konfiguruje. Może działać w niewielkich, statycznych sieciach.
• ZTP — Zero Touch Provisioning. Sprzęt przyjechał, ustawił się, po DHCP otrzymał adres, połączył się z specjalnym serwerem, samonastawił.
• Infrastruktura serwerów konsolowych, gdzie wstępna konfiguracja odbywa się automatycznie przez port konsolowy.

O trzech rzeczach porozmawiamy w osobnym artykule.

Komponent 5. Wzorzec konfiguracyjny niezależny od dostawcy

Do tej pory wszystkie systemy były rozdzielnymi fragmentami, które dawały zmienne i deklaratywny opis tego, co chcielibyśmy widzieć w sieci. Ale prędzej czy później trzeba będzie zmierzyć się z konkretnymi rzeczami.
Na tym etapie dla każdego konkretnego urządzenia prymitywy, serwisy i zmienne są łączone w model konfiguracyjny, który właściwie opisuje pełną konfigurację konkretnego urządzenia, ale w sposób niezależny od dostawcy.
Co daje ten krok? Dlaczego nie formować od razu konfiguracji urządzenia, którą można po prostu załadować?
W rzeczywistości pozwala to na rozwiązanie trzech zadań:

1. Nie dostosowuj się do konkretnego interfejsu interakcji z urządzeniem. Niezależnie od tego, czy to CLI, NETCONF, RESTCONF, SNMP — model będzie taki sam.
2. Nie utrzymuj liczby szablonów/skryptów w zależności od liczby dostawców w sieci i w przypadku zmiany projektu, zmieniaj to samo w wielu miejscach.
3. Ładuj konfigurację z urządzenia (kopii zapasowej), układaj ją w dokładnie taki sam model i bezpośrednio porównuj celową konfigurację z bieżącą, aby obliczyć różnicę i przygotować łatkę konfiguracyjną, która zmieni tylko te części, które są potrzebne, lub w celu wykrycia odchyleń.

W wyniku tego etapu uzyskujemy konfigurację niezależną od dostawcy.

Komponent 6. Interfejs dostawcy specyficzny dla sterownika.

Nie ma co łudzić się, że kiedykolwiek będziesz mógł skonfigurować Cisco tak samo jak Junipera, po prostu wysyłając na nie identyczne wywołania. Pomimo rosnącej popularności whiteboxów i pojawienia się wsparcia dla NETCONF, RESTCONF, OpenConfig, konkretny content dostarczany przez te protokoły różni się w zależności od dostawcy i jest jednym z ich konkurencyjnych wyróżników, którego tak łatwo nie oddadzą.
To mniej więcej tak, jak OpenContrail i OpenStack, które mają RestAPI jako swój interfejs północny, oczekują zupełnie różnych wywołań.

Zatem na piątym kroku niezależny od dostawcy model powinien przyjąć formę, w której zostanie załadowany na sprzęt.
I tutaj wszystkie metody są dobre (nie): CLI, NETCONF, RESTCONF, SNMP prosto z piekła.

Dlatego potrzebujemy sterownika, który przekształci wyniki poprzedniego kroku w odpowiedni format konkretnego dostawcy: zestaw komend CLI, struktura XML.

Komponent 7. Mechanizm dostarczania konfiguracji do urządzenia.

Konfigurację wygenerowaliśmy, ale trzeba ją jeszcze dostarczyć do urządzeń — i oczywiście nie ręcznie.
Po pierwsze,staje przed nami pytanie, jaki transport wykorzystamy? A wybór obecnie jest już niemały:

• CLI (telnet, ssh)
• SNMP
• JSON
• zapytaniach RESTCONF można zarządzać tymi urządzeniami. Nie będziemy pracować z fizycznym sprzętem, zamiast tego uruchomimy małe wirtualne laboratoria z jednym, jedynym routerem za pomocą
• REST API
• OpenFlow (choć wyróżnia się na liście, ponieważ to sposób dostarczania FIB, a nie ustawień)

Porozstawiajmy tu kropki nad i. CLI – to legenda. SNMP… khem-khem.
RESTCONF — prędko jeszcze nieznany stwór, REST API nie jest wspierane prawie przez nikogo. Dlatego w tym cyklu skupimy się na NETCONF.

W rzeczywistości, jak już zrozumiał czytelnik, w tym momencie ustaliliśmy już interfejs – wynik poprzedniego kroku został przedstawiony w formacie wybranego interfejsu.

Po drugie, a jakimi narzędziami będziemy to robić?
W tym przypadku wyboru jest również dużo:

• Skrypt pisany samodzielnie lub platforma. Uzbroimy się w ncclient i asyncIO i zrobimy to wszystko sami. Co nam stoi na przeszkodzie, aby zbudować system wdrożenia od podstaw?
• Ansible z jego bogatą biblioteką modułów sieciowych.
• Salt, który ma ograniczone możliwości pracy z siecią i integracji z Napalm.
• Właściwie Napalm, który zna kilku dostawców i to wszystko, do widzenia.
• Nornir — jeszcze jeden szkrab, którego przeanalizujemy w przyszłości.

Tutaj jeszcze faworyt nie został wybrany — będziemy to badać.

Co jeszcze jest ważne? Konsekwencje zastosowania konfiguracji.
Skutecznie czy nie. Czy dostęp do urządzenia pozostał, czy nie.
Wydaje się, że tutaj pomoże commit z potwierdzeniem i walidacją tego, co załadowano do urządzenia.
To w połączeniu z prawidłową realizacją NETCONF znacząco zawęża krąg odpowiednich urządzeń — normalne commity nie są wspierane przez wielu producentów. Ale to jest tylko jeden z wymogów w RFP. W końcu nikt się nie martwi, że żaden rosyjski dostawca nie przejdzie pod warunkiem 32*100GE interfejsu. A może się martwi?

Komponent 8. CI/CD

Na tym etapie mamy już gotową konfigurację dla wszystkich urządzeń w sieci.
Piszę „dla wszystkich”, ponieważ mówimy o wersjonowaniu stanu sieci. I nawet jeśli trzeba zmienić ustawienia tylko jednego switcha, obliczane są zmiany dla całej sieci. Oczywiście mogą one być w tym przypadku zerowe dla większości węzłów.

Jednak, jak już wcześniej wspomniano, nie jesteśmy jakimiś barbarzyńcami, aby wprowadzać wszystko od razu do produkcji.
Wygenerowana konfiguracja musi najpierw przejść przez Pipeline CI/CD.

CI/CD oznacza Continuous Integration, Continuous Deployment. To podejście, w którym zespół nie wdraża nowego dużego wydania raz na pół roku, całkowicie zastępując stare, ale regularnie wprowadza (Deployment) nową funkcjonalność w małych porcjach, z każdą z nich wnikliwie testując na zgodność, bezpieczeństwo i funkcjonalność (Integration).

Mamy system kontroli wersji, który śledzi zmiany w konfiguracji, laboratorium, w którym testujemy, czy usługa dla klienta działa poprawnie, system monitorowania, który to sprawdza, a ostatnim krokiem jest wprowadzenie zmian do sieci produkcyjnej.

Z wyjątkiem poleceń debugujących, wszystkie zmiany w sieci muszą przejść przez CI/CD Pipeline — to nasza gwarancja spokojnego życia i długiej, szczęśliwej kariery.

Komponent 9. System tworzenia kopii zapasowych i wyszukiwania odchyleń

Nie ma co przypominać o kopiach zapasowych.
Będziemy je po prostu archiwizować co określony czas lub po wprowadzeniu zmiany w konfiguracji w Gicie.

A druga część jest ciekawsza — ktoś musi doglądać tych kopii zapasowych. W niektórych przypadkach ten ktoś powinien przywrócić wszystko do stanu poprzedniego, a w innych dać znać, że coś jest nie tak.
Na przykład, gdy pojawia się nowy użytkownik, który nie jest zapisany w zmiennych, należy go usunąć z systemu. A nowe reguły zapory lepiej nie ruszać, być może ktoś włączył debugowanie, a może nowa usługa, nieprzestrzegająca regulaminu, została wprowadzona, i już korzystają z niej użytkownicy.

Z jakąkolwiek niewielką deltą w skali całej sieci i tak nie uciekniemy, niezależnie od jakichkolwiek systemów automatyzacji i żelaznej ręki zarządzania. W przypadku debugowania problemów nikt i tak nie będzie wprowadzać zmiany w konfiguracji do systemów. Tym bardziej, że model konfiguracji w ogóle jej nie przewiduje.

Na przykład, reguła zapory do zliczania liczby pakietów na określony adres IP, aby zlokalizować problem — to całkiem standardowa tymczasowa konfiguracja.

Komponent 10. System monitorowania

Na początku nie zamierzałem poruszać tematu monitorowania — to w końcu obszerny, kontrowersyjny i skomplikowany temat. Ale okazało się, że jest to nieodłączna część automatyzacji. Nie da się tego jakoś ominąć, nawet bez praktyki.

Rozwijając myśl — to organiczna część procesu CI/CD. Po wprowadzeniu konfiguracji do sieci musimy umieć ocenić, czy wszystko z nią jest w porządku.
Nie chodzi tylko i wyłącznie o wykresy wykorzystania interfejsów czy dostępność węzłów, ale także o bardziej subtelne sprawy — obecność odpowiednich tras, atrybutów na nich, liczby sesji BGP, sąsiadów OSPF, a także funkcjonowaniu end-to-end wyższych usług.
Czy logi systemowe przestały być przesyłane na zewnętrzny serwer, czy agent SFlow przestał działać, czy wzrosła liczba dropów w kolejkach, czy nie wystąpiły problemy z łącznością między jakąś parą prefiksów?

W osobnym artykule zastanowimy się nad tym.

Podsumowanie

Jako podstawę wybrałem jeden z nowoczesnych designów sieci w centrum danych — L3 Clos Fabric z BGP jako protokołem routingu.
Tym razem zbudujemy sieć na Juniper, ponieważ teraz interfejs JunOs to prawdziwy hit.

Utrudnimy sobie życie korzystając tylko z narzędzi Open Source i sieci wielobrandowej — dlatego oprócz Junipera wybiorę jeszcze jednego szczęśliwca.

Plan najbliższych publikacji wygląda mniej więcej tak:
Najpierw opowiem o sieciach wirtualnych. Po pierwsze, dlatego, że mam na to ochotę, a po drugie, że bez tego design infrastrukturalnej sieci będzie mało zrozumiały.
Potem właściwie o designie sieci: topologii, routingu, politykach.
Zbudujemy laboratorium.
Zastanowimy się i może poćwiczymy w inicjalizacji urządzenia w sieci.
A potem szczegóły każdego komponentu.

I tak, nie obiecuję, że zakończę ten cykl gotowym rozwiązaniem. 🙂

Przydatne linki

• Zanim zagłębimy się w serię, warto przeczytać książkę Natalii Samojlenko Python dla inżynierów sieciowych. Może warto również odbyć kurs.
• Dobrze będzie również poczytać RFC o designie fabryk centrów danych autorstwa Facebooka, autorstwa Piotra Lapuchowa.
• Dokumentacja dotycząca architektury Tungsten Fabric (wcześniej Open Contrail).

Dziękuję

Romanowi Gorgiemu. Za komentarze i poprawki.
Artemowi Czerwonowajowi. Za KDPW.

Źródło: habr.com