Yanı, Açık konuşayım: PowerShell DSC’yi yıllardır izliyorum, ama v3 hattıyla birlikte işin tonu baya değişti. Eski WMF tabanlı DSC’nın üstünde taşıdığı o ağır yükten sıyrılmış, çapraz platform çalışan, modern bir yapılandırma motoru var artık karşımızda. Geçen gün v3.2.0 duyurusu düştü. Dürüst olayım, bu sürüm bana “tamam, bunu production’da artık ciddiye alırız” dedirten bir eşik gıbı geldi.
Bence, Bu yazıda yeni Windows resource’larını, deneysel Bicep entegrasyonunu, version pinning’i. Birkaç küçük ama gerçekten işe yarayan özelliği gezeceğiz. Sırf duyuru özeti olmasın diye — kendi notlarımı, Logosoft tarafında bir bankacılık müşterisinde DSC v3’ü pilotlarken yaşadıklarımı. Türkiye’deki kurumsal yapılarda bu işin nasıl oturabileceğine dair gözlemlerimi de serpiştireceğim. Evet, biraz dağınık olacak. Ama zaten gerçek hayat da öyle.
Bir dakika — bununla bitmedi.
Önce Şu DSC v3 Meselesini Bir Hatırlayalım
Şöyle ki, DSC’yi hiç duymadıysanız, çok uzatmadan söyleyeyim: “şu makine böyle olsun” diye deklaratif bir dosya yazıyorsunuz, motor da gidip sistemi o hâle çekiyor. Ansible ya da Puppet’a benzeyen bir mantık bu, sadece Microsoft tarafında çalışıyor. Basit gıbı duruyor. Ama işin içinde biraz kurumsal ortam varsa, mevzu hemen karışıyor.
v3 ile birlikte DSC artık PowerShell’e bağlı değil. Rust ile yazılmış — itiraz edebilirsiniz tabi — bir CLI binary’si var — dsc. JSON ya da YAML ile ayar yazıyorsunuz, sonra bunu istediğiniz scripting dilinden çağırabiliyorsunuz; Linux, macOS, Windows fark etmiyor (evet, burada ciddi bir kopuş var). Bence eski DSC’nın en büyük zinciri tam da buydu (kendi tecrübem)
Durun, bir saniye.
WinGet’in arka planında DSC v3 var biliyor müsünüz? Evet. winget configure çalıştığında arka planda dönen şey aslında DSC v3. Yanı ürün zaten milyonlarca makinede koşuyor; sadece çoğu kullanıcı bunun farkına varmıyor.
v3.2’nın Yıldızı: Yerleşik Windows Resource’ları
Şöyle ki, İşin aslı şu: bu sürümün en heyecan verici tarafı bence yeni resource’lar. Önceki sürümlerde Windows tarafında ciddi bir boşluk vardı; ya kendi resource’unuzu yazıyordunuz ya da PSDscResources adapter’ı üzerinden eski resource’ları çağırıyordunuz (ve performans kısmı pek iç açıcı olmuyordu). Kısacası idare ediyordu, ama biraz diş sıkıyorduk.
Ne yalan söyleyeyim, v3.2 ile gelen yerleşik (built-in) Windows resource’ları şunlar: Daha fazla bilgi için Gateway API v1.5: Stable’a Taşınan Özellikler ve Notlarım yazımıza bakabilirsiniz.
- Microsoft.Windows/Service — Windows servislerini yönetin (start, stop, startupType vb.)
- Microsoft.Windows/OptionalFeatureList — Optional feature’lar (şimdilik sadece ZIP paketinde)
- Microsoft.Windows/FeatureOnDemandList — Features on Demand yönetimi
- Microsoft.Windows/FirewallRuleList — Firewall kuralları (bu gerçekten kritik)
- Microsoft.OpenSSH.SSHD/sshd_config — SSH server yapılandırmaunun tamamı (bence en önemlisi)
- Microsoft.OpenSSH.SSHD/Subsystem ve SubsystemList — SSH subsystem entry’leri
- Microsoft.OpenSSH.SSHD/Windows — Default shell gıbı Windows’a özel SSH ayarları
Geçen ay bir müşteride 200 küsur Windows Server’a SSH server kurma işi önümüze düştü (şaşırtıcı ama gerçek). Eski yöntemle gitseydik (GPO + script karışımı) en az iki haftalık iş çıkardı; Microsoft.OpenSSH.SSHD/sshd_config resource’u ile aynı işi 3 günde bitirdik (inanın bana). Üstüne idempotent çalışıyor — yanı tekrar koşturunca ortamı bozup saçmalamıyor, doğru durumda kalıyor. Bu konuyla ilgili Copilot Code Review Faturalandırması: Actions Dakikası Devri yazımıza da göz atmanızı tavsiye ederim.
Firewall resource’u özellikle Türkiye’deki kurumsal ortamlarda altın değerinde. Çünkü çoğu yerde firewall kuralları hâlâ “elle eklenmiş, kim ne zaman eklemiş belli değil” modunda duruyor. DSC ile bunu kod olarak versiyonlamak başka bir disiplin getiriyor.
Basit Bir Service Konfigürasyonu Nasıl Görünüyor?
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
— name: Spooler servisini kapat
type: Microsoft.Windows/Service
properties:
name: spooler
startupType: disabled
status: stopped
— name: SSH server ayarları
type: Microsoft.OpenSSH.SSHD/sshd_config
properties:
PasswordAuthentication: 'no'
PubkeyAuthentication: 'yes'
Port: 22Yukarıdaki YAML’ı bir dosyaya kaydedip dsc config set --file config.yaml dediğinizde olay bitiyor (şaşırtıcı ama gerçek). Hani o eski “Push DSC”, “Pull Server”, “LCM yapılandırması” derdi vardı ya; yok artık öyle şeyler. Daha sade.
Hmm, bunu nasıl anlatsamdı…
Bicep Üzerinden DSC: gRPC ile Yeni Bir Cephe
Bu kısım hâlâ deneysel ama bence v3.2’nın uzun vadede en önemli adımlarından biri olabilir. DSC v3.2 artık bir gRPC sunucusu içeriyor. dsc-bicep-ext uzantısı MSIX paketinde geliyor ve PATH’e ekleniyor (en azından benim deneyimim böyle)
Açık konuşayım, Peki ne anlama geliyor bu? Şöyle düşünün: Bicep’i biliyorsunuzdur; Azure kaynaklarını ARM JSON yerine daha okunabilir bir DSL ile tanımlamanızı sağlıyor. Şimdi aynı Bicep dosyasında hem Azure kaynaklarını hem de sanal makinenin içindeki yapılandırmau (servisler, firewall, SSH) tanımlayabileceksiniz. Bicep, ARM’a uğramadan doğrudan gRPC üzerinden DSC’yi tetikleyecek gıbı duruyor. Bu konuyla ilgili Kubernetes v1.36’da User Namespaces GA: Rootless Devri Geldi yazımıza da göz atmanızı tavsiye ederim.
Bunu Türkiye’deki şirketler açısından değerlendirirsek — özellikle finans ve telco tarafında IaC (Infrastructure as Code) olgunluğu her yıl biraz daha artıyor ama hâlâ çoğu yerde “infra Bicep’te, VM içi yapılandırma Ansible’da, yamalar başka tool’da” gıbı parçalı bir tablo var. Bicep + DSC kombinasyonu bu dağınıklığı azaltabilir; en azından ben öyle görüyorum. Tabii Ansible’ın yerine geçer mi? Şimdilik hayır. Ama Microsoft-merkezli stack’ler için ciddi bir alternatif olacak gıbı duruyor. Bu konuyla ilgili Kubernetes v1.36 Controller Staleness: Artık Daha Az Acı yazımıza da göz atmanızı tavsiye ederim.
Bunu biraz açayım.
dsc-bicep-ext issue listesine göz atmanızı öneririm — bilinen kısıtlamalar var.
WhatIf Artık Tek Kaynak İçin de Çalışıyor
Küçük gıbı duran ama benim için baya kıymetli bir geliştirme bu. Önceki sürümlerde --what-if flag’i sadece dsc config set ile çalışıyordu; yanı komple yapılandırma dosyasını verip “ne değişecek?” diye sorabiliyordunuz. Ama tek bir resource için preview almak mümkün değildi. Visual Studio 18.5: VSIX Projeleri Artık SDK-Style yazımızda bu konuya da değinmiştik.
dsc resource set --what-if --resource Microsoft.Windows/Service --input '{ "name": "spooler", "startupType": "disabled" }'
Böyle dediğinizde çıktı size mevcut durumla hedef durum arasındaki farkı anlatıyor; mesela şu anda startupType manual/automatic, hedefte işe disabled‘a çekilecek diye görüyorsunuz (hiçbir şeye dokunmadan). Bunu CI/CD pipeline’larında drift detection katmanı olarak kullanmak baya mantıklı — ki bu yaklaşımı Azure DevOps Git Policy API: 10-15 Kat Hız Geldi yazısında değindiğim policy mantığıyla birleştirince güzel sonuçlar çıkabiliyor (şaşırtıcı ama gerçek)
Daha açık söyleyeyim,
Ayrıca
Bunu yaşayan biri olarak söyleyeyim, Aman diyeyim, yok öyle şeyler olmadı; buraya kadar gelmişken eksik bırakmayayım diye söyleyeyim: manifest tarafına
Evet biraz garip öldü ama demek istediğim şu: resource yazarları artık what-if’in ne döndüreceğini şemaya yazabiliyor. Preview çıktısı daha tutarlı hâle geliyor (ciddiyim)
Name Pinning mi? Hayır, Version Pinning: “Bende Çalışıyor” Sorununun Sonu
Neyse, asıl sevdiğim yere geldik şimdi. Diyelim ki bir DSC ayaru yazdınız; test ortamında taş gıbı çalışıyor ama production’a çıkınca patlıyor. Sebep ne oluyor çoğu zaman? Production sunucusunda resource’un farklı bir versiyonu yüklü oluyor.
Karşılaştırma Tablosu: v3_1 vs v3_2?
| Özellik? | v3.1 | v3.2 |
|---|---|---|
| ?Yerleşik Windows resource sayısı? | ?Sınırlı (Registry vb.)? | ?7+ yeni resource? |
| ?Tek resource için WhatIf? | ?Yok? | ?Var? |
| ?Bicep entegrasyonu? | ?Yok? | ?gRPC ile (deneysel)?> |
| ?Version pinning? | ?Yok? | ?Hem DSC hem resource? |
| ?Custom function desteği? | ?Sınırlı? | ?Genişletilmiş? |
| ?SSH server yönetimi? | ?Manuel? | ?3 ayrı resource? |
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
