git

Automatyzacja odtwarzania Cisco ISE z backupu - część I

Automatyzacja odtwarzania Cisco ISE z backupu – część I

Automatyzacja odtwarzania Cisco ISE z backupu - część I

W tej serii artykułów przybliżę Ci jeden z moich ostatnich projektów do domowego labu. Nie ukrywam, że lubię mieć lab always-on, czyli taki, który działa, który ma skonfigurowane pewne funkcjonalności, do których w każdej chwili mogę się odwołać, sprawdzić je czy zmodyfikować. Powstała więc potrzeba zautomatyzowania procesu budowania maszyny wirtualnej z Cisco ISE oraz odtwarzania konfiguracji ISE z kopi zapasowej. W pierwszym odcinku spójrzmy jak wygląda automatyzacja odtwarzania Cisco ISE i z jakich komponentów będę korzystał.

Czytaj dalej
Przez Piotr Wojciechowski, temu
O automatyzacji sieciach - wywiad z Przemkiem Rogalą

O automatyzacji w sieciach – wywiad z Przemkiem Rogalą (część II)

O automatyzacji sieciach - wywiad z Przemkiem Rogalą

W pierwszej części mojej rozmowy z Przemkiem Rogalą, twórcą bloga TTL255, rozmawialiśmy o egzaminie DEVASC i certyfikacji Cisco DevNet. Certyfikaty byłby jednak zbędne, gdyby nie rzeczywiste projekty, w których wiedzę i doświadczenie zamienia się na konkretne rozwiązania. Zarówno Przemek jak i ja realizujemy tego typu projekty, choć na innych rynkach. W drugiej części mojej rozmowy skupimy się właśnie na rzeczywistym wykorzystaniu automatyzacji, projektach, programowaniu i narzędziach, które wykorzystujemy.

Czytaj dalej
Przez Piotr Wojciechowski, temu
Przestał budować się obraz kontenera

Przestał budować się obraz kontenera

Przestał budować się obraz kontenera

Częścią obrazów kontenerów, które używam w swoich środowiskach sieciowych zarządzam samodzielnie. Ich cykliczną budową zajmuje się Jenkins. Także kontenery z obrazem samego Jenkinsa są budowane w ten sposób. 10 sierpnia coś się jednak stało. Mój skrypt przestał działać. W efekcie tego przestał budować się obraz kontenera. Wszystko ze względu na zmiany w pakietach z językiem Python w dystrybucji Alpine Linux. Jeżeli budujesz obrazy w oparciu o tą właśnie dystrybucję, to w tym artykule znajdziesz rozwiązanie.

Czytaj dalej
Przez Piotr Wojciechowski, temu
Pull Request w Git

Pull Request w Git

Pull Request w Git

Dzisiaj słowo o tym, jak pracuje się wspólnie nad projektami i wprowadzaniem zmian do kodu. Z oczywistych względów do kodu programu nie mogą być wprowadzone żadne zmiany dokonane przez dowolną osobę. Zmiany takie muszą być zatwierdzone przez właściciela projektu lub osoby przez niego wyznaczone. Niemniej ważnym aspektem jest to, aby praca dwóch osób nie kolidowała ze sobą, a zaakceptowane zmiany na koniec były spójne. Służy temu mechanizm Pull Request.

Czytaj dalej
Przez Piotr Wojciechowski, temu
Jak szybko publikować pierwszy kod na GitHub?

Jak szybko publikować pierwszy kod na GitHub?

Jak szybko publikować pierwszy kod na GitHub?

W ciągu ostatnich kilku dni opublikowałem na GitHub pierwszy kod mojej aplikacji CMLNetKit. Od razu dostałem pytanie: “Już napisałeś całość? Tak szybko?“. No nie, aplikacja nie jest skończona. Ona jeszcze mało co potrafi, tak naprawdę zaimplementowałem jedynie jedną z funkcjonalności, o których pisałem w moim poprzednim artykule. Dlaczego zatem zdecydowałem się na pierwsze publiczne udostępnienie kodu już teraz? Jak szybko publikować pierwszy kod własnej aplikacji w repozytorium?

Czytaj dalej
Przez Piotr Wojciechowski, temu
Zakładamy projekt na GitHub i dodajemy go do PyCharm

Zakładamy projekt na GitHub i dodajemy go do pyCharm

Zakładamy projekt na GitHub i dodajemy go do PyCharm

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.

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