Na pewno nie umknęło Twojej uwadze, że w języku Python nazwy niektórych obiektów, zmiennych czy funkcji składają się z podkreśleń umieszczanych na początku, na końcu lub po obu stronach. Jest to celowy zabieg, konwencja i standard, który ma na celu uporządkowanie kodu zarówno pod względem semantycznym, funkcjonalnym jak i optycznym, czyli ułatwić jego czytanie. W dzisiejszym artykule wyjaśnię Ci jakie znaczenie mają podkreślenia w tych konkretnych przypadkach.
W pierwszej części pokazałem jak definiować listę oraz w jaki sposób odczytywać pojedyncze, lub całe grupy elementów listy. Operacji na listach i jej elementach jest nieco więcej. Raz utworzona lista nie jest obiektem stałym i można zarówno modyfikować wartość każdego z jej elementów jak i dodawać oraz usuwać poszczególne elementy. Listy w Python pozwalają na przeprowadzenie tych operacji w prosty sposób. W tym artykule zaprezentuję Ci jak to zrobić.
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.
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).
Nie będę ukrywał, że nadchodząca premiera nowej ścieżki certyfikacyjnej Cisco DevNet była jedną z motywacji do stworzenia Szkoły DevNet. Jednak nie jedyną. Program zaproponowany przez Cisco jest ciekawy, ale nie można powiedzieć, że wyczerpujący. Nie chodzi o to, że skupiony jest na produktach oferowanych przez Cisco, co jest dość naturalne. Po prostu skonstruowany jest wokół jednego z obszarów automatyzacji. W większości rzeczywistych projektów będzie to działka zbyt wąska, a co za tym idzie może skutkować porażką całego projektu. Certyfikacja Cisco DevNet jest jednak bardzo dobrym punktem, aby po poznaniu fundamentów swobodnie rozwijać swoje kompetencje na innych obszarach automatyzacji.
Certyfikacja Cisco DevNet podzielona jest na dwa poziomy – Associate oraz Professional. Na poziomie podstawowym musisz zdać jeden ogólny egzamin. Przystępując do certyfikacji Professional konieczne jest zdanie dwóch egzaminów – ogólnego oraz jednego ze specjalistycznych. Podział taki wydaje się ciekawy i sensowny. Osoba zainteresowana wiedzą z zakresu automatyzacji w Data Center powinna się skupić na specyficznych zagadnieniach z tej działki, a nie na sucho zgłębiać tajniki Collaboration czy IoT.
Oprócz ogólnej wiedzy sieciowej związanej z zasadami działania sieci komputerowych czy projektowania infrastruktury możemy wyróżnić kilka obszarów technologicznych, których nie tylko podstawy należy zgłębić
Nawet jeżeli nie będziesz developerem piszącym kod, to jednak musisz oswoić się z myślą, że wchodzisz w świat projektów programistycznych. Przestajesz tworzyć konfigurację, a element aplikacji. Zatem twoje podejście do pracy musi być takie samo, albo co najmniej zbliżone do tego, jakie programiści wykorzystują w swojej pracy. Zacznij od zrozumienia czym jest CI/CD (Continuous Integration / Continuous Deployment) i jak to co stworzysz będzie wkomponowane w ten proces. Koniecznie zapoznaj się z takimi narzędziami jak Jenkins, Terraform, Puppet, czy wspomniany już Ansible.
Nie zapominaj jednak o fundamentalnej wiedzy z zakresu routingu, switchingu czy security. Nie pozwól zakurzyć się swojej wiedzy o różnych produktach. Zmieniając swoją rolę z “wyklikiwacza” konfiguracji w programistę nie zapomnij, że samo urządzenie czy aplikacja nadal działa tak samo. Twój router nie zmienił sposobu routowania pakietów ponieważ konfigurację wprowadziłeś za pomocą RESTCONF a nie CLI. Zainstalowany w sieci FirePower Thread Defence nadal w ten sam sposób będzie analizował zawartość pakietów niezależnie, czy konfigurację wprowadzisz za pomocą REST API czy “staroświeckiego’ GUI.
Projektując zautomatyzowany proces tak na prawdę piszesz algorytm. Sekwencję kroków do wykonania, na którą mogą wpływać różne zmienne. To też jest programowanie, choć może nie wiązać się z napisaniem nawet jednej linii kodu. Często może zostać sprowadzone do poukładania klocków i odpowiedniego zarządzania parametrami, które są do nich przekazywane i z nich odbierane. Jednak nadal jest to programowanie, w którym musisz myśleć o tym jakimi parametrami operujesz i jak poszczególne elementy algorytmu będą wpływały na siebie nawzajem.
Postaraj się o dostęp do środowiska testowego, nigdy nie eksperymentuj na środowisku produkcyjnym.