sergey vasin

The IT blog

Основы Windows PowerShell Workflow: когда и зачем их использовать – Hey, Scripting Guy! Blog

leave a comment »

Резюме: Приглашенный блогер Jeff Wouters рассказывает об основах рабочих процессов WindowsPowerShell 3.0 и о том, когда и зачем их использовать.

Jeff Wouters (BICT, MCITP, MCSA, MCSE) – технический консультант-фрилансер из Нидерландов. Его основной специализацией является высокая доступность и автоматизация с использованием продуктов Microsoft и Citrix, и таких технологий, как виртуализация, избыточность, кластеризация и репликация. Кроме того, его страстью является Windows PowerShell. И еще он – основатель Dutch PowerShell User Group в 2012 году.

Jeff выступал с докладами на таких конференциях, как E2E Virtualization Conference (ранее известна как PubForum), BriForum Chicago, и NGN (Dutch IT community).  Вы можете найти Джеффа в социальных сетях (Twitter @JeffWouters | Facebook @JeffWouters | LinkedIn @JeffWouters) и в его блоге. Он выступает и пишет в основном о Windows PowerShell и виртуализации, но время от времени проскальзывает нечто, что вызывает его интерес.

Джефф также является одним из авторов проекта книги, где более 30 авторов со всего мира работают вместе над созданием книги о Windows PowerShell, которая будет издана в 2013 году.

Слово тебе, Джефф.

Когда был представлен Windows PowerShell 2.0, он подарил нам возможность удаленного выполнения команд. Спустя немного времени, вы можете видеть как множество продуктов используют эту технологию, так как она очень, очень мощная.

Windows PowerShell 3.0 принес рабочие процессы (workflow). Я осмелюсь предположить, что это окажет еще большее влияние, чем удаленная работа и поэтому я решил написать пост об этом с практической точки зрения и добавил тему в мой список «Нужно написать».

И чуть позже пришло письмо от Эда, с вопросом, будет ли мне интересно написать пост для блога «Hey, Scripting Guy!». По мере чтения письма я думал о моем намерении написать пост о рабочих процессах и решил что это будет отличной темой для блога Эда.

И вот он я, Jeff Wouters, энтузиаст PowerShell из Нидерландов и автор блога http://www.jeffwouters.nl/.

Что такое workflow?

Рабочий процесс – это в сущности несколько заданий, выполняемых последовательно, которые требуют некоторой координации, поскольку они могут выполняться на различных устройствах. По крайней мере так чем говорится в файле справки. Я обнаружил несколько более практических применений для рабочих процессов, о чем я и расскажу в этом посте.

С точки зрения дизайна, рабочие процессы могут повторяться, прерываться, перезапускаться, останавливаться и выполняться параллельно – больше об этом я расскажу в разделе «Для чего используются workflow?» далее в посте.

Хотя рабочие процессы очень мощные, нужно понимать, что они также и очень сложные. Можно запросто переусложнить скрипт, и поэтому, как и при работе с любыми большими скриптами, стоит сначала поразмыслить о том, что ваш скрипт будет делать, продумать его структуру, и лишь затем начинать его писать.

PowerShell содержит модуль PSWorkflow, который просто использует Windows Workflow Foundation. Рабочие процессы – это не часть Windows PowerShell. Это просто использование (очень разумное) технологии, которая уже присутствует в операционных системах Windows.

Мощь workflow

Для того, чтобы действительно оценить мощь рабочих процессов, я могу лишь посоветовать вам начать их использовать.

Но, конечно, это не то, что вы ждете от этого поста. Вам нужны примеры, так? Вместо того, чтобы дать вам кусок кода, я приведу пример, знакомый каждому администратору: Server Manager.

В Windows Server 2012 он был полностью переписан и стал значительно быстрее, поскольку теперь это фактически графическая оболочка вокруг Windows PowerShell и WMI. Кроме того, он позволяет вам управлять вашей средой из единой консоли, поскольку теперь он также использует рабочие процессы!

Когда вы развертываете решение на основе сценария из Server Manager, он знает (в соответствии со сценарием), в какой последовательности выполнять отдельные задачи. Он генерирует рабочий процесс для выполнения определенных действий и передает его на целевые серверы. Таким образом WMI, совместно с Windows PowerShell, рабочими процессами и удаленным выполнением представляет из себя немалую мощь.

Для чего используются workflow?

Don Jones, Windows PowerShell MVP, не так давно рассмотрел это вопрос в одном из постов в своем блоге, поэтому я не буду проделывать то же самое еще раз: http://powershell.org/wp/2012/08/30/powershell-workflow-when-should-you-use-it.

По моему мнению, только скрипты для развертывания, а также некоторые несложные скрипты для конфигурации и обслуживания позволят использовать рабочие процессы в простом и понятном виде. Вы увидите это в скриптах, приведенных в этом посте.

Вот почему, как и в случае с большими скриптами, я советую вам разделять большие рабочие процессы на меньшие части.

Разработчики называют это модульным программированием. Когда я обдумываю структуру скрипта – я называю это модульным обдумыванием. Когда я собираюсь написать скрипт, я думаю: Задачи -> Рабочие процессы -> Функции -> Модули… в таком порядке. В моем случае – это сильно облегчает мне жизнь.

Используйте workflowтолько тогда, когда нет другого выхода…?

Я видел, что кто-то – не помню точно, кто это был – написал, что вы должны использовать рабочие процессы только в том случае, когда действительно не существует иного варианта для выполнения задачи. Я не согласен с этим до определенной степени и позвольте мне объяснить, почему.

1.       Если вы можете читать функции, вы также можете читать рабочие процессы – они читаемы.

2.       Даже при использовании их основных возможностей – рабочие процессы очень мощные.

3.       Во многих случаях при использовании рабочих процессов требуется намного меньше когда, чем при их неиспользовании и они по-прежнему остаются читаемыми.

4.       Это может серьезно уменьшить время выполнения вашего скрипта.

5.       Если вы используете только основные возможности рабочих процессов, но они все же удовлетворяют вашим потребностям, это не так сложно… действительно!

Единственное ограничение использования Windows PowerShell– это ваше воображение. Таким образом, если вы переусложните ваш скрипт – это не вина Windows PowerShell. Сказать, что вы должны использовать рабочие процессы только в тех случаях, когда нет другого выхода – это все равно что сказать, что вы должны использовать Windows PowerShell только при отсутствии других вариантов… звучит дико, правда?

Простые практические варианты использования workflow

Если мне нужно развернуть 50 виртуальных машин одинаковой конфигурации с именами VM от 1 до 50, я могу сделать это несколькими способами.

Первый потребует написания 150 строк кода – не совсем то, что мне бы хотелось.

Второй – это написать небольшой цикл:

1..50 | ForEach-Object { New-VM -Name VM$_ -MemoryStartupBytes 512MB –NewVHDPath «D:\Hyper-V\Virtual Hard Disks\VM$_.vhdx» -NewVHDSizeBytes 15GB }

В цикле задания выполняются последовательно. Этот тот случай, когда рабочий процесс может серьезно увеличить скорость выполнения вашего скрипта. При использовании workflow вы можете использовать параметр –Parallel в командлете ForEach, который позволяет выполнять 5 потоков одновременно. Таким образом, если ваше оборудование справится с нагрузкой, то создание виртуальных машин может стать до 5 раз быстрее!

Третий способ – это использование workflow:

workflow New-VirtualMachines

{

  $VMs = 1..50

  foreach -parallel ($VM in $VMs)

  {

    New-VM -Name VM$VM -MemoryStartupBytes 512MB –NewVHDPath «D:\Hyper-V\Virtual Hard Disks\VM$VM.vhdx» -NewVHDSizeBytes 15GB

  }

}

Время выполнения первого скрипта в моем окружении составляло около 9 минут, время выполнения рабочего процесса – всего 2 минуты! Но если вы думаете, что рабочие процессы – статические, то я могу вам сказать, что рабочие процессы могут принимать параметры, так же как и функции. Следующий рабочий процесс в качестве входных параметров принимает имя виртуальной машины, число создаваемых виртуальных машин и размер виртуального диска:

workflow New-VirtualMachines

{

  [CmdletBinding()]

  Param (

    [Parameter(Mandatory=$true,Position=0)]$VMName,

    [Parameter(Mandatory=$true,Position=1)]$VMCount,

    [Parameter(Mandatory=$true,Position=2)]$VHDSize

  )

  $VMs = 1..$VMCount

  foreach -parallel ($VM in $VMs)

  {

    New-VM -Name $VMName$VM -MemoryStartupBytes 512MB -NewVHDPath «D:\Hyper-V\Virtual Hard Disks\$VMName$VM.vhdx» -NewVHDSizeBytes $VHDSize

  }

}

Вы можете вызвать этот рабочий процесс так же, как и функцию:

New-VirtualMachines -VMName VM -VMCount 50 -VHDSize 15GB

Даже на простейшем уровне – это несложно, быстро, читаемо и может использоваться повторно!

А теперь вторая распространенная причина для использования рабочих процессов: выполнение заданий в определенной последовательности. Некоторое время назад я написал скрипт для одного из моих заказчиков. Этот скрипт выполнял следующие задачи:

Number Wait for number Target Task
1 WEB01 Stop MyApp service
2 1 WEB01 Stop MyAppQueue service
3 1,2 FS01 Remove MyAppQueue.xml
4 1,2 FS02 Remove MyAppQueue.xml
5 4,5 WEB01 Start MyAppQueue service
6 5 WEB01 Start MyApp Service

Если бы я не мог использовать рабочие процессы, то скрипт содержал бы достаточно много кода. Но при их использовании он выглядит следующим образом:

Workflow Refresh-MyApp

{

  sequence

  {

    Invoke-Command -ComputerName WEB1 {Stop-Service -Name MyApp -Force}

    Invoke-Command -ComputerName WEB1 {Stop-Service -name MyAppQueue

    -Force}

    parallel

    {

      Invoke-Command -ComputerName FS1

       {

        Remove-Item -Path «D:\MyApp\Files\MyAppQueue.xml» –Force

      }

      Invoke-Command -ComputerName FS2

      {

        Remove-Item -Path «D:\MyApp\Files\MyAppQueue.xml» –Force

      }

    }

    Invoke-Command -ComputerName WEB1 {Start-Service -Name MyAppQueue}

    Invoke-Command -ComputerName WEB1 {Start-Service -Name MyApp}

  }

}

Заметка: я использовал Invoke-Command, потому что это просто, читаемо и соответствуем моим нуждам в этой конкретной ситуации. Я решил не использовать встроенные возможности рабочих процессов, и я не буду их рассматривать в этом посте.

Как вы видите, некоторые задачи выполняются в определенной последовательности и ждут, пока завершится предыдущее задание. Но так как обе задачи по удалению файлов зависят от тех же самых предыдущих шагов и не зависят друг от друга, они могут выполняться параллельно.

Функции против рабочих процессов

В чем отличие? Нет, подождите… это неверный вопрос, поскольку это совершенно разные вещи. Что общего? Точно, вот он, нужный вопрос!

Если вы знаете, как написать функцию, вы уже знаете большую часть того, что нужно для написания рабочего процесса. Workflow использует тот же синтаксис и принимает параметры таким же образом, как и функция. Продуктовая группа Windows PowerShell обладает весьма целостным подходом.

Давайте сравним рабочий процесс для развертывания виртуальных машин, приведенный ранее в посте, с функцией, выполняющей те же действия:

function New-VirtualMachines

{

  [CmdletBinding()]

  Param (

    [Parameter(Mandatory=$true,Position=0)]$VMName,

    [Parameter(Mandatory=$true,Position=1)]$VMCount,

    [Parameter(Mandatory=$true,Position=2)]$VHDSize

  )

  $VMs = 1..$VMCount

  foreach ($VM in $VMs)

  {

    New-VM -Name $VMName$VM -MemoryStartupBytes 512MB -NewVHDPath «D:\Hyper-V\Virtual Hard Disks\$VMName$VM.vhсьтольdx» -NewVHDSizeBytes $VHDSize

  }

}

Как вы можете заметить, здесь только 2 отличия:

1.       В первой строке вместо «workflow» – «function».

2.       В 10 строке отсутствует параметр –Parallel. Функции не могут использовать этот параметр, только рабочие процессы.

Что еще можно сделать

Функция может вызывать рабочий процесс и рабочий процесс может вызывать функцию. Но так же как и функция может вызывать функцию, рабочий процесс может вызывать рабочий процесс – все еще следите за мыслью? Именно здесь все может внезапно стать очень сложным.

Кроме того, помните о ресурсах. Если вы одновременно создаете 5 виртуальных машин используя ForEach –Parallel, ваша среда может начать работать о-о-очень медленно. Таким образом, думайте пере тем как приступить к написанию скрипта. И если вы действительно хотите все усложнить, то это должно вам понравиться. Внутри блока sequence может находиться блок parallel. И внутри этого блока parallel может находиться блок sequence и т.д.

Для того, чтобы представить вам идею, я добавил несколько строк в приведенный ранее рабочий процесс Refresh-MyApp:

Workflow Refresh-MyApp

{

  sequence {

    Invoke-Command -ComputerName WEB1 {Stop-Process -Name MyApp -Force}

    Invoke-Command -ComputerName WEB1 {Stop-Process -Name MyAppQueue -Force}

    parallel {

      Invoke-Command -ComputerName FS1 {Remove-Item -Path «D:\MyApp\Files\MyAppQueue.xml» –Force}

      Invoke-Command -ComputerName FS2 {Remove-Item –Path «D:\MyApp\Files\MyAppQueue.xml» –Force}

      sequence {

        parallel {

          Invoke-Command -ComputerName FS1 {Stop-Process -Name MyAppFSQueue}

          Invoke-Command -ComputerName FS2 {Stop-Process -Name MyAppFSQueue}

        }

        Invoke-Command -ComputerName FS1 {Remove-Item –Path «D:\MyApp\Log\Queue.log» –Force}

        Invoke-Command -ComputerName FS2 {Remove-Item –Path «D:\MyApp\Log\Queue.log» –Force}

        parallel {

          Invoke-Command -ComputerName SQL1 {Stop-Process -Name mssqlserver -Force}

          Invoke-Command -ComputerName SQL2 {Stop-Process -Name mssqlserver -Force}

          Invoke-Command -ComputerName SQL3 {Stop-Process -Name mssqlserver -Force}

        }

        parallel {

          Invoke-Command -ComputerName SQL1 {Start-Process -Name mssqlserver -Force}

          Invoke-Command -ComputerName SQL2 {Start-Process -Name mssqlserver -Force}

          Invoke-Command -ComputerName SQL3 {Start-Process -Name mssqlserver -Force}

        }

        sequence {

          Invoke-Command -ComputerName FS1 {Start-Process -Name MyAppFSQueue}

          Invoke-Command -ComputerName FS2 {Start-Process -Name MyAppFSQueue}

        }

      }

    }

    Invoke-Command -ComputerName WEB1 {Start-Process -Name MyAppQueue}

    Invoke-Command -ComputerName WEB1 {Start-Process -Name MyApp}

  }

  Send-MailMessage -From «MyApp@domain.com» -To «servicedesk@domain.com» -Subject «MyApp maintenance completed» -Body «The MyApp maintenance script has run.»

}

Далее представлена таблица, объясняющая взаимоотношения разных частей скрипта:

Number Wait for number Target Task
1 WEB1 Stop process MyApp
2 WEB1 Stop process MyAppQueue
3 1-2 FS1 Remove MyAppQueue.xml
4 1-2 FS2 Remove MyAppQueue.xml
5 1-4 FS1 Stop process MyAppFSQueue
6 1-4 FS2 Stop process MyAppFSQueue
7 1-6 FS1 Remove Queue.log
8 1-7 FS2 Remove Queue.log
9 1-8 SQL1 Stop process mssqlserver
10 1-8 SQL2 Stop process mssqlserver
11 1-8 SQL3 Stop process mssqlserver
12 1-11 SQL1 Start process mssqlserver
13 1-11 SQL2 Start process mssqlserver
14 1-11 SQL3 Start process mssqlserver
15 1-14 FS1 Start process MyAppFSQueue
16 1-15 FS2 Start process MyAppFSQueue
17 1-16 WEB1 Start process MyAppQueue
18 1-17 WEB2 Start process MyApp
19 1-18 Send email

Цель этого поста

Основная моя цель в этом посте была показать вам, насколько простыми могут быть рабочие процессы. Я думаю, вы смогли оценить их мощь, даже при использовании их простейших возможностей. Сходство с функциями облегчает их изучение и использование для выполнения параллельных задач. Может быть это пригодиться вам для выполнения ваших задач. Если вы новичок в рабочих процессах – начните с основ, приведенных в этом посте и двигайтесь дальше.

Удачного скриптинга!

~Jeff

Автор:

Ed Wilson, Microsoft Scripting Guy

Оригинал:

http://blogs.technet.com/b/heyscriptingguy/archive/2012/11/22/the-basics-of-windows-powershell-workflow-when-to-use-it-and-why.aspx


Страницы в социальных сетях:

Twitter: https://twitter.com/vsseth
Facebook: https://fb.com/inpowershell
VKontakte: https://vk.com/inpowershell


Реклама

Written by Сергей Васин

Декабрь 4, 2012 в 11:55

Опубликовано в HeyScriptingGuyBlog, PowerShell

Tagged with

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s