Windows PowerShell: O ambiente do Windows PowerShell Workflow
Cada mês do ano, Don Jones apresentará um novo artigo em um tutorial dividido em 12 partes sobre o Windows PowerShell Workflow. Nós encorajamos você a ler a série na ordem, começando com o de janeiro de 2013 coluna.
Don Jones
Como eu expliquei no mês passado, o fluxo de trabalho do Windows PowerShell é um novo recurso na versão 3 do Windows Management Framework. É pré-instalado no Windows Server 2012 e o Windows 8. Também está disponível para Windows 7, Windows Server 2008 e Windows Server 2008 R2. Você vai precisar de um desses sistemas operacionais para executar um fluxo de trabalho. Você também pode ter um alvo de fluxo de trabalho — ou seja, executar tarefas contra — qualquer versão do Windows, dependendo da tarefa que você está tentando realizar.
Existem dois pré-requisitos principais para usar o fluxo de trabalho do Windows PowerShell, afora os requisitos de sistema padrão para o Windows PowerShell versão 3. Primeiro, você precisará usar o pacote PSWorkflow módulo para habilitar recursos de fluxo de trabalho dentro do escudo. Em segundo lugar, você precisará ter o Windows PowerShell Remoting habilitado nas máquinas que você pretende atingir com o fluxo de trabalho do Windows PowerShell.
Comunicação remota não necessariamente precisa ser executado na máquina onde você executar fluxos de trabalho, mas qualquer máquinas pretende inventariar, configurar ou gerenciar caso contrário precisará de ter comunicação remota habilitada. Fluxo de trabalho do Windows PowerShell usa comunicação remota como seu protocolo de comunicação primária. Existem provavelmente alguns fluxos de trabalho você poderia escrever que não precisam de comunicação remota, mas aqueles são escassas.
Comunicação remota é um componente muito incompreendido do Windows PowerShell. Mais algumas organizações pessoal de segurança de TI tomar uma abordagem-não-implantar. Que é equivocada e infeliz. Essas mesmas pessoas preocupados com a segurança não tem nenhum problema, permitindo que um grande número de outro gerenciamento de protocolos de comunicação como o Remote Desktop Protocol (RDP), chamadas de procedimento remoto (RPCs) e HTTP.
Comunicação remota é o caminho a seguir para comunicações de gestão dentro de um ambiente Windows. Microsoft em breve começará a consolidação desses protocolos antigos em comunicação remota. Comunicação remota usa HTTP e HTTPS, é altamente configurável e gerenciável, e você pode centralmente travá-lo para baixo com um objeto de política de grupo (GPO). Também é geralmente mais seguro, mais auditável e mais controláveis do que os protocolos mais antigos. Para uma discussão mais completa sobre as implicações de segurança do sistema de interação remota e sua arquitetura, considerar o download do e-livro livre, "segredos do PowerShell Remoting."
Dentro de um fluxo de trabalho
O maior desafio que você terá ao se aproximar de fluxo de trabalho do Windows PowerShell é lembrar que ele se parece com um script do Windows PowerShell (especificamente, uma função), mas não é. A "língua do Windows PowerShell" você escreve é traduzido em uma linguagem externa (XAML). Em seguida, ele é executado pela tecnologia de não - Windows PowerShell.
Como resultado, há algumas regras diferentes. Alguns desses são puramente sintáticas. Em geral, você precisará de usar nomes de cmdlet completo para cmdlets que você executar. Também, não são permitidos nomes de parâmetro truncado e parâmetros posicionais. Você deve usar nomes de parâmetro completo.
O que pode ser mais confuso é o ambiente geral dentro de um fluxo de trabalho. O ponto inteiro de um fluxo de trabalho é que você pode interromper e retomar o fluxo de trabalho deliberadamente ou fazê-lo em reação a alguma coisa acontecendo de errado no seu ambiente (por exemplo, uma queda de energia).
Isso significa que cada comando em um fluxo de trabalho deve estar essencialmente sozinho. Ele deve ter nenhuma consciência do que fizeram outros comandos e nenhum meio nativo de persistência de dados entre comandos. Isso também significa que você não pode definir uma variável para armazenar a saída de um comando e passar essa variável como entrada para outro comando. Ele simplesmente não vai funcionar. Além disso, você não pode carregar módulos contendo comandos adicionais. Não há nenhum ambiente persistente no qual carregar o módulo.
O bloco de {} InlineScript especial que pode agora entrar em um fluxo de trabalho torna-se seu melhor amigo. Cada InlineScript basicamente é executado como uma única unidade. Windows Workflow Foundation (WWF) gira uma cópia do Windows PowerShell, compotas no InlineScript inteira, e ele é executado. O conteúdo de um InlineScript comportam-se como um script do Windows PowerShell tradicional.
Há também um InlineScript implícita. WWF realmente não é possível executar comandos do Windows PowerShell fora um InlineScript. Quando você usar um cmdlet do Windows PowerShell em seu fluxo de trabalho, Windows PowerShell verifica se um nativo WWF equivalente está disponível e diz a WWF para executar que em vez disso.
A equipe do Windows PowerShell tem escrito equivalentes do WWF para muitos comandos nativos do Windows PowerShell, mas quando você tenta usar um cmdlet que não tem uma versão nativa do WWF, Windows PowerShell implicitamente envolve seu comando em um bloco InlineScript. Isso faz com que a WWF lançar o Windows PowerShell, execute o comando e, em seguida, feche a essa instância do Windows PowerShell.
Esta falta de persistência entre comandos é o que ajuda a tornar seus scripts retomável fluxo de trabalho do Windows PowerShell. Daí uma grande parte do fluxo de trabalho do Windows PowerShell pode paralelizar comandos dentro de um script. Transforma-los em máquinas de automação de vários segmentos. No entanto, a falta de persistência é uma grande partida como normal do Windows PowerShell scripts e funções de trabalho. É preciso muito planejamento adicional, para fazer um script funcione corretamente.
Não será incomum ver fluxos de trabalho que consistem em um monte de blocos InlineScript. Não será incomum ver fluxos de trabalho que são nada mais do que um bloco de InlineScript único e longo.
Tais fluxos de trabalho terá capacidades de paralelização ou currículo limitadas (ou inexistentes). Um InlineScript é uma única unidade de trabalho. Você pode simplesmente optar por executar esses scripts como funções normais, usando comunicação remota, em vez de fluxos de trabalho. Você gostaria de estar recebendo muito poucos dos benefícios reais do fluxo de trabalho do Windows PowerShell de qualquer maneira.
Mantê-los à mão
Uma coisa que é distintamente falta de fluxo de trabalho do Windows PowerShell é um meio de persistência de dados do fluxo de trabalho entre os comandos. Que iria torná-lo útil em uma ampla gama de circunstâncias. Se um fluxo de trabalho fosse interrompido e retomado, comandos poderiam facilmente recriar informações de estado como endereços IP, nomes de computadores, nomes de usuário ou qualquer outra coisa e continue em execução.
Dada esta lacuna nativa, é algo que você provavelmente vai querer criar para si mesmo. Configurar uma instância do SQL Server (mesmo uma instância de Express grátis) e criar tabelas de banco de dados que seus fluxos de trabalho podem salvar os dados. Um fluxo de trabalho vai precisar de alguns meios de excepcionalmente identificando-se, como o nome de fluxo de trabalho e o nome de computador, que cada instância de fluxo de trabalho é alvo.
Seu fluxo de trabalho, em seguida, pode consistir em um número de blocos de InlineScript discretos. Cada um irá ler o estado atual do banco de dados, executar alguma tarefa e, se necessário, atualizar o banco de dados com novas informações. É uma pena que os recursos de fluxo de trabalho do Windows PowerShell não podem ajudar a automatizar isso. Talvez um "fluxo de trabalho$: variável" arquitetura que usa arquivos XML ou SQL Server sob o capô poderia ajudar, mas isso é algo para uma versão futura.
A boa notícia é que é muito fácil de "rolar o seu próprio" persistência usando SQL Server. SQL Server é preferível para arquivos XML, porque é mais escalável, você pode acessá-lo mais facilmente de vários locais de rede e suporta melhor acesso simultâneo de várias instâncias de uma só vez.
A classe do Microsoft .NET Framework System.Data.Sql.SqlClient é fácil de usar. Há exemplos no meu "Aprender a ferramentaria do PowerShell em um mês de almoços" e-book. Na verdade, meu co-autor e eu criei um módulo inteiro você pode reaproveitar e para download como parte dos scripts de exemplo do livro.
Com essas preliminares fora do caminho, nós estamos prontos para começar a analisar o que se parece com um fluxo de trabalho básico. Que será o assunto da coluna do próximo mês.
.jpg)
Don Jones é um vencedor do prêmio de MVP do Windows PowerShell e editor colaborador da TechNet Magazine. Ele é co-autor de quatro livros sobre o Windows PowerShell versão 3, incluindo vários títulos gratuitos na criação de relatórios HTML no Windows PowerShell e Windows PowerShell Remoting. Encontrá-los todos no PowerShellBooks.com, ou Jones sua pergunta nos fóruns de discussão em PowerShell.org.