Conceitos de fluxo de trabalho do Windows PowerShell

Importante

Esta versão do SMA (Service Management Automation) chegou ao fim do suporte. Recomendamos que você atualize para o SMA 2022.

Um tipo de runbook para Automação de Gerenciamento de Serviços é baseado em fluxos de trabalho Windows PowerShell. Este artigo fornece uma breve visão geral dos recursos críticos dos fluxos de trabalho comuns aos runbooks de Automação. Detalhes completos sobre fluxos de trabalho encontram-se disponíveis em Getting Started with Windows PowerShell Workflow (Introdução ao Fluxo de Trabalho do Windows PowerShell).

A estrutura do runbook é idêntica entre runbooks para a Automação de Gerenciamento de Serviços e para o Microsoft Automação do Azure embora os dois normalmente funcionem com recursos diferentes.

Fluxos de Trabalho do Windows PowerShell

Um fluxo de trabalho é uma sequência de etapas programadas e conectadas que executam tarefas de execução longa ou exigem a coordenação de várias etapas em vários dispositivos ou nós gerenciados. Os benefícios de um fluxo de trabalho comparado com um script normal incluem a capacidade de realizar simultaneamente uma ação em vários dispositivos e a capacidade de se recuperar automaticamente de falhas. Um Fluxo de Trabalho do Windows PowerShell é um script do Windows PowerShell que usa o Windows Workflow Foundation. Embora o fluxo de trabalho seja gravado com Windows PowerShell sintaxe e iniciado por Windows PowerShell, ele é processado pelo Windows Workflow Foundation.

Estrutura básica

Um fluxo de trabalho Windows PowerShell começa com o fluxo de trabalho palavra-chave seguido pelo corpo do script entre chaves. O nome do fluxo de trabalho segue a palavra-chave Workflow , como mostra a sintaxe a seguir. O nome do fluxo de trabalho corresponde ao nome do runbook de Automação.

Workflow Test-Runbook
{
   <Commands>
}

Para adicionar parâmetros ao fluxo de trabalho, use o palavra-chave Param, conforme mostrado na sintaxe a seguir. O Portal de Gerenciamento solicitará ao usuário que forneça valores para esses parâmetros quando os usuários iniciarem o runbook. Este exemplo usa o atributo Parameter opcional, que especifica se o parâmetro é obrigatório ou não.

Workflow Test-Runbook
{
  Param
  (
   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>,

   [Parameter(Mandatory=<$True | $False>]
   [Type]$<ParameterName>
  )
  <Commands>
}

Nomenclatura

O nome do fluxo de trabalho deve estar em conformidade com o formato Verbo-Substantivo que é padrão no Windows PowerShell. É possível consultar Approved Verbs for Windows PowerShell Commands (Verbos Aprovados para Comandos do Windows PowerShell) para obter uma lista de verbos aprovados para o uso. O nome do fluxo de trabalho deve corresponder ao nome do runbook de automação. Se o runbook está sendo importado, o nome do arquivo deve corresponder ao nome do fluxo de trabalho e deve terminar em. ps1.

Limitações

Para obter uma lista completa de limitações e diferenças de sintaxe entre fluxos de trabalho do Windows PowerShell e o Windows PowerShell, consulte Diferenças sintáticas entre os fluxos de trabalho de script e scripts.

Atividades

Uma atividade é uma tarefa específica em um fluxo de trabalho. Assim como um script é composto de um ou mais comandos, um fluxo de trabalho é composto de uma ou mais atividades que são executadas em uma sequência. O fluxo de trabalho do Windows PowerShell converte automaticamente muitos dos cmdlets do Windows PowerShell para atividades ao executar um fluxo de trabalho. Quando você especifica um desses cmdlets em seu runbook, a atividade correspondente é efetivamente executada pelo Windows Workflow Foundation. Para cmdlets sem uma atividade correspondente, Windows PowerShell Fluxo de Trabalho executa automaticamente o cmdlet dentro de uma atividade InlineScript. Há um conjunto de cmdlets que são excluídos e não podem ser usados em um fluxo de trabalho, a menos que você os inclua explicitamente em um bloco InlineScript . Para obter mais informações sobre esses conceitos, consulte Usando atividades em fluxos de trabalho de script.

As atividades de fluxo de trabalho compartilham um conjunto de parâmetros comuns para configurar suas operações. Para obter detalhes sobre os parâmetros comuns do fluxo de trabalho, consulte about_WorkflowCommonParameters.

Módulos de Integração

Um Módulo de Integração é um pacote que contém um módulo Windows PowerShell e pode ser importado para a Automação. Windows PowerShell Módulos contêm cmdlets que podem ser usados em runbooks de Automação. Produtos e serviços, como o Operations Manager e o Azure, têm módulos que incluem cmdlets específicos para sua operação.

Os módulos de integração importados para a Automação estão automaticamente disponíveis para todos os runbooks. Como a Automação é baseada no Windows PowerShell 4.0, ela dá suporte ao carregamento automático de módulos, o que significa que os cmdlets de módulos instalados podem ser usados sem importá-los para o script com Import-Module.

Qualquer módulo Windows PowerShell pode ser importado para a Automação, desde que todas as suas dependências possam estar localizadas em uma única pasta. Se o módulo depender das configurações do Registro ou dos arquivos que não estão no caminho padrão, ele poderá ser importado, mas provavelmente não funcionará porque a Automação não poderá localizar suas dependências. Os módulos com dependências externas podem ser usados em um runbook instalando-os em outro host e, em seguida, acessando-s com um bloco de script InlineScript .

Com a Automação de Gerenciamento de Serviços, você pode usar módulos com dependências externas instalando-os em cada servidor de trabalho. Embora os cmdlets nesses módulos possam ser usados em runbooks, eles não serão descobertos pela Automação para dar suporte a recursos como o assistente Inserir Atividade. Pode-se criar um módulo Portátil para utilizar esse recurso, utilizando o cmdlet New-SmaPortableModule . Esse cmdlet cria um módulo que inclui um stub para cada um de seus cmdlets e pode ser importado para a Automação. Quando um runbook utiliza um desses cmdlets, o stub redireciona a chamada para o cmdlet real no módulo externo. Esse módulo deve ser instalado em cada servidor Worker ou a chamada vai falhar.

Execução paralela

Uma vantagem dos Fluxos de Trabalho do Windows PowerShell é a capacidade de executar um conjunto de comandos em paralelo em vez de sequencialmente como com um script típico. Isso é particularmente útil em runbooks, uma vez que podem efetuar ações múltiplas que levam um tempo significativo para serem concluídas. Por exemplo, um runbook pode fornecer um conjunto de máquinas virtuais. Em vez de executar cada processo de provisionamento em sequência entre si, as ações poderiam ser executadas simultaneamente, aumentando a eficiência geral. Somente quando todas as ações forem concluídas o runbook continua.

Você pode usar a palavra-chave Parallel para criar um bloco de script com vários comandos que serão executados simultaneamente. Isso é feito através da sintaxe mostrada abaixo. Nesse caso, a Atividade1 e a Atividade2 vão começar ao mesmo tempo. A Atividade3 somente começará após conclusão da Atividade1 e da Atividade2.

Parallel
{
  <Activity1>
  <Activity2>
}
<Activity3>

Você pode usar o construct ForEach-Parallel para processar comandos de cada item em uma coleção simultaneamente. Os itens na coleção são processados em paralelo, enquanto os comandos no bloco de script são executados em sequência. Isso é feito através da sintaxe mostrada abaixo. Nesse caso, Activity1 será iniciado ao mesmo tempo para todos os itens da coleção. Para cada item, a Atividade2 será iniciada após a conclusão da Atividade1. Activity3 será iniciado somente depois que Activity1 e Activity2 tiverem sido concluídos para todos os itens.

ForEach -Parallel ($<item> in $<collection>)
{
  <Activity1>
  <Activity2>
}
<Activity3>

O palavra-chave de Sequência é usado para executar comandos em sequência dentro de um bloco de script Paralelo. O bloco Script de sequência é executado em paralelo com outros comandos, mas os comandos dentro do bloco são executados sequencialmente. Isso é feito através da sintaxe mostrada abaixo. Nesse caso, a Atividade1, a Atividade2 e a Atividade3 vão começar ao mesmo tempo. A Atividade4 será iniciada após a conclusão da Atividade3. A Atividade5 será iniciada após a conclusão de todas as outras atividades

Parallel
{
  <Activity1>
  <Activity2>

  Sequence
  {
   <Activity3>
   <Activity4>
  }
}
<Activity5>

Pontos de verificação

Um ponto de verificação é um instantâneo do estado atual do fluxo de trabalho, incluindo o valor atual das variáveis e qualquer saída gerada para aquele ponto. O último ponto de verificação a ser concluído em um runbook é salvo no banco de dados de Automação para que o fluxo de trabalho possa ser retomado mesmo no caso de uma interrupção. Os dados do ponto de verificação são removidos quando o trabalho do runbook é concluído.

Você pode definir um ponto de verificação em um fluxo de trabalho com a atividade Checkpoint-Workflow . Quando essa atividade é incluída em um runbook, um ponto de verificação é executado imediatamente. Se o runbook for suspenso devido a um erro, quando o trabalho for retomado o runbook vai reiniciar do último ponto de verificação estabelecido.

No código de exemplo a seguir, ocorre um erro após Activity2, fazendo com que o runbook seja suspenso. Quando o trabalho é reiniciado, ele começa pela execução da Atividade2, já que esse foi o último ponto de verificação definido.

<Activity1>
Checkpoint-Workflow
<Activity2>
<Error>
<Activity3>

Você deve definir pontos de verificação em um runbook após atividades que podem ser propensas a erros e não devem ser repetidas se o runbook for retomado. Por exemplo, o runbook pode criar uma máquina virtual. Você pode definir um ponto de verificação antes e depois dos comandos para criar a máquina virtual. Se a criação falha, os comandos são repetidos quando o runbook é retomado. Se a criação for bem-sucedida, mas o runbook falhar mais tarde, a máquina virtual não será criada novamente quando o runbook for retomado.

Para saber mais sobre pontos de verificação, confira Adicionando pontos de verificação a um Fluxo de Trabalho de script.

Suspender um Runbook

Você pode forçar um runbook a se suspender com a atividade Suspend-Workflow . Essa atividade vai definir um ponto de verificação e fazer com que o fluxo de trabalho seja suspenso imediatamente. A suspensão de um fluxo de trabalho é útil para runbooks que possam requerer que se efetue uma etapa manual antes que outro conjunto de atividades seja executado.

Para obter mais informações sobre a suspensão de um fluxo de trabalho, consulte Making a Workflow Suspend Itself (Fazer um Fluxo de Trabalho Suspender a Si Mesmo).

InlineScript

A atividade InlineScript executa um bloco de comandos em uma sessão separada e não de fluxo de trabalho e retorna sua saída para o fluxo de trabalho. Enquanto os comandos em um fluxo de trabalho são enviados ao Windows Workflow Foundation para processamento, os comandos em um bloco de InlineScript são processados pelo Windows PowerShell. A atividade usa os parâmetros comuns de fluxo de trabalho padrão, incluindo PSComputerName e PSCredential, que permitem especificar que o bloco de código seja executado em outro computador ou usando credenciais alternativas.

O InlineScript usa a sintaxe mostrada abaixo.

InlineScript
{
  <Script Block>
} <Common Parameters>

O uso mais comum para InlineScript em um runbook é executar um bloco de código em outro computador. Isso é necessário quando os cmdlets em seu runbook não são instalados na Automação ou se a ação tem apenas permissões para serem executadas localmente no computador de destino. Isso é ilustrado no diagrama a seguir.

Para executar o bloco de código em outro computador, os parâmetros PSComputer e PSCredential são usados com a atividade InlineScript . Normalmente é utilizado um recurso global, como Credential ou Connection , em um runbook para fornecer valores para esses parâmetros. O código de exemplo a seguir executa um conjunto de comandos em um computador representado por uma conexão denominada MinhaConexão.

$con = Get-AutomationConnection -Name 'MyConnection'
$securepassword = ConvertTo-SecureString -AsPlainText -String $con.Password -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $con.Username, $securepassword
InlineScript
{
  <Commands>
} -PSComputer $con.ComputerName -PSCredential $cred

Embora as atividades inlineScript possam ser críticas em determinados runbooks, elas só devem ser usadas quando necessário pelos seguintes motivos:

• Você não pode usar pontos de verificação de dentro de um bloco InlineScript . Se uma falha ocorre dentro do bloco, o mesmo deve ser reiniciado desde o início.

• InlineScript afeta a escalabilidade do runbook, pois ele mantém a sessão Windows PowerShell para todo o comprimento do bloco InlineScript.

• Atividades como Get-AutomationVariable e Get-AutomationPSCredential não estão disponíveis em um bloco InlineScript.

Se você precisar usar um InlineScript, deverá minimizar seu escopo. Por exemplo, se o runbook iterar em uma coleção ao aplicar a mesma operação a cada item, o loop deverá ocorrer fora do InlineScript. Isso irá fornecer as seguintes vantagens:

• É possível verificar o fluxo de trabalho depois de cada iteração. Se o trabalho for suspenso ou interrompido e reiniciado, o loop será capaz de continuar.

• Você pode usar ForEach "Paralelo para lidar com itens de coleção simultaneamente.

Tenha em mente as seguintes recomendações se você usar um InlineScript em seu runbook:

• É possível passar valor para o script de qualquer forma com o modificador de escopo $Using . Por exemplo, uma variável chamada $abc que foi definida fora do InlineScript se tornaria $using:abc dentro de um InlineScript.

• Para retornar a saída de um InlineScript, atribua a saída a uma variável e gere qualquer dado a ser retornado ao fluxo de saída. O exemplo a seguir atribui a cadeia de caracteres hi a uma variável chamada $output.

  $output = InlineScript { Write-Output "hi" }
  

• Evite definir fluxos de trabalho no escopo inlineScript . Embora alguns fluxos de trabalho possam parecer operar corretamente, esse não é um cenário testado. Como resultado, você pode encontrar mensagens de erro confusas ou comportamento inesperado.

Para obter mais informações sobre como usar o InlineScript, consulte Executando comandos Windows PowerShell em um fluxo de trabalho e about_InlineScript.

Próximas etapas

• Criar runbooks de automação.