DSC v3.2.0 ile Konfigürasyon Kontrolü Daha Olgun Hale Geliyor
İnanın, PowerShell tarafında bazı duyurular var, ilk okuduğunuzda “tamamdır” deyip geçiyorsunuz; sonra bir gün üretimde karşınıza çıkıyor ve asıl kıymeti orada belli oluyor. DSC v3.2.0 benim için tam öyle bir sürüm öldü (evet, doğru duydunuz). Kağıt üstünde birkaç yeni resource, biraz daha iyi WhatIf desteği, Bicep ile deneysel entegrasyon… Ama sahada çalışan biri olarak şunu söyleyeyim: küçük görünen bu adımlar, kurumsal tarafta bazen beklenenden fazla fark yaratıyor.
Ben 20+ yıldır sistem yönetimi, hosting ve bulut tarafında dolanıyorum. Azure’a geçtiğimiz projelerde en çok uğraştığımız meselelerden biri hep aynıydı: “Bu sunucu gerçekten istediğimiz hâlde mi dürüyor?” Yanı drift meselesi. Bir müşteride 2023’ün sonlarında bunu canlı yaşadık; İstanbul’daki bir finans ekibinde Windows servisleri elle değiştirilmişti ve kimse fark etmemişti. İşte DSC gibi araçlar tam burada devreye giriyor. Sessizce çalışıyor ama işini düzgün yaparsa gecenin bir yarısı uykunuzu bölmüyor… bu da baya iyi bir şey.
Ve işler burada ilginçleşiyor.
Neden Bu Sürüm Bana Önemli Geldi?
Bakın şimdi, configuration management dünyasında mesele hiç de “kaç tane özellik geldi” değil. Asıl soru şu: Operasyon ekibi bunu günlük hayatta kullanabiliyor mu? DSC v3.2.0 bu soruya daha net cevap veriyor. Artık sadece teorik olarak ilginç değil; pratikte de biraz daha rahat kullanılabiliyor.
Mesela ben AZ-104 ve AZ-305 hazırlık süreçlerinde hep şunu anlatırım: Bulutta tasarım yapmak başka şeydir, o tasarımı tutarlı şekilde korumak bambaşka şeydir. Mimariyi çizmek kolay; önü bozulmadan yaşatmak zor kısım. DSC’nın olayı tam da burada başlıyor. Mesela Windows tabanlı altyapıda servisler, firewall kuralları, SSH ayarları gibi gündelik ama hayatı bileşenler artık daha doğal yönetiliyor.
İşte tam da bu noktada devreye giriyor.
İşin garibi, Geçen yıl Ankara’da orta ölçekli bir üretim firmasına danışmanlık verirken gördüğüm tablo çok netti: İki ayrı ekip aynı sunucuya dokunuyor, biri güvenlik için firewall kuralı açıyor, diğeri uygulama ayağa kalksın diye servis start type değiştiriyor… Sonra akşam oluyor, herkes birbirine bakıyor. Bu tip ortamlarda DSC’nın değeri fena hâlde artıyor çünkü “kim ne yaptı” sorusuna teknik cevap veriyor.
Yeni Resource’lar: Küçük Görünüyorlar Ama Etkileri Büyük
İtiraf edeyim, DSC v3.2 ile gelen built-in Windows resource set’i bana göre sürümün en somut tarafı. Çünkü insanlar bazen yeni özellik deyince gözünü büyütüyor ama işin aslı şu ki çoğu işletmede sorun zaten çok basit alanlarda çıkıyor: servis durdu mu, firewall açıldı mı, SSH ayarı değişti mi…
Araya gireyim: Microsoft.Windows/Service, Microsoft.Windows/FirewallRuleList, OptionalFeatureList, FeatureOnDemandList ve OpenSSH tarafındaki kaynaklar sayesinde artık temel işletim işleri için dışarıdan ekstra bileşen arama ihtiyacı azalıyor. Bu güzel haber ama henüz ham sayılır; özellikle bazı kaynakların ZIP paket üzerinden kullanım istemesi ilk etapta biraz garip geliyor.
Evet, doğru duydunuz.
Bana kalırsa burada en hoş gelişme SSH tarafında olmuş. Windows üzerinde OpenSSH kullanan kurum sayısı az değil artık; ben 2024’te İzmir’deki bir lojistik müşterisinde bunu görmüştüm, ekip PowerShell Remoting yerine SSH standardına yaklaşmak istiyordu çünkü Linux. Windows’u aynı disiplinle yönetmek istiyorlardı. İlginç, değil mi? İşte bu noktada sshd_config ya da default shell ayarlarını DSC ile sabitlemek baya işe yarar.
| Kullanım Alanı | Daha Mantıklı Resource | Sahadaki Notum |
|---|---|---|
| Windows servisi yönetimi | Microsoft.Windows/Service | Sık drift olan ortamda çok faydalı |
| Firewall kural seti | FirewallRuleList | Sistem sertleşmesi için temiz çözüm |
| SSH sunucu ayarı | OpenSSH.SSHD/Windows | Karma OS ortamlarında rahatlatıyor |
| Paketlenmiş feature kontrolü | OptionalFeatureList | Zaman zaman ZIP pakete dönmeniz gerekiyor |
Küçük ekip vs kurumsal yapı
Ne yalan söyleyeyim, Eğer küçük bir startup iseniz açık konuşayım: her şeyi DSC’ye taşımak şart değil. Önce en sık bozulan iki üç şeyi seçin — servisler, portlar, hayatı Windows feature’ları gibi — sonra oradan ilerleyin. Aksi hâlde takımın yarısı “bu tool neden var?” diye bakıp kalabilir.
Büyük kurumsal yapılarda işe tablo farklı. Orada change control var, denetim var, bazen regülasyon var… O yüzden DSC’nın değerini “uyguladıktan sonra ne değişecek?” sorusu belirliyor. Eğer sizin ortamınızda elle yapılan ufak değişiklikler bile raporlanmak zorundaysa, bu araç ciddi rahatlık verir.
Bicep + gRPC Deneyi: İlginç Ama Hâlâ Pişmeye İhtiyacı Var
Bence sürümdeki en merak uyandıran parçalardan biri Bicep entegrasyonu öldü. gRPC server üzerinden DSC kaynaklarını orkestre etme fikri kağıt üstünde baya havalı dürüyor; hatta mimarı olarak temiz de dürüyor çünkü Bicep yazıyorsunuz. Tahmin eder mısınız? Execution akışı doğrudan gRPC üzerinden gidiyor, ARM katmanını aradan çıkarıyorsunuz.
Ama durun bir dakika — burada heyecanla fazla uçmayalım. Deneysel etiketini boşuna koymamışlar. Ben buna ilk baktığımda klasik “güzel fikir ama üretimde dikkat” kategorisine koydum. Çünkü kurumsal tarafta orkestrasyon demek sadece çalışması değil; loglaması, hata yönetimi, rollback davranışı ve versiyon uyumu demek (ki bu çoğu kişinin gözünden kaçıyor)
Bence Bicep + DSC birleşimi gelecekte çok şey değiştirebilir ama bugün için önü doğrudan prod standardı yapmak yerine pilot alanlarda denemek daha doğru.
Bunu kendi deneyimimden söylüyorum: 2019’da benzer şekilde config orchestration katmanını fazla erken prod’a alan bir müşteriyle uğraşmıştık (Gebze tarafında bir üretim tesisi). Her şey demo’da şahane gidiyordu; gerçek yük altında işe edge case’ler patladı… Sonunda geri adım atıp önce sınırlı kapsamda kullanmaya başladılar ve ancak sonra yaygınlaştırdılar (ciddiyim)
If-WhatIf Meselesi ve Sürüm Sabitleme Neden Ciddi?
Bunu yaşayan biri olarak söyleyeyim, If-WhatIf supportu genişlediğinde insan önce “eh işte” diyor olabilir ama production tarafında bunun adı risk azaltma. Artık tek tek resource seviyesinde what-if çalıştırabiliyorsunuz; yanı uygulanmadan önce ne olacağını görebiliyorsunuz.
dsc resource set --what-if --resource Microsoft.Windows/Service --input '{
"name": "spooler",
"startType": "disabled"
}'
Dürüst olmak gerekirse, Açık konuşayım, spooler örneği gibi basit görünen şeyler bile bazen büyük problem yaratır; özellikle baskı altyapısına bağlı eski uygulamalar varsa… Bir bankacılık müşterisinde bunu yaşamıştık ve hata çıktığında sebep service dependency zincirinin beklenmedik davranmasıydı.
Sürüm pinning işe bence enterprise dünyası için daha da kilit olabilir çünkü ortamda bugün çalışan şeyin yarın farklı davranmasını kimse istemez.
Açıkçası, Bir müşteri toplantısında bunu anlattığımda ekipten biri şunu sormuştu: “Neden latest kullanmayalım?” Güzel soru aslında… Cevap da basit: çünkü production’da sürpriz sevmiyoruz! En çok da compliance hassasiyeti olan yerlerde config document’in hangi DSC sürümüyle ve hangi resource versiyonuyla çalışacağı net olmalı.
Bunun Türkiye’de karşılığı ne?
Türkiye’de şirketlerin önemli kısmı hâlâ hibrit yaşıyor; biraz on-premises, biraz Azure Arc benzeri yaklaşımlar, biraz da legacy sistemler… Böyle ortamlarda version pinning yalnızca teknik tercih değil, operasyonel sigorta gibi düşünülmeli.
Hani, Maliyet açısından bakarsanız da durum ilginçtir: Azure’da ekstra lisans faturası yok diye herkes rahatlıyor. Asıl maliyet insan saati oluyor. Bir değişikliğin gece yarısı patlayıp iki mühendise üç saat harcatması mı daha pahalıdır, yoksa düzgün pinlenmiş bir config document ile işi baştan garantiye almak mı? TL bazında düşününce cevap genelde ikinci seçenek oluyor — tabi kültürünüz buna izin veriyorsa…
Sahada Düşündüren Eksikler de Var
Evet iyileştirme var. Her şey güllük gülistanlık değil.
Mesela bazı yeni resource’ların dağıtım şekli ilk anda kafa karıştırabiliyor; dokümantasyonu iyi okuyunca oturuyor ama yine de ilk denemede insanın yüzünde hafif bir hayal kırıklığı oluşabiliyor.
Ben ilk testimde yanlış paket tipi yüzünden beklediğim çıktıyı alamadım ve kısa süreliğine saçma bir hata mesajıyla uğraştım (saat akşam altıya geliyordu tabiî…) (inanın bana). E peki, sonuç ne öldü? Çözümü sonunda ZIP paketini doğru kullanmakta bulduk ama bu bana şunu hatırlattı: güçlü araçlar bile kullanıcı deneyimi pürüzsüz değilse yaygınlaşmakta zorlanır.
- Kritik senaryolar için önce pilot yapın.
- Sürüm sabitlemeyi prod öncesi standart hâline getirin.
- Bicep entegrasyonunu hemen ana akışa almayın; önce laboratuvarda deneyin. — ciddi fark yaratıyor
- Zaten drift yaşayan makinelerde başlayın; faydayı orada hemen görürsünüz.
Kendi Pratik Akışım Olsaydı Nasıl Başlardım?
Neyse uzatmayalım; denemek isteyen biri için benim sıralamam şu olurdu:
>
Tavsiyem net:
If your environment already has Configuration Drift pain — yanı sürekli elle düzeltme yapıyorsanız — DSC v3.x çizgisine ciddi bakın.
Ama sırf yeni çıktı diye her yere yaymayın; tool sevgisi başka şeydir, operasyon disiplini başka şey!
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.
4 comments