本文介绍了如何将自定义 PowerShell 模块导入远程会话?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个自定义 PowerShell 模块,我想在与另一台计算机的远程会话的上下文中使用它.以下代码(显然不起作用)解释了我要实现的目标:

I'm developing a custom PowerShell module, which I'd like to use in context of a remote session to a different computer. The following code (which obviously doesn't work) explains what I'm trying to achieve:

import-module .\MyCustomModule.psm1
$session = new-pssession -computerName server01
invoke-command -session $session -scriptblock {
  <# use function defined in MyCustomModule here #>
}

第一个问题是是否有可能实现这种场景?我的意思是我只希望我的自定义模块物理存在于我的机器上,而不是远程服务器上.

The first question is whether it is at all possible to achieve this scenario? I mean I would only like my custom module to be physically present on my machine, not on remote server.

我找到了这个帖子,但我没有设法让它工作 - 它不允许从远程机器创建一个会话回到本地机器.可能我遇到了该线程评论中提到的配置限制......此外,作者提到了对我的解决方案至关重要的性能影响......

I have found this thread, but I didn't manage it to work - it doesn't allow creating a session from remote machine back to the local one. Probably, I faced with the configuration limitations mentioned somewhere in the comments to that thread... Besides, the author mentioned the performance implications which is critical for my solution...

如果可以,那怎么做?

PowerShell 的版本目前没有限制 - 如果解决方案仅在 PS 3.0 中可用 - 我可以接受.

The version of PowerShell is currently not a constraint - if the solution is only available in PS 3.0 - I can live with this.

推荐答案

对这个问题有一些很好的评论,我花了一些时间研究解决问题的各种方法.

There were some great comments to the question, and I've spent some time investigating various ways to approach the problem.

首先,我最初的要求是不可能的.我的意思是,如果您采用模块方式,那么该模块应该物理存在于目标机器上,以便能够Import-Module 进入远程会话.

To begin with, what I've initially asked for is not possible. I mean, if you go the module way, then the module should be physically present on a target machine to be able to Import-Module into remote session.

为了进一步抽象我的问题,我正在尝试为产品部署创建一个可重用的基于 PowerShell 的框架.这将是一种推送方式部署,这意味着我们鼓励人们在本地机器上运行一些脚本以部署到某个远程服务器.就我调查的领域而言,有两种可能的方式符合常识.

To abstract my question further, I'm trying to create a reusable PowerShell-based framework for the product deployments. It's going to be a push-manner deployments, meaning that we encourage people to run some scripts on a local machine to deploy to some remote server. As far as I investigated the area, there are two possible ways which are friendly to the common sense.

流程如下:

  • 将每个逻辑上不同的功能块放入 PowerShell 模块 (*.psm1)
  • 将模块分发到远程机器并扩展 PSModulePath 变量以包含新模块位置
  • 在客户端机器上,创建一个到远程服务器的新会话,并使用 Invoke-Command -Session $s -ScriptBlock {...}
  • 在从 Import-Module CustomModule 开始的脚本块中 - 它将在远程机器上搜索 CustomModule 并且显然会找到它
  • place each logically different piece of functionality into the PowerShell module (*.psm1)
  • distribute the module to the remote machine and extend the PSModulePath variable to include the new modules location
  • on a client machine, create a new session to the remote server, and use Invoke-Command -Session $s -ScriptBlock {...}
  • in the script block start from Import-Module CustomModule - it will search the CustomModule on a remote machine and obviously will find it

以下是喜欢这种方法的原因:

The following are the reasons to love this approach for:

  • 传统模块角色的结果 - 促进可重用库的创建
  • 根据好书Windows PowerShell in Action,模块可用于创建特定领域的应用程序".据我了解,可以通过结合模块嵌套和混合脚本/二进制模块来暴露特定领域特定的直观界面来实现.基本上,这是我最看重的基于 PowerShell 的部署框架的目标
  • the consequence of the traditional module role - facilitate the creation of reusable libraries
  • according to the great book Windows PowerShell in Action, "modules can be used to create domain-specific applications". As far as I understand, it can be achieved by combining the module nesting and mixing script / binary modules to expose the intuitive interface specific to a certain domain. Basically, this is the one I value most for the goal of PowerShell-based deployment framework

需要考虑以下几点:

  • 您必须找到一种方法将自定义模块交付到远程机器.我玩过 NuGet,我不确定它是否适合这项任务,但还有其他选择以及,例如,共享文件夹中的 MSI 安装程序或普通 xcopy.此外,交付机制应该支持升级/降级和(最好)多实例安装,但这与我的任务更相关,而不是一般问题
  • You have to find a way to deliver the custom modules to the remote machine. I have played with NuGet, and I'm not sure it suits well for the task, but there are other options as well, for instance, MSI installer or plain xcopy from the shared folder. Besides, the delivery mechanism should support upgrade / downgrade and (preferably) multi-instance installations, but that's more related to my task than to the problem in general

流程如下:

  • 将每个逻辑上不同的功能放在单独的 PowerShell 脚本 (*.ps1) 中
  • 在客户端计算机上,创建到远程服务器的新会话,并使用 Invoke-Command -Session $s -FilePath .\myscript.ps1 将脚本中定义的函数加载到远程会话
  • 使用另一个 Invoke-Command -Session $s -ScriptBlock {...} 并引用您的自定义函数 - 它们将在会话中存在
  • place each logically different piece of functionality in a separate PowerShell script (*.ps1)
  • on a client machine, create a new session to the remote server, and use Invoke-Command -Session $s -FilePath .\myscript.ps1 to load the functions defined in a script to the remote session
  • use another Invoke-Command -Session $s -ScriptBlock {...} and refer to your custom functions - they will be there in a session

以下是这种方法的优点:

The following are good points of this approach:

  • 这很简单——您不必了解模块特性.只需编写普通的 PowerShell 脚本即可
  • 您无需向远程机器交付任何内容 - 这使得解决方案在维护过程中更加简单且不易出错

当然,这并不理想:

  • 对解决方案的控制较少:例如,如果您将一组函数导入"到会话中,所有这些函数都将被导入"并对用户可见,因此没有封装"等.我相信很多解决方案都可以接受这一点,所以不要只根据这一点来决定
  • 每个文件中的功能必须是自包含的 - 从那里的任何点源或模块导入都将搜索远程机器,而不是本地机器

最后,我应该说远程机器仍然需要为远程处理做好准备.这就是我的意思:

Finally, I should say that remote machine still needs to be prepared for the remoting. This is what I mean:

  • 执行策略应该改成一些东西,因为它默认是受限制的:Set-ExecutionPolicy Unrestricted
  • 应启用 PowerShell 远程处理:Enable-PSRemoting
  • 应该将脚本运行的帐户添加到远程服务器的本地管理员
  • 如果您计划在远程会话中访问文件共享,请确保您了解 multi-跳跃身份验证并采取适当的行动
  • 确保您的防病毒软件是您的朋友,并且不会将您发送至 PowerShell 地狱

这篇关于如何将自定义 PowerShell 模块导入远程会话?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-14 14:44