Рабочие процессы, или потоки, или Workflows. Довольно интересная тема в цифровом мире и в мире Powershell особенно.
Что же такое Powershell Workflows?
Мне об этом поведал 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 только при отсутствии других вариантов…
Сделать легкий старт и представить себе что могут Workflows вы можете в этом блоге.
Лично я просто впечатлен новыми возможностями которые открываются у меня как администратора: параллельное выполнение заданий, выполнение их в фоновом режиме, контрольные точки, продолжение выполнения задания после останова или сбоя, вложенность процессов друг в друга...
Мне это нравится определенно! Ниже пример самого простого процессса(потока) при запуске которого будт выполнены 5 Get-заданий параллельно друг другу и при это еще параллельно на двух хостах сomp1 и comp2.
workflow Get-WFInfo
{
parallel
{
Get-CimInstance -ClassName win32_BaseBoard
Get-CimInstance -ClassName win32_bios
Get-NetAdapter
Get-Disk -CimSession $PSComputerName
Get-Partition -CimSession $PSComputerName
}
}
Get-WFInfo -PSComputerName сomp1, comp2 | select CimClass,SystemName,PSComputerName
Где почитать? В сети и книги от гуру:
- "PowerShell in Depth" Second Edition, DON JONES JEFFERY HICKS RICHARD SIDDAWAY©2015 by Manning Publications Co, chapter 23.
Даже если книги не нашли, то их код с сайта издтельства копируется свободно.
ReplyDelete