¿Método para integrar scripts de Powershell con flujo de trabajo que no sea Windows?

16

Me encanta el olor de las máquinas nuevas en la mañana.

Estoy automatizando un flujo de trabajo de creación de máquinas que involucra varios sistemas separados en mi infraestructura, algunos de los cuales involucran scripts perl de 15 años en hosts Solaris, sistemas Linux de arranque PXE y Powershell en Windows Server 2008.

Puedo guiar cada una de las partes individuales, e integrar la automatización de Linux y Unix es bastante sencillo, pero no sé cómo vincular de manera confiable los scripts de Powershell con el resto de los procesos.

Preferiría que el proceso comenzara en un host Linux, ya que imagino que terminará como una aplicación web que vive en un servidor Apache, pero si necesita comenzar en Windows, dudo que esté de acuerdo con eso.

Idealmente me gustaría algo similar a psexec para que Linux se ejecute contra Windows, pero Cygwin parece responder a esa dirección , y aunque aprecio todo el arduo trabajo que hicieron, nunca se sintió bien , Si sabes a lo que me refiero. Es ideal para un escritorio y ofrece mucha funcionalidad, pero siento que los servidores de Windows deberían tratarse como servidores de Windows y no como máquinas Unix bastardas (que, por cierto, es mi argumento en contra de los servidores OSX, y en realidad son Unix) . De todos modos, no quiero ir con Cygwin a menos que sea la última y única opción.

Entonces, supongo que lo que pregunto es si hay una manera de ejecutar trabajos en máquinas Windows desde Linux. Sin Cygwin Estoy abierto a ideas y sugerencias, incluyendo "Mira idiota, todos usan Cygwin, así que aguanta y lidia con eso". ¡Gracias por adelantado!

linux windows powershell automation Matt Simmons
fuente

Respuestas:

5

He pasado horas trabajando en este mismo problema y eventualmente se redujo a dos opciones viables (hay muchas opciones no viables):

  1. Cree un cuadro de Windows con un servicio IIS que aloje un WebAPI que esté dominado y configurado de tal manera que las sesiones de WinRM del mismo funcionen.
  2. Cygwin

Con la segunda opción, estás atrapado luchando a través de la capa de abstracción GNU / Posix para llegar a los bits reales de Windows. Lo que restringe lo que puedes hacer con él.

La primera opción construye una capa de abstracción basada en la web que usted escribe encima de su instalación completa de Windows de pila nativa. Si está dispuesto a trabajar, el servidor maestro de Linux solo tiene que hacer un montón de llamadas curl para hacer lo que necesita hacer. Sin embargo, esto funciona mejor cuando los scripts son disparar y olvidar, ya que construir un sistema de devolución de llamada es mucho más esfuerzo.

sysadmin1138
fuente
Tenía miedo de esa primera opción :-) Hay un gran tanque de tiburones lleno de problemas allí, esperando a morderme si también lo hago mal. Autenticación, análisis de errores, seguridad general de la aplicación ... etc, etc. Pero gracias por la entrada. Me alegro de no ser la única persona que se obsesionó con esto.
Matt Simmons
2
@MattSimmons Hice algo similar en $ Job-1. Las restricciones de IP de IIS facilitan mucho esto; Si las llamadas a la API solo pueden provenir de un host, reduce bastante la superficie de ataque.
sysadmin1138
No lo he usado, pero por lo que he leído, WinRM puede ejecutarse por sí solo (sin IIS o una API personalizada). Use enrutamiento restrictivo y autenticación Kerberos y suena (SONIDOS) como si pudiera ser bastante seguro. Pensamientos?
laughingbovine
@laughingbovine El problema siempre ha sido el soporte de WinRM. El método IIS que propongo permite enfrentar PowerShell con una API REST que es compatible con casi todo. El soporte WinRM apenas es compatible con algunos lugares. En los casi tres años transcurridos desde que escribí esto, ese apoyo probablemente ha mejorado desde el estado inexistente que tenía en 2012.
sysadmin1138
3

También puede comprar software multiplataforma de programación o automatización de flujo de trabajo que puede iniciar scripts nativos en muchos hosts en función de acciones anteriores, o incluso sus resultados devueltos. Las grandes empresas usan software como Tivoli, UC4, Espresso (CA dSeries, ahora) que hace esto, y lo he usado en grandes empresas que necesitaban hacer este tipo de cosas. Para su información, a menudo tienen soporte nativo para cosas como trabajos de Oracle, para darle una idea del precio que podría estar viendo.

(En mi trabajo anterior, también usaban Cygwin de todos modos , para poder usar los mismos scripts de Perl sin modificaciones cuando las cargas de trabajo se movían entre plataformas. Mucha diversión).

También podría intentar crear el suyo, como sugiere @ sysadmin1138; eso sería un proyecto divertido, e incluso podría terminar siendo lo suficientemente robusto como para ser utilizable y no molestarlo a las 2 AM cuando las exportaciones financieras fracasan en el primer intento.

mfinni
fuente
1
Afortunadamente, ya no paso datos financieros :-) Esto es automatización para una universidad. Factor de fruncido mucho más bajo.
Matt Simmons
3

Usaría la función Powershell Web Access presentada en Powershell v3.0. Esto le permite usar scripts de Powershell desde un host Linux.

Roy Kaldung
fuente
2

El servidor PowerShell le permite ingresar SSH a un servidor Windows y obtener una consola PowerShell. No lo he usado más allá de la prueba gratuita, pero mi uso informal me demostró que era un producto bastante confiable.

cuello largo
fuente
Bleh, su precio es tal que está diseñado para el uso del servidor de implementación en lugar de 'implementar en todo lo que necesita administrarse de forma remota'. Funcionable, solo un modelo diferente al de Linux.
sysadmin1138
2

Qué asqueroso quieres sentirte después, porque siempre hay telnet :)

En serio, ¿por qué necesita el servidor Linux para llamar al script de PowerShell? ¿Puede rediseñar su flujo de trabajo para que el servidor Linux simplemente entregue la imagen boot.wim correcta a través de tftp a un host con arranque PXE? He tenido buena suerte en el pasado manteniendo una imagen de Windows con diferentes archivos de respuesta en un servidor de archivos de Windows y entregando una imagen de arranque WinPE personalizada usando tftpd desde un host Linux. Luego, puede hacer que el archivo de respuesta llame al script de PowerShell correcto y no tiene que lidiar con la astucia multiplataforma como Cygwin.

MDMarra
fuente
Oh, si fuera tan fácil. No estaba bromeando sobre la parte de Perl de 15 años. He estado aquí durante 3 meses y todavía no sé cómo funcionan todas las interconexiones, pero sé que son muchas y variadas, con una sutileza que lleva a las personas que han estado aquí por años a completamente no tenga en cuenta las características documentadas en las herramientas existentes desarrolladas internamente porque nadie está seguro de si / cuándo / cómo se depuran. Es peludo Será un proyecto de varios años para arreglarlo todo.
Matt Simmons
@MattSimmons Supongo que no entiendo completamente los requisitos entonces :-) ¿Por qué el servidor Linux necesita llamar al script de PowerShell? En el pasado, he solucionado este requisito manteniendo la información de aprovisionamiento de la máquina en una base de datos (que puede actualizar el servidor * nix) y luego WinPE consulta esa base de datos al determinar qué archivo de respuesta aplicar. Seguramente algo similar se puede adaptar a casi cualquier entorno, ¿verdad? Básicamente es solo reconstruir MDT desde cero por ti mismo je
MDMarra
Hay cosas que (en algunos casos) deben suceder en el lado de Windows cada vez que se ejecuta el script de la nueva máquina. PODRÍA comenzar las cosas desde el lado de Windows, pero necesitaría construir un nuevo servidor de aplicaciones web para la interfaz frontal cuando llegue ese momento, y estoy mucho más cómodo haciendo eso con PHP en Linux que C # (o lo que sea) en Windows . Pero como dije, si tengo que hacerlo, tengo que hacerlo.
Matt Simmons
2

Podría usar algo como nrpe para ejecutar de forma remota el script de PowerShell en el host de Windows. Es posible que desee modificar sus scripts de PowerShell para devolver códigos de salida como se esperaba por nrpe, pero no hay ninguna razón por la que no pueda llamar a check_nrpe desde sus scripts en su host de Linux.

rorr
fuente
1
Eso es deliciosamente contra-intuitivo. Me gusta. Es un gran truco, pero aún así, creativo! Gracias.
Matt Simmons
2

Sobre el tema de los hacks contraintuitivos , ¿ha considerado abusar del software de integración continua como una herramienta de orquestación multiplataforma?

Instale el maestro de CI donde sea más conveniente, instale el agente en su caja de Windows (ya sea esto o esto ), configure un trabajo para ejecutar su script de PowerShell (ya sea invocando directamente usando la configuración de Comando por lotes de Windows o usando un complemento si lo desea escribir / mantener su script dentro de la aplicación CI) en su agente de Windows y activar el trabajo de forma remota a través de curl o similar.

Greg trabajo
fuente
0

Trabajo en una gran empresa donde este problema es común. Para los procesos que actualmente admitimos, nuestro enfoque es hacer que los sistemas Unix realicen llamadas web a un servidor Windows "administrador" que ejecuta ColdFusion en IIS. Tenemos clases y funciones que se activan a partir de solicitudes GET que utilizan la directiva "cfexecute" para lanzar scripts de PowerShell específicos. Es feo pero funciona. Estamos analizando las características del servicio web powershell v3 para migrar y evitar que ColdFusion actúe como intermediario.

Ryan Fisher
fuente