5 trendów DevOps, które warto śledzić w 2021

5 trendów DevOps, które warto śledzić w 2021

5 trendów DevOps, które warto śledzić w 2021

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.

Czytaj dalej
Skaner podatności CodeQL na GitHub

Skaner podatności CodeQL na GitHub

Skaner podatności CodeQL na GitHub

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. 

Czym jest 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.

Jak włączyć CodeQL

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.

Aktywacja skanera kodu CodeQL w projekcie na GitHub
Aktywacja skanera kodu CodeQL w projekcie na GitHub

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. 

Z dostępnych skanerów wybieramy CodeQL
Z dostępnych skanerów wybieramy 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ą.

Wgranie pliku konfiguracyjnego CodeQL do repozytorium projektu
Wgranie pliku konfiguracyjnego CodeQL do repozytorium projektu

Działanie skanera w praktyce

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.

Wykonywania zadania typu workflow w tle
Wykonywania zadania typu workflow w tle

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.

Szczegóły działania procesu skanowania kodu przez CodeQL
Szczegóły działania procesu skanowania kodu przez CodeQL

Jeżeli w kodzie nie zostały znalezione żadne znane podatności, to status wykonania zadań w projekcie zmieni się na zielony

Sygnalizacja poprawnego wykonania zadań w projekcie
Sygnalizacja poprawnego wykonania zadań w projekcie

Jeżeli chcemy zobaczyć wyniki przeprowadzonych skanów musimy przejść do zakładki Actions, w której znajdziemy raporty z wykonanych skanów.

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

Pierwszy etap pracy nad moją aplikacją zakończony

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.ę

Czytaj dalej
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
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
Dokumentacja playbooków Ansible

Dokumentacja playbooków Ansible

Dokumentacja playbooków Ansible

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.

Czytaj dalej