Azure DevOps

W ten weekend miałem okazję być na kursie/warsztatach/prezentacji zorganizowanych przez StacjaIT .

Był to płatny, kilkugodzinny kurs w tematyce narzędzia "Azure DevOps". Poziom warsztatu był oznaczony jako "wprowadzenie" tudzież "dla początkujacych".  Ostatnio zainteresowałem się tematyką DevOps nieco głębiej, a że tematy Chmurowe są mile widziane w wielu ogłoszeniach o pracę postanowiłem się wybrać na ten warsztat. I po wszystkim uczucia mam nieco mieszane. Spodziewałem się czegoś związanego z Chmurą, na co mógłby wskazywać pierwszy człon nazwy, tj. "Azure". Stety bądź niestety coś, co Microsoft nazwał "Azure DevOps" to nie jest typowe "Azure", a jedynie stary "Team Foundation System" po rebrandingu. 

Moja pierwsza styczność z TFS miała miejsce jakieś ~15 lat temu i wtedy w firmie, w której pracowaliśmy zaliczyliśmy jeden poważny fackup związany z błędem merge kodu źródłowego. Autorski, microsoftowy system kontroli wersji zaliczył na naszym projekcie wielkiego faila. Na tyle dużego, że programiści go nienawidzili. Managment natomiast był zbyt zajęty łapaniem "punktów bonusowych" u Microsoftu i nalegał na dalsze kontynuowanie korzystania z tej technologii.

Pierwsza część warsztatów to była cała filozofia "DevOps". Wyjaśnienie czym jest DevOps, a czym nie jest. Nie będę się tutaj nad tym teraz rozpisywał. Polecona była również książka "Projekt Fenix" którą swego czasu rozdawano nam za darmo gdy jeszcze pracowałem w Santanderze. 

Teraz wracamy do części praktycznej i... okazało się że ten cały współczesny "Azure DevOps" to jest nic innego, jak tool w którym pracowałem przez ~2.5 roku w Duńskim Santanderze. I w sumie tyle bym mógł napisać. Że największą wartością dodaną tego szkolenia było to, że została mi usystematyzowana pewna wiedza, którą już wcześniej miałem, ale nie do końca orientowałem się w fachowym nazewnictwie. Całe szczęście, że ticket na to szkolenie dostałem za darmo w mojej obecnej firmie.

To jeszcze tak z kronikarskiego obowiązku wypadało by wspomnieć czym ten Azure Devops jest. 

Azure DevOps to jest zintegrowane narzędzie, a dokładniej kilka narzędzi w jednym które spełnia podstawowe funkcje takie jak: Scrum Board, Pull Request Board, firmowa Wikipedia, Build Pipeline (CI), tool do publikowania deployów (CD)* i parę innych rzeczy. Taki mini kombajn, który dla firm, które siedzą na stack M$ i maja wykupione płatne licencje na Visual Studio dodawany jest niejako do tych licencji w gratisie.

No cóż. Nie do końca było to to, czego się spodziewałem ale przynajmniej teraz wiem jak się nazywa tool, którego znajomość mogę sobie wpisać do CV.

* - tutaj CD oznaczało jedynie inicjalizację builda (kwestia akceptacji), a sam build ogarniany był w Octopus Deploy. Tutaj część procesu była automatyczna, tutaj uzyskiwane były zgody (jeśli np. deploy na proda wymagał jakiejś akceptacji kogoś "powyżej"), ustawiany był czas deployu, ale sam finalny build i deploy na wiele różnych serwerów czy środowisk odbywał się w Octopusie.

https://en.wikipedia.org/wiki/Azure_DevOps_Server - strona Azure Devops na wikipedi.

Prometeus + Grafana

Ost. w pracy miałem do zrobienia fajne zadanie, tj. dodać narzędzie monitorujące Prometeus wraz z narzędziem wyświetlającym te dane czyli Grafaną. Wszystko w kontenerach Dockerowych, czyli bardzo przyjemne zadanie. Na wstępnie chciałbym pozdrowić Marcina Budnego, którego prezentacja na Śląskiej Grupie .NET dostępna na youtube bardzo mi w tym pomogła: link do nagrania

Gdyby ktoś jednak nie miał czasu, to opiszę w dużym skrócie. System monitorujący składa się z 3 elementów:

1. klient Prometeusa, który wystawia endpoint /metrics z ustandaryzowanym tekstem (format monitu)

2. serwer Prometeusa, który jest de fakto bazą danych nasłuchującą entpointy klientów, agregujace je oraz wystawiający własny endpoint z danymi

3. interfejs UI w postaci Grafany

Klienci mogą być różni. Wiele technologii posiada własnych klientów, a jak w jakiejś brakuje to dosyć łatwo można napisać własnego klienta. Do .net istnieje kilka klientów. Do tego obrazy Dockerowe mają swojego klienta. Serwer może mieć swojego klienta (np. monitorowanie zajętości dysku twardego), kolejki typu Kafka mogą mieć klienta itp.itd.

Serwer w sposób dynamiczny agreguje te dane, dzięki czemu klienci mogą się "rozszerzać" np. w oparciu o kontenery Dockerowe i np. Kubernetesa. Jak mamy większe obciążenie to zwiększamy ilość aplikacji klienta, a serwer Prometeusa automatycznie to wykrywa i ogarnia.

Grafana, która nasłuchuje zagregowanych danych z Prometeusa to część UI która do wyświetlania danych w przystępny sposób. Obok wyświetlania może też wysyłać powiadomienia, np. na email, slacka, teamsy itp. 

Klienci Prometeusa zazwyczaj posiadają pewien zbiór gotowych metryk, ale zawsze można dodawać swoje (Marcin to fajnie wyjaśnił w swoim filmie). Do tego, można się podpiąć pod inne toole, np. Open Telemetry i wystawić dane dla Prometeusa przepuszczając dane z OpenTelemetry przez mapper (dane wystawiane przez OpenTelemetry są w innym formacie niż ten, którego oczekuje Prometeus).

Wszystko działa całkiem miło i przyjemnie. Wiele rzeczy jest zautomatyzowanych. Bawiąc się grafaną opartą o obraz dockerowy w miarę szybko ogarnąłem jak zapisać i przechowywać dane tablic (dashboardów) w taki sposób, aby wszystko było "na gotowe" po uruchomieniu kontenera. Trzeba w tym celu zmapować Volumes na swój własny katalog, ale fajnie to działa. Widać, że technologia jest dopracowana (np. dashboard jest w formacie .json więc fajnie się archiwizuje zmiany w raportach w Git-cie). 

W międzyczasie zrobiłem też w firmie małą, wewnętrzną prezentację z tego tematu, jednak obawiam się że mogę nie dostać zgody na jej upublicznienie.

Linki:

https://www.youtube.com/watch?v=jYbqGB3Vhbo - prezentacja Marcina Budnego na Ślaskiej grupie .NET

https://github.com/docker/awesome-compose/blob/master/prometheus-grafana/README.md  - przykładowy plik Docker-Compose.yml

easyretro.io

Pracując w SCRUM swego czasu mieliśmy problem w zespole aby znaleźć odpowiednie narzędzie do robienia Retro. Niby prosta sprawa, zwykła tabelka, kilka pogrupowanych karteczek itp.itd., ale wbrew pozorom był problem aby zrobić to dobrze. Nawet tool z "Azure Devops" był słaby, choćby dlatego że od razu było widać kto i co napisał. Testowaliśmy też jakieś darmowe odpowiedniki ale były zwyczajnie słabe. Obecnie w projekcie w którym pracuję wykorzystujemy easyretro.io i z tych wszystkich (4-5?) tooli których używałem w tym celu to narzędzie wydaje się być jak do tej pory najlepsze.

Dockle - narzędzie do skanowania już zbudowanych obrazów Docker

 W poprzednim poście opisałem narzędzie do skanowania obrazów dockera Trivy link. W tym wpisie wspomnę o narzędziu, które służy do skanowania kwestii bezpieczeństwa już zbudowanych narzędzi, które w dodatku posiada dosyć dobrą możliwość wpięcia w proces CI/CD czyli Dockle.

Szerzej opisane co to narzędzie robi jest na blogpoście a na portalu Medium - link

Linki:

https://github.com/goodwithtech/dockle - kod źródłowy na github

https://containers.goodwith.tech/ - strona projektu

https://shrihariharidas73.medium.com/dockle-container-image-linter-for-security-helping-build-the-best-practice-docker-image-easy-b4853fb3675e - blogpost z opisem czym jest dockle

Trivy - narzędzie do skanowania podatności obrazów Docker

Budując lub wykorzystując obraz Dockerowy warto mieć świadomość że ten obraz często i gęsto posiada własne zależności, np. różnego rodzaju oprogramowanie zainstalowane przez Twórców obrazu dockerowego. Każde z tych narzędzi czy bibliotek może posiadać swoje podatności bezpieczeństwa. Jeżeli zbudujemy obraz, np. bazując na Node.js, który z kolei bazuje m.in. "buildpack-deps:stretch" to musimy mieć świadomość, że jeśli paczka "buildpack-deps:stretch" będzie posiadała jakąś podatność bezpieczeństwa to nasz obraz również będzie ją posiadał. W tym celu warto skanować obrazy dockerowe pod kątem podatności bezpieczeństwa. Przykładowe narzędzie: Trivy.

Linki:

https://trivy.dev/latest/ - strona projektu

https://github.com/aquasecurity/trivy - kod źródłowy na githubie

https://wkontenerach.pl/zarobili-36000-usd-z-kopania-kryptowalut-przez-podatne-obrazy-dockerowe-na-docker-hub/ - blogpost z uzasadnieniem dlaczego warto skanować swoje kontenery pod kątem podatności bezpieczeństwa.

KeyValueStore - Vault

 Mojego bloga często traktuje jako swojego rodzaju notatnik na przyszłość. Tak jest i tym razem, tj. chciałbym sobie gdzieś przechować referencje do projektu https://www.vaultproject.io/ czyli projektu, który możemy użyć jako swego rodzaju KeyValueStore dla różnego rodzaju haseł w aplikacji w przypadku podejścia rozproszonej architektury aplikacji, tj. aplikacji opartej o mikroserwisy. Zamiast więc powtarzać wszystkie sekrety dla każdego projektu na każdym osobnym serwisie w builderze to możemy je trzymać w schronie (ang. Vault), a sami pilnujemy tylko hasła do vaulta (łatwiej się wtedy to wszystko zmienia gdy zachodzi potrzeba zmiany).

Integracje z aplikacją .net możemy zrobić przez VaultSharp

nBomber - testy wydajnościowe w .NET

Czasami biznes wymaga od nas przedstawienia raportu wydajności naszego API. Odpowiedni czas odpowiedzi lub ilość zapytań na sekundę może też być zdefiniowane jako element wymagań biznesowych wobec systemu który projektujemy lub którym zarządzamy. Możemy wtedy próbować pisać odpowiednie rozwiązania samemu, lub użyć gotowego rozwiązania. Takim gotowym rozwiązaniem napisanym w .NET i współpracującym z .NET-owymi bibliotekami testującymi (np. xUnitem) jest biblioteka nBomber. 

Linki:

https://nbomber.com/ - strona projektu

https://github.com/PragmaticFlow/NBomber - kod źródłowy na GitHub