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