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).
Instalacja CML 2.0
Pierwszą rzeczą, która rzuca się w oczy to sposób instalacji CML 2.0. Przede wszystkim nie ma możliwości wersji Personal zainstalować jako natywnego systemu operacyjnego (bare metal). W pakiecie dostajemy jedynie obraz maszyny wirtualnej w formacie OVA oraz plik ISO zawierający obrazy wirtualnych urządzeń sieciowych, który musimy podłączyć do utworzonej maszyny wirtualnej. Trochę nietypowo, ale nie przeszkadza mi to, utrudnia jedynie potencjalne przenoszenie maszyny wirtualnej pomiędzy serwerami. Przenoszenia, gdyż na chwilę obecną ani wersja Personal, ani Enterprise nie wspiera klastrowania. Dodatkowo jedynym wspieranym hypervisorem są produktyu VMware. Użytkownicy domowi nie muszą się obawiać – wystarczy wersja Player, Workstation czy Fusion. Instalacja i uruchomienie zajmują ledwie kilka minut.
CML 2.0 nie działa oczywiście bez licencji – musimy ściągnąć token ze swojego konta na cisco.com, wpisać go w odpowiednie pole i aktywować.
GUI
Cały interfejs CML 2.0 został napisany od nowa. Do zarządzania samym systemem otrzymujemy graficzną konsolę System Maintenance Controls, która nasłuchuje na porcie 9090. GUI symulacji dostępne jest na porcie 443. Aplikacja VM Maestro została całkowicie wycofana i topologią symulacji i jej pracą zarządzamy przez przeglądarkę za pomocą przejrzystego interfejsu HTML5. Na bieżąco widzimy stopień zużycia zasobów przypisanych do maszyny wirtualnej, zarządzanie symulacjami jest bardzo proste, dodawanie urządzeń także. I niestety na tym się pozytywne wrażenia kończą.
Osoba odpowiedzialna za design interfejsu powinna zostać w moim przekonaniu natychmiast wysłana na kurs tworzenia interfejsów graficznych aplikacji. Oto główne błędy popełnione przy tworzeniu interfejsu:
- Mysz każdego urządzenia ma przynajmniej dwa przyciski. Jest dla mnie zagadką, dlaczego w GUI nie ma zaimplementowanego menu kontekstowego. Kliknięcie prawym przyciskiem myszy na obiekcie czy obszarze roboczym jest naturalnym odruchem każdej osoby pracującej przy komputerze. Wiele akcji, które wymagają teraz kilku kliknięć, przykładowo otwarcie połączenia do konsoli, mogłoby się zamknąć w dwóch. Brak menu kontekstowego jest niesamowicie frustrujący.
- Utworzenie połączenia między urządzeniami jest mega nieintuicyjne. Musisz wybrać urządzenie, kliknąć małą ikonkę nad nim i trzymając przeciągnąć połączenie, a na koniec wybrać porty. Jest to tak nieintuicyjne i niespójne z całym interfejsem, że musiałem spojrzeć do dokumentacji jak wykonać tę podstawową czynność.
- Wszystkie parametry urządzenia czy połączenia wpisuje się w dedykowanym oknie w dolnej części symulacji. Można by w wyskakujących okienkach kontekstowych, niestety trzeba się myszką namachać.
- Kontekstowe dymki z podpowiedziami są źle zaprojektowane i często nie da się przeczytać ich zawartości.
API w CML 2.0
CML 2.0 ma na szczęście też API, o którym więcej napiszę więcej w najbliższym czasie. API pozwala na wykonanie wszystkich działać co z GUI. Dostępna jest dobrze skonstruowana dokumentacja do API zbudowana z wykorzystaniem Swaggera. Zatem bezpośrednio z dokumentacji możemy sprawdzić działanie poszczególnych metod. Dostępna jest też biblioteka Pythona. Zainstalować możemy ją zarówno z pliku .whl dostępnego w instalacji CML 2.0 jak i z repozytorium PyPi. Zwróćmy zawsze uwagę na wersję – aktualnie w PyPi znajdziemy starsze wydanie biblioteki.
Ponadto w Ansible Galaxy znajdziemy moduły do Ansible, co pozwoli nam tworzyć playbooki. Mam nadzieję, że teraz po rozdzieleniu modułów od głównej części projektu Ansible, o czym pisałem niedawno, Cisco zgłosi moduły do oficjalnej kolekcji.
Gdzie jest generator konfiguracji?
Nie ma go. I to jest obok mało funkcjonalnego GUI największe moje zdziwienie. W Cisco VIRL jedną z największych zalet było to, że można było szybko wygenerować działającą topologię. Ustawialiśmy urządzenia, łączyliśmy je, ustawialiśmy pojedynczo lub dla grup parametry takie jak numer AS, protokołu routingu, VRF-y i klikaliśmy jeden przycisk. Adresy IP interfejsów i wiele parametrów generowało się automatycznie. Wystarczyło uruchomić symulację i miało się w pełni działającą sieć do testów.
W CML 2.0 automatyczne budowanie konfiguracji początkowej ogranicza się do nadania opisów interfejsom, ich aktywacji i ustawieniu użytkownika cisco/cisco. I chyba tyle.
Nie wiem jaka idea przyświecała twórcom. Jedna z najlepszych cech VIRL-a została z produktu usunięta. Oczywiście, można sobie napisać konfigurację, można napisać skrypty, można wykorzystać narzędzia do provisioningu dzięki API, tylko to zajmuje czas i nie każdy ma taką wiedzę.
Podsumowanie
Może jeszcze zmienię swoje zdanie, ale po 4 godzinach pracy z CML 2.0 jestem… może nie zawiedziony, ale mocno rozczarowany. Oczekiwałem kroku naprzód, a dostałem nie wiadomo do końca co. Trochę jakby produkt był rozwijany bez żadnego badanie satysfakcji klienta. Nie podejrzewam bym był jakimś wyjątkowym i nietypowym klientem.
Są jeszcze pewne funkcjonalności, których do końca nie sprawdziłem i wyglądają obiecująco. Między innymi lepsza możliwość integrowania zewnętrznych rozwiązań, czy właśnie wykorzystanie API. Napiszę na pewno o nich w najbliższym czasie. Jednak jak na razie moja ocena to 5/10.
CML 2.0 kosztuje tak jak VIRL $199 za roczną subskrybcję, którą można zakupić tutaj.
