Powershell DSC ve Konfigürasyon Yönetimi
DevOps’un en önemli parçalarından bir tanesi de konfigürasyon yönetimi. Konfigürasyon yönetimi için Ansible, Puppet, Chef, Salt ya da Powershell DSC seçeneklerinden bir tanesini kullanabiliriz. Bu ve gelecek üç yazımda konfigürasyon yönetimini Powershell DSC ile nasıl yapacağımızı aktarmaya çalışacağım. Sırasıyla aşağıdaki yazıları yayımlamayı hedefliyorum.
- Powershell DSC ve Konfigürasyon Yönetimi
- Json Konfigürasyon Dosyası ile Sunucularda Konfigürasyon Yönetimi
- Pull Server ile DSC Konfigürasyon Yönetimi
- Github, Jenkins ve Powershell DSC Kullanarak Konfigürasyon Yönetimi
Peki Powershell DSC ya da kısaca DSC nedir?
Adından da anlayabileceğimiz gibi Desired State Configuration, istenilen konfigürasyon durumunun sürekli olarak sağlanabilmesidir. Peki GPO, klasik scriptlerle ya da Powershell ile hazırladığımız scriptlerle bunu yapamaz mıyız? Elbette yapabiliriz ancak DSC ile temel amaç bu süreçleri kolaylaştırmak ve bakım maliyetlerini azaltarak sistemin tamamına uygulamaktır.
DSC ile takip edilen konfigürasyonlar kolay okunabilir, kolay saklanabilir ve kolayca güncellenebilirdir. Ayrıca DSC ‘nin kullanımı Windows ortamlarda script yazmanın kompleksliğini azaltarak, tekrarlayan kontrollerin daha sık aralıklarla ve kolaylıkla yapılmasını sağlamaktadır. Son olarak açık kaynak ürünlerin en önemli özelliği olan komünite tarafından hazırlanmış hazır modüller sayesinde kolayca uygulamaya alınabilir. DSC’yi Windows sunucularda uygulamaya almak için hedef ortamlarda WMF (Windows Management Framework) versiyonun ve WinRm konfigürasyonunun dikkatlice takip edilmesi yeterlidir. WMF versiyonu standart olmayan ya da WinRm konfigürasyonu düzgün yapılandırılmayan bir ortamda Powershell scriptleri (DSC olsun ya da olmasın) çalıştırılırken sorunlar yaşanabilir.
Örneğin standart bir Powershell scriptiyle bir Windows servisinin running durumda olduğunu aşağıdaki gibi kontrol edebiliriz.
$serviceName
=
‘W3SVC’
if($serviceObj
=
Get-Service
-Name
$serviceName)
{
Write-Verbose (“Checking service status: {0}”
-f
$serviceObj.Status)
if($serviceObj.Status -ne
“Running”)
{
try{
Start-Service
$serviceObj
-Verbose
Write-Verbose (“{0} is started successfully.”
-f
$serviceName)
}
catch
{
throw (“Couldn’t start {0} service successfully.”
-f
$serviceName)
}
}
else
{
Write-Verbose (“{0} is running.”
-f
$serviceName)
}
}
Biraz uğraştık ancak yine de bu scripti belirli intervalda çalıştıracak bir orkestra şefine, yeni parametreleri konfigüre etmek istersek ekstra efora ihtiyacımız olacak. Şimdi bir de aynı scriptin DSC ile geliştirilmiş versiyonunu ekleyelim.
Configuration
serviceHealthCheck{
param($serviceName)
Import-DscResource
-ModuleName
PSDesiredStateConfiguration
Node
‘localhost’
{
Service
ServiceExample
{
Name =
$serviceName
StartupType =
“Automatic”
State =
“Running”
}
}
}
serviceHealthCheck
-serviceName
‘W3SVC’
-OutputPath
C:\MOF
Start-DscConfiguration
-Path
C:\MOF
-Verbose
-Wait
-Force
DSC ile de pek kolay değilmiş Hakkı dediğinizi duyar gibiyimJ Tamam bir satır değil ancak farkettiyseniz bu sefer sadece servis durumu ile yetinmedik, startup tipini de isteğimiz doğrultusunda düzenleyebildik. Ve emin olun sağlayabildikleri bununla sınırlı değil. Service Resource için https://docs.microsoft.com/en-us/powershell/dsc/serviceresource sitesini ziyaret ederek bu resource için desteklenen konfigürasyon parametrelerini inceleyebilirsiniz.
İyi de DevOps ile DSC ‘nin ilgisi nedir?
DevOps insan, süreç ve araçların (DevOps is a great combination of people, process and tools) birleşimiyle daha hızlı ürün çıkarabilmek amacıyla deploymentların daha sık aralıklarla, daha hızlı yapılabilmesini amaçlar. Temelde en önemli amacı iç ya da dış müşterilere daha hızlı ve bugsız ürünler sunabilmektir. DSC de DevOps hesaba katılarak tasarlanmıştır. Konfigürasyon dosyalarıyla tanımlanan IT Environment ve bu dosyalara erişebilen IT Prolar ya da Developerlar aslında hem ortam envanterini görüntüleyebilecek hem de eğer değiştirme yetkileri var ise ortamda kontrollü, onaylı ve kayıtlı değişiklik yapabileceklerdir.
Yani hazırladığımız DSC scriptlerini konfigürasyon dosyalarını okuyacak ve dinamik olacak (Bir windows feature ya da 10 windows feature kurmak istediğimde scriptim değişmemeli, konfigürasyon dosyasında ne kadar windows feature girdiysem hepsi üzerinde aynı scriptle işlem yapabilmeliyim) şekilde tasarlarsak bir servisin çalışıp çalışmadığını monitoring tool ile kontrol etmeye (production tavsiyesi değildirJ) dahi gerek duymadan, telefonumuz “şu servis çalışmıyor hocam bir bakar mısın?” diye çalmadan DSC benim yerime işte şu servis çalışmıyor benim hemen onu ayağa kaldırmam gerekiyor diyecek ve gece uykumuz belki de gereksiz bölünmeyecek.
Ya da hazırlanmış bir windows servis kurulum scriptini yeni bir node için uyguladığımızı düşünelim, performans sorunu yaşadığımız bir günde servisin kurulum prosedürünü bulup, dökümanı okuyarak adımlarda ilerlemeyi mi tercih edersiniz yoksa örneğin $nodes array’ine yeni bir host ekleyerek kurulumun otomatik yapılmasını mı? Abi ben servisi elimle kurup görmeden güvenemem diyorsanız ikna etmek için uzun uzun konuşabiliriz.
DevOps bu mu peki diyorsanız, hayır ileride DevOps’u da anlatmayı planladığım yazılarım olacak ancak bu yazıdan sadece DSC’nin DevOps temelinde tasarlandığına dair ufacık değinmek istedim.
Bir sonraki yazımda json dosyasından okuyacağımız konfigürasyonu Powershell DSC ile nasıl sistemlere uygulayabileceğimizi anlatacağım.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
TAGs: DevOps, Configuration Management, Konfigürasyon Yönetimi, Powershell DSC, Desired State Configuration,Desired State Configuration nedir