Aspire: AppHost, service discovery i dashboard

Aspire porządkuje sposób opisywania, uruchamiania i obserwowania aplikacji rozproszonej, ale nie jest produkcyjnym runtime’em ani dostawcą chmury. AppHost zapisuje topologię usług i zależności w kodzie, service discovery usuwa adresy wpisane na stałe, a dashboard zbiera stan zasobów oraz telemetrię OpenTelemetry. Największa wartość pojawia się wtedy, gdy zespół traktuje model aplikacji jako wspólny kontrakt dla lokalnego developmentu i publikacji. Samo dodanie Aspire nie zapewnia skalowania, odporności, bezpieczeństwa ani poprawnej architektury.

Aspire jako model systemu rozproszonego

Oficjalna dokumentacja definiuje Aspire jako warstwę orkiestracji i obserwowalności opartą na kodzie. W AppHost można opisać projekty, kontenery, procesy wykonywalne, bazy, kolejki, cache i usługi chmurowe. Relacje mówią, które zasoby się znają, w jakiej kolejności mają się uruchamiać i jaka konfiguracja ma zostać przekazana.

To nie wymaga, aby każda usługa była napisana w .NET. AppHost może być tworzony w C# lub TypeScript, a model obejmować workloady w wielu językach. Dla zespołu platformowego oznacza to możliwość ujednolicenia doświadczenia programisty bez przepisywania aplikacji. Integracja konkretnego zasobu musi jednak rzeczywiście wspierać sposób, w jaki organizacja go uruchamia.

Element	Odpowiedzialność	Nie należy od niego oczekiwać
AppHost	Deklaruje zasoby, relacje, konfigurację i model publikacji	Obsługi ruchu produkcyjnego jako runtime
Integracja Aspire	Modeluje konkretną bazę, kolejkę lub usługę	Automatycznej optymalizacji kosztów i konfiguracji
Service discovery	Rozwiązuje logiczne nazwy na endpointy	Autoryzacji wywołań między usługami
Dashboard	Pokazuje zasoby, logi, trace’y i metryki	Pełnej platformy monitoringu produkcji bez konfiguracji
Publisher	Zamienia model na artefakty dla celu	Uniwersalnej zgodności wszystkich celów wdrożenia
Service Defaults	Ujednolica typową telemetrię i health checks	Zastąpienia decyzji SRE i polityk bezpieczeństwa

AppHost jest wykonywalnym opisem topologii

AppHost to aplikacja, która buduje model zasobów. Dodanie projektu tworzy zasób aplikacyjny, dodanie kontenera opisuje obraz i endpointy, a WithReference() ustanawia relację oraz przekazuje potrzebną konfigurację. WaitFor() może wyrazić zależność startową od gotowości innego zasobu. Nazwy zasobów powinny być stabilne, bo stają się częścią konfiguracji i diagnostyki.

Przykład syntetyczny obejmuje frontend portal, API orders, PostgreSQL orders-db i cache redis. AppHost deklaruje wszystkie cztery zasoby. API dostaje referencje do bazy i cache, a frontend do API. Programista uruchamia aspire run i otrzymuje wspólną topologię zamiast czterech ręcznie utrzymywanych poleceń oraz portów.

AppHost nie powinien zawierać logiki biznesowej. Jest miejscem kompozycji i reguł środowiska, takich jak endpointy, zależności oraz parametry. Sekrety pozostają w przeznaczonym do tego magazynie lub mechanizmie celu wdrożenia. Nie należy wpisywać kluczy do kodu AppHost ani przekazywać ich jako zwykłych wartości wersjonowanych w repozytorium.

Modeluj różnicę między zależnością a kolejnością startu. Referencja mówi, że zasób potrzebuje konfiguracji drugiego zasobu. Nie zawsze oznacza, że musi czekać na jego pełną gotowość. WaitFor() stosuj tam, gdzie start bez zależności rzeczywiście kończy się błędem albo generuje mylący szum. Usługa produkcyjna i tak powinna poprawnie reagować na czasową niedostępność, bo kolejność uruchomienia nie gwarantuje trwałej dostępności.

Duży AppHost warto podzielić na rozszerzenia opisujące domeny lub grupy zasobów. Zachowaj jednak czytelny punkt kompozycji, w którym widać najważniejsze relacje. Abstrakcja ukrywająca dziesiątki zasobów pod jedną metodą może przyspieszyć tworzenie, ale utrudnić przegląd topologii i skutków zmiany. Nazewnictwo, tagi oraz konwencje endpointów powinny być wspólne dla repozytoriów.

Przegląd architektury Aspire rozróżnia run mode od publish mode. W trybie lokalnym AppHost przekłada model na zasoby uruchamiane przez developer control plane. W trybie publikacji generuje lub przekazuje model do narzędzia tworzącego artefakty dla docelowego środowiska. To rozróżnienie zapobiega błędnemu założeniu, że proces AppHost powinien działać jako produkcyjny orkiestrator.

Service discovery usuwa przypadkowe adresy

Usługi powinny odwoływać się do nazw logicznych zamiast do localhost i ręcznie dobranych portów. Gdy zasób otrzymuje WithReference(), Aspire przekazuje informacje o endpointach przez konfigurację. Resolver zamienia logiczną nazwę na rzeczywisty adres dla danego środowiska. Szczegóły opisuje dokumentacja service discovery.

Mechanizm działa wyłącznie dla zadeklarowanych relacji. Jest to zaleta: zależności stają się widoczne w modelu. Jeśli usługa ma trzy niejawne połączenia zapisane w zmiennych środowiskowych poza AppHost, model nie jest kompletny. Warto podczas migracji porównać topologię Aspire z rzeczywistymi wywołaniami i connection strings.

Service discovery nie szyfruje automatycznie ruchu, nie nadaje tożsamości workloadom i nie decyduje, czy wywołanie jest dozwolone. TLS, uwierzytelnianie między usługami, polityki sieciowe i rotacja poświadczeń pozostają osobnymi obowiązkami platformy. Nie zakładaj również, że zachowanie lokalnego resolvera dokładnie odtwarza każdy mechanizm DNS lub service mesh w produkcji. Test integracyjny musi działać w środowisku zbliżonym do celu.

W aplikacji korzystaj z fabryk klientów i logicznych nazw zamiast budować adres w kodzie. Dzięki temu polityki HTTP, propagacja trace oraz konfiguracja mogą być spójne. Zwróć uwagę na protokół i obsługę wielu endpointów. Jeśli lokalnie dostępne są HTTP i HTTPS, reguła wyboru musi odpowiadać temu, co zapewnia środowisko docelowe. Błędna preferencja potrafi ujawnić się dopiero po publikacji.

Dashboard pokazuje przebieg żądania, jeśli aplikacja wysyła telemetrię

Aspire dashboard jest lokalnym widokiem danych OpenTelemetry. Pokazuje logi strukturalne, trace’y rozproszone i metryki. Połączony z AppHost dodaje stan zasobów, health checks, output konsoli, konfigurację oraz akcje startu i restartu. Pozwala przejść od błędu frontendu przez API do zapytania zależności, jeśli kontekst trace jest propagowany.

Dashboard nie tworzy brakującej instrumentacji. Aplikacje muszą mieć skonfigurowane źródła telemetryczne i exporter. Własne operacje biznesowe warto opisać spanami oraz atrybutami, które nie ujawniają danych wrażliwych. Log tekstowy bez identyfikatora korelacji nadal będzie trudny do połączenia z trace’em.

Sygnał	Pytanie diagnostyczne	Przykład kontroli
Stan zasobu	Czy proces lub kontener działa?	Restart i obserwacja zależności
Health check	Czy usługa jest gotowa przyjąć ruch?	Opóźniony start bazy lub kolejki
Trace	Gdzie żądanie spędziło czas?	Przejście portal → API → baza
Log strukturalny	Dlaczego operacja zakończyła się błędem?	Filtrowanie po trace ID i typie błędu
Metryka	Czy problem jest trendem?	Percentyl czasu i liczba błędów
Konfiguracja	Jaki endpoint dostał zasób?	Porównanie modelu z procesem

Widok lokalny jest świetny do pracy deweloperskiej, ale retencja, alerty, dostęp, koszty i wysoka dostępność telemetrii produkcyjnej wymagają docelowego backendu obserwowalności. Dashboard może działać samodzielnie jako odbiornik OpenTelemetry, lecz nie zmienia się przez to w kompletną usługę operacyjną.

Integracje i Service Defaults ograniczają powtarzalną konfigurację

Integracje Aspire opisują sposób dodania i połączenia zasobu. Często oferują dwa elementy: model hostingu w AppHost i bibliotekę kliencką używaną przez aplikację. Zespół powinien sprawdzić dokumentację pakietu, obsługiwane wersje oraz konsekwencje publikacji. Integracja wygodna lokalnie może mapować się na inny typ zasobu w konkretnym publisherze.

Projekt Service Defaults służy do współdzielenia typowej konfiguracji usług, na przykład OpenTelemetry, health checks, service discovery i odporności klienta HTTP. To dobry punkt startowy, ale nazwa „defaults” jest trafna: organizacja musi dopasować retry, timeouty, sampling oraz endpointy zdrowia do własnego ruchu. Nierozważne ponowienia operacji zapisującej mogą utworzyć duplikaty.

Wprowadź centralne ustawienia małymi krokami. Najpierw telemetria i health checks, potem klient HTTP oraz polityki odporności. Każdy element zweryfikuj w scenariuszu awarii. W przeciwnym razie wspólny pakiet może rozprzestrzenić błędną konfigurację na wszystkie usługi szybciej niż ręczne ustawienia.

Traktuj Service Defaults jak produkt wewnętrzny. Wersjonuj go, dokumentuj zmianę zachowania i wyznacz właściciela. Aktualizacja globalnego timeoutu może mieć inny skutek dla interaktywnego API i zadania wsadowego. Zamiast jednej agresywnej polityki udostępnij bezpieczne profile, które usługa wybiera jawnie. Krytyczne odstępstwo powinno być widoczne w przeglądzie kodu i telemetrii.

Publikacja nie oznacza identyczności środowisk

Aspire pozwala użyć modelu aplikacji do przygotowania wdrożenia, ale target decyduje o sposobie mapowania zasobów. Artefakty mogą przyjąć postać manifestów Kubernetes, konfiguracji infrastruktury lub formatu właściwego dla platformy. Publisher ma własny zakres możliwości. Przed wyborem sprawdź, jak mapuje sekrety, sieć, wolumeny, autoscaling, tożsamości i zasoby zarządzane.

Nie wszystkie elementy lokalne powinny trafić do produkcji. Lokalny kontener bazy może odpowiadać zarządzanej bazie w chmurze. Emulator może nie zachowywać się identycznie pod obciążeniem. Z kolei zasób zewnętrzny może być jedynie referencją, której Aspire nie tworzy. Model aplikacji jest wspólnym źródłem intencji, a nie obietnicą bitowej zgodności.

Utwórz macierz mapowania: zasób AppHost, odpowiednik lokalny, odpowiednik testowy, produkcyjna usługa i właściciel. Dodaj sposób dostarczania poświadczeń, regułę sieciową, kopię zapasową i oczekiwany model kosztu. Taka macierz szybko ujawnia elementy, których publisher nie obsługuje lub które wymagają osobnego modułu infrastruktury.

Przeglądaj wygenerowane artefakty tak samo jak ręcznie napisaną infrastrukturę. Automatyczne pochodzenie nie gwarantuje poprawnych limitów, klas pamięci, reguł ekspozycji ani lokalizacji danych. W pipeline rozdziel wygenerowanie, walidację polityk, podgląd zmiany oraz zastosowanie. Zachowaj możliwość powiązania wdrożenia z wersją AppHost i publishera.

Potrzebujesz nadal pipeline’u, kontroli zmian infrastruktury, skanowania obrazów, polityk, planu migracji danych i rollbacku. Aspire może dostarczyć artefakty do tych procesów. Nie usuwa odpowiedzialności zespołu platformowego za ich zatwierdzenie i wykonanie.

Granice bezpieczeństwa i niezawodności

Dashboard może ujawniać konfigurację i dane diagnostyczne, dlatego dostęp powinien być chroniony. Wbudowane logowanie tokenem pomaga lokalnie, ale publikacja dashboardu wymaga świadomej konfiguracji uwierzytelniania, sieci i TLS. Nigdy nie traktuj przypadkowego, trudnego do odgadnięcia URL jako kontroli dostępu.

Health check musi mierzyć właściwą rzecz. Liveness odpowiada, czy proces należy restartować, a readiness, czy może otrzymać ruch. Sprawdzanie każdej odległej zależności w liveness może wywołać kaskadę restartów. Z kolei sam status procesu nie pokaże, że usługa nie potrafi obsłużyć żądania.

Odporność wymaga limitów czasu, kontrolowanych retry, circuit breakerów, idempotencji oraz zachowania przy częściowej awarii. Aspire pomaga obserwować i konfigurować elementy, lecz nie wybierze poprawnej semantyki. Te decyzje wynikają z procesu biznesowego i charakteru danych.

Zaplanuj również zasoby lokalnej stacji. Uruchomienie wielu kontenerów, emulatorów i usług może przekroczyć dostępną pamięć. AppHost powinien wspierać profile albo możliwość podłączenia współdzielonych zależności, jeśli pełna topologia jest zbyt ciężka. Profil uproszczony nie może jednak ukrywać ścieżki krytycznej, którą zespół potem odkryje dopiero w środowisku testowym.

Pilotaż istniejącej aplikacji

Wybierz system z dwiema lub trzema usługami i jedną zależnością infrastrukturalną. Zapisz bieżący sposób uruchamiania, porty, zmienne oraz znane problemy. Następnie dodaj AppHost, nazwij zasoby, zadeklaruj referencje i uruchom całość przez aspire run. Oficjalny przegląd Aspire CLI opisuje, jak polecenie znajduje AppHost, buduje zasoby i uruchamia dashboard.

Przeprowadź pięć prób: czysty start na nowej stacji, opóźniony start bazy, awarię jednej usługi, śledzenie pełnego żądania i wygenerowanie artefaktów dla celu. Zmierz liczbę ręcznych kroków, czas diagnozy i różnice względem produkcji. Jeśli zespół nie potrafi wyjaśnić mapowania zasobu lokalnego na docelowy, publikacja nie jest jeszcze gotowa.

Po pilotażu ustal właściciela AppHost, wersjonowanie integracji, zasady dodawania zasobów i minimalny zestaw telemetrii. Włącz model do systemu pracy i odpowiedzialności, aby nie stał się kolejnym nieutrzymywanym plikiem. Jeżeli frontend jest budowany w .NET i ma korzystać z funkcji AI, następnym krokiem może być Blazor dla inteligentnych aplikacji webowych, już uruchamiany oraz obserwowany jako część tej samej topologii.