Artykuł ten jest szóstym w cyklu artykułów „Jak przejąć kontrolę nad infrastrukturą sieciową”. Wszystkie artykuły w cyklu oraz linki można znaleźć .
Zostawiając kilka tematów za sobą, postanowiłem jednak rozpocząć nowy rozdział.
Do bezpieczeństwa wrócę nieco później. Tutaj chcę omówić jedno proste, ale skuteczne podejście, które, jestem pewien, w takim czy innym wymiarze, może się przydać wielu osobom. To bardziej krótka historia o tym, jak automatyzacja może zmienić życie inżyniera. Będzie chodzić o wykorzystanie szablonów. Na końcu znajduje się lista moich projektów, gdzie można zobaczyć, jak to wszystko działa.
DevOps dla sieci
Tworzenie konfiguracji za pomocą skryptu, użycie GIT do kontroli zmian w infrastrukturze IT, zdalne „ładowanie” — te pomysły przychodzą na myśl, gdy rozważasz techniczną realizację podejścia DevOps. Plusy są oczywiste. Ale niestety są też minusy.
Kiedy ponad 5 lat temu nasi programiści przyszli do nas, sieciowców, z tymi propozycjami, nie byliśmy zachwyceni.
Należy powiedzieć, że w spadku odziedziczyliśmy dość zróżnicowaną sieć, składającą się z urządzeń około 10 różnych dostawców. Coś było wygodnie konfigurować za pomocą naszego ulubionego CLI, ale gdzie indziej woleliśmy używać GUI. Dodatkowo, długa praca na „żywym” sprzęcie przyzwyczaiła nas do monitorowania w czasie rzeczywistym. Na przykład, wprowadzając zmiany, czuję się znacznie pewniej, pracując bezpośrednio przez CLI. W ten sposób szybko mogę zauważyć, że coś poszło nie tak i „cofnąć” zmiany. Wszystko to było w pewnym stopniu sprzeczne z ich pomysłami.
Pojawiają się też inne pytania, na przykład, od wersji do wersji oprogramowania interfejs może się nieco zmieniać. To w końcu doprowadzi do sytuacji, że twój skrypt będzie tworzył błędny „konfig”. Nie chciałbym stosować produkcji do „testowania”.
Albo, jak zrozumieć, że komendy konfiguracyjne zostały zastosowane poprawnie i co robić w przypadku błędu?
Nie chcę powiedzieć, że te pytania są nie do rozwiązania. Po prostu mówiąc „A”, prawdopodobnie rozsądnie jest powiedzieć również „B”, a jeśli chcesz stosować te same procesy do kontroli zmian, co w przypadku programowania, to musisz mieć oprócz produkcji również środowiska dev i staging. Wówczas podejście to wygląda na kompletne. Ale ile to będzie kosztować?
Jednak istnieje jedna sytuacja, w której wady praktycznie się zacierają, a pozostają tylko zalety. Mówię o pracach projektowych.
Projekt
Przez ostatnie dwa lata brałem udział w projekcie budowy centrum danych dla jednego dużego dostawcy. W tym projekcie odpowiadam za F5 i Palo Alto. Z perspektywy Cisco to sprzęt zewnętrzny.
Osobiście widzę dwie wyraźne fazy w tym projekcie.
Pierwsza faza
Pierwszy rok byłem nieskończono zajęty, pracowałem w nocy i w weekendy. Nie mogłem podnieść głowy. Naciski ze strony zarządzających i klienta były silne i nieprzerwane. W ciągłej rutynie nie mogłem nawet spróbować zoptymalizować procesu. To było nie tylko, a nawet nie tyle konfekcjonowanie sprzętu, co sporządzanie dokumentacji projektowej.
Oto zaczęły się pierwsze testy i byłem zdumiony, ile drobnych błędów i nieścisłości zostało popełnionych. Oczywiście wszystko działało, ale tu brakowało litery w nazwie, tam brakowało linii w komendzie… Testy trwały i trwały, a ja znajdowałem się w ciągłej, codziennej walce z błędami, testami i dokumentacją.
Tak trwało przez rok. Projekt, o ile rozumiem, był trudny dla wszystkich, ale stopniowo klient stawał się coraz bardziej zadowolony, a to pozwoliło na zatrudnienie dodatkowych inżynierów, którzy mogli zająć się częścią rutyny.
Teraz można było trochę się rozejrzeć.
I to był początek drugiej fazy.
Druga faza
Postanowiłem zautomatyzować proces.
Czego nauczyłem się z tamtejszej współpracy z programistami (i trzeba przyznać, mieliśmy mocny zespół), to to, że format tekstowy, choć na pierwszy rzut oka może wydawać się czymś z świata systemu operacyjnego DOS, ma szereg cennych właściwości.
Na przykład format tekstowy będzie przydatny, jeśli chcesz w pełni wykorzystać zalety GIT i wszystkich jego pochodnych. A ja chciałem.
Cóż, wydawałoby się, że można po prostu przechowywać konfigurację lub listę poleceń, ale wprowadzanie zmian jest dość niewygodne. Ponadto podczas projektowania istnieje jeszcze jedno ważne zadanie. Musisz mieć dokumentację, która opisuje twój projekt jako całość (Low Level Design) oraz konkretną implementację (Network Implementation Plan). A w tym przypadku użycie szablonów wydaje się bardzo odpowiednim rozwiązaniem.
Tak, przy użyciu YAML i Jinja2, plik YAML z parametrami konfiguracji, takimi jak adresy IP, numery BGP AS,… doskonale pełni rolę NIP, podczas gdy szablony Jinja2 zawierają składnię odpowiednią do projektu, co w zasadzie jest odzwierciedleniem LLD.
Na naukę języków YAML i Jinja2 poświęciłem dwa dni. Aby zrozumieć, jak to działa, wystarczy kilka dobrych przykładów. Następnie około dwóch tygodni zajęło mi stworzenie wszystkich szablonów odpowiadających naszemu projektowi: tydzień dla Palo Alto i kolejny tydzień dla F5. Wszystko to zostało opublikowane na korporacyjnym githab.
Teraz proces zmian wyglądał następująco:
- zmieniłem plik YAML
- stworzyłem za pomocą szablonu (Jinja2) plik konfiguracyjny
- zapisałem w zdalnym repozytorium
- wgrałem stworzoną konfigurację na sprzęt
- zauważyłem błąd
- zmieniłem plik YAML lub szablon Jinja2
- stworzyłem za pomocą szablonu (Jinja2) plik konfiguracyjny
- …
Jasne, że na początku dużo czasu zajmowały poprawki, ale po tygodniu-dwóch stało się to już raczej rzadkością.
Dobrą kontrolą i możliwością do wszystkiego debugowania stała się chęć klienta do zmiany konwencji nazewnictwa. Ci, którzy pracowali z F5, rozumieją złożoność sytuacji. Dla mnie wszystko było dość proste. Zmieniłem nazwy w pliku YAML, usunąłem całą konfigurację ze sprzętu, wygenerowałem nową i wgrałem. Na wszystko, uwzględniając poprawki błędów, zajęło mi 4 dni: po dwa dni na każdą technologię. Po tym byłem gotowy na kolejny etap, a mianowicie stworzenie centrów danych DEV i Staging.
Dev i Staging
Staging faktycznie w pełni powtarza produkcję. Dev — znacznie okrojona i zbudowana głównie na wirtualnym sprzęcie kopia. Idealna sytuacja do zastosowania nowego podejścia. Jeśli z ogólnego procesu wyodrębnić czas, który poświęciłem, to myślę, że prace zajęły nie więcej niż 2 tygodnie. Główna część czasu to czas oczekiwania na drugą stronę i wspólne szukanie problemów. Implementacja 3rd party przebiegła prawie niezauważalnie dla otoczenia. Pojawiło się nawet trochę czasu, aby czegoś się nauczyć i napisać kilka artykułów na Habra 🙂
Podsumujmy
Zatem, co mam w ostatecznym podsumowaniu?
- wszystko, czego potrzebuję do zmiany konfiguracji — zmienić prosty, jasno zorganizowany plik YAML z parametrami konfiguracyjnymi. Nigdy nie zmieniam skryptu python i bardzo rzadko (tylko jeśli jest błąd) zmieniam szablon Jinja2.
- Z punktu widzenia dokumentacji sytuacja wydaje się niemal idealna. Zmieniasz dokumentację (pliki YAML pełnią rolę NIP) i przesyłasz tę konfigurację na urządzenia. Dzięki temu twoja dokumentacja jest zawsze aktualna.
Wszystko to doprowadziło do tego, że
- procent błędów spadł niemal do 0
- 90 procent rutyny odeszło
- znacząco zwiększyła się prędkość wdrażania
PAY, F5Y, ACY
Mówiłem, że kilka przykładów wystarczy, aby zrozumieć, jak to działa.
Oto krótka (i oczywiście zmieniona) wersja tego, co zostało stworzone w trakcie mojej pracy.
= wdrożenie Palo Alto z Yaml = Palo Alto z Yaml
= wdrożenie F5 od Yaml = F5 od Yaml (wkrótce)
= wdrożenie ACi z Yaml = F5 od Yaml
Dodam kilka słów o ACY (nie mylić z ACI).
Ci, którzy pracowali z ACI, wiedzą, że to cudo (i to w dobrym sensie) zostało stworzone z pewnością nie przez sieciowców :). Zapomnij o wszystkim, co wiedziałeś o sieci — to się nie przyda!
Nieco przesadzone, ale mniej więcej oddaje to uczucie, które odczuwam, pracując z ACI przez ostatnie 3 lata.
W tym przypadku ACY to nie tylko możliwość zbudowania procesu kontroli zmian (co ma szczególne znaczenie w przypadku ACI, ponieważ zakłada się, że to centralna i najważniejsza część twojego Data Center), ale także przyjazny interfejs do tworzenia konfiguracji.
Inżynierowie w tym projekcie do konfigurowania ACI zamiast YAML z dokładnością tych samych celów używają Excela. Użycie Excela ma oczywiście swoje zalety:
- twój NIP w jednym pliku
- ładne tabelki, na które przyjemnie patrzeć klientowi
- możesz używać niektórych narzędzi Excela
Ale jest jeden minus, który moim zdaniem przeważa nad zaletami. Kontrola zmian i uzgadnianie pracy zespołu staje się znacznie trudniejsze.
ACY to właściwie zastosowanie tych samych podejść, które użyłem do 3rd party, do konfigurowania ACI.
Źródło: habr.com
