Cloud-Native | The .NET Blog

Hooki azd w Python, TypeScript i .NET: koniec ze skryptami shell

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Ten artykuł został przetłumaczony automatycznie. Aby zobaczyć oryginalną wersję, kliknij tutaj.

Jeśli kiedykolwiek miałeś projekt w całości napisany w .NET i mimo to musiałeś pisać skrypty Bash dla hooków azd — znasz ten ból. Po co przełączać się na składnię shell w kroku pre-provisioning, skoro reszta projektu to C#?

Ta frustracja ma teraz oficjalne rozwiązanie. Azure Developer CLI właśnie wprowadził obsługę wielu języków dla hooków, i jest dokładnie tak dobre, jak brzmi.

Czym są hooki

Hooki to skrypty wykonywane w kluczowych punktach cyklu życia azd — przed provisioningiem, po deploymencie i nie tylko. Definiuje się je w azure.yaml i pozwalają na wstrzyknięcie własnej logiki bez modyfikowania CLI.

Wcześniej obsługiwane były tylko Bash i PowerShell. Teraz można używać Pythona, JavaScript, TypeScript lub .NET — resztą zajmuje się azd automatycznie.

Jak działa wykrywanie

Wystarczy wskazać hook na plik, a azd wywnioskuje język z rozszerzenia:

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Bez dodatkowej konfiguracji. Jeśli rozszerzenie jest niejednoznaczne, można jawnie podać kind: python (lub odpowiedni język).

Ważne szczegóły według języka

Python

Umieść requirements.txt lub pyproject.toml obok skryptu (lub w dowolnym katalogu nadrzędnym). azd automatycznie tworzy środowisko wirtualne, instaluje zależności i uruchamia skrypt.

JavaScript i TypeScript

Ten sam wzorzec — package.json blisko skryptu, a azd najpierw wykona npm install. Dla TypeScript używa npx tsx bez etapu kompilacji i bez tsconfig.json.

.NET

Dwa dostępne tryby:

Tryb projektu: jeśli obok skryptu jest .csproj, azd automatycznie uruchamia dotnet restore i dotnet build.
Tryb single-file: na .NET 10+ samodzielne pliki .cs uruchamiają się bezpośrednio przez dotnet run script.cs. Plik projektu nie jest wymagany.

Konfiguracja dla konkretnego executora

Każdy język obsługuje opcjonalny blok config:

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Dlaczego to ważne dla programistów .NET

Hooki były ostatnim miejscem w projekcie opartym na azd, które wymuszało zmianę języka. Teraz cały pipeline deploymentu — od kodu aplikacji po hooki cyklu życia — może żyć w jednym języku. Można ponownie wykorzystywać istniejące narzędzia .NET w hookach, referencować współdzielone biblioteki i porzucić utrzymywanie skryptów shell.

Podsumowanie

Jedna z tych zmian, które wydają się drobne, ale naprawdę redukują codzienne tarcia w pracy z azd. Obsługa wielu języków dla hooków jest dostępna teraz — pełna dokumentacja w oficjalnym poście.

Aspire 13.2 Dostaje MongoDB EF Core i Azure Data Lake — Dwie Integracje Warte Wypróbowania

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Ten post został automatycznie przetłumaczony. Aby przejść do oryginału, kliknij tutaj.

Aspire 13.2 właśnie wylądował z dwiema nowymi integracjami bazodanowymi, które są warte uwagi: MongoDB Entity Framework Core i Azure Data Lake Storage.

MongoDB spotyka EF Core w Aspire

To ta, z której jestem najbardziej podekscytowany. Aspire obsługiwał MongoDB przez chwilę, ale zawsze był to surowy sterownik — bez EF Core, bez DbContext, bez zapytań LINQ. Teraz otrzymujesz pełne doświadczenie EF Core z MongoDB, wraz z automatycznymi health checks i service discovery Aspire.

Konfiguracja w AppHost:

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

W projekcie klienckim:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Zarejestruj DbContext:

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

Integracja obsługuje connection pooling, ślady OpenTelemetry i health checks za kulisami.

Azure Data Lake Storage dołącza do zabawy

W AppHost:

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

W projekcie klienckim:

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Żadnego ręcznego zarządzania ciągami połączeń, żadnego polowania na poświadczenia.

Podsumowanie

Aspire 13.2 to wydanie przyrostowe, ale integracje MongoDB EF Core i Data Lake wypełniają rzeczywiste luki. Zaktualizuj do 13.2 i wypróbuj je.

Azure Smart Tier jest GA — Automatyczna Optymalizacja Kosztów Blob Storage Bez Reguł Cyklu Życia

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Ten post został automatycznie przetłumaczony. Aby przejść do oryginału, kliknij tutaj.

Jeśli kiedykolwiek spędziłeś czas na dostosowywaniu polityk cyklu życia Azure Blob Storage i obserwowałeś ich rozpadanie się, gdy wzorce dostępu się zmieniły, to jest coś dla Ciebie. Microsoft właśnie ogłosił ogólną dostępność inteligentnej warstwy dla Azure Blob i Data Lake Storage.

Co inteligentna warstwa faktycznie robi

Inteligentna warstwa ciągle ocenia czas ostatniego dostępu do każdego obiektu. Często dostępne dane pozostają w hot, nieaktywne dane przechodzą do cool po 30 dniach, następnie do cold po kolejnych 60 dniach. Gdy dane są ponownie dostępne, są natychmiast promowane z powrotem do hot.

Podczas podglądu Microsoft poinformował, że ponad 50% pojemności zarządzanej przez inteligentną warstwę automatycznie przesunęło się do chłodniejszych warstw.

Dlaczego to ważne dla deweloperów .NET

Scenariusze praktyczne:

Telemetria i logi aplikacji — gorące podczas debugowania, rzadko dostępne po kilku tygodniach
Pipeline’y danych i wyniki ETL — intensywnie dostępne podczas przetwarzania, potem głównie zimne
Treści generowane przez użytkowników — nowe przesłania są gorące, starsze treści stopniowo się schładzają

Konfiguracja

Nowe konta: Wybierz inteligentną warstwę jako domyślną warstwę dostępu podczas tworzenia konta
Istniejące konta: Zmień domyślną warstwę dostępu do blobów na inteligentną

Obiekty mniejsze niż 128 KiB pozostają w hot i nie ponoszą opłaty monitoringowej.

Gdzie Hostować Agenty AI na Azure? Praktyczny Przewodnik po Decyzjach

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Ten post został automatycznie przetłumaczony. Aby przejść do oryginału, kliknij tutaj.

Jeśli teraz budujesz agenty AI z .NET, pewnie zauważyłeś: jest wiele sposobów na hostowanie ich na Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents.

Microsoft opublikował kompleksowy przewodnik po hostowaniu agentów Azure AI.

Sześć opcji na pierwszy rzut oka

Opcja	Najlepsza dla	Zarządzasz
Container Apps	Pełna kontrola kontenera bez K8s	Obserwowalność, stan, cykl życia
AKS	Enterprise compliance, multi-cluster	Wszystkim
Azure Functions	Sterowane zdarzeniami, krótkotrwałe zadania	Prawie niczym
App Service	Prosty agent HTTP	Wdrożeniem, skalowaniem
Foundry Agents	Agenty bez kodu	Prawie niczym
Foundry Hosted Agents	Agenty z własnym frameworkiem	Tylko kodem agenta

Foundry Hosted Agents — słodkie miejsce dla deweloperów agentów .NET

Wdrożenie jest naprawdę proste:

azd ext install azure.ai.agents
azd ai agent init
azd up

To pojedyncze azd up buduje kontener, wypycha go do ACR, provisionuje projekt Foundry i uruchamia agenta.

Mój framework decyzyjny

Potrzebujesz zero infrastruktury? → Foundry Agents
Masz własny kod agenta ale chcesz zarządzanego hostingu? → Foundry Hosted Agents
Sterowane zdarzeniami, krótkotrwałe zadania? → Azure Functions
Maksymalna kontrola kontenera? → Container Apps
Ścisła zgodność i multi-cluster? → AKS

Podsumowanie

Dla większości deweloperów .NET budujących z Semantic Kernel lub Microsoft Agent Framework, Hosted Agents to prawdopodobnie właściwy punkt startowy. Sprawdź pełny przewodnik Microsoftu.

KubeCon Europe 2026: Na Czym Powinni Naprawdę Zależeć Deweloperom .NET

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

Ten post został automatycznie przetłumaczony. Aby przejść do oryginału, kliknij tutaj.

Znasz to uczucie, gdy spada ogromny post z ogłoszeniami i przewijasz go myśląc “fajne, ale co to dla mnie znaczy”?

Microsoft właśnie opublikował swoje pełne podsumowanie KubeCon Europe 2026.

mTLS bez podatku service mesh

Azure Kubernetes Application Network daje ci wzajemne TLS, autoryzację świadomą aplikacji i telemetrię ruchu — bez wdrażania pełnej siatki z sidecarami. Twoje API ASP.NET Core rozmawiające z robotnikami w tle — wszystko zaszyfrowane na poziomie sieci, bez żadnych zmian kodu aplikacji.

Obserwowalność GPU

AKS teraz ujawnia metryki GPU natywnie do zarządzanego Prometheus i Grafana. Bez niestandardowych eksporterów.

Wieloklasterowa sieć

Azure Kubernetes Fleet Manager dostarcza teraz sieciowanie między klastrami przez zarządzaną siatkę Cilium — unified connectivity, globalny rejestr usług.

Bezpieczniejsze ulepszenia

Ulepszenia niebiesko-zielone tworzą równoległy pool węzłów. Wycofanie puli agentów pozwala ci cofnąć się do poprzedniej wersji.

Gdzie zacząć

Obserwowalność najpierw — włącz metryki GPU i logi przepływu sieci
Wypróbuj ulepszenia niebiesko-zielone — przetestuj przepływ pracy wycofywania
Pilot sieci świadomej tożsamości — włącz mTLS dla jednej ścieżki usługi