Powershell DSC Nedir? Örnek Kullanım Senaryoları

En kısa haliyle Powershell DSC, Chef ve Puppet gibi yapılandırma yöneticisidir. Ancak burada yapılandırma yöneticisi rolünün üzerine çıkmasını sağlayan özelliklere de sahiptir. Örneğin Powershell DSC ile IIS’i kur, ASP.Net’i kur ve şu klasördeki uygulamayı sun” diyebilir ek olarak bunu bir adım öteye taşıyabilir ve “IIS özelliği kurulu ve çalışıyor olmalıdır. Üzerinden XYZ uygulaması bulunmalı ve çalışır durumda olmalı” diyebiliyoruz.

DSC ( Desired State Configuration ) Powershell 4.0 ile gelmiş, 5.0 ile birlikte v2 seviyesine ulaşmış yönetim platformudur. Tüm sunucularda tutarlılık ve zaman kazanma gibi mottolar ile pazarlanmaktadır. DSC sayesinde bir sunucu üzerinde yapılabilecek otomasyona dair işlemler aşağıdaki gibidirler.

• Server role ve feature’larının etkinleştirilmesi yada kaldırılması
• Registry key’lerin yönetilmesi
• Dosya ve dizinlerin yönetilmesi
• Process ve servislerin çalıştırılması,durdurulması ve yönetilmesi
• Kullanıcı ve grup’ların yönetilmesi
• Yeni uygulamaların yüklenmesi
• Ortam değişkenlerinin yönetilmesi
• Windows Powershell script’lerinin çalıştırılması
• Desired state dışına çıkan konfigürasyonların tekrardan düzenlenmesi
• Belirlenen node’daki geçerli konfigürasyon durumunun discover edilmesi

İki adet Metodu mevcuttur. PUSH ve PULL metodu.

Push Metodu WinRm sayesinde oluşturulmuş bir MOF dosyasına bağlı konfigürasyonun Client Makine üzerine kopyalanması işlemidir.

Pull Metodu ise Web Server yardımıyla Client cihazların sürekli kendilerine dair yeni bir konfigürasyon olup olmadığını kontrol ederek sürekli iletişimde kalması modelidir. Belirlenen süreler çerçevesinde Client, Master Node olarak adlandırlan Web Server üzerinde kendisine dair yeni bir MOF konfigürasyonu olup olmadığını kontrol eder. Burada yaptığı işlem kendisine verilen son MOF ile kendi üzerinde çalışan MOF dosyasının kıyaslamaktır. Eğer farklılık söz konusu ise Client yeni MOF dosyasını PULL eder.

Production ortam için Microsoft elbetteki PULL metodu önermektedir.

LCM ( Local Configuration Manager)

DSC ile beraber gelen bir engine olan LCM kendi NODE’u için yeni bir konfigürasyon olup olmadığını kontrol etme amacı taşımaktadır. Eğer yeni bir konfigürasyon var ise bu yeniliğin kabul edilme işlemi yine bu engine üzerinden gerçekleştrilir. Yenilikleri almak için PULL ya da PUSH metotlarını kullanmaktadır. LCM üzerinden kontrol sıklığı düzenlenebilir. LCM konfigüre etmek için meta-MOF dosyaları yaratılır ve bunun sayesinde değerleri üzerinde değişiklik yapılabilir.

DSC Resources:

Powershell bünyesinde yer alan hazır şablonlardır. Daha kısa ve verimli kod yazarak işlem yapılmasını amaçlamak adına custom olarak gelmektedir. Hali hazırda var olan şablonlara ulaşmak için Get-DscResources komutu kullanılır.

Powershell Gallery’de yüzlerce custom şablon bulunmaktadır.

Resim-1

Örnek verilmesi gerekirse,

Service şablonu yardımıyla Client Node’a yer alan bir sunucunun servisleri hakkında düzenleme ve yönetim işlemi yapılabilir. Örnek olarak yazmış olduğum kod aşağıdaki gibidir.

Configuration
ServiceKontrol {

node
“192.168.0.1” {

Service
ServiceKontrol {

Name =
“AudioSrv”

State =
“Running”

}

}

}

ServiceKontrol

Push Metodu

• Hedefteki sunucunun LCM konfigüre edip reflesh metodunun “Push” olarak ayarlanması gerekmektedir.
• Bunun yapılabilmesi için meta MOF dosyası yaratılır. Meta MOF dosyası client sunucu üzerine konfigürasyon değişikliği yapan MOF dosyasıdır.
• Bu işlemden sonra ise Set-DSCLocalConfigurationManager komutu ile MOF dosyası client sunucuya deploy edilir.
• LCM konfigürasyonu yukarıdaki komut yardımıyla deploy edildikten sonra, makine konfigürasyonu için salt MOF dosyası oluşturulur.
• Start-DscConfiguration
  komutu sayesinde ise bu MOF dosyasındaki konfigürasyonlar hedef makinede uygulanmaya başlanır.

Meta-Mof Dosyası

Öncelikle client üzerinde Get-DscLocalConfigurationManager
komutu ile hali hazırda var olan Refresh Mode
tipinin ne olduğu kontrol edilmelidir. PUSH modunun aktif olması için değişkenin PUSH olması gerekmektedir. Burada halihazırda PUSH gelmektedir. Olmama ihtimaline karşı meta-mof dosyası yardımıyla bu değişkenin PUSH yapılması mümkündür.

Resim-2

LCM konfigürasyonu için oluşturulan örnek meta-MOF dosyası aşağıdaki gibidir.

[DSCLocalConfigurationManager()]

Configuration
LCMPUSH {

Node
“dsc-client.ekol.local” {

Settings {

AllowModuleOverwrite =
$True

ConfigurationMode =
‘ApplyAndAutoCorrect’

RefreshMode =
‘Push’

}

}

}

LCMPUSH
-outputPath
C:\Script\

Bu işlemin çalıştırılmasının ardında bizlere bir adet meta-MOF dosyası yaratılır. Normal şartlar altında Configuration tag’i ile başlayan bir script sonucunda MOF dosyası yaratılması gerekmektedir. Bunun meta-MOF olmasını sağlayan ve bu dosya formatına sahip olmasını [DSCLocalConfigurationManager()] tag’i sağlamaktadır.

Resim-3

Hostname ile gerekli konfigürasyonu hazırladım. Node parametresi ile verilen değer cihazı temsil eden bir değişken olmak zorundadır. MOF dosyası bu isme göre yaratılacaktır.

Bu işlemden sonra yukarıda adımlar çerçevesinde yapılması gereken eylem oluşturulan meta-mof dosyasının client sunucu üzerine deploy edilmesi olacaktır. Bu işlem için belirtmiş olduğum gibi Set-DSCLocalConfigurationManager komutu kullanılmalıdır.

Resim-4

İşlemin sorunsuzca gerçekleşmesi için ;

Eğer cihazlarımız aynı domainde olmasaydı aşağıda vereceğim path ile gerekli izini tanımlamamız gerekecekti.

Gpedit.msc à Computer Configuration à Administrative Templates à Windows Components à WinRM à WinRM Client à Trusted Hosts policy ayarına client IP’sini eklemeliydik.

Yukarıdaki çıktıyı incelediğimizde yaratmış olduğum meta-mof konfigürasyonu 0.747 saniye içinde client üzerine deploy edildi.

Daha öncesinde ConfigurationMethod parametresi ApplyAndMonitor iken ( )

Yeni düzenlemem ile bu paratmetre ApplyAndAutoConnect değerine sahip olmuş oldu. Yukarıdaki çıktı ile karşılaştırabilmek adına konfigürasyon işlemi sonucu yeni Get-DscLocalConfigurationManager çıktısını ekliyorum.

Resim-5

Deploy işlemi kısaca Master üzerinde oluşturmuş olduğum meta-MOF dosyasını, client üzerine yazma işlemiydi. Client Node bu konfigürasyonu aşağıdaki gibi System32 altında var olan Configuration dizininde saklamaktadır.

Resim-6

Artık Client makinemiz (dsc-client.ekol.local) Push yöntemi ile konfigure edilebilecek konuma gelmiş durumdadır. Basit bir şekilde şablon kullanarak konfigürasyon işlemi içerecek MOF dosyası yaratalım.

Bu işlem için WindowsFeature şablonu kullanacağım ancak Feature ismini aynı şekilde verilmesi gerekmektedir aksi taktirde MOF dosyası oluşturulmayacaktır. Bu isimlere ulaşmak için PowerShell üzerinde Get-WindowsFeature komutu ile yüklenebilecek ya da yüklü features isimleri bulunabilir.

Resim-7

Liste bayağı uzun ancak kısa bir kurulum süresi olduğu için ben Telnet-Client’I tercih edeceğim. Bu işlem için önce configuration betiğimizi yazıp bu betik sayesinde bir MOF dosyası oluşturmamız gerekmektedir.

Configuration
ilkDeploy {

Node
“dsc-client.ekol.local” {

#WindowsFeature şablonu sayesinde yeni bir servis kuracağım.

WindowsFeature
Telnet-Client {

Name =
“Telnet-Client”

}

}

}

ilkDeploy
-outputPath
C:\Script\ilkdeploy

Yazmış olduğum konfigurasyon Telnet-Client’I kurup gelecek. Aslında gelmeyecek yukarıda belirtmiş olduğum System32 altında yer alan bölüme yazılarak sürekli olarak Telnet-Client featurenın aktif olup olmadığını kontrol edecek bu yüzden ben özelliği kaldırsam bile MOF dosyası orada yer aldığı için yeniden ve yeniden bu Özelliği aktif edecek. Oluşturulan MOF dosyasını Start-DscConfiguration
komutu sayesinde dürtüyorum.

Resim-8

Bu işlem sonrasında System32 à Configuration içine Current.mof isminde bir MOF dosyası yaratıldı ve bu MOF dosyası sayesinde Telnet-Client özelliği kuruldu.

Resim-9

Peki current.mof dosyası nasıl bir içeriğe sahip,

Resim-10

Genel olarak MOF dosyasının yapısından bahsetmiştim ancak burada dikkat edilecek durum Master Node üzerinde yazmış olduğum konfigürasyonun aynı şekilde Client Node üzerinde bulunuyor olmasıdır.

Peki ben bu Özelliği kaldırırsam ne olacak ?

Resim-11

Komut yardımıyla Telnet-Client özelliği sunucudan kaldırıyorum. Bu durumda Master Node ile Client Node arasındaki Test işlemi $False cevabını dönecektir. Bu sebepten sunucuyu yeniden başlattığımız zaman Telnet-Client yeniden kurulacaktır.

Tekrardan Telnet-Client kurulmasını istenmiyor ise, current.mof dosyası silinebilir ya da master node üzerinden yapılan set işleminin zıttı olan Remove işlemi ile bu işlem sonlandırılabilir.

Powershell DSC üzerinde PUSH metodu bu şekilde çalışmaktadır.

Resim-12

PULL METODU

Pull metodu iki şekilde yapılabilir.

• SMB Server
• Web Server sayesinde.

Pull metodunun mantalitesi şu şekildedir.

Client Node sürekli kendisine verilen yeni bir konfigürasyon olup olmadığını kontrol etmek için sürekli olarak SMB ya da Web Server üzerinden kontrol işlemi yapar. Eğer yeni bir konfigürasyon var ise bu yeniliği uygular. Dsc-admin sunucuma Powershell-Dsc servisini kurduğumda aslında IIS’de kurulmuş oldu. Bunun sebebi PULL Method için IIS ile dürtebilmemizdir. SMB Server kullanımı için hem client hem admin Powershell 5.1 olması gerekiyor. Henüz yeni ve test aşamasında olan bir özellik olduğu için PULL Methodu IIS üzerinde anlatmaya çalışacağım.

Pull Server Ayarlanması Hk.

Gereklilikler;

• Powershell 5.0 ve/veya üzeri olması gerekmektedir.
• IIS rolü kurulu olmalıdır.
• DSC servisi olmalıdır.

Bu işlem için iki adet yeni sunucu yarattım. Microsoft 5.0 ve üzeri demesine rağmen 5.1 WMF sürümüne sahip client ve admin sunucuları ile bu işlemi yapmaya başladığımda bazı sertifika ve registration key’ile alakalı problemler yaşadım. Bu sebeple yeni admin ve client nodeları yaratarak işlemini WMF 5.0 düzeyinde yapmaya karar verdim.

Sunucu Bilgilerim;

Bu bilgiler ışığında yapmamız gereken adımlara başlıyorum. İlk olarak pull server olarak kullanacağım sunucumun konfigürasyonu ile başlıyorum.

Admin ( Pull-server.ekol.local) Konfigürasyonu Hk.

Web Service aracılığıyla konfigürasyonu belirttiğimiz bir path’e koyarak client’ın belirli aralıklarla kendisine ait yeni bir konfigürasyon olup olmadığını kontrol etmesi planına dayalı bu sistem için öncelikle pull server olarak adlandırmış olduğum sunucumu web servis üzerinden hizmet verebilecek hale getirmem gerekmektedir. Bu işlemi yine DSC aracılığıyla yapmak mümkündür. Tek yapmış olduğum işlem WMF 5.0 yükleyerek gerekli node üzerindeki powershell sürümünü 5.0’a çıkarmak oldu. Bu işlemin akabinde gerekli olan konfigürasyonu aşağıda yazmış olduğum betik yardımıyla yapıyorum.

NOT:

Resim-13

Clientlarda ihtiyacımız olmamasına rağmen Admin Node üzerinde DSC servisi kurulu olmak durumdadır. Kurulu olmasa da biz konfigürasyon betiğimizde bu işlemi zaten yapacağımız için ekstra kurulum gerekmemektedir.

Configuration
CreatePullServer {

param

(

[string[]]$computerName =
‘localhost’,

[parameter(Mandatory)]

[ValidateNotNullOrEmpty()]

[string]
$RegistrationKey

)

Import-DscResource
-ModuleName
xPsDesiredStateConfiguration

Import-DscResource
-ModuleName
PsDesiredStateConfiguration

Node
$computerName {

WindowsFeature
DSCServiceFeature {

Ensure =
“Present”

Name =
“DSC-Service”

}

xDscWebService
PSDSCPullServer {

Ensure =
“Present”

EndpointName =
“PSDSCPullServer”

Port =
8080

PhysicalPath =
“$env:SystemDrive\inetpub\wwwroot\PSDSCPullServer”

CertificateThumbPrint =
“AllowUnencryptedTraffic”

ModulePath =
“$env:ProgramFiles\WindowsPowershell\DscService\Modules”

ConfigurationPath =
“$env:PROGRAMFILES\WindowsPowershell\DscService\Configuration”

State =
“Started”

DependsOn =
“[WindowsFeature]DSCServiceFeature”

UseSecurityBestPractices =
$false

}

File
RegistrationKeyFile

{

Ensure =
‘present’

Type =
‘File’

DestinationPath =
“$env:ProgramFiles\WindowsPowershell\DscService\RegistrationKeys.txt”

Contents =
$RegistrationKey

}

}

}

CreatePullServer
-RegistrationKey
e7336293-4341-46c1-b18e-f5420d105b48

Start-DscConfiguration
.\CreatePullServer
–wait

Sizlere betiği kısaca anlatmak isterim;

Klasik bir konfigürasyon tag’i açarak bu işlemin hangi cihaz üzerinde kullanılacağının ve bu işlem sırasında kullanılacak değişkenlerin tanımını aşağıdaki bölümde yapıyoruz. Biz bu betiği pull-server.ekol.local sunucusu üzerinde çalıştıracağız. Yani yapılan konfigürasyon localhost olarak adlandırmış olduğum gibi kendi üzerine uygulanacaktır. CreatePullServer konfigürasyon için kullanmış olduğum isimdir. Bu özgür hür iradeyle belirlenen bir cümleden başka bir şey değildir. Burada asıl önemli olan durum ise RegistrarionKey olarak vermek zorunda olduğum bir değişken tanımlamamız. Nedir bu registration key ?

Aslında bakarsanız herhangi bir sayı ve harf’den oluşan dizidir. Ancak Client Node olan sunucu admin’e bağlanıp kendine ait konfigürasyonu kontrol etmek için bu key’e sahip olmak durumundadır. Yani admin ile client birbirlerini bu key sayesinde doğrulamaktadırlar. Özellikle Http olarak konuşan bir sistem yaratıldığında key’in önemi daha çok artıyor. Boş ve geçersiz bir parametre olmaması konusunda kesin bir kural koyarak registration key’in verilmesini zorluyorum.

Configuration
CreatePullServer {

param

(

[string[]]$computerName =
‘localhost’,

[parameter(Mandatory)]

[ValidateNotNullOrEmpty()]

[string]
$RegistrationKey

)

İşlemin devamında Powershell Gallery üzerinden çekeceğim bir module var. Bu module öncesinde sisteme kuruldu. Kurulum işlemi için basit bir işlem yapmanız yeterli. ( Install-module
-name
xPsDesiredStateConfiguration )

Kurmuş olduğum bu modülü ikinci aşamada betik’e dahil ediyorum. Bu module Pull-Server yaratmak için Microsoft tarafından yaratılmış hazır bir module olup işlemleri cidden çok hızlandırmaktadır.

Import-DscResource
-ModuleName
xPsDesiredStateConfiguration

Import-DscResource
-ModuleName
PsDesiredStateConfiguration

Node
$computerName {

WindowsFeature
DSCServiceFeature {

Ensure =
“Present”

Name =
“DSC-Service”

}

Module’leri dahil ettikten sonra DSC-Service kurulu değilse bu servisin kurulumu yapıyorum. Kurulum sonrasında gerekli olan konfigürasyon işlemlerine başlıyorum.

xDscWebService
PSDSCPullServer {

Ensure =
“Present”

EndpointName =
“PSDSCPullServer”

Port =
8080

PhysicalPath =
“$env:SystemDrive\inetpub\wwwroot\PSDSCPullServer”

CertificateThumbPrint =
“AllowUnencryptedTraffic”

ModulePath =
“$env:ProgramFiles\WindowsPowershell\DscService\Modules”

ConfigurationPath =
“$env:PROGRAMFILES\WindowsPowershell\DscService\Configuration”

State =
“Started”

DependsOn =
“[WindowsFeature]DSCServiceFeature”

UseSecurityBestPractices =
$false

}

Yukarıdaki parça, pull server’ı pull server yapan kısım diyebiliriz. Ne yapıyoruz burada;

Aslında bir adet Web sitesi yaratıyoruz. Root Path’i inetpub altında wwwroot altında olan bir web-sitesi. Bu sayfa 8080 portu üzerinden yayın yapacak. Sertifikaya zorlamayacak. Configurasyonlarını DscService altında bulunan Configuration içerisinde saklayacak.

File
RegistrationKeyFile

{

Ensure =
‘present’

Type =
‘File’

DestinationPath =
“$env:ProgramFiles\WindowsPowershell\DscService\RegistrationKeys.txt”

Contents =
$RegistrationKey

}

Konfigürasyonla beraber vereceğimiz bir Registaration Key’de gidip DscService altındaki text dosyasına yazılsın diyoruz. Client istek yaptığında sunucumuz gidip bu text dosyasını kontrol edecek. Microsoft bu dosyanın çok iyi bir şekilde korunmasını önermektedir. Sebebi bu registration key’e sahip olan her client sunucular için oluşturulan konfigürasyonu kolayca elde edebilir olmalarıdır. Peki powershell üzerinde bu key nasıl yaratılır. İşlem çok basit şekilde uygulanabiliyor;

Resim-14

Şeklinde ürettirebilmemiz mümkün her seferinde başka bir key veren bir mekanizmadır. Bu işlem ardından gerekli olan konfigürsayonu çalıştırıyoruz ve sunucumuz artık Pull-Server sıfatına kavuşuyor. Bu işlemin ardından client node üzerine vereceğimiz direktifleri oluşturan bir konfigürasyon daha yaratalım.

Configuration
webservice

{

param ($MachineName)

Node
$MachineName

{

WindowsFeature
IIS

{

Ensure =
“Present”

Name =
“Web-Server”

}

WindowsFeature
ASP

{

Ensure =
“Present”

Name =
“web-Asp-Net45”

}

}

}

webservice
-MachineName
localhost

Mesela webservice adında bir görev oluşturalım. Client bu konfigürasyonu çekip kendi üzerinde uygulayacak. Bu yüzden localhost olarak isimlendirmemiz yanlış olmaz. Yarın bir gün başka sunucularda bunu uygulatmak istediğimizde localhost parametresi sayesinde sorun yaşamayacağız bu da bizim karımıza olacaktır. IIS kur diyorum ve Asp 4.5 kurulsun görevini veriyorum. Yukarıdaki pull server konfigürasyonunda şöyle bir ibare var,

ConfigurationPath =
“$env:PROGRAMFILES\WindowsPowershell\DscService\Configuration”

Bu şu anlama gelmektedir. Eğer ben bu client’a yazmış olduğum konfigürasyonu uygulamak istiyorsam bunu WindowsPowershell\DscService altında yer alan Configuration dizini içerisine koymam gerekiyor. Webservice –MachineName localhost komutuyla üretiyorum. Ve bunu gerekli dizine taşıyorum. Ancak bu yeterli değil bu oluşturduğum konfigürasyon için bir checksum oluşturmam gerekiyor. Peki bu ne anlama geliyor.

New-DscChecksum
-Path
“webservice.mof”

Komutunu kullanarak bir checksum oluşturmam gerekiyor bu işlem yaratmış olduğum konfigürasyonun sağlıklı bir konfigürasyon olup olmadığını kontrol ediyor. Bu işlem yapılmadan yani admin tarafından onaylanmamış bir konfigürasyon client tarafından uygulamaz. Bu işlemi de yapıp gerekli yere taşımasını gerçekleştiriyorum.

Resim-15

Client üzerine uygulanmaya hazır webservice.mof ve bu mof dosyamın bir checksum’u mevcut. İçeriği de göstermek isterim. Merak edenleriniz olabilir.

Resim-16

Mof dosyasının içeriğide ise şu şekilde;

Resim-17

Bu işlemin ardından artık client için gerekli olan konfigürasyonu yaratma vaktimiz geldi. Client Node üzerinde yapacağımız işlem ile onu pull işlemi yapacak ve konfigürasyon olup olmadığını sık sık kontrol edecek bir hale dönüştüreceğiz.

Pull-Client Ayarlaması Hk.

[DscLocalConfigurationManager()]

Configuration
PullClientConfigID

{

node
localhost

{

Settings

{

RefreshMode =
‘pull’

RefreshFrequencyMins =
30

RebootNodeIfNeeded =
$true

ConfigurationMode =
“ApplyAndAutoCorrect”

}

ConfigurationRepositoryWeb
PullSrv

{

ServerURL =
‘http://pull-admin.ekol.local:8080/PSDSCPullServer.svc’

RegistrationKey =
‘e7336293-4341-46c1-b18e-f5420d105b48’

ConfigurationNames = @(‘WebService’)

AllowUnsecureConnection =
$true

}

}

}

PullClientConfigID

Admin node’a göre çok daha sade bir konfigürasyona sahiptir. Burada yaptığımız işlem Client’ımızın artıl pull moduna sahip 30 dakikada bir vermiş olduğumuz web sitesi üzerinden @(‘webservice’) adına sahip konfigürasyonu çekmesi şeklindedir. Her 30 dakikada bir kendi üzerinde olan konfigürasyon ile sunucu tarafındaki konfigürasyonu karşılaştırarak var ise değişiklikleri uygulamasıdır. ConfigurationMode =
“ApplyAndAutoCorrect” parametresi ile uygulamsına izin veriyoruz. Eğer bu işlem reboot gerektirerse atması ya da atmaması konusunda da izin tanımlayabiliyoruz. Özellikle ServerURL aşamasıyla hangi adrese gideceğini ve bu adrese kendini doğrulatmak için kullanacağı RegistrationKey dosyasını vermemiz gerekmektedir. Http konuştuğumuz için AllowUnSecureConnection parametresini $true veriyorum.

Bu işlemin ardından oluşturduğumuz meta-mof dosyamızı çalıştırarak gerekli konfigürasyonu almasını ve uygulamasını sağlıyoruz.

Set-DscLocalConfigurationManager
.\PullClientConfigID

Komutu ile dürtüyorum. Kısa bir beklemeden sonra,

PS C:\dsc> Get-DscConfigurationStatus

Status StartDate Type Mode RebootRequested NumberOfResources

—— ——— —- —- ————— —————–

Success 12/24/2017 3:35:20 PM Consistency Pull False 2

PS C:\dsc>

İşlemin başarıyla gerçekleştiği cevabını Get-DscConfigurationStatus komutu ile alıyorum. Gerekli kurulumları kontrol ettiğimde ise;

Asp 4.5 ve IIS için gerekli servislerin kurulduğu görüyorum.

Resim-18

Resim-19

Böylelikle gerekli Pull Server – Client ilişkisini yaratmış olduk.

Bu konuyla ilgili sorularınızı  alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.

Referanslar

www.mshowto.org

TAGs: Poweshell DSC, Powersell DSC nedir, Powershell, DSC,DSC nedir,Desired State Configuration nedir,Desired State Configuration,Chef,Puppet