Azure Otomasyonu için PowerShell İş Akışı'Azure Otomasyonu
Azure Otomasyonu runbook'lar, Windows PowerShell workflow Foundation Windows PowerShell betikleri Windows uygulanır. İş akışı uzun süre çalışan görevleri gerçekleştiren veya birden çok aygıttaki veya yönetilen düğümlerdeki birden çok adımın koordinasyonu için gereken programlanmış, bağlantılı adımlardan oluşan bir dizidir.
Bir iş akışı, Windows PowerShell söz dizimi ile yazıldığı ve Windows PowerShell başlatıldığı sırada, Windows Workflow Foundation tarafından işlenir. Bir iş akışının normal bir betik üzerinde 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) iş akışlarını desteklemez. PowerShell İş Akışı betiği, bir Windows PowerShell betiğine çok benzer, ancak yeni bir kullanıcı için kafa karıştırıcı olan bazı önemli farklılıklar vardır. Bu nedenle, runbook'larınızı yalnızca denetim noktalarını kullanmak zorundaysanız PowerShell İş Akışı kullanarak yazmanızı öneririz.
Bu makaledeki konuların tüm ayrıntıları için bkz. Başlarken İş Akışı ile Windows PowerShell.
İş Akışı anahtar sözcüğünü kullanma
PowerShell betiklerini Bir PowerShell iş akışına dönüştürmenin ilk adımı, bu betiği anahtar sözcüğüyle birlikte içine Workflow alır. İş akışı anahtar Workflow sözcüğüyle başlar ve ardından küme ayraçları içine alınmış betiğin gövdesiyle başlar. İş akışının adı, aşağıdaki söz Workflow dizimsinde gösterildiği gibi anahtar sözcüğünü izler:
Workflow Test-Workflow
{
<Commands>
}
İş akışının adı Otomasyon runbook'un adıyla eşleşmeli. Runbook içe aktarılmışsa, dosya adı iş akışı adıyla eşleşmeli ve dosya adı ile .ps1.
İş akışına parametre eklemek için, bir Param betikte olduğu gibi anahtar sözcüğünü 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ıdır. Aşağıdaki bölümlerde, bir iş akışında çalışması için Bir PowerShell betiğinde yapmak için gereken değişiklikler açıklanmaktadır.
Etkinlikler
Etkinlik, bir iş akışında sıralı olarak gerçekleştirilen 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'uzda bu cmdlet'lerden birini belirttiğinizde, ilgili etkinlik Windows Workflow Foundation tarafından çalıştırıldı.
Bir cmdlet'e karşılık gelen bir etkinlik yoksa, Windows PowerShell İş Akışı cmdlet'i bir InlineScript etkinliğinde otomatik olarak çalıştırır. Bazı cmdlet'ler hariç tutularak bir InlineScript bloğuna açıkça dahil olmadığınız sürece bir 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
Konumsal parametreleri bir iş akışında etkinlikler ve cmdlet'lerle birlikte kullanaabilirsiniz. Bu nedenle, parametre adlarını kullan gerekir. Tüm çalışan hizmetleri alan aşağıdaki kodu düşünün:
Get-Service | Where-Object {$_.Status -eq "Running"}
Bu kodu bir iş akışında çalıştırmayı denersanız, aşağıdaki örnekte olduğu gibi Bu sorunu düzeltmek için, parametre adını belirtin 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"}
}
Deserialized objects
İş akışlarında nesneler, özelliklerinin hala kullanılabilir olduğu, ancak yöntemlerinin kullanılabilir olmadığını ifade eder. Örneğin, nesnesinin yöntemini kullanarak bir hizmeti durduran aşağıdaki PowerShell Stop kodunu göz önünde Service bulundurabilirsiniz.
$Service = Get-Service -Name MyService
$Service.Stop()
Bunu bir iş akışında çalıştırmayı denersiniz, şöyle bir hata alırsınız: Method invocation is not supported in a Windows PowerShell Workflow.
Seçeneklerden biri, bu iki kod satırı bir InlineScript bloğunda sarmaktır. Bu durumda, Service blok içindeki bir hizmet nesnesini temsil eder.
Workflow Stop-Service
{
InlineScript {
$Service = Get-Service -Name MyService
$Service.Stop()
}
}
Bir diğer seçenek de, varsa yöntemiyle aynı işlevselliğe sahip başka bir cmdlet kullanmaktır. Bizim örneğimizde, cmdlet yöntemiyle aynı işlevselliği sağlar ve Stop-Service bir iş akışı için aşağıdaki kodu Stop kullanabilirsiniz.
Workflow Stop-MyService
{
$Service = Get-Service -Name MyService
Stop-Service -Name $Service.Name
}
InlineScript kullanma
Etkinlik, InlineScript PowerShell iş akışı yerine geleneksel PowerShell betiği olarak bir veya daha fazla komut çalıştırmanız gerekirse 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 söz dizimlerini kullanır.
InlineScript
{
<Script Block>
} <Common Parameters>
Bir inlineScript'in çıktısını değişkene ataarak geri dönerek. Aşağıdaki örnek bir hizmeti durdurur ve ardından hizmet adını çıkış olarak belirtir.
Workflow Stop-MyService
{
$Output = InlineScript {
$Service = Get-Service -Name MyService
$Service.Stop()
$Service
}
$Output.Name
}
Değerleri bir InlineScript bloğuna geçebilirsiniz, ancak kapsam değiştiricisini $Using gerekir. Aşağıdaki örnek, hizmet adının bir değişken tarafından sağlanıyor olması 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 sahip olabilir ancak iş akışı yapılarını desteklemez. Bunları yalnızca aşağıdaki nedenlerle gerekli olduğunda kullanacağız:
- Denetim noktalarını bir InlineScript bloğu içinde kullanasiniz. Blok içinde bir hata oluşursa, bloğun başından devam etmesi gerekir.
- Bir InlineScript bloğu içinde paralel yürütmeyi kullanasiniz.
- InlineScript, InlineScript bloğu uzunluğu boyunca Windows PowerShell oturumda yer alan iş akışının ölçeklenebilirliğini etkiler.
InlineScript kullanma hakkında daha fazla bilgi için bkz. Windows PowerShell komutlarını bir İş Akışında çalıştırma ve about_InlineScript.
Paralel işlemeyi 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.
Eşzamanlı olarak çalıştıran Parallel birden çok komutla betik bloğu oluşturmak için anahtar sözcüğünü kullanabilirsiniz. Aşağıda gösterilen söz dizimi kullanılır. Bu durumda, Activity1 ve Activity2 aynı anda başlar. Activity3 yalnızca Activity1 ve Activity2 tamamlandıktan sonra başlar.
Parallel
{
<Activity1>
<Activity2>
}
<Activity3>
Örneğin, bir ağ hedefine birden çok dosya kopyaleyen aşağıdaki PowerShell komutlarını göz önünde bulundurabilirsiniz. Sonraki başlamadan önce bir dosyanın kopyalamayı bitirmesi için bu komutlar sırayla çalıştırın.
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 aynı anda kopyalamaya başlamalarını sağlar. Yalnızca hepsi kopyalandıktan sonra görüntülenen tamamlama iletisidir.
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 dizimlerini kullanır. Bu durumda Activity1, koleksiyondaki tüm öğeler için aynı anda başlatılır. Her öğe için Activity2, Activity1 tamamlandıktan sonra başlar. Activity3 yalnızca hem Activity1 hem de Activity2 tüm öğeler için tamamlandıktan sonra başlar. Paralelliği ThrottleLimit sınırlamak için parametresini kullanıruz. çok yüksek bir ThrottleLimit soruna neden olabilir. parametresi için ideal ThrottleLimit değer, ortamınız içinde birçok faktöre bağlıdır. Düşük bir değerle işe başlar ve belirli bir durum için uygun olan bir değer bulana kadar farklı artan değerler deneyin.
ForEach -Parallel -ThrottleLimit 10 ($<item> in $<collection>)
{
<Activity1>
<Activity2>
}
<Activity3>
Aşağıdaki örnek, dosyaları paralel olarak kopyalayıp önceki örnekle benzerdir. Bu durumda, kopyalanan her dosya için bir ileti görüntülenir. Yalnızca hepsi kopyalandıktan sonra görüntülenen son tamamlanma iletisidir.
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
Bu, güvenilir olmayan sonuçlar vermek için gösterildiği için alt runbook'ların paralel olarak çalıştırılmalarını önerilmez. Alt runbook'un çıktısı bazen gösterlanmaz ve bir alt runbook'ta ayarlar diğer paralel alt runbook'ları etkileyebilir. VerbosePreference, ve WarningPreference gibi değişkenler alt runbook'lara yayılmayabilir. Alt runbook bu değerleri değiştirirse, çağrı yapıldıktan sonra düzgün geri yüklenebilirler.
İş akışında denetim noktalarını kullanma
Denetim noktası, değişkenler için geçerli değerleri ve bu noktaya kadar oluşturulan tüm çıkışları içeren iş akışının geçerli durumunun anlık görüntüsü. Bir iş akışı hatayla sona erer veya askıya alınırsa, başlangıçtan başlayarak değil, bir sonraki çalışma noktasından başlar.
Etkinliği olan bir iş akışında denetim noktası Checkpoint-Workflow ayarlayın. Azure Otomasyonu, diğer runbook'larınçalışmasına izin vermek için üç saat çalışan tüm runbook'ların kaldırılmış olduğu, fair share adlı bir özelliği vardır. Sonunda, kaldırılan runbook yeniden yüklenir. Olduğunda, runbook'ta alınan son denetim noktasından yürütmeyi sürdürür.
Runbook'un sonunda tamamlandıktan emin olmak için üç saatten az süreyle çalıştıracak aralıklarla denetim noktaları eklemeniz gerekir. Her çalıştırma sırasında yeni bir denetim noktası eklenirse ve bir hata nedeniyle üç saat sonra runbook çıkarıldıktan sonra runbook süresiz olarak devam eder.
Aşağıdaki örnekte, Activity2'den sonra bir özel durum oluşur ve iş akışının sona erer. İş akışı yeniden çalıştır başlatıldığında Activity2 çalıştırarak başlar çünkü bu etkinlik son denetim noktası ayarlamadan hemen sonradır.
<Activity1>
Checkpoint-Workflow
<Activity2>
<Exception>
<Activity3>
Bir iş akışındaki denetim noktalarını özel durumlara açık olan ve iş akışı devam ettirilene kadar tekrarlanmaz etkinliklerinden sonra ayarlayın. Ö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ı oluşturabilirsiniz. Oluşturma başarısız olursa, iş akışı yeniden başlatılsa komutlar yinelenir. Oluşturma başarılı olduktan sonra iş akışı başarısız olursa, iş akışı sürdürüldüğünde sanal makine yeniden oluşturulmaz.
Aşağıdaki örnekte birden çok dosya bir ağ konumuna kopyalanır ve her dosyadan sonra bir denetim noktası ayarlanır. Ağ konumu kaybolursa, iş akışı hata ile sona erer. Yeniden başlatıldığında, son denetim noktasında sürdürülür. Yalnızca önceden 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."
}
Askıya alma Iş akışı etkinliğini veya son kontrol noktasından sonra Kullanıcı adı kimlik bilgileri kalıcı olmadığından, kimlik bilgilerini null olarak ayarlamanız ve ardından Suspend-Workflow veya denetim noktası çağrıldıktan sonra bunları 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 aynı kodda PowerShell Iş akışı runbook 'larınızda bu durumun nasıl işleneceği gösterilmektedir.
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ı için Add-AzAccount ve Add-AzureRMAccount Bağlan-azaccountiçin diğer adlar. 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. Hizmet sorumlusu ile yapılandırılmış bir farklı çalıştır hesabı kullanarak kimlik doğrulaması yapıyorsanız, bu cmdlet 'lerin kullanılması gerekli değildir.
Denetim noktalarıyla ilgili daha fazla bilgi için bkz. Betik İş Akışına Denetim Noktaları Ekleme.
Sonraki adımlar
- PowerShell Iş akışı runbook 'ları hakkında bilgi edinmek için bkz. öğretici: PowerShell Iş akışı runbook 'U oluşturma.