Zrobiłem migrację bloga na https://zchpit.github.io/zchpitblog, a chwilę później na https://zchpitblog.pages.dev/
Docelowo planuję wykupić własną domenę, ale do tego czasu nowe wpisy można oglądać pod adresem: https://zchpit.github.io/zchpitblog/
Edycja: Aktualnie zdecydwałem się wykonać kolejną migrację bloga, tym razem na Claudflare Pages i aktualnie blog dostępny jest pod adresem: https://zchpitblog.pages.dev/
using System.CommandLine;var nameOption = new Option<string>(name: "--name",description: "Nazwa użytkownika",getDefaultValue: () => "World");var rootCommand = new RootCommand("Przykładowa aplikacja CLI");rootCommand.AddOption(nameOption);rootCommand.SetHandler((string name) =>{Console.WriteLine($"Hello, {name}!");}, nameOption);return await rootCommand.InvokeAsync(args);
myapp --name John
# Output: Hello, John!
myapp --help
# Wyświetli automatycznie wygenerowaną pomoc
Axios to jest biblioteka dla Reacta oraz innych frameworków w języku javascript/typescript do wykonywania połączeń HTTP do API w oparciu o asynchroniczny mechanizm Promise udostępniony na licencji MIT.
https://axios-http.com/docs/intro - strona projektu
https://github.com/axios/axios - link do Githuba
Kilka małych tipów dla Visual Studio Code przy programowaniu FE:
- install ESLint
- install Prettier - Code formatter
- go to: File -> Preferences -> Settings -> Format On Save on (in Edditor)
- install ES7+ React/Redux/React-Native snippets
In Google Chrom install "React Developer Tools".
Po wielu, wielu latach pracy na Visual Studio nadszedł ten moment, w którym zdecydowałem się na komercyjną pracę z innym IDE. Wybór padł na JetBrains Rider. Z jednej strony chciałem spróbować coś nowego, a z drugiej jednak sam Rider jest tańszy niż Visual Studio + Resharper.
Ogólnie pracuje się spoko, aczkolwiek pracując na domyślnych ustawieniach zauważyłem, że czasami nie widzę pewnego błędu z user code w runtime. Całe szczęście da się to łatwo włączyć w opcjach. tj. Breakpoints -> CLR Exceptions Breakpoints -> Exception Handler -> User Code.
Obrazek z oficjalnej dokumentacji:
https://www.jetbrains.com/help/rider/Debugging_Exceptions.html#exception-breakpoints
Visual Studio posiada fajny bajer do debuggowania, który nazywa się "Inmediate window" który włączamy przy pomocy opcji Debug -> Windows -> inmediate lub skrótowo Ctrl + Alt + I.
Inmediate windows to dodatkowe okienko, które pozwala nam zmieniać zmienne lub też je podglądać w trakcie zatrzymanego debuga w visual studio. Całkiem przypadny bajer.
Oglądając kurs "Messaging Pragmatycznie" od DevMentors moją uwagę zwróciło narzędzie Jeager czyli myśliwy. Jeager jest narzędziem służącym do polowania na błędy w aplikacji ze szczególnym nastawieniem na aplikacje rozproszone. Jeager niemal z pudełka (wraz z Open Telemetry) działa w przypadku aplikacji synchronicznych jednak swoje prawdziwe możliwości pokazuje w przypadku aplikacji rozproszonych.
Fragment kodu od DevMentors jak to włączyć "z pudełka" dla aplikacji synchronicznych opartych o HttpContext czyli M18L4 -> https://github.com/devmentors/Messaging-Pragmatycznie/blob/M18L4/src/Shared/TicketFlow.Shared/Observability/Extensions.cs
Wytyczne w3.org na których opiera się zastosowany tracing: https://www.w3.org/TR/trace-context/#traceparent-header
Więcej info w dokumentacji lub rozdziale 18 kursu "Messaging Pragmatycznie". Tutaj umieściłem tylko taką krótką notkę dla samego siebie gdybym tego potrzebował na przyszłość.
Chyba każdy zna Dockera oraz jego graficzne UI czyli Docker Desktop. Projekt Docker początkowo był zarządzany przez jeden projekt OpenSource jednak z uwagi na prozę życia, tj. potrzebę samofinansowania pewnego dnia postanowiono rozdzielić silnik Dockerowy czyli Docker CLI oraz nakładkę graficzną czyli Docker Desktop i to UI sprzedać firmie zewnętrznej, która to komercjalizuje. Ten model biznesowy działa. Ostatnimi dniami jednak Docker Destkop postanowił podnieść ceny za swoje usługi, więc w firmie dla której obecnie pracuję postanowiono poszukać darmowych alternatyw. Taką darmową alternatywą wykorzystującą pod spodem darmowe Docker CLI jest Rancher.
Z moich obserwacji działa wolniej i nie aż tak intuicyjnie jak DD (Docker Desktop), ale robi robotę. I tak większość rzeczy robi się z konsoli, a nakładka graficzna jest raczej jako miły dodatek niż coś co jest niezbędne do korzystania z konteneryzacji dostarczanej przez DockerCLI.
Z takich uwag, to nie można mieć równocześnie uruchomionego DD oraz Ranchera. Albo jedno, albo drugie.
Linki:
https://www.rancher.com/ -> oficjalna strona projektu.
https://github.com/rancher/rancher - repozytorium kodu źródłowego na github
Dodatkowe komendy, które mogą być przydatne:
- Ustawienie kontekstu "default" dla Ranchera (Docker Desktop nadpisuje to ustawienie):
docker context ls
docker context use default
- Otwieranie w PowerShell ustawień konfiguracyjnych:
notepad.exe "\\wsl$\rancher-desktop\etc\docker\deamon.json"
A następnie dodać odpowiednie adresy IP do pliku konfiguracyjnego.
Przykładowy wpis:
{
"registry-mirrors": ["http://1.2.3.4:9090", "http:/1.2.3.4:9095"],
"insecure-registries": ["1.2.3.4:9090", "1.2.3.4:9095"],
"debug": true,
"experimental": false
}Ostatnio w firmie w której pracowaliśmy dział bezpieczeństwa na spółkę z działem zakupowym zabronili nam korzystać z Postmana. Było z nim kilka problemów:
Zostaliśmy zmuszeni poszukać alternatywy i ją znaleźliśmy. Tą alternatywą jest Bruno:
Bruno:
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.
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
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
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.
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
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
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
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