Ten artykuł jest szóstym z serii „Jak przejąć kontrolę nad infrastrukturą sieciową”. Można znaleźć treść wszystkich artykułów z serii oraz linki .
Zostawiwszy kilka tematów za sobą, postanowiłem rozpocząć nowy rozdział.
Wrócę do kwestii bezpieczeństwa nieco później. Tutaj chcę omówić jedno proste, ale skuteczne podejście, które, jestem pewien, w tej czy innej formie, może być przydatne dla wielu osób. To raczej krótka historia o tym, jak automatyzacja może zmienić życie inżyniera. Porozmawiamy o korzystaniu z szablonów. Na końcu znajduje się lista moich projektów, na której możesz zobaczyć, jak działa wszystko, co tu opisano.
DevOps dla sieci
Stworzenie konfiguracji za pomocą skryptu, wykorzystanie GIT-a do kontroli zmian w infrastrukturze IT, zdalne „wgranie” – te pomysły przychodzą na myśl jako pierwsze, gdy myślimy o technicznej implementacji podejścia DevOps. Zalety są oczywiste. Ale niestety są też wady.
Kiedy ponad 5 lat temu nasi programiści zwrócili się do nas, networkerów, z tymi propozycjami, nie byliśmy zachwyceni.
Muszę powiedzieć, że odziedziczyliśmy dość pstrokatą sieć, składającą się ze sprzętu od około 10 różnych dostawców. Wygodnie było konfigurować niektóre rzeczy za pomocą naszego ulubionego cli, ale w innych woleliśmy korzystać z GUI. Dodatkowo długa praca na sprzęcie „pod napięciem” nauczyła nas kontroli w czasie rzeczywistym. Na przykład, wprowadzając zmiany, czuję się znacznie bardziej komfortowo, pracując bezpośrednio przez cli. W ten sposób szybko mogę zobaczyć, że coś poszło nie tak i cofnąć zmiany. Wszystko to pozostawało w jakiejś sprzeczności z ich wyobrażeniami.
Pojawiają się też inne pytania, np. interfejs może się nieznacznie różnić w zależności od wersji oprogramowania. To ostatecznie spowoduje, że Twój skrypt utworzy niewłaściwą „konfigurację”. Nie chciałbym używać produkcji do „dotarcia”.
Albo jak zrozumieć, że polecenia konfiguracyjne zostały zastosowane poprawnie i co zrobić w przypadku błędu?
Nie chcę powiedzieć, że wszystkich tych problemów nie da się rozwiązać. Samo powiedzenie „A” prawdopodobnie ma sens, aby powiedzieć także „B”, a jeśli chcesz używać tych samych procesów do kontroli zmian, co podczas programowania, oprócz produkcji musisz mieć środowiska deweloperskie i testowe. Wtedy to podejście wygląda na kompletne. Ale ile to będzie kosztować?
Ale jest jedna sytuacja, gdy wady są praktycznie zniwelowane i pozostają tylko zalety. Mówię o pracy projektowej.
Projekt
Od dwóch lat biorę udział w projekcie budowy centrum danych dla dużego dostawcy. W tym projekcie jestem odpowiedzialny za F5 i Palo Alto. Z punktu widzenia Cisco jest to „sprzęt innej firmy”.
Dla mnie osobiście istnieją dwa odrębne etapy tego projektu.
Pierwszy etap
Przez pierwszy rok byłem nieskończenie zajęty, pracowałem nocami i w weekendy. Nie mogłam podnieść głowy. Nacisk ze strony kierownictwa i klienta był silny i ciągły. W ciągłej rutynie nie mogłem nawet spróbować zoptymalizować procesu. Nie chodziło tylko i nie tyle o konfigurację sprzętu, co o przygotowanie dokumentacji projektowej.
Rozpoczęły się pierwsze testy i zdziwiłbym się, ile drobnych błędów i niedokładności zostało popełnionych. Oczywiście wszystko działało, ale zabrakło litery w nazwie, zabrakło linijki w poleceniu... Testy ciągnęły się dalej, a ja już byłem w ciągłej, codziennej walce z błędami, testami i dokumentacją .
Trwało to rok. Projekt, o ile rozumiem, nie dla wszystkich był łatwy, ale stopniowo klient był coraz bardziej usatysfakcjonowany, co umożliwiło zatrudnienie dodatkowych inżynierów, którzy byli w stanie sami podjąć się części rutyny.
Teraz moglibyśmy się trochę rozejrzeć.
I to był początek drugiego etapu.
Drugi etap
Postanowiłem zautomatyzować ten proces.
Z mojej ówczesnej komunikacji z twórcami zrozumiałem (i trzeba przyznać, że mieliśmy mocny zespół), że format tekstowy, choć na pierwszy rzut oka wydaje się czymś ze świata systemu operacyjnego DOS, ma szereg o cennych właściwościach.
Na przykład format tekstowy będzie przydatny, jeśli chcesz w pełni wykorzystać GIT i wszystkie jego pochodne. 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. Powinieneś mieć dokumentację opisującą projekt jako całość (projekt niskiego poziomu) i konkretną implementację (plan wdrożenia sieci). I w tym przypadku użycie szablonów wydaje się bardzo odpowiednią opcją.
Zatem w przypadku korzystania z YAML i Jinja2 plik YAML z parametrami konfiguracyjnymi takimi jak adresy IP, numery BGP AS,… doskonale spełnia rolę NIP, natomiast szablony Jinja2 zawierają składnię odpowiadającą projektowi, czyli jest to w istocie odbicie LLD.
Nauka YAML i Jinja2 zajęła dwa dni. Wystarczy kilka dobrych przykładów, aby zrozumieć, jak to działa. Następnie stworzenie wszystkich szablonów pasujących do naszego projektu zajęło około dwóch tygodni: tydzień dla Palo Alto i kolejny tydzień dla F5. Wszystko to zostało opublikowane na korporacyjnym githabie.
Teraz proces zmiany wyglądał następująco:
- zmienił plik YAML
- utworzył plik konfiguracyjny przy użyciu szablonu (Jinja2)
- zapisane w zdalnym repozytorium
- wgrał utworzoną konfigurację na sprzęt
- Zobaczyłem błąd
- zmienił plik YAML lub szablon Jinja2
- utworzył plik konfiguracyjny przy użyciu szablonu (Jinja2)
- ...
Oczywiste jest, że na początku poświęcano dużo czasu na edycję, ale po tygodniu lub dwóch stało się to raczej rzadkością.
Dobrym testem i okazją do debugowania wszystkiego była chęć klienta zmiany konwencji nazewnictwa. Ci, którzy pracowali z F5, rozumieją pikantność sytuacji. Ale dla mnie wszystko było całkiem proste. Zmieniłem nazwy w pliku YAML, usunąłem całą konfigurację ze sprzętu, wygenerowałem nową i wgrałem. Wszystko, łącznie z naprawą błędów, zajęło 4 dni: po dwa na każdą technologię. Potem byłem gotowy na kolejny etap, czyli utworzenie data center DEV i Staging.
Dev i Staging
Inscenizacja faktycznie całkowicie replikuje produkcję. Dev jest mocno okrojoną kopią zbudowaną głównie na sprzęcie wirtualnym. Idealna sytuacja dla nowego podejścia. Jeśli oddzielę czas, który spędziłem od całego procesu, to myślę, że praca zajęła nie więcej niż 2 tygodnie. Najważniejszy czas to czekanie na drugą stronę i wspólne szukanie problemów. Wdrożenie strony trzeciej przeszło prawie niezauważone przez innych. Był nawet czas, żeby się czegoś dowiedzieć i napisać kilka artykułów o Habré :)
Podsumowując
Więc co mam w ostatecznym rozrachunku?
- Wszystko, co muszę zrobić, aby zmienić konfigurację, to zmienić prosty, przejrzyście ustrukturyzowany plik YAML z parametrami konfiguracyjnymi. Nigdy nie zmieniam skryptu Pythona i bardzo rzadko (tylko w przypadku błędu) zmieniam heatlate Jinja2
- Z punktu widzenia dokumentacji jest to sytuacja niemal idealna. Zmieniasz dokumentację (pliki YAML służą jako NIP) i wgrywasz tę konfigurację do sprzętu. Dzięki temu Twoja dokumentacja będzie zawsze aktualna
Wszystko to doprowadziło do tego, że
- poziom błędów spadł prawie do 0
- Zniknęło 90 procent rutyny
- szybkość wdrażania znacznie wzrosła
ZAPŁATA, F5Y, ACY
Mówiłem, że wystarczy kilka przykładów, żeby zrozumieć jak to działa.
Oto krótka (i oczywiście zmodyfikowana) wersja tego, co powstało podczas mojej pracy.
= wdrożenie Palo Ato od Yaml = Palo Alto z Yaml
= wdrożenie F5 od Yaml = F5 od Yaml (wkrótce)
= wdrożenie ACjest z Yaml = F5 od Yjr
Dodam kilka słów o ACY (nie mylić z ACI).
Ci, którzy współpracowali z ACI, wiedzą, że ten cud (i to w dobrym tego słowa znaczeniu) na pewno nie został stworzony przez networkerów :). Zapomnij o wszystkim, co wiedziałeś o sieci – nie będzie Ci to przydatne!
To trochę przesadzone, ale z grubsza oddaje uczucie, którego nieustannie doświadczam przez ostatnie 3 lata, pracując z ACI.
I w tym przypadku ACY to nie tylko szansa na zbudowanie procesu kontroli zmian (co jest szczególnie ważne w przypadku ACI, bo to ma być centralna i najbardziej krytyczna część Twojego data center), ale także daje Ci możliwość przyjazny interfejs użytkownika do tworzenia konfiguracji.
Inżynierowie tego projektu używają Excela do skonfigurowania ACI zamiast YAML w dokładnie tych samych celach. Korzystanie z Excela ma oczywiście zalety:
- Twój NIP w jednym pliku
- piękne szyldy, na które klient chętnie patrzy
- możesz użyć niektórych narzędzi Excela
Ale jest jeden minus, który moim zdaniem przeważa nad zaletami. Kontrolowanie zmian i koordynowanie pracy zespołu staje się znacznie trudniejsze.
ACY jest w rzeczywistości zastosowaniem tych samych podejść, których użyłem dla strony trzeciej do skonfigurowania ACI.
Źródło: www.habr.com