Continuous Integration w konfiguracji urządzeń sieciowych
•Download as PPTX, PDF•
0 likes•185 views
Konfigurowanie urządzeń sieciowych można traktować jak pisanie kodu. To co programiści znają jako continous integration może być wykorzystane również w zarządzaniu siecią, nawet tak dużą jak w Grupie Onet-RAS Polska. Na PLNOG Piotr Pieprzycki przedstawilł model w jakim wprowadzamy w DreamLabie zmiany w naszym środowisku i z jakimi problemami zetknęliśmy się po drodze.
Recommended
Recommended
More Related Content
What's hot
What's hot (17)
Viewers also liked
Viewers also liked (11)
Similar to Continuous Integration w konfiguracji urządzeń sieciowych
Similar to Continuous Integration w konfiguracji urządzeń sieciowych (20)
More from DreamLab
More from DreamLab (14)
Continuous Integration w konfiguracji urządzeń sieciowych
- 1. Ścieżka CI w konfiguracji urządzeń sieciowych PLNOG 2016
- 4. 23 mln real users 7 mln requests every minute 150 mln PV daily
- 5. 130 Gbps traffic 3 data centers 3 000 servers and devices
- 8. down” Przez którego pajaca padła sieć? Żródło: photo.sf.co.ua 5 Fala Richa Tenannta
- 10. Netowork As a Service
- 11. • Styki z BGP do ISP • Leaf & Spine dla SDN • Infrastruktura dla CDN • Endpoint IPSEC dla partnerów Kierunek SDN ?
- 12. • Szybsze wykrywanie problemów • Mechanizm wycofania wdrożenia • Niezależność od producenta sprzętu • Generacja i wysyłanie pełnej konfiguracji • Historia zmian Co chcieliśmy osiągnąć
- 14. DevOps & CI
- 16. master branch feature/new_bgp Pull Request Rollback GIT Master & Branch
- 17. PLAN • Zespół otrzymuje zadanie. Nowy branch CODE • Tworzymy nową konfigurację BUILD • Generujemy nową konfigurację TEST • Uruchomiamy środowisko wirtualne. Testujemy RELEASE • Nasze zmiany dodajemy do gałęzi master DEPLOY • Wprowadzamy zmiany na produkcji
- 19. FILM
- 20. Film z workflow
- 21. PLAN CODE BUILD TEST RELEASE DEPLOY JIRA – Planowanie zadań
- 22. • Brak wymogu agenta • Wsparcie dla sprzętu poprzez moduły : producentów, NAPALM, Ansible 2.x • Logiczny podział konfiguracji na role • Multivendor PLAN CODE BUILD TEST RELEASE DEPLOY ANSIBLE
- 23. ANSIBLE PLAN CODE BUILD TEST RELEASE DEPLOY
- 24. • Testy - master & branches • Wykrywanie zmian w repozytorium • Powołanie środowiska wirtualnego Bamboo CI PLAN CODE BUILD TEST RELEASE DEPLOY
- 25. • Mapa środowiska – Vagrantfile • Repozytorium obrazów • Integracja z ansible Vagrant PLAN CODE BUILD TEST RELEASE DEPLOY
- 26. Testy pełnej konfiguracji PLAN CODE BUILD TEST RELEASE DEPLOY
- 27. • Zarządzanie konfiguracją I pozyskiwanie informacji • Wsparcie dla: JunOS, EOS, IOS-XR, FortiOS, IOS, PANOS, Pluribus, NX- OS, IBM switches, ROS, VyOS NAPALM PLAN CODE BUILD TEST RELEASE DEPLOY
- 28. • Wymagany „code review” czyli akceptacja przez inną osobę z zespołu Włączenie kodu do gałęzi master PLAN CODE BUILD TEST RELEASE DEPLOY
- 29. • Wdrożenie do produkcji • Wykrywanie prób ręcznej kofiguracji • Testy po deploy RING ring.nlnog.net Bamboo Deploy PLAN CODE BUILD TEST RELEASE DEPLOY
- 30. • Redundantny system kontroli wersji • Dedykowane maszyny deploy • Proces zakupu urządzeń który uwzględnia automatyzację Co warto posiadać
- 31. • Zmiana techniczna i mentalna • Dostępna dla każdego • Zacznij małymi krokami • Myśl jak programista
Editor's Notes
- Dzień dobry… Nazywam ... Pracuje jako ... Dreamlab. Na codzień zajmuje się projektowaniem oraz utrzymywaniem rozwiązań w obszarach data center oraz sieci pracowniczej Na dzisiejszej prezentacji opowiem jak zmienił się sposób konfiguracji urządzeń w naszej firmie. I jak wplynely na nasz charakter pracy. Czyli jak od roli tzw. “sieciowów” przeszliśmy do zespołu pracującego bardziej jak programisci. O tym wszystkim opowiem z perspektywy osoby związanej z sieciami od blisko 10 lat
- DL - spółka IT - część grupy medialnej RAS Spółka medialna obecna w kilku krajach Europy Jak to grupa medialna zajmujemy się dostarczaniem treści w różnej postaci – drukowanej : gazety, magazyny Główny nacisk kładziemy na treść cyfrową
- Tworzymy serwisy i aplikacje mobilne na pewno Znacie portal Onet ? Informacyjne: Fakt, Newsweek, Ecommerce: Skąpiec, Opineo, Społecznościowe: Nasza-Klasa, Sympatia Na co to się przekłada?
- Przede wszystkim na gigantyczną liczbę użytkowników Którzy generują ogromną liczbę zapytań
- To wszystkiego wykorzystujemy 3 serwerownie - to wszystko obslugujemy z Wysyłamy spory ruch sieciowy Zarządzamy pokaźną/dużą liczbą serwerów
- Za tym wszystkim stoją ludzie 40 zespołów w 3 biurach – w Krakowie, Wrocławiu i Warszawie Pracuje u nas Ponad 300 specjalistów Nasze zespoły przeprowadzają nawet podan 250 wdrożeń dziennie
- Nad tematem konfiguracji systemów który jest związany z dzisiejszą prezentacją pracujemy już od pewnego czasu. Naszą motywacją do działania były zarówno utrudnienia w pracy widziane każdego dnia Ale także problemy które przeradzały się w awarie. Przykładem takich sytuacji mogą być małe wdrożenia Małe wdrożenia mają to do siebie, że są małe [ ] i jest ich dużo. Pośpiech i brak naszej koncentracji może spowodować, że łatwe zlecenie zamienia się w koszmar.
- Końcowy efekt nieudanej zmiany głównie odczuwają użytkownicy Potencjalna Awaria odcina ich od naszych treści. Może ich ominąć ciekawe wydarzenie lub nie oglądną ulubionego programu. Ale [ ] nie zapominajmy też o ludziach, którzy te zmiany wykonują. Pojawia się ogromny stres i presja [ ] w końcu nie ogląda nas 100 osób. Przy dzisiejszych wymaganiach naszych użytkowników co do stabilności działania [] ->nie możemy sobie pozwolić na zbyt częste błędy. Potrzebujemy dodatkowej pomocy która powie nam kiedy zmiany które robimy mogą spowodować problem
- Innym przykładem są ręczne zmiany Czyli sytuacja dość powszechna dla środowiska sieciowców to praca która wymaga często logowania się do wielu rożnych systemów jest to praca żmudną i prowadzi do pomyłek. Co jakiś czas odkrywaliśmy różnice w ustawieniach pomiędzy urządzeniami których oczywiście nie powinno być. Konfiguracje nie były spójne a problemy uwidaczniane były podczas testów. Brakowało nam systemu pomagającego utrzymać porządek i współdzielić miedzy urzadzeniami.
- Coraz więcej systemów instalujemy w formie wirtualnych maszyn. Zastępujemy drogie sprzętowe rozwiązania często darmowymi ich odpowiednikami. Skalujemy je już nie poprzez dokładanie mocy dla pojedyńczej maszyny a uruchamianie nowych instancji. Zauważyliśmy, że nie będziemy w stanie nadążyć z pracą robiąc wszystko ręcznie z linii poleceń.
- W pierwszej chwili może przyjść na myśl użycie SDN Są obszary których to rozwiązanie jeszcze na chwilę obecną nie obejmuje
- Widząc te potrzeby zaczeliśmy nakreślać nasze nowe rozwiązanie 1)Chcieliśmy posiadać system który podpowie nam kiedy rzeczy które robimy mogą spowodować awarie 2)Kiedy już jednak coś jednak zepsujemy chcemy umieć wycofać całe wdrożenie w łatwy sposób.. 3)Fajnie aby nasza konfiguracja była niezależna od producenta Pomoże nam zamieniać urządzenia w tych miejscach gdzie ma to sens. 4)Generujemy I wysyłamy pełną konfigurację za każdym razem. Jeżeli są jakieś ręcznie wprowadzone zmiany chcemy o nich wiedzieć. Zmniejszamy również rolę backupu.Nie chcemy być zaskoczeni brakiem dostępu do kofiguracji kiedy jest nam potrzebna 5)Mamy więcej informacji na temat historii konfiguracji.Jakie potrzeby biznesowe spełnia
- Zaczeliśmy poszukiwania nowego rozwiązania. Chcieliśmy użyć sprawdzonego modelu który wiemy że działa. Przyglądaliśmy się jakie procesy wykorzystuja inne zespoly w firmie Spodobała nam się forma działania zespołów devops. Wymagało to jednak oderwania się od tego co znamy I środowiska do któregi byliśmy przyzwyczajeni. Nie tylko zmieniły się narzędzia ale także podejście do pracy.
- Czym jest CI ? Mi sie kojarzyło z .. Skrót od Continuous .... czyli jeden z procesów zespołu Devops Proces ten odpowiedzialny jest za obszar testów DevOps to zespoły skupione na wydzielonym produkcie złożone z programistów i administartorów. Cechą takich zespołów jest nastawienie na automatyzację najlepiej wszystkiego co możliwe Począwszy od testowania nowego kodu, kończąc na wdrożeniu nowej wersji na produkcyjne serwery Cykl zmian jest iteracyjny oznacza to, że Kod jest pisany I testowany małymi fragmentami. Dzięki temu nowe funkcjonalności mogą być dostarczane szybciej a błędy mogą zostać wykryte wcześniej.
- Dzięki temu, że kod pisany jest małymi częściami pozwala to na jego częstsze testy. Osoba pisząca kod otrzymuje szybciej informacje czy dalej aplikacja działa poprawnie z nowa funkcjonalnoscia. Testy polegają zarówno na sprawdzeniu kodu jak I uruchomieniu aplikacji na wydzielonym środowisku.Za cały ten etap odpowiada proces nazywany – Contuniuous Integration Spróbujmy ta wizje przyrownac do naszego swiata sieci. Zazwyczaj w sieciach robimy zmiany które sa dobrze okreslone aby spelnic konkretne potrzeby – ACL, routing Używamy do tego składni przypominającej czasem język programowania Czy nasze zmiany możemy wprowadzać w taki sposób jak pisze się kod aplikacji ? Czy możemy dodatkowo testować nasze zmiany zanim wejdą na produkcję ? Brzmiało to ciekawie i postanowiliśmy tego spróbować Zobaczmy jak można taki model zaimplementować także dla sieci.
- Podstawą jest system kontroli wersji. Sledzi zmiany jakie dokonujemy w plikach. Informacje o zmianach zazwyczaj wysyłamy do zdalnego serwera. W najprosszej wersji występuje pojedyńcza Gałąź master do której wysyła się zmiany. Nie jest to jednak wystarczające , gdyż master powinien oznaczać wierne odwzorowanie stanu na produkcji. Nie może zawierać błędów które mogą wywołać awarię lub coś uszkodzić. Dlatego stosuje się dodatkowe gałęzie nazywanymi Branchami Branch tworzy miejsce w którym mozemy dokonywac zmian bez obawy o wywolanie awarii. W branchu realizujemy nowa funkcjonalnosc. Nie musi zawierać zawsze poprawnego kodu. Informacje o porblemie dostarcza CI Jeżeli posiadamy poprawny kod Otwieramy pull request. Wymagane jest tez potwierdzenie innej osoby z zepsołu Zmiany dodajemy do mastera – merge w Przypadku awarii wycofujemy ostatnie zmiany Cofamy do poprzedniej wersji
- Jak wygląda proces zmian u nas? Po otrzymaniu przez zepsół zadania. Tworzymy nowy branc w którym będziemy tworzyc nowe rzeczy. Tworzymy nowa konfiguracje ktora spelnia wymogi zadania. Aby sprawdzić jej poprawność [ ] najpierw ja generujemy Oraz testujemy w środowisku wirtualnym Pozytywne testy pozwalaja na włączenie ich do głównej gałęzi repozytorium A końcowo również wprowadzeie zmian na urządzenia produkcyjne. Brzmi prosto
- Do tego jednak potrzebny jest cały zestaw narzędzi. Wybraliśmy dostępne już u nas narzędzia firmy atlassian Mozna podobny system zbudować w oparciu o rozwiazania opensource Definiujemy zmienne w języku yaml a szablony w jinja Release – wlaczenie zmian do mastera i deploy bitbucket/bamboo Testy w vagrant I skrypty shell , python
- Zespoł otrzymuje zadanie do wykonanie. Jest to efekt planowania ktory odbywa sie w cyklach u nas dwutygodniowych. Wcześniej zespoł na osobnym spotkaniu nazywnym grromingiem doklanie opisuje rzecy jakie nalezy wykonac i wycenia wymagany naklad pracy Osoba podejmujaca sie zadania tworzy nowego brancha. Na codziennych porannych spotkaniach zespół śledzi stan wykonania zadania.
- Po otrzymaniu zadania musiy napisac kod juz pod odpowiedni system konfiguracji Wykorzystujemy ansible jako narzedzie do konfiguracji urzadzen Nie wymaga agenta po stronie urzadzenia sieciowego oraz posiada szerokie wsparce Nasza konfiguracje w ansible jest podzielona za pomocą ról Role Realizuja one okreslone funkcje np konf. Prot bgp, ospf, tunele ipsec. wieloplatformowość osiągamy za pomoca roznych wersji szablonow uzywanych w zaleznosci od systemu
- Pliki konfiguracyjne w yaml zawsze zawieraja ta sama skladnie niezaleznie od producenta Zmienne wykorzystywane sa przez szablony I one generuja koncowy kod Sama generacja kodu jest juz testem skladni yaml oraz skladni szablonow jinja Wygenerowana konfiguracje poprzez role sprawdzamy czy akceptują urzadzenia.
- Sprawdzamy poprawnosc konfiguracji dla wszytkich gałęzi Po wykryciu w nich zmian. Jest mocno zintegrowany z repozytorium Testy przeprowadzane w wydzielonym srodowisku wirtualnym Dostarcza informacje zwrotne o wyniku testów
- Budujemy srodowisko wirtualne aby przetestować poprawnośc konfiguracji. Za pomoca pojedynczego pliku okreslamy jakie systemy chcemy uzyc oraz jak maja byc ze soba polaczone Dostępnych jest wiele obrazów w publicznym repozytoriu w tym dzisiaj wykorzystywane Vagrant posiada integracje z systemami zarzadzania konfiguracja umozliwia to zdefioniwanie grup czy dodatkowych zmiennych Dzieki V. Jesteśmy w stanie w ten sposób przetestowac kod generowany przez nasze role i oraz fragmenty środowisk które są powtarzalne - np leaf&spine, vpn Wagrant wymaga modyfikacji konfiguracji aby uruchomic ja w srodowisku testowym - Uklad interfejsow
- W miejscach gdzie konfiguracja jest krytyczna chcemy testować ja w całości Przykładem takiego miejsca jest styk z Internetem. Dzięki wirtualnemu odpowiednikowi dla naszych routerów sprzętowych czyli vMX Jestesmy w stnanie sprawdzić konfigurację w całosci . Możemy zasymulować interfejsy o różnej prędkości 1/10/100 Nie musimy modyfikować konfiguracji która jest w tych miejscach jest skomplikowana Testy polegają na odwzorowaniu operatora z perspektywy ktorego sprawdzamy dostepnosc naszych uslug. Pozwala nam to upewnisc sie ze nie odetniemy naszych uzytkownikow od naszych tresci.
- Testy wykonujemy za pomoca skryptow python oraz przydatna jest biblioteka napalm jednolite rozwiazanie do konfiguracji i weryfikacji systemow Bibilioteka zarówno dostarcza mozliwosc konfiguracji za pomoca ansible czy salt Rowniez jest bardzo uzyteczna dla przeprowadzania testów systemow. Pozwala ona na uzyskanie jednolitego formatu wyjsciowego wyniku dla zapytania niezaleznie od systemu operacyjnego jaki mamy na urzadzeniu mozemy odpytac o stan sesji bgo, czy stan urzadzenia. Jest dostepnych wiele metod
- Code review gdyz testy rowniez dopisujemy iteracyjnie mozemy nie miec uwzglegnionego przypadku testy rowniez wykonywane na masterze Upewniamy sie ze zmiany innej osoby nie wykluczaja sie z naszymi nie nastepuje konflikt pomiedzy ustawieniami
- Przeprowadzamy wdrozenie W naszym srodowisku cyklicznie przeprowadzamy porownanie wersji zawartej w masterze z konfiguracja na urzadzeniach. Wykrywamy proby recznej ich konfiguracji. Dzieki projektowi ring mozemy sie upewnic ze nasi uzytkownicy po zmianie maja dostep do naszych zasobow. Ulatwia rozwiazywanie problemow .
- Już dziś nawet tutaj gdzy interesujesz sie sprzętem pytaj o autmatyzację. Interesuj się jakie wasparcie jest dla automatyzacji. Czy możesz wrzucić pełną konfigurację czy pracować tylko na pojedynczych komendach. Nie zostancie z urzadzeniami ktore bedziecie mogli tylko konfigurowac recznie
- To Co my osiągneliśmy System który wspomaga nas w codziennej pracy. Przeprowadza testy których nie bylibysmy w stanie wykonywac recznie. Jest to dobra baza do budowy dalszej automatyzacji. Mamy zawszemożliwość wycofania zmian w naszym srodowiskudo poprzedniego stanu. Zmiany są przejrzyste i widoczne dla wszystkich Wierzymy, że to dopiero początek naszej drogi. Zapraszamy do wspólnej podróży
- Zapraszam do kontaktu Odwiedzenia strony na github Slack I oddania glosu za pomoca aplikacji eventory jezeli podobala wam sie moja prezentacja.