Nadszedł ten moment, w którym, aby rozpocząć pracę nad moim projektem muszę go założyć. A dokładniej stworzyć dla niego repozytorium kodu źródłowego. CMLNetKit, tak nazwałem swój projekt, będzie publicznie dostępny na platformie GitHub, aby każda zainteresowana osoba mogła z niego korzystać. Jako środowisko do pracy nad projektem będę używał PyCharm, o którym pisałem już wcześniej. Przeprowadzę Cię teraz przez wszystkie kroki niezbędne do utworzenia nowego projektu i stworzenia dla niego środowiska w PyCharm.
Porady
Jak określam założenia projektu automatyzacji
W najbliższych artykułach pokażę Wam proces budowania narzędzia do automatyzacji oraz jak korzystać z narzędzi do zarządzania kodem i pracy grupowej. Gdy rozpoczynam pracę nad nowym projektem, zawsze zaczynam od określenia kilku kluczowych jego parametrów. Jednym z nich jest oczywiście nazwa, którą zawsze mogę zmienić, dlatego początkowo nie musi ona porywać tłumów. Ciężej jednak odzyskać czas stracony na kodowanie niepotrzebnych funkcjonalności czy takich, które znajdziemy w publicznie dostępnych bibliotekach. Zamiast tego lepiej skupić się na esencjalnych dla tworzonego projektu elementach i pamiętać o nałożonych na projekt ograniczeniach. Tak, są one konieczne, a określając je, powinniśmy postępować zgodnie z zasadami, o których pisałem w poprzednim artykule. Dlatego na początek przedstawię Ci, jakie są moje założenia w tym projekcie.
Założenia projektu dotyczące funkcjonalności
W mojej głowie stworzyła się już wizja aplikacji z tyloma “ficzerami”, że CML 2.0 może się przy niej schować. I to oczywiście w pierwszej wersji, potem ma być tylko lepiej! Właśnie dlatego, aby nie ponieść się wodzom fantazji, a tym samym nie zaprzepaścić pomysłu na pomocny produkt, konieczne jest jasne określenie podstawowych celów. Zawsze określamy założenia projektu automatyzacji, zanim przystąpimy do jakichkolwiek prac. Podstawowe problemy, które chcę rozwiązać za pomocą swojej aplikacji to:
- Po ułożeniu topologii w ramach wyznaczonych przeze mnie podsieci chcę, aby moja aplikacja automatycznie zaadresowała:
- Połączenia L3 pomiędzy urządzeniami
- Wszystkie interfejsy Loopback0
- Interfejsy służące do zarządzania
- Zmieniła konfigurację obiektów “External Connection” na Bridge
Nie jest tego dużo. Można by się spytać, dlaczego tylko tyle? Na początku jest ich niewiele po to, by stworzyć aplikację, która rozwiąże moje najbardziej palące problemy. Wyręczy mnie w czynnościach, na których budując symulację, tracę najwięcej czasu. Gdy to się uda, mogę aplikację dalej rozwijać.
Ograniczenia i ramy
Aby stworzyć funkcjonalny produkt, założenia projektu muszą obejmować także listę ograniczeń i wyznaczyć ramy technologiczne, w jakich chcę się zmieścić. Są to minimalne funkcjonalności, które chcę zaimplementować i narzędzia, z których chcę korzystać. Moje ramy odnoszą się zarówno do elementów funkcjonalnych, jak i technicznych tworzonej aplikacji:
- W pierwszej wersji urządzenia, które będą obsługiwane, to IOS i IOS XE.
- Aplikacja ma jednak pozwalać w sposób prosty na dołączanie do obsługi pozostałych typów urządzeń dostępnych w CML 2.0. Oznacza to, że powinna być ona napisana z myślą pod przyszły jej rozwój.
- W możliwie największym zakresie aplikacja ma korzystać z API dostępnego w CML 2.0
- Językiem aplikacji będzie Python 3.7 i w miarę możliwości będę ograniczał liczbę wykorzystywanych bibliotek.
- Interfejs programu, jak i komentarze w kodzie, będą w języku angielskim.
- Będę programował obiektowo.
- Kod będę utrzymywał jako publiczny projekt na GitHub.
Dlaczego zdecydowałem się na programowanie obiektowe? Po wstępnej analizie dokumentacji API stwierdziłem, że stworzenie kodu obiektowego może przyszłościowo sprawić, że będzie on bardziej “przenaszalny”. Poza tym dzięki programowaniu w ramach projektu Ansible czuję się dość komfortowo, gdy piszę obiektowo w języku Python.
Być może powyższe ograniczenia będę musiał zweryfikować w trakcie projektu.
Możesz być częścią tego projektu! Napisz w komentarzu, poniżej jakie funkcjonalności uznajesz za kluczowe? Jakie narzędzia wybierzesz? W jakich ramach się zamkniesz? Czy przyjąłbyś inne założenia niż ja? Jeżeli tak to dlaczego?
Przez Piotr Wojciechowski, temu
Porady
Czytaj dalej
Zasady budowy mechanizmów automatyzacji
W tym roku prowadzę sporo różnego rodzaju webinarów, elementem większości z nich jest demo rozwiązania, a niektóre całe moje wystąpienia były jednym kompletnym demo, bez żadnych slajdów. Do demonstracji rozwiązań sieciowych opartych o urządzenia Cisco używam Cisco Modeling Labs, wcześniej Cisco VIRL. Jak wiecie CML 2.0 nie przypadł mi do gustu, obecnie lista moich zarzutów co do wykonania i użyteczności GUI CML 2.0 jest jeszcze bardziej negatywna. Dlatego postanowiłem sam rozwiązać przynajmniej część z tych problemów. Wy będziecie obserwatorami, a może i uczestnikami procesu tworzenia tego narzędzia. Zanim jednak zaczniemy poznajmy zasady budowy i projektowania różnego typu narzędzi.
Przez Piotr Wojciechowski, temu
DevNet Associate
Czytaj dalej
Namespace i podłączenie gniazda Dockera do kontenera
Bezpieczne urządzenie w domyślnej konfiguracji to takie wyłączone urządzenie. A najlepiej także odłączone od prądu. Bezpieczna aplikacja to wyłączona aplikacja, a najlepiej odinstalowana. Tak, trochę za dużo chyba ostatnio z “bezpiecznikami” rozmawiam… Niemniej tych zasad nie uda nam się spełniać w systemach IT, musimy zatem zadbać o odpowiednie mechanizmy bezpieczeństwa. Nie inaczej jest z Dockerem. W poprzednim swoim artykule zaznaczałem, że Docker w swojej domyślnej instalacji może się co najwyżej nadawać do domowego odizolowanego laboratorium. Nawet w systemach testowych czy developerskich powinniśmy wdrożyć mechanizm zwany namespace. Jego aktywacja powoduje jednak problemy z dostępem do gniazda (socket), służącego do lokalnej komunikacji z demonem Dockera.
Przez Piotr Wojciechowski, temu
Ansible
Czytaj dalej
Backup konfiguracji routera za pomocą Ansible
Kolejne dni pracy z Cisco Modeling Labs 2.0. Przygotowywałem się do pierwszego wykorzystania go w większej topologii i scenariuszu w ramach webinaru. Ale tym razem nie będę pisał o CML 2.0. Przygotowując scenariusza laba chciałem mieć zapisane wzorcowe konfiguracje urządzeń z kolejnych etapów. Niestety CML 2.0 nie pozwala na łatwe zgranie konfiguracji z urządzeń biorących udział w symulacji. Napisanie playbooka wykonującego backup konfiguracji routera za pomocą Ansible jest przecież bardzo proste.
Przez Piotr Wojciechowski, temu