Méthode pour intégrer des scripts Powershell avec un workflow non Windows?

16

J'adore l'odeur des nouvelles machines le matin.

J'automatise un workflow de création de machine qui implique plusieurs systèmes distincts dans mon infrastructure, dont certains impliquent des scripts perl de 15 ans sur les hôtes Solaris, les systèmes Linux de démarrage PXE et Powershell sur Windows Server 2008.

Je peux créer un script pour chacune des parties individuelles, et l'intégration de l'automatisation Linux et Unix est assez simple, mais je ne sais pas comment lier de manière fiable les scripts Powershell au reste des processus.

Je préférerais que le processus commence sur un hôte Linux, car j'imagine qu'il se terminera comme une application Web vivant sur un serveur Apache, mais s'il doit commencer sur Windows, je suis d'accord avec hésitation.

J'aimerais idéalement que quelque chose du genre psexec pour Linux s'exécute contre Windows, mais la réponse dans ce sens semble être donnée par Cygwin , et autant que j'apprécie tout le travail acharné qu'ils ont fourni, cela n'a jamais semblé juste , si tu vois ce que je veux dire. C'est génial pour un bureau et donne beaucoup de fonctionnalités, mais je pense que les serveurs Windows devraient être traités comme des serveurs Windows et non des machines Unix bâtardes (ce qui, soit dit en passant, est mon argument contre les serveurs OSX, et ils sont en fait Unix) . Quoi qu'il en soit, je ne veux pas aller avec Cygwin sauf si c'est la dernière et la seule option.

Donc je suppose que ce que je demande, c'est s'il existe un moyen d'exécuter des travaux sur les machines Windows à partir de Linux. Sans Cygwin. Je suis ouvert aux idées et suggestions, y compris "Regardez idiot, tout le monde utilise Cygwin, alors aspirez-le et traitez-le". Merci d'avance!

— Matt Simmons
source

5

J'ai passé des heures à marteler ce problème et il s'est finalement résolu à deux options viables (il y a beaucoup d'options non viables):

Créez une boîte Windows avec un service IIS hébergeant une WebAPI qui est à la fois dominée et configurée de manière à ce que les sessions WinRM à partir de celle-ci fonctionnent.
Cygwin

Avec la deuxième option, vous êtes coincé à vous frayer un chemin à travers la couche d'abstraction GNU / Posix pour obtenir les bits réels de Windows. Ce qui restreint ce que vous pouvez en faire.

La première option crée à peu près une couche d'abstraction basée sur le Web que vous écrivez vous-même au-dessus de votre installation complète de Windows dans la pile native. Si vous êtes prêt à faire le travail, le maître-serveur Linux n'a qu'à faire un tas d'appels curl pour faire ce qui doit être fait. Cela fonctionne mieux quand les scripts sont incendiés et oubliés, car la construction d'un système de rappel est beaucoup plus difficile.

— sysadmin1138
source

J'avais peur de cette première option :-) Il y a un gros réservoir de requins plein de problèmes, attendant juste de me mordre si je le fais mal aussi. Authentification, analyse d'erreur, sécurité générale des applications ... etc etc etc. Mais merci pour l'entrée. Je suis content de ne pas être le seul à avoir raccroché là-dessus.

— Matt Simmons

2

@MattSimmons J'ai fait quelque chose de similaire à $ Job-1. Les restrictions IP IIS rendent cela beaucoup plus facile; si les appels d'API ne peuvent provenir que d'un seul hôte, cela réduit considérablement la surface d'attaque.

— sysadmin1138

Je ne l'ai pas utilisé, mais d'après ce que j'ai lu, WinRM peut fonctionner seul (sans IIS ni API personnalisée). Utilisez un routage restrictif et une authentification Kerberos et cela semble (SONS) comme s'il pouvait être assez sécurisé. Pensées?

— laughingbovine

@laughingbovine Le problème a toujours été le support de WinRM. La méthode IIS que je propose permet de faire face à PowerShell avec une API REST qui est prise en charge par à peu près tout. La prise en charge de WinRM est à peine prise en charge à quelques endroits. Depuis près de trois ans que j'ai écrit ceci, ce support s'est probablement amélioré par rapport à l'état inexistant qu'il était en 2012.

— sysadmin1138

3

Vous pouvez également acheter un logiciel de planification multiplateforme ou d'automatisation de workflow qui peut lancer des scripts natifs sur de nombreux hôtes en fonction des actions précédentes, ou même de leurs résultats renvoyés. Les grandes entreprises utilisent des logiciels comme Tivoli, UC4, Espresso (CA dSeries, maintenant) qui le font, et je l'ai utilisé dans les grandes entreprises qui avaient besoin de faire ce genre de choses. Pour info, ceux-ci ont souvent un support natif pour des choses comme les travaux Oracle, pour vous donner une idée du prix que vous pourriez consulter.

(Dans mon travail précédent, ils ont également utilisé Cygwin de toute façon , afin de pouvoir utiliser les mêmes scripts Perl sans modification lorsque les charges de travail se déplaçaient entre les plates-formes. Beaucoup de plaisir.)

Vous pouvez également essayer de créer le vôtre, comme le suggère @ sysadmin1138; ce serait un projet amusant, et pourrait même se révéler suffisamment robuste pour être utilisable et ne pas vous faire pager à 2 heures du matin lorsque les exportations financières échouent du premier coup.

— mfinni
source

1

Heureusement, je ne fais plus circuler de données financières :-) C'est de l'automatisation pour un collège. Facteur de plissement beaucoup plus faible.

— Matt Simmons

3

J'utiliserais la fonctionnalité Powershell Web Access introduite dans Powershell v3.0. Cela vous permet d'utiliser des scripts Powershell à partir d'un hôte Linux.

— Roy Kaldung
source

2

Le serveur PowerShell vous permet de vous connecter à un serveur Windows et d'obtenir une console PowerShell. Je ne l'ai pas utilisé au-delà de l'essai gratuit, mais mon utilisation informelle m'a prouvé que c'était un produit assez fiable.

— long cou
source

Bleh, leur prix est tel qu'il est conçu pour une utilisation sur un serveur de déploiement plutôt que de «se déployer sur tout ce qui doit être géré à distance». Fonctionnable, juste un modèle différent de Linux.

— sysadmin1138

2

Quelle grosseur voulez-vous ressentir après, car il y a toujours telnet :)

Sérieusement, pourquoi avez-vous besoin du serveur Linux pour appeler le script PowerShell? Pouvez-vous repenser votre flux de travail afin que le serveur Linux fournisse simplement l'image boot.wim correcte via tftp à un hôte démarré PXE? J'ai eu de la chance dans le passé de conserver une image Windows avec différents fichiers de réponses sur un serveur de fichiers Windows et de fournir une image de démarrage WinPE personnalisée à l'aide de tftpd à partir d'un hôte Linux. Ensuite, vous pouvez faire en sorte que le fichier de réponses appelle le bon script PowerShell et vous n'avez pas à vous occuper des plaisanteries multiplateformes comme Cygwin.

— MDMarra
source

Oh, si seulement c'était aussi simple que ça. Je ne plaisantais pas sur la partie perl de 15 ans. Je suis ici depuis 3 mois, et je ne sais pas encore comment toutes les interconnexions "fonctionnent", mais je sais qu'elles sont nombreuses et variées, avec une subtilité qui conduit les gens qui sont ici depuis des années à complètement ne pas tenir compte des fonctionnalités documentées dans les outils existants développés en interne car personne n'est sûr si / quand / comment ils sont débogués. C'est poilu. Ce sera un projet pluriannuel pour tout arranger.

— Matt Simmons

@MattSimmons Je suppose que je ne comprends pas complètement les exigences alors :-) Pourquoi le serveur Linux doit-il appeler le script PowerShell? Dans le passé, j'ai contourné cette exigence en conservant les informations de provisionnement de la machine dans une base de données (qui peut être mise à jour par le serveur * nix), puis WinPE interroge cette base de données lors de la détermination du fichier de réponses à appliquer. Certes, quelque chose de similaire peut être adapté à presque tous les environnements, n'est-ce pas? Il s'agit simplement de reconstruire MDT à partir de zéro par vous-même heh

— MDMarra

Il y a des choses qui (dans certains cas) doivent se produire du côté de Windows chaque fois que le script de la nouvelle machine s'exécute. Je pourrais commencer les choses du côté de Windows, mais j'aurais besoin de construire un nouveau serveur d'applications Web pour l'interface frontale le moment venu, et je suis beaucoup plus à l'aise avec PHP sur Linux qu'avec C # (ou autre) sur Windows . Mais comme je l'ai dit, si je le dois, je le dois.

— Matt Simmons

2

Vous pouvez utiliser quelque chose comme nrpe pour exécuter à distance le script PowerShell sur l'hôte Windows. Vous voudrez peut-être modifier vos scripts PowerShell pour retourner les codes de sortie comme prévu par nrpe, mais il n'y a aucune raison pour que vous ne puissiez pas appeler check_nrpe à partir de vos scripts sur votre hôte Linux.

— rorr
source

1

C'est délicieusement contre-intuitif. Je l'aime. C'est un hack majeur, mais toujours créatif! Merci.

— Matt Simmons

2

En ce qui concerne les hacks contre-intuitifs , avez-vous envisagé d'abuser du logiciel d'intégration continue comme outil d'orchestration multiplateforme?

Installez le maître CI à l' endroit le plus pratique, installez l'agent sur votre boîte Windows ( ceci ou cela ), configurez un travail pour exécuter votre script powershell (soit en l'invoquant directement à l'aide de la configuration de la commande par lots de Windows, soit en utilisant un plugin si vous le souhaitez) pour écrire / conserver votre script dans l'application CI) sur votre agent Windows et déclencher le travail à distance via curl ou similaire.

— Greg Work
source

0

Je travaille dans une grande entreprise où ce problème est courant. Pour les processus que nous prenons actuellement en charge, notre approche consiste à demander aux systèmes Unix de passer des appels Web vers un serveur Windows «admin» qui exécute ColdFusion sur IIS. Nous avons des classes et des fonctions qui sont déclenchées à partir de requêtes GET qui utilisent la directive "cfexecute" pour lancer des scripts PowerShell spécifiques. C'est moche mais ça marche. Nous examinons les fonctionnalités du service Web powershell v3 pour éviter que ColdFusion n'agisse en tant qu'intermédiaire.

— Ryan Fisher
source