Windows PowerShell. L'ambiente dell flusso di lavoro di Windows PowerShell
Ogni mese di quest'anno, Don Jones presenterà un articolo all'interno di un'esercitazione in 12 parti sul flusso di lavoro di Windows PowerShell. Ti invitiamo a leggere la serie nell'ordine, cominciando con il colonna gennaio 2013.
Don Jones
Come ho già spiegato il mese scorso, Workflow Windows PowerShell è una nuova funzionalità nella versione 3 di Windows Management Framework. Esso è preinstallato su Windows Server 2012 e Windows 8. È anche disponibile per Windows 7, Windows Server 2008 e Windows Server 2008 R2. Avrete bisogno di uno di quei sistemi operativi per eseguire un flusso di lavoro. Si può anche avere una destinazione del flusso di lavoro — cioè, eseguire operazioni contro — qualsiasi versione di Windows, a seconda del compito che si sta cercando di realizzare.
Ci sono due principali prerequisiti per utilizzare Windows PowerShell del flusso di lavoro, a parte i requisiti di sistema standard per Windows PowerShell versione 3. In primo luogo, è necessario utilizzare il modulo PSWorkflow in dotazione per attivare le funzionalità di flusso di lavoro all'interno del guscio. In secondo luogo, è necessario avere Windows PowerShell Remoting attivati sulle macchine che si intende con Windows PowerShell del flusso di lavoro di destinazione.
Servizi remoti necessariamente non ha bisogno di essere in esecuzione sulla macchina dove eseguire i flussi di lavoro, ma qualunque macchine progettate per inventario, configurare o gestire in altro modo saranno necessario avere servizi remoti abilitati. Windows PowerShell Flusso di lavoro utilizza servizi remoti come protocollo di comunicazione primario. Ci sono probabilmente alcuni flussi di lavoro si potrebbe scrivere che non avrebbe bisogno di servizi remoti, ma quelli sono pochi e lontani tra.
Remoting è un componente ampiamente frainteso di Windows PowerShell. Oltre ad alcune organizzazioni gente di sicurezza IT adottano un approccio non-fare-distribuire. Che è sbagliata e sfortunata. Quelle stesse persone attente alla sicurezza non hanno alcun problema consentendo un gran numero di altri strumenti di gestione protocolli di comunicazione come il Remote Desktop Protocol (RDP), chiamate di procedura remota (RPC) e HTTP.
Comunicazione remota è la via da seguire per le comunicazioni di gestione all'interno di un ambiente Windows. Microsoft inizierà presto a consolidare quelli più vecchi protocolli in Remoting. Remoting utilizza HTTP e HTTPS, è altamente configurabile e gestibile, e si può centralmente bloccare giù con un oggetto Criteri di gruppo (GPO). Inoltre è generalmente più sicuro, più controllabili e più controllabile rispetto a quelli più vecchi protocolli. Per una discussione più completa delle implicazioni di sicurezza remota e la sua architettura, è consigliabile scaricare l'e-book gratuito, "segreti di PowerShell Remoting."
All'interno di un flusso di lavoro
La sfida più grande che avrai quando si avvicina Windows PowerShell del flusso di lavoro è da ricordare che assomiglia ad uno script Windows PowerShell (in particolare, una funzione), ma non lo è. La "lingua diWindows PowerShell si scrive è tradotto in un linguaggio esterno (XAML). Poi viene eseguito da non-tecnologiaWindows PowerShell .
Come risultato, ci sono alcune regole differenti. Alcuni di questi sono puramente sintattiche. In generale, è necessario utilizzare nomi di cmdlet completo per eseguire i cmdlet. Inoltre, non sono ammessi parametri posizionali e i nomi di parametro troncato. È necessario utilizzare nomi di parametro completo.
Che cosa può essere più confusa è l'ambiente generale all'interno di un flusso di lavoro. Il punto di un flusso di lavoro è che è possibile interrompere e riprendere il flusso di lavoro deliberatamente o farlo in reazione a qualcosa che non va nel tuo ambiente (ad esempio una perdita di potenza).
Ciò significa che ogni comando in un flusso di lavoro deve essenzialmente stand-alone. Deve avere alcuna consapevolezza di ciò che hanno fatto altri comandi e non significa nativo di dati persistenti tra i comandi. Significa anche che non è possibile impostare una variabile per contenere l'output di un comando e quindi passare tale variabile come input per un altro comando. Semplicemente non funziona. Inoltre, è Impossibile caricare moduli contenenti comandi aggiuntivi. Non non c'è nessun ambiente persistente in cui caricare il modulo.
Il blocco di {} InlineScript speciale che può andare ora in un flusso di lavoro diventa il tuo migliore amico. Ogni InlineScript è fondamentalmente eseguire come una singola unità. Windows Workflow Foundation (WWF) gira una copia di Windows PowerShell, marmellate in InlineScript intera, e funziona. Il contenuto di un InlineScript si comporta come uno script Windows PowerShell tradizionale.
C'è anche un implicito InlineScript. WWF in realtà non è possibile eseguire comandi Windows PowerShell di fuori di un InlineScript. Quando si utilizza un cmdlet di Windows PowerShell nel vostro flusso di lavoro, Windows PowerShell controlla se un nativo WWF equivalente è disponibile e racconta la WWF per eseguire che invece.
Il team Windows PowerShell ha scritto equivalenti WWF per molti comandi Windows PowerShell nativi, ma quando si tenta di utilizzare un cmdlet che non dispone di una versione nativa di WWF, Windows PowerShell implicitamente avvolge il vostro comando in un blocco di InlineScript. Questo provoca la WWF lanciare Windows PowerShell, eseguire il comando, quindi chiudere l'istanza di Windows PowerShell.
Questa mancanza di persistenza tra i comandi è ciò che aiuta Windows PowerShell flusso di lavoro di rendere il vostro script può essere ripristinato. Ecco una grande parte del Workflow Windows PowerShell può parallelizzare i comandi all'interno di uno script. Li trasforma in macchine di automazione con multithreading. Tuttavia, la mancanza di persistenza è una partenza importante da script Windows PowerShell come normale e funzioni di lavoro. Ci vuole un sacco di pianificazione supplementari fare uno script funziona correttamente.
Non è insolito vedere i flussi di lavoro che consistono di un mucchio di blocchi di InlineScript. Non sarà insolito vedere i flussi di lavoro che non sono altro che un singolo blocco lungo InlineScript.
Tali flussi di lavoro avrà capacità di parallelizzazione o resume limitata (o inesistente). Un InlineScript è una singola unità di lavoro. È possibile semplicemente scegliere di eseguire tale script come normali funzioni, usando Remoting, piuttosto che i flussi di lavoro. Vi sarebbe sempre molto pochi i vantaggi effettivi di Windows PowerShell del flusso di lavoro comunque.
Queste tenere portata di mano
Una cosa Windows PowerShell Workflow è nettamente carente è un mezzo di persistenza dei dati di un flusso di lavoro tra i comandi. Che lo rendono utile in una più ampia gamma di circostanze. Se un flusso di lavoro fosse interrotte e riprese, comandi potrebbero facilmente ricreare le informazioni sullo stato come indirizzi IP, nomi di computer, i nomi utente o quant'altro e continuare l'esecuzione.
Dato questo difetto nativo, è qualcosa che probabilmente vorrete creare per voi stessi. Impostare una SQL Server istanza (anche un libero Express) e creare tabelle di database in cui i flussi di lavoro possono salvare i dati. Un flusso di lavoro avrà bisogno di alcuni mezzi di identificandosi in modo univoco, come ad esempio il nome del flusso di lavoro e il nome del computer che è il targeting per ogni istanza del flusso di lavoro.
Il tuo flusso di lavoro potrebbe quindi costituiti da un numero di blocchi discreti InlineScript. Ognuno di essi sarà leggere lo stato corrente del database, eseguire alcune attività e, se necessario, aggiornare il database con le nuove informazioni. È una vergogna che Windows PowerShell Workflow funzionalità non consentono di automatizzare questo. Forse un "flusso di lavoro$: variabile" architettura che utilizza file XML o SQL Server sotto il cofano potrebbe aiutare, ma che è qualcosa per una versione futura.
La buona notizia è che è abbastanza facile da "roll your own" persistenza utilizzando il SQL Server. SQL Server è preferibile al file XML perché è più scalabile, è possibile accedere più facilmente da più percorsi di rete e supporta meglio accesso simultaneo da più istanze contemporaneamente.
La classe Microsoft .NET Framework System.Data.Sql.SqlClient è facile da usare. Ci sono esempi nel mio "Stampi di PowerShell imparare in un mese di pranzi" e-book. Infatti, il mio coautore e ho creato un modulo intero può riutilizzare e scaricare gratis come parte di script di esempio del libro.
Con questi preliminari fuori strada, siamo pronti per iniziare a esaminare che cosa assomiglia a un flusso di lavoro base. Che sarà oggetto del mese prossimo.
.jpg)
Don Jones è un Windows PowerShell MVP Award vincitore e redattore di TechNet Magazine. Egli è coautore di quattro libri su Windows PowerShell versione 3, tra cui diversi titoli gratuiti sulla creazione di report HTML in Windows PowerShell e Windows PowerShell Remoting. Trovarli tutti a PowerShellBooks.com, o chiedere Jones la tua domanda nel forum di discussione a PowerShell.org.