Azure Otomasyonu için PowerShell İş Akışını Öğrenin
Azure Otomasyonu runbook'ları Windows PowerShell iş akışları, Windows Workflow Foundation kullanan Windows PowerShell betikleri olarak uygulanır. Bir iş akışı, birden fazla cihazda veya yönetilen düğümde uzun süre çalışan görevler gerçekleştiren veya birden fazla adımın eşgüdümünü gerektiren programlı ve bağlı adımlardan oluşan bir dizidir.
Bir iş akışı Windows PowerShell söz dizimi ile yazılmış ve Windows PowerShell tarafından başlatılmış olsa da, Windows Workflow Foundation tarafından işlenir. Bir iş akışının normal bir betik üzerindeki avantajları, bir eylemin birden çok cihaza karşı eşzamanlı performansını ve hatalardan otomatik kurtarmayı içerir.
Not
Bu makale PowerShell 5.1 için geçerlidir; PowerShell 7.1 (önizleme) ve PowerShell 7.2 (önizleme) iş akışlarını desteklemez. PowerShell İş Akışı betiği, Windows PowerShell betiğine çok benzer, ancak yeni bir kullanıcı için kafa karıştırıcı olabilecek bazı önemli farklılıklara sahiptir. Bu nedenle, runbook'larınızı yalnızca denetim noktalarını kullanmanız gerekiyorsa PowerShell İş Akışı'nı kullanarak yazmanızı öneririz.
Bu makaledeki konuların tüm ayrıntıları için bkz . Windows PowerShell İş Akışı ile Çalışmaya Başlama.
İş Akışı anahtar sözcüğünü kullanma
PowerShell betiğini PowerShell iş akışına dönüştürmenin ilk adımı, bunu anahtar sözcüğüyle Workflow
içine almaktır. bir iş akışı anahtar sözcüğüyle Workflow
başlar ve ardından betiğin gövdesi küme ayraçları içine alınır. İş akışının adı, aşağıdaki söz diziminde gösterildiği gibi anahtar sözcüğünü izler Workflow
:
Workflow Test-Workflow
{
<Commands>
}
İş akışının adı Otomasyon runbook'unun adıyla eşleşmelidir. Runbook içeri aktarılıyorsa, dosya adı iş akışı adıyla eşleşmeli ve .ps1 ile bitmelidir.
İş akışına parametre eklemek için anahtar sözcüğünü Param
bir betikte olduğu gibi kullanın.
PowerShell İş Akışı kodu ile PowerShell betik kodu arasındaki farkları öğrenin
PowerShell İş Akışı kodu, birkaç önemli değişiklik dışında PowerShell betik koduyla neredeyse aynı görünür. Aşağıdaki bölümlerde, iş akışında çalışması için PowerShell betiğinde yapmanız gereken değişiklikler açıklanmaktadır.
Aktiviteler
Etkinlik, bir dizide gerçekleştirilen bir iş akışındaki belirli bir görevdir. Windows PowerShell Workflow birçok Windows PowerShell cmdlet'ini bir iş akışı içinde çalıştıklarında otomatik olarak etkinliklere dönüştürür. Runbook'unuzda bu cmdlet'lerden birini belirttiğinizde, ilgili etkinlik Windows Workflow Foundation tarafından çalıştırılır.
Bir cmdlet'in karşılık gelen etkinliği yoksa, Windows PowerShell İş Akışı cmdlet'i bir InlineScript etkinliğinde otomatik olarak çalıştırır. Bazı cmdlet'ler dışlanır ve bir InlineScript bloğuna açıkça eklemediğiniz sürece iş akışında kullanılamaz. Daha fazla bilgi için bkz . Betik İş Akışlarında Etkinlikleri Kullanma.
İş akışı etkinlikleri çalışmalarını yapılandıran ortak parametreler kümesini paylaşır. bkz. about_WorkflowCommonParameters.
Konumsal parametreler
Bir iş akışındaki etkinlikler ve cmdlet'lerle konumsal parametreleri kullanamazsınız. Bu nedenle parametre adlarını kullanmanız gerekir. Çalışan tüm hizmetleri alan aşağıdaki kodu göz önünde bulundurun:
Get-Service | Where-Object {$_.Status -eq "Running"}
Bu kodu bir iş akışında çalıştırmaya çalışırsanız, bu sorunu düzeltmek için aşağıdaki örnekte olduğu gibi parametre adını girin gibi Parameter set cannot be resolved using the specified named parameters.
bir ileti alırsınız:
Workflow Get-RunningServices
{
Get-Service | Where-Object -FilterScript {$_.Status -eq "Running"}
}
Seri durumdan çıkarılmış nesneler
İş akışlarındaki nesneler seri durumdan çıkarılır, yani özellikleri hala kullanılabilir ancak yöntemleri kullanılamaz. Örneğin, nesnesinin yöntemini Service
kullanarak Stop
bir hizmeti durduran aşağıdaki PowerShell kodunu göz önünde bulundurun.
$Service = Get-Service -Name MyService
$Service.Stop()
Bunu bir iş akışında çalıştırmayı denerseniz şunu belirten bir hata alırsınız: Method invocation is not supported in a Windows PowerShell Workflow.
Bir seçenek, bu iki kod satırı bir InlineScript bloğuna sarmalamadır. Bu durumda, Service
blok içindeki bir hizmet nesnesini temsil eder.
Workflow Stop-Service
{
InlineScript {
$Service = Get-Service -Name MyService
$Service.Stop()
}
}
Başka bir seçenek, varsa yöntemiyle aynı işlevselliğe sahip başka bir cmdlet kullanmaktır. Örneğimizde Stop-Service
, cmdlet yöntemiyle aynı işlevselliği Stop
sağlar ve bir iş akışı için aşağıdaki kodu kullanabilirsiniz.
Workflow Stop-MyService
{
$Service = Get-Service -Name MyService
Stop-Service -Name $Service.Name
}
InlineScript kullanma
EtkinlikInlineScript
, PowerShell iş akışı yerine geleneksel PowerShell betiği olarak bir veya daha fazla komut çalıştırmanız gerektiğinde kullanışlıdır. Bir iş akışındaki komutlar işlenmek üzere Windows Workflow Foundation'a gönderilirken, bir InlineScript bloğundaki komutlar Windows PowerShell tarafından işlenir.
InlineScript aşağıda gösterilen aşağıdaki söz dizimini kullanır.
InlineScript
{
<Script Block>
} <Common Parameters>
Çıkışı bir değişkene atayarak InlineScript'ten çıkış döndürebilirsiniz. Aşağıdaki örnekte bir hizmet durdurulur ve hizmet adı çıkışını alır.
Workflow Stop-MyService
{
$Output = InlineScript {
$Service = Get-Service -Name MyService
$Service.Stop()
$Service
}
$Output.Name
}
Bir InlineScript bloğuna değer geçirebilirsiniz, ancak $Using kapsam değiştiricisini kullanmanız gerekir. Aşağıdaki örnek, hizmet adının bir değişken tarafından sağlanması dışında önceki örnekle aynıdır.
Workflow Stop-MyService
{
$ServiceName = "MyService"
$Output = InlineScript {
$Service = Get-Service -Name $Using:ServiceName
$Service.Stop()
$Service
}
$Output.Name
}
InlineScript etkinlikleri belirli iş akışlarında kritik öneme sahiptir ancak iş akışı yapılarını desteklemez. Bunları yalnızca aşağıdaki nedenlerle gerekli olduğunda kullanmalısınız:
- Bir InlineScript bloğunun içinde denetim noktaları kullanamazsınız. Blok içinde bir hata oluşursa, bloğun başından devam etmesi gerekir.
- InlineScript bloğunun içinde paralel yürütme kullanamazsınız.
- InlineScript, Windows PowerShell oturumunu InlineScript bloğunun tüm uzunluğu boyunca tuttuğundan iş akışının ölçeklenebilirliğini etkiler.
InlineScript kullanma hakkında daha fazla bilgi için bkz . İş Akışında Windows PowerShell Komutlarını Çalıştırma ve about_InlineScript.
Paralel işleme kullanma
Windows PowerShell İş Akışlarının bir avantajı da bir komutlar kümesini tipik bir betikteki gibi sırayla yürütmek yerine paralel olarak gerçekleştirebilmesidir.
Anahtar sözcüğünü Parallel
kullanarak eşzamanlı olarak çalışan birden çok komut içeren bir betik bloğu oluşturabilirsiniz. Bu, aşağıda gösterilen aşağıdaki söz dizimini kullanır. Bu durumda, Activity1 ve Activity2 aynı anda başlar. Activity3 yalnızca Hem Activity1 hem de Activity2 tamamlandıktan sonra başlar.
Parallel
{
<Activity1>
<Activity2>
}
<Activity3>
Örneğin, bir ağ hedefine birden çok dosya kopyalayan aşağıdaki PowerShell komutlarını göz önünde bulundurun. Bu komutlar sıralı olarak çalıştırılır, böylece bir dosya sonraki başlatılmadan önce kopyalanmayı bitirmelidir.
Copy-Item -Path C:\LocalPath\File1.txt -Destination \\NetworkPath\File1.txt
Copy-Item -Path C:\LocalPath\File2.txt -Destination \\NetworkPath\File2.txt
Copy-Item -Path C:\LocalPath\File3.txt -Destination \\NetworkPath\File3.txt
Aşağıdaki iş akışı aynı komutları paralel olarak çalıştırarak tümünün aynı anda kopyalamaya başlamasını sağlar. Yalnızca hepsi kopyalandıktan sonra görüntülenen tamamlama iletisi görüntülenir.
Workflow Copy-Files
{
Parallel
{
Copy-Item -Path "C:\LocalPath\File1.txt" -Destination "\\NetworkPath"
Copy-Item -Path "C:\LocalPath\File2.txt" -Destination "\\NetworkPath"
Copy-Item -Path "C:\LocalPath\File3.txt" -Destination "\\NetworkPath"
}
Write-Output "Files copied."
}
Bir koleksiyondaki her öğe için komutları eşzamanlı olarak işlemek için ForEach -Parallel
yapısını kullanabilirsiniz. Betik bloğundaki komutlar sırayla yürütülürken koleksiyondaki öğeler paralel olarak işlenir. Bu işlem aşağıda gösterilen aşağıdaki söz dizimini kullanır. Bu durumda, Etkinlik1 koleksiyondaki tüm öğeler için aynı anda başlar. Her öğe için Activity2, Activity1 tamamlandıktan sonra başlar. Activity3 yalnızca tüm öğeler için hem Activity1 hem de Activity2 tamamlandıktan sonra başlar. Paralelliği sınırlamak için parametresini kullanırız ThrottleLimit
. Çok yüksek bir ThrottleLimit
sorunlara neden olabilir. parametresi için ThrottleLimit
ideal değer ortamınızdaki birçok faktöre bağlıdır. Düşük bir değerle başlayın ve özel durumunuz için uygun bir değer bulana kadar farklı değerleri artırmayı deneyin.
ForEach -Parallel -ThrottleLimit 10 ($<item> in $<collection>)
{
<Activity1>
<Activity2>
}
<Activity3>
Aşağıdaki örnek, dosyaları paralel olarak kopyalayan önceki örneğe benzer. Bu durumda, kopyalandıktan sonra her dosya için bir ileti görüntülenir. Yalnızca tümü kopyalandıktan sonra görüntülenen son tamamlama iletisi görüntülenir.
Workflow Copy-Files
{
$files = @("C:\LocalPath\File1.txt","C:\LocalPath\File2.txt","C:\LocalPath\File3.txt")
ForEach -Parallel -ThrottleLimit 10 ($File in $Files)
{
Copy-Item -Path $File -Destination \\NetworkPath
Write-Output "$File copied."
}
Write-Output "All files copied."
}
Not
Güvenilir olmayan sonuçlar vermek üzere gösterildiğinden alt runbook'ları paralel olarak çalıştırmanızı önermeyiz. Alt runbook'un çıkışı bazen görünmez ve bir alt runbook'taki ayarlar diğer paralel alt runbook'ları etkileyebilir. , WarningPreference
ve diğerleri gibi VerbosePreference
değişkenler alt runbook'lara yayılmayabilir. Alt runbook bu değerleri değiştirirse, çağrıdan sonra düzgün bir şekilde geri yüklenmeyebilir.
İş akışında denetim noktalarını kullanma
Denetim noktası, değişkenlerin geçerli değerlerini ve bu noktaya oluşturulan herhangi bir çıkışı içeren iş akışının geçerli durumunun anlık görüntüsüdür. Bir iş akışı hatayla biterse veya askıya alınırsa, bir sonraki çalıştırmada en baştan başlamak yerine son denetim noktasından başlar.
Bir iş akışında etkinliği olan Checkpoint-Workflow
bir denetim noktası ayarlayabilirsiniz. Azure Otomasyonu, diğer runbook'ların çalışmasına izin vermek için üç saat boyunca çalışan tüm runbook'ların kaldırıldığı fair share adlı bir özelliğe sahiptir. Sonunda, kaldırılan runbook yeniden yüklenir. Bu durumda, runbook'ta alınan son denetim noktasından yürütmeye devam eder.
Runbook'un sonunda tamamlanmasını garanti etmek için, üç saatten kısa bir süre boyunca çalışan aralıklara denetim noktaları eklemeniz gerekir. Her çalıştırma sırasında yeni bir denetim noktası eklenirse ve runbook bir hata nedeniyle üç saat sonra çıkarılırsa, runbook süresiz olarak sürdürülür.
Aşağıdaki örnekte, Activity2'nin ardından bir özel durum oluşur ve bu da iş akışının sona ermesini sağlar. İş akışı yeniden çalıştırıldığında, bu etkinlik son denetim noktası kümesinden hemen sonra olduğundan Activity2 çalıştırılarak başlar.
<Activity1>
Checkpoint-Workflow
<Activity2>
<Exception>
<Activity3>
Özel duruma eğilimli olabilecek etkinliklerden sonra iş akışında denetim noktaları ayarlayın ve iş akışı sürdürülürse tekrarlanmaması gerekir. Örneğin, iş akışınız bir sanal makine oluşturabilir. Sanal makineyi oluşturmak için komutlar öncesinde ve sonrasında bir denetim noktası ayarlayabilirsiniz. Oluşturma işlemi başarısız olursa, iş akışı yeniden başlatılırsa komutlar yinelenir. Oluşturma başarılı olduktan sonra iş akışı başarısız olursa, iş akışı sürdürülürken sanal makine yeniden oluşturulmaz.
Aşağıdaki örnek birden çok dosyayı bir ağ konumuna kopyalar ve her dosyadan sonra bir denetim noktası ayarlar. Ağ konumu kaybolursa iş akışı hatayla biter. Yeniden başlatıldığında, son denetim noktasında devam eder. Yalnızca zaten kopyalanmış dosyalar atlanır.
Workflow Copy-Files
{
$files = @("C:\LocalPath\File1.txt","C:\LocalPath\File2.txt","C:\LocalPath\File3.txt")
ForEach ($File in $Files)
{
Copy-Item -Path $File -Destination \\NetworkPath
Write-Output "$File copied."
Checkpoint-Workflow
}
Write-Output "All files copied."
}
Kullanıcı adı kimlik bilgileri Askıya Alma-İş Akışı etkinliğini çağırdıktan sonra veya son denetim noktasından sonra kalıcı olmadığından, kimlik bilgilerini null olarak ayarlamanız ve sonra veya denetim noktası çağrıldıktan sonra Suspend-Workflow
varlık deposundan yeniden almanız gerekir. Aksi takdirde aşağıdaki hata iletisini alabilirsiniz: The workflow job cannot be resumed, either because persistence data could not be saved completely, or saved persistence data has been corrupted. You must restart the workflow.
Aşağıdaki kod, PowerShell İş Akışı runbook'larınızda bu durumun nasıl işleneceğini gösterir.
workflow CreateTestVms
{
$Cred = Get-AzAutomationCredential -Name "MyCredential"
$null = Connect-AzAccount -Credential $Cred
$VmsToCreate = Get-AzAutomationVariable -Name "VmsToCreate"
foreach ($VmName in $VmsToCreate)
{
# Do work first to create the VM (code not shown)
# Now add the VM
New-AzVM -VM $Vm -Location "WestUs" -ResourceGroupName "ResourceGroup01"
# Checkpoint so that VM creation is not repeated if workflow suspends
$Cred = $null
Checkpoint-Workflow
$Cred = Get-AzAutomationCredential -Name "MyCredential"
$null = Connect-AzAccount -Credential $Cred
}
}
Not
Grafik olmayan PowerShell runbook'ları Add-AzAccount
için ve Add-AzureRMAccount
Connect-AzAccount için diğer adlardır. Bu cmdlet'leri kullanabilir veya Otomasyon hesabınızdaki modüllerinizi en son sürümlere güncelleştirebilirsiniz. Yeni bir Otomasyon hesabı oluşturmuş olsanız bile modüllerinizi güncelleştirmeniz gerekebilir.
Denetim noktalarıyla ilgili daha fazla bilgi için bkz. Betik İş Akışına Denetim Noktaları Ekleme.
Sonraki adımlar
- PowerShell İş Akışı runbook'ları hakkında bilgi edinmek için bkz . Öğretici: PowerShell İş Akışı runbook'u oluşturma.