Dzisiaj chciałbym podzielić się z Wami wyjątkowym repozytorium, które zawiera zbiór biblioteki Python przydatne w automatyzacji. Wykorzystasz je w skryptach automatyzujących zarządzanie sieciami komputerowymi. Repozytorium dostępne jest na GitHub Szkoły DevNet dla wszystkich. Jest to projekt, który może zainteresować zarówno początkujących, jak i doświadczonych programistów sieciowych. A co w nim znajdziesz? Szczegóły poniżej.
Wśród wielu serwisów udostępniających skrypty automatyzacji warto zwrócić uwagę na Cisco DevNet Code Exchange. Jest to platforma, na której zebrane są stworzone przez Cisco oraz niezależnych developerów i entuzjastów skrypty ułatwiające automatyzację produktów z ekosystemu Cisco. Jeżeli więc pracujesz z urządzeniami tej firmy na co dzień, to powinieneś mieć ten serwis w swoich zakładkach. Mój projekt, CMLNetKit, także znajduje się w tym repozytorium.
Ten post trendach DevOps w 2021 roku musiał się miesiąc “odleżeć”. Tyle czasu czekał on w kolejce na publikację. Dlaczego? Technologie wokół szeroko rozumianego DevNet (a także DevOps) gnają jak szalone, i może lista ta za pół roku będzie wyglądać zupełnie inaczej. Czekał, gdyż chciałem zobaczyć, czy styczeń sam w sobie nie przyniesie czegoś zaskakującego, co wywróci ją do góry nogami. I choć były zmiany to nie było rewolucji. Poniższe zestawienie ma charakter czysto subiektywny. Patrzę na technologie przez pryzmat infrastruktury, a nie samych aplikacji. Sam DevOps postrzegany jest także coraz częściej już nie przez pryzmat procesów związanych z samą aplikacją i środowiskiem chmurowym, ale szeroko pojętą infrastrukturą IT. Także tą zwirtualizowaną na sprzęcie umieszczonym w firmowych data center.
W moim subiektywnym zestawieniu wartych uwagi trendów DevOps w 2021 roku nie pojawia się żaden język programowania. Nie dlatego, że żaden nie zasługuje na uwagę. Uważam, że znajomość co najmniej jednego języka programowania to obecnie konieczność, a nie trend czy moda. A językiem, który należy znać, jest obecnie Python.
Błędy w oprogramowaniu wynikają bardzo często z błędów programistów. Z naszego niedopatrzenia, z tego, że nie przewidzieliśmy pewnych sytuacji czy zachowania użytkowników. Mogliśmy też zaniechać poprawnego sprawdzenia poprawności danych wejściowych. Przyczyn jest wiele. Dlatego ważne jest, abyśmy skanowali kod źródłowy naszego programu niezależnie od tego czy jest on kompilowany czy interpretowany. Bardzo mnie cieszy, że pod koniec września właściciele publicznych repozytoriów w serwisie GitHub uzyskali możliwość wykorzystania w swoim repozytorium darmowego skanera podatności CodeQL.
Skanowanie kodu to funkcja używana do analizowania kodu w repozytorium GitHub w celu znajdowania luk w zabezpieczeniach i błędów w kodowaniu. Takie błędy popełnia każdy programista i nie jest to nic dziwnego. Ważne jest by odpowiednio eliminować je ze swojego programu i doskonalić swój warsztat. Należy też unikać wykorzystywania bibliotek, w których zidentyfikowano podatności bezpieczeństwa.
W GitHub Marketplace dostępnych jest kilka skanerów, w większości płatnych. Od niedawna właściciele publicznych projektów mogą skorzystać z darmowego skanera CodeQL. Jeśli skanowanie kodu wykryje potencjalną lukę lub błąd w kodzie, GitHub wyświetli alert w repozytorium. Po naprawieniu kodu, który wywołał alert, usługa GitHub zamyka alert.
Darmowa usługa ma jednak swoje limity. W przypadku darmowego konta użytkownik ma do wykorzystania 2000 tak zwanych Action Minutes w każdym miesiącu. W zależności od tego jakie operacje wykonujemy stosowany jest odpowiedni mnożnik w stosunku do rzeczywistego czasu pracy modułu. Dla kodu wykonywanego na platformie Linux jest to 1, Windows 2, zaś MacOS to 10. Domyślny limit wydatków ustawiony jest na $0. Oznacza to, że gdy wyczerpie się nasza pula darmowych minut to zadania przestaną się wykonywać. Więcej informacji znajduje się w dokumentacji.
Włączenie skanera CodeQL jest bardzo proste. W głównym oknie naszego projektu przechodzimy do zakładki Security, a następnie z menu wybieramy sekcję Overview, oraz odnajdujemy przycisk Set up code scanning.
Dostępnych skanerów jest kilka, pamiętajmy jednak, że w większości są to produkty komercyjne, za których używanie będziemy musieli zapłacić. Wybieramy zatem z dostępnych opcji CodeQL.
Kreator doda w w naszym projekcie nowy plik codeql-analysis.yml. Znajduje się w nim konfiguracja skanera opisana w języku YAML. Otworzy się też nam edytor tego pliku co pozwoli nam już na tym etapie ustawić opcje skanowania. Zwróć w niej uwagę na sekcję on.
on:
push:
branches: [master]
pull_request:
# The branches below must be a subset of the branches above
branches: [master]
schedule:
- cron: '0 1 * * 3' W moim projekcie CMLNetKit jest tylko jeden branch o nazwie master. W przyszłości, gdy projekt się rozrośnie, będzie ich więcej. Wtedy w sekcji on będę musiał zdefiniować, dla których gałęzi projektu skaner ma być aktywny.
Skanowanie definiujemy dla operacji push, pull oraz jako cykliczne zadanie crona.
Większości użytkowników powinny wystarczyć domyślne ustawienia skanera. Zainteresowani opisem wszystkich dostępnych opcji mogą zapoznać się z dokumentacją.
Jeżeli zastosujemy domyślne ustawienia skaner będzie się uruchamiał domyślnie po kazdej aktualizacji kodu w repozytorium, czyli także od razu po dodaniu pliku konfiguracyjnego. Jego działanie jest sygnalizowane pomarańczową kropką status. Gdy na nią klikniemy, zobaczymy informację, że odbywa się w tle zdefiniowane przez nas zadanie.
Możemy teraz kliknąć na szczegóły i prześledzić działanie samego skanera. Jest ono podzielone na kilka etapów. Szczegóły wykonanej pracy w każdym z nich zobaczymy rozwijając właściwe poddrzewo z dostępnej listy.
Jeżeli w kodzie nie zostały znalezione żadne znane podatności, to status wykonania zadań w projekcie zmieni się na zielony
Jeżeli chcemy zobaczyć wyniki przeprowadzonych skanów musimy przejść do zakładki Actions, w której znajdziemy raporty z wykonanych skanów.
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.
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.
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.ę
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?
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.
Każdy programista wie, że umieszczanie komentarzy w kodzie źródłowym aplikacji jest nie tylko elementem dobrej praktyki, ale także często wymogiem. Często jednak nie ma na to czas lub jest go zbyt mało. W domowych czy firmowych labach często w ogóle nie zawracamy sobie tym głowy. Jednak nawet gdy piszemy aplikację lub playbook tylko dla siebie warto zadbać o choćby minimalną jego dokumentację, a komentarze zawarte w kodzie źródłowym przydadzą się, jeżeli będziemy chcieli go wykorzystać potem w innym projekcie.