2026'da .NET'i Dockerfile olmadan konteynerleştirmek

Benjamin Abt, .NET SDK'nın PublishContainer hedefiyle ASP.NET Core servislerinden Dockerfile yazmadan OCI imajı üretebildiğini ve bu imajı registry'ye, arşive ya da yerel çalışma zamanına verebildiğini anlatıyor. Yazı, hangi durumda SDK yayımlamasının, hangi durumda Dockerfile'ın tercih edilmesi gerektiğine dair pratik bir kural sunuyor.

Kilit noktalar

• /t:PublishContainer hedefiyle SDK, TFM, RID ve AOT ayarlarına göre base image'ı otomatik seçer.
• ContainerImageTag ile ContainerImageTags birlikte verilirse SDK CONTAINER2008 hatasıyla derlemeyi reddeder.
• Dağıtımı tag yerine çözümlenmiş sha256 digest'i üzerinden yapın; tag'ler değişebilir.
• Arşiv çıktısı Docker daemon gerektirmez; çoklu mimari derleme SDK 8.0.405 ve 9.0.102 ile gelir.
• ContainerEnvironmentVariable değerleri imaj metadatasında görünür; gizli bilgileri oraya koymayın.
• Non-root varsayılanı APP_UID üzerinden gelir; ContainerUser ile root'a çevirmek yazma hatalarını gizler.

.NET SDK, ASP.NET Core API'leri ve worker servisleri için OCI imajı üretebiliyor; bu imajı bir registry'ye gönderebilir, arşiv dosyası olarak yazabilir ya da yerel bir çalışma zamanına yükleyebilir. Yazar, sıradan servislerde elle yazılan Dockerfile yerine SDK yayımlamasının yeterli olduğunu, ortak işletim sistemi gereksinimlerinin merkezi bir base image'da tutulmasını ve Dockerfile'ın yalnızca shell adımları, native derleme veya birden fazla araç gerektiren durumlarda kalmasını savunuyor.

Yazıda öne çıkan ayrıntılar arasında imaj ayarlarının MSBuild özelliklerinde tutulması, SDK'nın proje yapısına göre Microsoft base image seçmesi ve varsayılan non-root kullanıcı yer alıyor. Etiketler değişebilir işaretçiler olarak görülmeli, bu yüzden dağıtımlar çözümlenmiş digest ile yapılmalı; çoklu mimari derleme tek komutla OCI index üretiyor. SDK keyfi komut çalıştırmadığı için işletim sistemi paketi değişiklikleri özel base image gerektiriyor. .NET 11 ayrıntıları Preview 7'ye dayanıyor ve final sürümle doğrulanmalı.

Gerçek dünyada kullanımı

• Her servisinde 15-20 satırlık Dockerfile tekrar eden bir ASP.NET Core API ekibi, build adımlarını .csproj ve ortak props dosyasına taşıyabilir.
• CI'da arşiv üretip tarama, imzalama ve registry'ye yükleme aşamalarını ayıran bir release hattı.
• Kurumsal sertifika veya onaylı paketleri tüm servislere ekleyen bir platform ekibi, bunları tek bir base image'da yönetebilir.

Neden önemli

Standart ASP.NET Core servisleri için Dockerfile bakımı azalırken imajın kimliği digest üzerinden ve güvenlik kontrolleri final imaj üzerinden yürütülmeli.

Benzer haberler

• MCP Sunucularında Ölçekte Rate Limiting ve Kaynak YönetişimiDVDEV Community: #aspnetcore1 gün önce
• .NET ile SSH, Docker ve Dosya Yönetimi Bir Arada: TermForge İncelemesiHBHabr C# (ru)2 gün önce
• Claude Code ile ASP.NET Core endpoint incelemesi için yeniden kullanılabilir skillDLNick Cosentino (Dev Leader)3 gün önce