Windows PowerShell: El entorno de Windows PowerShell Workflow
Durante este año, Don Jones presentará todos los meses la entrega de un tutorial en 12 partes sobre Windows PowerShell Workflow. Le recomendamos que lea la serie en orden, empezando por el columna de enero 2013.
Don Jones
Como expliqué el mes pasado, el flujo de trabajo de Windows PowerShell es una nueva característica en la versión 3 del marco de la gestión de Windows. Está preinstalado en Windows Server 2012 y Windows 8. También está disponible para Windows 7, Windows Server 2008 y Windows Server 2008 R2. Usted necesitará uno de los sistemas operativos para ejecutar un flujo de trabajo. Usted también puede tener un objetivo de flujo de trabajo — es decir, realizar tareas contra — cualquier versión de Windows, dependiendo de la tarea que se está tratando de lograr.
Existen dos requisitos principales para usar Windows PowerShell Workflow, además de los requisitos de sistema estándar para Windows PowerShell versión 3. En primer lugar, usted necesitará utilizar el módulo de PSWorkflow incluido para habilitar funciones de flujo de trabajo dentro de la cáscara. En segundo lugar, usted tiene que tener Windows PowerShell Remoting habilitado en las máquinas que va a atacar con flujo de trabajo de Windows PowerShell.
Interacción remota no necesita necesariamente a ejecutarse en la máquina donde ejecutar flujos de trabajo, pero cualquier máquinas va a inventario, configurar o administrar lo contrario tendrá que tener remoto habilitado. Flujo de trabajo de Windows PowerShell utiliza Remoting como su Protocolo de comunicación primaria. Hay probablemente algunos flujos podría escribir que no haría falta comunicación remota, pero son pocos y distantes entre.
Comunicación remota es un componente muy incomprendido de Windows PowerShell. Las organizaciones más que unos amigos de seguridad IT adoptan un enfoque-no implementar. Que es desafortunado y lamentable. Esas mismas personas conscientes de la seguridad no tienen ningún problema, lo que permite un gran número de gestión de otro protocolos de comunicaciones como Remote Desktop Protocol (RDP), llamadas de procedimiento remoto (RPC) y HTTP.
Comunicación remota es el camino a seguir para las comunicaciones de gestión en un entorno Windows. Microsoft pronto comenzará a consolidar los protocolos mayores en Remoting. Comunicación remota utiliza HTTP y HTTPS, es altamente configurable y manejable, y usted puede centralmente bloquearlo abajo con un objeto de directiva de grupo (GPO). También es generalmente más seguro, más auditable y más controlable que los protocolos mayores. Para una discusión más completa de las implicaciones de seguridad de Remoting y su arquitectura, considere descarga gratis e-book, "secretos de PowerShell Remoting."
Dentro de un flujo de trabajo
El mayor desafío que tendrás al acercarse a flujo de trabajo de Windows PowerShell es recordar que se parece a una secuencia de comandos de Windows PowerShell (en concreto, una función), pero no es. El "idioma de Windows PowerShell" escribes es traducido a un lenguaje externo (XAML). Entonces es ejecutado por tecnología no - Windows PowerShell.
Como resultado, hay unas reglas diferentes. Algunos de los que son puramente sintácticas. En términos generales, usted necesitará utilizar nombres de cmdlet completo para ejecutar los cmdlets. Además, no pueden parámetros posicionales y nombres de parámetro truncado. Se deben utilizar nombres de parámetro completo.
¿Qué puede ser más confuso es el ambiente general dentro de un flujo de trabajo. La idea de un flujo de trabajo es que puede interrumpir y reanudar el flujo de trabajo deliberadamente o hacerlo en reacción a algo va mal en su entorno (como una pérdida de energía).
Significa que cada comando en un flujo de trabajo debe esencialmente stand alone. Debe tener ningún conocimiento de lo que han hecho otros comandos y ningún medio nativo de datos persistentes entre los comandos. También significa que no puede establecer una variable para mantener la salida de un comando y luego pasar esa variable como entrada a otro comando. Simplemente no funcionará. Además, usted no puede cargar módulos que contienen comandos adicionales. No hay ningún entorno persistente cargar el módulo.
El bloque especial de {} de JSON que puede entrar en un flujo de trabajo ahora se convierte en su mejor amigo. Cada JSON básicamente se ejecuta como una sola unidad. Windows Workflow Foundation (WWF) gira una copia de Windows PowerShell, atascos en el JSON entero, y funciona. El contenido de un JSON se comporta como una secuencia de comandos de Windows PowerShell tradicional.
También hay un implícito JSON. WWF realmente no puede ejecutar comandos de Windows PowerShell fuera un JSON. Cuando utilizas un cmdlet de Windows PowerShell en su flujo de trabajo, Windows PowerShell comprueba si un nativo WWF equivalente está disponible y dice WWF correr en su lugar.
El equipo de Windows PowerShell ha escrito equivalentes de WWF para muchos nativos comandos de Windows PowerShell, pero cuando intenta utilizar un cmdlet que no tiene una versión nativa de la WWF, Windows PowerShell implícitamente ajusta su comando en un bloque de JSON. Esto hace que WWF iniciar Windows PowerShell, ejecute el comando, luego cerrar esa instancia de Windows PowerShell.
Esta falta de persistencia entre comandos es lo que ayuda a Windows PowerShell Workflow hacer reanudar las secuencias de comandos. Se trata de una gran parte de por qué Windows PowerShell Workflow puede paralelizar comandos dentro de un script. Convierte en máquinas de automatización multiproceso. Sin embargo, la falta de persistencia es una salida importante de secuencias de comandos de Windows PowerShell como normales y trabajo. Se necesita mucho de planificación adicional para que un script funcione correctamente.
No es raro ver a los flujos de trabajo que consisten en un montón de bloques de JSON. Ni será raro ver flujos de trabajo que no son más que un bloque único y largo de JSON.
Estos flujos de trabajo tendrá capacidades de paralelización o curriculum vitae limitadas (o inexistentes). Un JSON es una sola unidad de trabajo. Simplemente podría optar ejecutar estos scripts como funciones normales, usando Remoting en lugar de flujos de trabajo. Usted estaría consiguiendo muy pocos de los beneficios reales de flujo de trabajo de Windows PowerShell de todos modos.
Tenga a mano estos
Una cosa que claramente carece de flujo de trabajo de Windows PowerShell es un medio de conservar los datos de un flujo de trabajo entre los comandos. Sería útil en una amplia gama de circunstancias. Si un flujo de trabajo se interrumpe y se reanudó, comandos podrían fácilmente recrear la información de estado como direcciones IP, nombres de equipo, nombres de usuario o cualquier otra cosa y continuar corriendo.
Dada esta carencia nativa, es algo que usted probablemente querrá crear para sí mismo. Establecer una instancia de SQL Server (incluso una instancia de Express gratis) y crear tablas de base de datos en la que los flujos de trabajo pueden guardar datos. Un flujo de trabajo va a necesitar algún medio de sí mismo, identifica de forma única como el nombre de flujo de trabajo y el nombre del equipo que se dirige cada instancia de flujo de trabajo.
Su flujo de trabajo puede ser entonces un número de bloques discretos de JSON. Cada uno se lee el estado actual de la base de datos, realizar alguna tarea y, si es necesario, actualizar la base de datos con nueva información. Es una lástima que características de flujo de trabajo de Windows PowerShell no pueden ayudar a automatizar esto. Tal vez un "flujo de trabajo de $: variable" arquitectura que utiliza archivos XML o SQL Server bajo el capó podría ayudar, pero eso es algo para una futura versión.
La buena noticia es que es bastante fácil de persistencia "roll your own", usando el SQL Server. SQL Server es preferible a archivos XML porque es más escalable y se puede acceder más fácilmente desde múltiples ubicaciones de red, soporta mejor acceso simultáneo de múltiples instancias a la vez.
La clase de Microsoft .NET Framework System.Data.Sql.SqlClient es fácil de usar. Hay ejemplos en mi "Fabricación de utillajes PowerShell aprender en un mes de comidas" e-book. De hecho, mi coautor y he creado un módulo completo usted puede reutilizar y descargar gratis como parte de los scripts de muestra del libro.
Con estos preliminares fuera del camino, ya estamos listos para empezar a examinar lo que parece un flujo de trabajo básico. Será el tema de la columna del mes que viene.
.jpg)
Don Jones es un ganador del premio MVP de Windows PowerShell y editor colaborador para la TechNet Magazine. Él ha coautor de cuatro libros sobre Windows PowerShell versión 3, incluyendo varios títulos libres en la creación de informes HTML en Windows PowerShell y Windows PowerShell Remoting. Encontrarlos todos en PowerShellBooks.com, o Jones su pregunta en los foros de discusión en PowerShell.org.