niedziela, 15 grudnia 2024

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


sobota, 14 grudnia 2024

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.

sobota, 23 listopada 2024

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


piątek, 15 listopada 2024

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

pact.io - testy kontraktów (CDC)

 Aktualnie poszerzam moją wiedzę nt. tworzenia aplikacji i natrafiłem na nowy dla mnie temat, tj. testowanie kontraktów Consumer-Driven-Contract-Testing w skrócie zwane CDC. Do tego typu testów wykorzystywane jest rozwiązanie pact.io nt. z wtyczką dot-netową Pactify

Same testy polegają na stworzeniu w JSON "kontraktu" którego oczekuje konsument, a następnie samoistne odpytywanie endpointów czy oczekiwany kontrakt jest cały czas dostarczany. W tego typu testach skupiamy się na zmiennych oraz typach danych, a nie na samych wartościach, tzn. bardziej nas interesuje czy endpoint nadal posiada zakładane pola z zakładanymi typami danych niż faktyczne wartości tych pól.


Linki:

https://docs.pact.io/ - strona projektu 

https://github.com/snatch-dev/Pactify - wtyczka .netowa

wtorek, 5 listopada 2024

onetimesecret.com

Czasami zdarza nam się prośba o wysłanie do kogoś jakiegoś hasła albo dyskretnej wiadomości, która po przeczytaniu powinna zostać usunięta. Czasami stosuje się do tego Teams, gdzie po przeczytaniu wiadomość jest usuwana z chatu. A co jeśli chcemy wysłać dyskretną wiadomość do kogoś, kto nie ma Teamsów? Tutaj z pomocą przychodzi strona onetimesecret.com , gdzie możemy wpisać naszą wiadomość, którą odbiorca za pomocą specjalnie wygenerowanego linku będzie mógł wyświetlić tylko raz. Wygenerowany przez nas link będzie mógł zostać odczytany tylko raz, co (przynajmniej w teorii) powoduje że nawet jeśli ktoś w przyszłości wykradnie skrzynkę pocztową naszą lub adresata naszej wiadomości to (przynajmniej w teorii) nie powinien poznać hasła przez nas przekazanego.

Strona może nie jest idealna, ale zawsze to kolejny kamyczek do ogródka zwanego bezpieczeństwem. 

czwartek, 3 października 2024

WebMotions.Fake.Authentication.JwtBearer

 Nowy .net 8 daje nam bardzo fajną możliwość wykonywania testów integracyjnych naszych aplikacji webowych przy pomocy klasy WebApplicationFactory. Tego typu testy mogą się odbywać zarówno na faktycznej aplikacji jak i częściowo podmienionej, np. możemy sami podmienić niektóre serwisy, a inne zostawić takie jak były. Możemy zmienić bazę danych, na której mają się wykonywać testy itp. Bardzo fajne narzędzie choćby  po to, aby mieć pewność co finalnie wychodzi z naszej aplikacji. 

Czasami jednak potrzebujemy mieć aplikację z uwierzytelnieniem, tj. autoryzacją. Przykładowo przy pomocy JWT token. Oczywiście możemy pisać pełny kod od początku tak, aby łatwo się to podmieniało lub aby serwis tworzący tokena poprawnie zwracał go zarówno dla projektu z API jak i dla projektu z testami, ale czasami może się zdarzyć, że trafimy do istniejącego projektu, w którym następuje uwierzytelnienie w zewnętrznym serwisie do którego nie mamy dostępu, a przy okazji nie chcemy od samego początku przebudowywać całej aplikacji (refaktor powinien się odbywać ewolucyjnie, a nie rewolucyjnie). W takich sytuacjach z pomocą przychodzi nam paczka nugetowa: WebMotions.Fake.Authentication.JwtBearer 

Dzięki tej paczce w naszym BaseTestController możemy stworzyć metodę autoryzacji:

            dynamic data = new ExpandoObject();

            data.sub = Guid.NewGuid();

            data.role = new [] {"sub_role","admin"};

           Client.SetFakeBearerToken((object)data);


gdzie Client to jest obiekt klienta tworzony przez WebApplicationFactory w metodzie "WithWebHostBuilder(builder => {}).CreateClient();


Później możemysię to tych Claimsów odwołać w dowolnym miejscu aplikacji poprzez implementację interfejsu IHttpContextAccessor ,który możemy wstrzyknąć np. do naszej testowej implementacji ISecurityService (czy jaki tam będziemy mieli dowolny inny interfejs w naszej aplikacji odpowiedzialny za obsługę uwierzytelnienia).

Kod źródłowy dostępny na https://github.com/webmotions/fake-authentication-jwtbearer z licejcją MIT więc możemy to komercyjnie zastosować. Dzięki tej paczce, możemy sobie "zasymulować" autoryzację i podmienić jedynie serwis odpowiedzialny za autoryzację. Cała reszta aplikacji może pozostać tak jak była (sami decydujemy, którą część aplikacji chcemy testować tak jak jest, a którą chcemy symulować).


Linki

https://www.nuget.org/packages/WebMotions.Fake.Authentication.JwtBearer -  nuget

https://github.com/webmotions/fake-authentication-jwtbearer - github

https://licenses.nuget.org/MIT - licencja MIT

piątek, 20 września 2024

Humanizer

 Jak już wspomniałem w moim poprzednim poście oglądam sobie kurs "SOLID WebApi" od DevMentors i co jakiś czas wyłuskuję sobie z niego coś nowego. Tym razem wyłuskałem od nich paczkę NuGetową Humanizer  czyli gotowe rozszerzenie to zamiany stringów z jednej wersji na inną, np. z CamelCase na SnakeCase, albo ze SnakeCase na wyrazy rozdzielone spacją. Więcej przykładów jest na stronie projektu. To co warto wspomnieć, to kod źródłowy dostępny jest na githubie (open source), a sama paczka jest na licencji MIT, czyli można ją bez problemu używać również w komercyjnym oprogramowaniu.


Linki:

https://github.com/Humanizr/Humanizer - link do kodu źródłowego na GitHub z plikiem README oraz przykładami użycia.

https://www.nuget.org/packages/Humanizer/ - link do paczki na serwisie nuget

niedziela, 15 września 2024

Shouldly NugetPackage

Oglądając kurs od DevMentors zauważyłem że używają oni pakietu Nugetowego Shoudly. Shouldy jest to kolejny pakiet który pozwala wykonywać testy jednostkowe w sposób bardziej płynny, czyli innymi słowy robi dokładnie to samo, co opisana przezemnie wcześniej paczka FluentAssertions.

Co warto wspomnieć, zarówno Shouldy jak i FluentAsserions mają w miarę przyjazne (z komercyjnego punktu widzenia) licencje. Shouldy ma licencję BSD-2, natomiast FluentAsserions posiada licencję Apache.


Linki:

https://docs.shouldly.org/ - strona projektu

https://www.nuget.org/packages/Shouldly - link do Shoudly na Nuget.

piątek, 13 września 2024

Wtyczka REST Client do Visual Studio Code

Kupiłem sobie kurs "Solidne Web API" od DevMentors, zacząłem sobie tego słuchać zauważyłem fajne narzędzie które pokazali. Chodzi o wtyczkę "Rest Client" dla edytora Visual Studio Code. Mianowicie możemy w bardzo prosty i łatwy sposób utworzyć sobie nowy plik tekstowy z rozszerzeniem .http i przy pomocy tej wtyczki testować nasze REST API niczym przy pomocy Postmana. Zaleta tego rozwiązania jest taka, że wszystko mamy zapisane w kodzie pod kontrolą systemu kontroli wersji (np. GIT).

Bardzo fajne i zgrabne podejście. Już mi się podoba.


Linki:

https://marketplace.visualstudio.com/items?itemName=humao.rest-client -> wtyczka

https://codewithandrea.com/tips/rest-client-vscode/ - tutaj przykładowe użycie

https://code.visualstudio.com/ -> visual studio code

piątek, 6 września 2024

MediatR czyli wstęp do CQRS

Przeglądając polecane biblioteki do .NET Framework natrafiłem na bibliotekę MediatR. Czasami się przewija w różnych miejscach, ale jej nie kojarzyłem. Przynajmniej nie w pełni świadomie. Postanowiłem więc jej się nieco  przyjrzeć. W tym celu zrobiłem sobie mały wstęp bazujący na blogu Cezarego Walenciuka oraz umieszczonemu przez niego kodowi źródłowemu. Okazało się, że jednak kiedyś z tego korzystałem w jednym z projektów CQRS utworzonych przez jednego z kolegów z pracy, tyle że robiłem to wtedy w sposób nie do końca w pełni świadomy. Aktaulnie, po przeczytaniu blogposta i wykonaniu przykładowego projektu jestem już nieco bardziej świadomy, a przynajmniej wiem z czym to się je :)


Linki:

Cezary Walenciuk - blogpost nr.1

Cezary Walenciuk - blogpost nr.2

Cezary Walenciuk - kod źródłowy

Piotr Rabiniak - kod źródłowy

piątek, 30 sierpnia 2024

npm error LRUCache is not a constructor

When I updated my npm and node versions on my PC for over few years and try to insall/unistall anything on my PC I get error: "npm error LRUCache is not a constructor"

Then I have found this blogpost how to solve the probmem:
https://forums.gentoo.org/viewtopic-t-1170095-start-0.html

In my situation it was go to: C:\Program Files\nodejs\node_modules\npm\node_modules\cacache\lib\memoization.js and remove brackets:

const { LRUCache } = require('lru-cache')

change to:

const LRUCache = require('lru-cache')



Image show messages from console before and after the change:


poniedziałek, 19 sierpnia 2024

Fine Code Coverage

 Bawiąc się moim testowym projektem WinFormsCrud w pewnym momencie postanowiłem sprawdzić sobie jakie mam pokrycie kodu testami jednostkowymi. O ile wiedziałem, że dla samego projektu WinForms będzie zero (bo do tego projektu jeszcze nie dołożyłem testów) o tyle dla pozostałych projektów byłem zainteresowany ile % wyjdzie. 

Samo visual studio 2022 nie ma tego feature w standardzie, o tyle z pomocą przyszedł mi stackoverflow.com który poinformował mi, że dla Visual Studio 2022 Community istnieje darmowy tool pozwalający to sprawdzić, czyli FineCodeCoverage2022 

Sprawdzilem sobie ten tool i on faktycznie działa.

Wiadomo, zawsze mogło być lepiej, natomiast w tym momencie najważniejsze że tool jest darmowy i działa.



poniedziałek, 12 sierpnia 2024

Flurl oraz Flurl.Http

 Do napisania tego postu zainspirowały mnie dwie rzeczy. Pierwszą był post Cezarego Walenciuka na jego blogu odnośnie problemów z klasą HttpClent  https://cezarywalenciuk.pl/blog/programing/ihttpclientfactory-na-problem-z-httpclient 

Cezary omawia tam problem braku zwalniania socketów przez klasę HttpClient. Jako pierwsze rozwiązanie pada "użyj Flur", który opakowuje HttpClienta i dzięki temu działa to dużo bezpieczniej. Później Cezary omawia problem czystego HttpClienta i na koniec podaje rozwiązanie docelowe dla aplikacji .NET CORE MVC  czyli HttpClientFactrory wpiętego w pipeliy (sorry, middleware) ASP MVC CORE. Wszystko pięknie, tyle że ja aktualnie pisałem sobie apkę na zadanie rekrutacyjne i tam było w wymaganiach podane aby to była aplikacja Windows Forms. Chwilę popatrzyłem, nie bardzo wiedziałem jak się wpiąć w pipeliny (middleware) WinFormsów więc użyłem Flur.Http i jestem szczęśliwy. 

Dziękuje Cezary.


Linki:

https://www.nuget.org/packages/Flurl.Http


piątek, 9 sierpnia 2024

FluentAssertions

FluentAssertions to jest paczka NuGet rozszerzająca sposób pisania testów jednostkowych w .NET. W praktyce dostajemy dodatkowe metody rozszerzające służące do testowania. Ja wykorzystywałem to razem z biblioteką xUnit ale nie jestem pewny czy musi to być koniecznie xUnit czy też może być inna biblioteka testów jednostkowych. Paczka FluentAssertions dodaje nam możliwość wykonywania assercji w "płynny" sposób, np. zamiast pisać:

string username = "dennis";
Assert.Equal("jonas", username);

możemy napisać:

string username = "dennis";
username.Should().Be("jonas");

Oczywiście biblioteka ma więcej metod i jest znacznie bardziej płynna i zawiera znacznie więcej sposób rozszerzenia i testowania. 


Polly - paczka NuGet do obsługi RetryPolicy

 Czasami pisząc różne zapytania http, np. zapytania REST potrzebujemy wprowadzić politykę ponowienia zapytania. Serwer mógł dostać czkawkę, mógł się pojawić jakiś problem sieciowy lub deadlock na bazie danych po stronie aplikacji serwerowej. Dlatego dobrze jest mieć jakiś sprawdzony sposób na wykonanie powtórnych zapytań. Jest to szczególnie ważne w kodzie współbierznym.. 

W tym momencie, zgodnie z teorią "not invented here" (nie wynaleziono tutaj) wchodzi paczka nuget o nazwie Polly która jest odpowiedzialna za ogarnięcie polityki ponownego wysyłania zapytania. Można napisać ile razy chcemy wysłać zapytanie (ile porażek akceptujemy), z jaką częstotliwością robić ponowienie, które wyjątki oraz w jaki sposób chcemy je przechwycić.


https://www.nuget.org/packages/polly/