Konfigurowanie .NET Aspire na Linuxie

Instalowanie Aspire CLI

[0:48 - 2:20] Tim zaczyna od aspire.dev, zauwazajac, ze projekt niedawno zmienil nazwe z "Aspire.NET" na po prostu "Aspire." Ta zmiana nazwy odzwierciedla rosnacy zakres narzedzia: chociaz Aspire wciaz jest budowane na .NET i glownie sluzy deweloperom .NET, teraz wspiera takze hosty aplikacji TypeScript, a wiecej integracji jezykowych jest w planach.

Sama instalacja to pojedyncze polecenie bash skopiowane z dokumentacji Aspire dla wersji 9.2:

dotnet tool install -g aspirate

dotnet tool install -g aspirate

Po uruchomieniu instalatora, zrestartuj sesje terminala, aby narzedzie zarejestrowalo sie na Twojej sciezce. Bez restartu Twoja powloka nie rozpozna nowego polecenia.

Nastepnie potwiedz, ze instalacja zakonczyla sie poprawnie:

aspire --version

aspire --version

Jesli numer wersji sie wyswietli, CLI jest gotowe. Ten proces w dwoch krokach (instalacja, weryfikacja) to cala konfiguracja po stronie terminala.

Konfigurowanie rozszerzenia VS Code

[2:23 - 3:30] Z zainstalowanym CLI, nastepnym krokiem jest rozszerzenie VS Code. Otworz panel rozszerzen, wyszukaj "Aspire" i zainstaluj oficjalne rozszerzenie opublikowane przez Microsoft. Rozszerzenie dodaje szkicowanie projektow, wsparcie dla konfiguracji uruchomienia i integracje z dashboardem Aspire.

Po zainstalowaniu, VS Code wykonuje krok weryfikacji, aby potwierdzic zgodnosc CLI i rozszerzenia. Tim zauwaza, ze rozszerzenie moze rowniez szkicowac nowy projekt bezposrednio przez palete polecen, chociaz on wybiera podejscie CLI. Ten wybór był celowy: znajomosc CLI oznacza, ze nigdy nie bedzie sie utkwionym, gdy narzedzie GUI dziala niewlasciwie. Gdy wybieranie szablonow VS Code nie moglo wywolywac szablonow Aspire po zainstalowaniu, CLI zapewnilo natychmiastowe wyjscie awaryjne.

Szkicowanie projektu startowego

[3:30 - 6:42] Zamiast uzyc polecenia VS Code "Stworz nowy projekt .NET" (ktore okresowo nie moglo odkryc szablonow Aspire), Tim przechodzi do terminala i uruchamia:

aspire new

aspire new

W interaktywnym podpowiedzi pojawia sie kilka mozliwosci szablonow. Dla aplikacji produkcyjnej normalnie wybralbys pusty host aplikacji C# i budowal odtąd. Dla celow nauki, Tim wybiera Aplikacje startowa, ktora generuje frontend Blazor obsługiwany przez minimalne API. Szablon startowy zawiera punkt koncowy prognozy pogody, strone licznika i wstecznie podlaczone kontrole stanu, dajac ci cos dzialajacego do zbadania od razu.

Nastepne podpowiedzi przeprowadzaja przez pozostala konfiguracje:

Nazwa projektu:         TinyTicket
Sciezka wyjsciowa:     TinyTicket
Uzyc dev localhost:    Tak
Cache Redis:           Nie
Projekt testowy:       Nie
Srodowisko agenta AI: Nie

Tim wszystkie opcjonalne funkcje trzyma wylaczone, aby zminimalizowac zlozonosc. Celem jest chudy punkt startowy, ktory przyszle odcinki beda rozbudowywac stopniowo. Gdy szkicowanie sie zakonczy, otworz folder w VS Code i zaufaj przestrzeni roboczej, gdy zostaniesz o to poproszony.

Zrozumienie struktury projektu

[6:42 - 10:00] Wygenerowane rozwiazanie zawiera cztery projekty, a relacje miedzy nimi odslaniaja, jak dziala Aspire. Projekt hosta aplikacji jest warstwa orkiestracji. Jego Program.cs to mniej wiecej dwanascie linii kodu:

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

Zauwaz, jak frontend deklaruje odniesienie do API i czeka, az stanie sie zdrowe, zanim uruchomi sie. To zamawianie zaleznosci, odkrywanie uslug i sprawdzanie zdrowia to wszystko, co dostarcza Aspire na poziomie kodu. Nie ma zadnej ukrytej magii poza tym, co widzisz w tym pliku.

Obok hosta aplikacji znajduje sie projekt Service Defaults, ktory zawiera metody rozszerzen dla telemetrii, strukturalnego logowania i rejestracji kontroli zdrowia. Te sa wygodami opt-in: jesli jeszcze nie skonfigurowales OpenTelemetry lub punktow koncowych zdrowia w swoich uslugach, domyslne podlaczaja je dla ciebie.

Projekt API Service ma pojedynczy punkt koncowy, ktory zwraca losowo generowane prognozy pogodowe. Projekt Web to aplikacja Blazor, ktora wywoluje API za posrednictwem HttpClient skonfigurowanego tylko z nazwa uslugi ("api"). Aspire rozwiazuje ta nazwe do prawidlowego URL-a w czasie wykonywania, wiec aplikacja Blazor nigdy nie "twardo koduje" numeru portu lub nazwy hosta.

Tim podkresla wazny szczegol wdrozenia: Sam Aspire nie jest wdrazany do produkcji. Orkiestracja jest narzedziem czasu deweloperskiego. W produkcji, URL-e uslug pochodza z konfiguracji (zmienne srodowiskowe, ustawienia aplikacji lub rury wdrozeniowe), a aplikacje dzialaja samodzielnie bez hosta aplikacji.

Uruchamianie i eksplorowanie dashboardu

[10:59 - 14:46] Urucham dysk przez panel Uruchamiania i Debugowania w VS Code, wybierajac profil HTTPS. Po poczatkowym przywroceniu i budowie, dashboard Aspire otwiera sie w przegladarce. Za pierwszym razem, gdy sie laczasz, bedziesz musial wkleic token logowania z wyjscia terminala.

Dashboard wyprowadza cztery kategorie danych dla obslugiwalnosci bez zadnej dodatkowej konfiguracji:

Wyjscie konsoli agreguje stdout z kazdej uslugi w jeden widok. Zamiast przelaczac sie miedzy zakladkami terminala, widzisz cale wyjscie przeplatajace sie i filtrujace wedlug uslugi.

Dzienniki strukturalne pokazuja wpisy dziennikow z ich strukturalnymi wlasnosciami zachowanymi. Ostrzezenie o zaufaniu certyfikatu, z jakim spotyka sie Tim, pojawia sie tutaj z pelnym kontekstem o tym, ktora usluga go wygenerowala i na jakim poziomie powagi.

Slady pokazuja rozproszone lancuchy wywolan. Kiedy frontend Blazor prosi o dane o pogodzie, slad pokazuje wywolanie HTTP GET z frontendu, przejscie do uslugi API (ktore trwalo 7,35 milisekund w filmie) i calkowity czas renderowania strony. Tim podkresla, ze bezwzgledne liczby maja mniejsze znaczenie niz porownania względne: jesli normalnie wywolanie trwa 5 sekund, a nagle trwa 10, odnalazles swoja regresje bez dolaczania profilera.

Metryki zapewniaja liczniki per-usluga dla licznikow zapytan, stop bledow i konsumpcji zasobow. Dashboard równiez odslania zmienne srodowiskowe i dane uwierzytelniajace dla kazdej uslugi, co jest przydatne do weryfikacji, czy wartosci konfiguracyjne przechodza poprawnie.

Wprowadzenie Tiny Ticketu: Projekt Serii

[14:46 - 17:17] Tim nakresla plan projektu, który przejdzie przez reszte serii. Tiny Ticket to uproszczona aplikacja helpdesk: uzytkownicy zglaszaja bilety wsparcia, a system sledzi priorytet i status. Model danych moze byc tak maly, jak pojedyncza tabela SQL. Celem nie jest zbudowanie produktu bogatego w funkcje, ale stworzenie pionowej "plaszczyzny" pokrywajacej kazdy etap cyklu zycia programistycznego na Linuxie: budowanie, testowanie, wdrazanie i laczenie z uslugami zewnetrznymi.

Startowe strony prognozy pogody i licznikow zostana zastapione widokami biletow, ale orkiestracja Aspire, wzorzec API-frontend i domyslne ustawienia uslug pozostana. Przyszle odcinki dodadza Microsoft SQL Server jako baze danych, a Tim zajmie sie czestym zarzutem: programisci, ktorzy nie moga uruchamiac SQL Server lokalnie (na przyklad procesory ARM), czasami wybieraja inna baze danych. Jego odpowiedz to, ze srodowisko rozwojowe powinno replikowac produkcyjne. Jesli produkcyjna baza danych to SQL Server, srodowisko deweloperskie musi sie z tym zgadzac, nawet jesli oznacza to uruchamianie bazy danych w kontenerze.

Podsumowanie: Od zera do dashboardu

[17:17 - 18:20] W niecale dwadziescia minut wideo obejmuje pełna konfiguracje Aspire na Linuxie: instalacje CLI, rozszerzenie VS Code, szkicowanie projektu i dashboard, ktory zapewnia strukturalne logowanie, rozproszone sledzenie i metryki bez zadnej wlasnej konfiguracji. Prawdziwa wartosc Aspire nie lezy w zadnej pojedynczej funkcji, ale w redukcji tarcia: jeden proces do uruchomienia, jeden dashboard do monitorowania i jedno miejsce do zobaczenia, jak uslugi wchodza w interakcje.

Wnioski

[18:20 - 18:53] Konfiguracja Aspire na Linuxie wymaga narzedzia CLI, rozszerzenia VS Code i szkicu projektu. Stamtad dashboard daje widocznosc dla kazdej uslugi bez pisania kodu telemetrii. Plik hosta aplikacji definiuje graf Twoich uslug w tuzinie linijek, a domyslne ustawienia uslug zarzadzaja instalacja, ktora normalnie musialbys skonfigurowac sam recznie.

Projekt Tiny Ticket przedstawiony tutaj posluzy jako fundament dla nadchodzacych odcinkow dotyczacych integracji baz danych, wdrazania na Azure i miedzyplatformowych workflowow. Podazanie za tym punktem startowym oznacza, ze kazdy nowy koncept buduje sie na infrastrukturze, ktorej juz zweryfikowales.

Nawigacja Serii: Ten artykul jest czescia serii C# na Linuxie budujacej aplikacje Tiny Ticket. Poprzednie: SQL Server w Docker na Linuxie. Next: Adding Swagger UI to .NET Aspire on Linux.

Przyklad wskazowki: Gdy wybierak szablonow w VS Code nie wykrywa szablonow Aspire po zainstalowaniu rozszerzenia, uzyj aspire new z terminala jako niezawodnego zastepnika, a nastepnie uruchom ponownie VS Code, aby zsynchronizowac stan rozszerzenia.

Ogladaj cale wideo na jego YouTube kanale, aby zyskac wiecej informacji na temat konfigurowania .NET Aspire dla rozwoju na Linuxie.