CML 2.0

Pierwszy etap pracy nad moją aplikacją zakończony

Pamiętacie zapewne, że byłem bardzo rozczarowany Cisco Modeling Labs 2.0. Brakowało mi fantastycznej funkcjonalności z Cisco VIRL pozwalającej w prosty sposób prekonfigurować urządzenia. Pozwalało to inżynierom zaoszczędzić sporo czasu na adresowaniu interfejsów czy konfigurowaniu protokołów. Funkcja ta ma miała nazwę AutoNetKit. Jakiś miesiąc temu postanowiłem, że napiszę własny program wypełniający, choć częściowo, tą lukę. Tak powstał CMLNetKit i mogę powiedzieć, że jego pierwsza wersja gotowa jest do testów.ę

Czytaj dalej
Przez Piotr Wojciechowski, temu
Jak określam założenia projektu automatyzacji

Jak określam założenia projektu automatyzacji

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:

  1. 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
  2. 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:

  1. W pierwszej wersji urządzenia, które będą obsługiwane, to IOS i IOS XE.
  2. 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.
  3. W możliwie największym zakresie aplikacja ma korzystać z API dostępnego w CML 2.0
  4. Językiem aplikacji będzie Python 3.7 i w miarę możliwości będę ograniczał liczbę wykorzystywanych bibliotek.
  5. Interfejs programu, jak i komentarze w kodzie, będą w języku angielskim.
  6. Będę programował obiektowo.
  7. 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
Jak zmienić certyfikat SSL w CML 2.0

Jak zmienić certyfikat SSL w CML 2.0 na własny

Jak zmienić certyfikat SSL w CML 2.0

W poprzednim artykule opisałem swoje pierwsze wrażenia po uruchomieniu następcy Cisco VIRL, czyli Cisco Modeling Labs 2.0. Zaznaczyłem, że jednym z potencjalnie silnych punktów CML 2.0 będzie jego API. Jednak do poprawnego działania API wypadałoby zmienić domyślny certyfikat SSL. Przygotowałem dla Was instrukcję jak to zrobić – nie jest to czynność niestety prosta, ale każdy może zainstalować własny certyfikat SSL w CML 2.0

Czytaj dalej
Przez Piotr Wojciechowski, temu
Dlaczego CML 2.0 mnie rozczarowało?

Dlaczego CML 2.0 mnie rozczarowało?

Dlaczego CML 2.0 mnie rozczarowało?

Nareszcie po kilku(nastu) tygodniach czekania mogłem uruchomić następcę słynnego VIRL-a, czyli Cisco Modeling Lab 2.0. Wcześniej produkt był znany pod roboczą nazwą VIRL2, ale stanęło finalnie na CML 2.0. Tak, wiem, w sieci jest już sporo recenzji, zarówno pisanych czy w formie video, Niestety nie jestem pracownikiem Cisco, by mieć dostęp do wewnętrznych wersji od dawna, użytkownikiem wersji Enterprise, która została wydana miesiąc wcześniej i ze względu na cenę pewnie też nie jest dostępna dla każdej firmy. Na szczęście już jest i wczoraj miałem okazję się nieco jej przyjrzeć. Spisałem swoje pierwsze wrażenia. Jest kilka rzeczy, które moim zdaniem zasługują na uwagę (nie jest to kompletna lista na pewno).

Czytaj dalej
Przez Piotr Wojciechowski, temu