İlginizi Çekebilir
  1. Ana Sayfa
  2. DevOps
  3. Powershell DSC ve Konfigürasyon Yönetimi

Powershell DSC ve Konfigürasyon Yönetimi

PS_DSC

ve

’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.

  1. Powershell DSC ve Konfigürasyon Yönetimi
  2. Json Konfigürasyon Dosyası ile Sunucularda Konfigürasyon Yönetimi
  3. Pull Server ile DSC Konfigürasyon Yönetimi
  4. 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 , 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ı https://forum.mshowto.org linkini kullanarak ulaşacağınız forum sayfamızda sorabilirsiniz.

Referanslar

www.mshowto.org

TAGs: DevOps, , Konfigürasyon Yönetimi, Powershell DSC, Desired State Configuration,

Yorum Yap

Yazar Hakkında

Üniversite ve öncesindeki öğrenimimi İzmir’de tamamladım. Ege Üniversitesi Bilgisayar Mühendisliği bölümünden mezun olduktan sonra IBTech ‘te System Administrator olarak kariyerime adım attım. Sonrasında yine IBTech içerisinde System, Database ve Application yönetimini aynı anda yapabildiğim kartlı ödeme sistemleri ekibinde görev aldım. Burada gerçekleştirdiğimiz altyapı otomasyon projelerinin de etkisiyle Intertech’te DevOps pozisyonunda kariyerime devam etme fırsatını elde ettim. Microsoft onprem ürünlerinden SCCM, SCO, Windows Server, Active Directory, Exchange ve SQL Server gibi temel ürünlerde adminlik yapmamın yanı sıra, Failover Cluster, Powershell gibi konularda da iş hayatımda önemli çalışmalarım ve tecrübelerim oldu. DevOps ‘un hayatıma girmesiyle de işler çok hızlı değişmeye başladı. Hızlıca CI/CD süreçlerinde kullanılan Microsoft TFS kullanmaya başlayarak, Open Source ürünlerle tanışma fırsatını yakaladım. Piyasada kullanılan Open Source ürünlerden Jenkins, Ansible, Docker, Kubernetes, Elastic Search, Logstash, Kibana ile uğraşma fırsatım oldu. Üniversiteden mezun olduktan sonra hiç bitmeyen yazılım merakım sayesinde ASP .Net, .Net Core, C# programlama dilleriyle geliştirmelerim oldu. Orta seviyede Groovy, başlangıç seviyesinde de Python dillerinde program ya da script geliştirebiliyorum, ileri derecede Powershell bilgisine sahibim. Önümüzdeki yıllarda Powershell ile ilgili Türkçe kaynaklar yayımlamayı, python bilgimi arttırarak, DevOps ‘un özellikle IaC alanında programlama diline bağımlı kalmaksızın geliştirmeler yapabilmeyi hedefliyorum.

Yorum Yap