Cloud-Native | The .NET Blog

Hooks azd dengan Python, TypeScript, dan .NET: Selamat Tinggal Shell Script

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

Postingan ini diterjemahkan secara otomatis. Untuk versi aslinya, klik di sini.

Jika pernah memiliki proyek yang sepenuhnya ditulis dalam .NET namun tetap harus menulis script Bash untuk hooks azd, rasa frustrasi itu sudah pasti familiar. Mengapa harus beralih ke sintaks shell di langkah pre-provisioning ketika seluruh proyek menggunakan C#?

Masalah ini kini memiliki solusi resmi. Azure Developer CLI baru saja meluncurkan dukungan multi-bahasa untuk hooks, dan hasilnya sesuai ekspektasi.

Apa itu hooks

Hooks adalah script yang berjalan di titik-titik penting dalam siklus hidup azd — sebelum provisioning, setelah deployment, dan lainnya. Didefinisikan di azure.yaml, mereka memungkinkan injeksi logika kustom tanpa memodifikasi CLI.

Sebelumnya hanya Bash dan PowerShell yang didukung. Kini bisa menggunakan Python, JavaScript, TypeScript, atau .NET — dan azd menangani sisanya secara otomatis.

Cara kerja deteksi bahasa

Cukup arahkan hook ke sebuah file dan azd akan menyimpulkan bahasa dari ekstensinya:

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

Tanpa konfigurasi tambahan. Jika ekstensinya ambigu, bisa menambahkan kind: python (atau bahasa yang sesuai) secara eksplisit.

Detail penting per bahasa

Python

Letakkan requirements.txt atau pyproject.toml di samping script (atau direktori induknya). azd akan otomatis membuat virtual environment, menginstal dependensi, dan menjalankan script.

JavaScript dan TypeScript

Pola yang sama — letakkan package.json dekat script dan azd akan menjalankan npm install terlebih dahulu. Untuk TypeScript, menggunakan npx tsx tanpa langkah kompilasi dan tanpa tsconfig.json.

.NET

Dua mode tersedia:

Mode project: Jika ada .csproj di samping script, azd otomatis menjalankan dotnet restore dan dotnet build.
Mode single-file: Di .NET 10+, file .cs mandiri dapat dijalankan langsung via dotnet run script.cs. Tidak perlu file project.

Konfigurasi per executor

Setiap bahasa mendukung blok config opsional:

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

Mengapa ini penting bagi developer .NET

Hooks adalah tempat terakhir dalam proyek berbasis azd yang memaksa pergantian bahasa. Sekarang seluruh deployment pipeline — dari kode aplikasi hingga lifecycle hooks — bisa hidup dalam satu bahasa. Utility .NET yang sudah ada bisa digunakan kembali di hooks, shared library bisa direferensikan, dan pemeliharaan shell script pun berakhir.

Penutup

Salah satu perubahan yang terlihat kecil namun benar-benar mengurangi gesekan dalam workflow azd sehari-hari. Dukungan multi-bahasa untuk hooks sudah tersedia sekarang — cek post resmi untuk dokumentasi lengkap.

Aspire 13.2 Mendapatkan MongoDB EF Core dan Azure Data Lake — Dua Integrasi yang Patut Dicoba

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

Postingan ini diterjemahkan secara otomatis. Untuk versi aslinya, klik di sini.

Aspire 13.2 hadir dengan dua integrasi database baru yang patut diperhatikan: MongoDB Entity Framework Core dan Azure Data Lake Storage.

MongoDB bertemu EF Core di Aspire

Aspire telah mendukung MongoDB untuk sementara, tapi selalu driver mentah — tidak ada EF Core, tidak ada DbContext, tidak ada kueri LINQ. Sekarang Anda mendapatkan pengalaman EF Core penuh dengan MongoDB, beserta health check otomatis dan service discovery dari Aspire.

Pengaturan di AppHost:

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

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

Di proyek yang menggunakan:

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Daftarkan DbContext Anda:

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

Integrasi menangani connection pooling, trace OpenTelemetry, dan health check di belakang layar.

Azure Data Lake Storage bergabung

Di 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);

Di proyek yang menggunakan:

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

Tidak ada manajemen connection string manual, tidak ada pencarian kredensial.

Kesimpulan

Aspire 13.2 adalah rilis inkremental, tapi integrasi MongoDB EF Core dan Data Lake mengisi celah nyata. Upgrade ke 13.2 dan coba.

Azure Smart Tier Kini GA — Optimasi Biaya Blob Storage Otomatis Tanpa Aturan Siklus Hidup

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

Postingan ini diterjemahkan secara otomatis. Untuk versi aslinya, klik di sini.

Jika Anda pernah menghabiskan waktu menyetel kebijakan siklus hidup Azure Blob Storage dan kemudian menyaksikannya runtuh ketika pola akses berubah, ini untuk Anda. Microsoft baru saja mengumumkan ketersediaan umum smart tier untuk Azure Blob dan Data Lake Storage.

Yang sebenarnya dilakukan smart tier

Smart tier terus mengevaluasi waktu akses terakhir setiap objek di akun penyimpanan Anda. Data yang sering diakses tetap di hot, data tidak aktif pindah ke cool setelah 30 hari, lalu ke cold setelah 60 hari lagi. Saat data diakses lagi, langsung dipromosikan kembali ke hot.

Tidak ada aturan siklus hidup yang perlu dikonfigurasi. Tidak ada penyesuaian manual.

Selama pratinjau, Microsoft melaporkan bahwa lebih dari 50% kapasitas yang dikelola smart tier secara otomatis berpindah ke tingkat lebih dingin.

Mengapa ini penting untuk developer .NET

Skenario praktis:

Telemetri dan log aplikasi — panas saat debugging, jarang diakses setelah beberapa minggu
Pipeline data dan output ETL — akses intensif saat pemrosesan, lalu sebagian besar dingin
Konten yang dibuat pengguna — unggahan terbaru panas, konten lama mendingin secara bertahap

Pertukaran yang perlu diketahui

Aturan peringkatan smart tier bersifat statis (30 hari → cool, 90 hari → cold). Jika Anda membutuhkan ambang batas kustom, aturan siklus hidup masih berlaku.

Di Mana Anda Harus Meng-host Agen AI di Azure? Panduan Keputusan Praktis

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

Postingan ini diterjemahkan secara otomatis. Untuk versi aslinya, klik di sini.

Jika Anda sedang membangun agen AI dengan .NET sekarang, Anda mungkin sudah memperhatikan: ada banyak cara untuk meng-host-nya di Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents.

Microsoft baru saja menerbitkan panduan komprehensif untuk hosting agen Azure AI.

Enam opsi sekilas

Opsi	Terbaik untuk	Anda kelola
Container Apps	Kontrol container penuh tanpa kerumitan K8s	Observabilitas, state, siklus hidup
AKS	Kepatuhan enterprise, multi-cluster	Semuanya
Azure Functions	Tugas singkat berbasis event	Hampir tidak ada
App Service	Agen HTTP sederhana	Deployment, scaling
Foundry Agents	Agen opsional kode	Hampir tidak ada
Foundry Hosted Agents	Agen framework kustom	Hanya kode agen Anda

Foundry Hosted Agents — titik manis untuk developer agen .NET

Deployment benar-benar sederhana:

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

Satu perintah azd up membangun container, mendorongnya ke ACR, menyediakan proyek Foundry, dan memulai agen.

Kerangka keputusan saya

Butuh infrastruktur nol? → Foundry Agents
Punya kode agen kustom tapi ingin hosting terkelola? → Foundry Hosted Agents
Tugas singkat berbasis event? → Azure Functions
Kontrol container maksimum? → Container Apps
Kepatuhan ketat dan multi-cluster? → AKS

Kesimpulan

Untuk sebagian besar developer .NET yang membangun dengan Semantic Kernel atau Microsoft Agent Framework, Hosted Agents kemungkinan adalah titik awal yang tepat. Cek panduan lengkap dari Microsoft.

KubeCon Europe 2026: Yang Sebenarnya Perlu Diperhatikan Pengembang .NET

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

Postingan ini diterjemahkan secara otomatis. Untuk versi aslinya, klik di sini.

Microsoft baru saja menerbitkan rekap lengkap KubeCon Europe 2026 mereka.

mTLS tanpa pajak service mesh

Azure Kubernetes Application Network memberi Anda mutual TLS, otorisasi berbasis aplikasi, dan telemetri traffic — tanpa menerapkan mesh sidecar berat. API ASP.NET Core yang berkomunikasi dengan background worker — semua terenkripsi di tingkat jaringan, tanpa perubahan kode aplikasi.

Observabilitas GPU

AKS kini menampilkan metrik GPU secara native ke Prometheus dan Grafana terkelola. Tanpa exporter kustom.

Jaringan lintas kluster

Azure Kubernetes Fleet Manager kini mengirimkan jaringan lintas kluster — konektivitas terpadu, registri layanan global.

Upgrade yang lebih aman

Upgrade agent pool biru-hijau membuat node pool paralel. Rollback agent pool memungkinkan Anda kembali ke versi sebelumnya.

Dari mana memulai

Observabilitas dulu — aktifkan metrik GPU dan log aliran jaringan
Coba upgrade biru-hijau — uji alur kerja rollback
Pilot jaringan berbasis identitas — aktifkan mTLS untuk satu jalur layanan