Piotr Wojciechowski

Wtorki z Pythonem: Importowanie bibliotek

Importowanie bibliotek w Python

Wtorki z Pythonem: Importowanie bibliotek

W automatyzacji nie uciekniesz od programowania. Najpopularniejszym językiem jest Python i śmiało można powiedzieć, że musisz go w dzisiejszych czasach znać. W przygotowywanej przez CiscoPress do wydania książce CCNP and CCIE Enterprise Core ENCOR 350-401
Official Cert Guide znajdziemy cały rozdział poświęcony automatyzacji z przykładami rozwiązań w języku Python. No i oczywiście jest cała ścieżka certyfikacji Cisco DevNet, w której programowanie odgrywa ogromną rolę. Dlatego startuję z nowym cyklem Wtorki z Pythonem, w ramach którego przeczytacie krótsze i dłuższe teksty poświęcone językowi Python i realizacji różnych zadań, z którymi możecie się w przyszłości spotkać, za pomocą tego języka. Importowanie bibliotek czy funkcji w języku Python to jedna z podstawowych czynności nawet w prostych programach dlatego jej poświęcę pierwszy z artykułów.

Czytaj dalej
Przez Piotr Wojciechowski, temu
Dogfooding

Dogfooding

Dogfooding

Wielokrotnie w swoich artykułach zalecałem, aby wszelkiego rodzaju mechanizmy automatyzacji tworzyć według zasady „start small, grow big„. Gdy rozwijamy swoją aplikację albo skrypt, musimy je wciąż testować. Jednym z najlepszych sposobów na takie testowanie jest używanie stworzonego produktu we własnej infrastrukturze. Takie podejście nazywa się dogfooding i choć może się wydawać, że ma sporo wspólnego z pojęciem „testowania na produkcji„, do odnosi się do czegoś nieco innego.

Czytaj dalej
Przez Piotr Wojciechowski, temu
Wprowadzanie zmian do repozytorium projektu w pyCharm

Wprowadzanie zmian do repozytorium projektu w pyCharm

Wprowadzanie zmian do repozytorium projektu w pyCharm

W poprzednim artykule pokazałem, w jaki sposób założysz projekt na GitHub oraz dodasz go do pyCharm, czyli zintegrowanego środowiska programistycznego. Wspomniałem wtedy, że na Twoim komputerze powstała lokalna kopia, klon, repozytorium projektu z GitHub-a. Pracujesz na niej, dodając nowe linie kodu, czy modyfikując istniejące. W pewnym momencie musisz jednak wprowadzić zmiany do repozytorium projektu. W pyCharm i każdym innym środowisku IDE, wprowadzanie zmian do repozytorium projektu jest to bardzo proste i nie wymaga znajomości komend git-a.

Gdzie tak naprawdę piszesz swój kod?

No właśnie, gdzie go piszemy? Gdybyśmy korzystali z edytora wbudowanego w GitHub czy GitLab edytowalibyśmy kod bezpośrednio na serwerze. Prawdopodobnie wiązałoby się to z jednoczesną jego aktualizacją w repozytorium. W rzeczywistości jednak WebIDE to narzędzie do drobnych poprawek czy małych prywatnych repozytoriów. W świecie programistów robi się to inaczej.

Kod aplikacji każdy z programistów uczestniczących w projekcie edytuje na własnym komputerze, tam też go testuje. W dużych projektach takich jak Ansible, dla którego stworzyłem i opiekuję się modułami do obsługi Docker Swarm, korzysta się z zaawansowanych funkcjonalności takich jak: branch, pull request, merge, rebase. Zapamiętaj te terminy, bo na pewno Ci się kiedyś przydadzą, ale nie przywiązuj do nich teraz wielkiej wagi.

Jak już wspomniałem, tworząc moją aplikację będę pisał i testował kod na własnym komputerze w sklonowanym repozytorium. Na początek przygotowuje wszystkie zmiany lokalnie, na przykład tworzę nowy folder czy plik. Za każdym razem, gdy tworzymy nowy plik, pyCharm pyta się czy dodać go do repozytorium. Tylko pliki dodane do repozytorium będą w nim zarządzane. Pliki będące częścią repozytorium, w pyCham wyświetlane są w projekcie w kolorze zielonym, niedodane w czerwonym zaś zmodyfikowane w niebieskim.

pyCharm - plik niedodany do repozytorium Git
pyCharm - plik niedodany do repozytorium Git
pyCharm - plik dodany do repozytorium Git
pyCharm - plik dodany do repozytorium Git

Wprowadzanie zmian do repozytorium

Wprowadzanie zmian do repozytorium jest dwuetapowe. W pierwszym z nich zatwierdzamy zmiany w lokalnej kopii repozytorium. Taka zmiana nazywa się commit. Powinniśmy go wprowadzać z każdym nowym utworzonym i przetestowanym blokiem naszej pracy. Może to być nowa funkcjonalność albo drobna poprawka. Dobrą zasadą jest, aby nie commit-ować niedziałających elementów kodu, ale czasem nie da się tego uniknąć. Każdy commit powinien być opatrzony komentarzem. 

Aby dodać nowy commit wybieramy z menu aplikacji VCS -> Commit... W oknie dialogowym możemy wybrać zmiany odnoszące się do których plików chcemy wprowadzić oraz dodać komentarz. Komentarze powinny być zwięzłe, ale informować czego zmiana dotyczy.

Zmiany, które wprowadziliśmy, nie są póki co widoczne w repozytorium naszego projektu. Nadal są to tylko zmiany odnotowane lokalnie. Aby dodać je do repozytorium projektu, musimy wykonać operacje Push. W ten sposób synchronizujemy jeden lub więcej commit-ów do repozytorium.Wtedy dopiero system analizuje czy wprowadzone przez nas zmiany nie stoją w konflikcie ze zmianami wprowadzonymi przez inną osobę pracującą nad projektem. 

Aby dodać wprowadzone zmiany do projektu na GitHub wybieramy VCS -> Git -> Push.. W oknie dialogowym zobaczymy listę commitów, które zostaną wprowadzone do kodu na repozytorium GitHub. 

Jeżeli operacja wykona się poprawnie zobaczymy wprowadzone przez nas zmiany w repozytorium projektu na GitHub.

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
Zasady budowy mechanizmów automatyzacji

Zasady budowy mechanizmów automatyzacji

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.

Czytaj dalej
Przez Piotr Wojciechowski, temu
Namespace i podłączenie gniazda Dockera do kontenera

Namespace i podłączenie gniazda Dockera do kontenera

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.

Czytaj dalej
Przez Piotr Wojciechowski, temu
Backup konfiguracji routera za pomocą Ansible

Backup konfiguracji routera za pomocą Ansible

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.

Czytaj dalej
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