powershell - 如何在企业中使用 PowerShell 和 PowerShell 模块

Question

最近，我加入了我企业的 Windows 团队，凭借我的开发人员背景(一般是 Java、.NET 和 Web)，我很快就对 PowerShell 产生了兴趣。我可以看到它比普通的旧批处理文件、VB 更有值(value)……这就是为什么我想推广它的使用，并且一点一点地插入人们喜欢它而不是其他的，除非有理由不这样做。

部署 PowerShell 看起来非常简单，因为我们可以轻松地批准 WSUS 中的相关补丁并通过 GPO 为 AD 集成服务器配置执行策略。

我的问题实际上更多是关于 PowerShell 和 PowerShell 模块(例如 PCSX、PowerShellPack、自制……)的分布和使用。

对于那些已经在企业中部署 PowerShell 的人:

您是否有某种用于 PowerShell 的标准包，其中包含您在每台服务器上部署的一组模块？如果这样做，那么如何部署已安装模块的新版本？

您是否放置了一个中央 PowerShell 存储库来存储所有 PowerShell 模块？如果是这样，该存储库是否可以全局访问，或者您是否还有同步的辅助存储库？

我已经习惯了 Maven、Ivy 和其他依赖管理软件等工具，这就是为什么我对 PowerShell 在这方面提供的功能有点失望的原因。

我找到了 a very nice article about this subject并且可能会走同样的路，因为它符合我的要求。

你使用 WinRM 吗？您是直接从工作站连接还是有中央管理服务器？您是否将 WinRM 的访问权限限制在那些管理服务器上？

您是否在非托管环境(不在 AD 域中的服务器)中使用 WinRM？如何配置 WinRM？

我们有一个网络区域，其中的服务器不属于 AD 域，因此我不能依赖 Kerberos 身份验证来进行 WinRM。

在全局范围内，您的经验是什么，您对结果满意吗？

编辑:
关于问题 2，我们决定建立一个中央存储库。

我们的想法是拥有一个受版本控制 (GIT) 控制的主存储库，并且我们将是唯一拥有写入权限的存储库。

从该存储库中，我们将使用类似 rsync 的工具(在我们的示例中为 robocopy)将模块复制到其他辅助存储库(将是只读副本)。客户端只能访问那些存储库(我们只需更新这些客户端上的 PSModulePath 以确保它们可以访问存储库)。

我们还将分阶段发布我们的版本，因此在存储库中，将有多个版本可用:开发、集成和生产。

Answer 1

让我们按类别讨论每个问题。

布道

为了让您的同事开始对 PowerShell 产生兴趣，我建议从自动化的面包和黄油开始。找到一个相对容易实现的常见痛点(快速将某些东西呈现在您的同事面前)并使用 PowerShell 将其自动化。然后从那里扩展。

另一个好主意是在您的办公室建立一个“脚本俱乐部”，在那里您可以进行一些培训并分享有关在 PowerShell 中编写脚本的想法或问题。您可以每隔几周开始一次，看看情况如何。在我的工作中，我们有一个读书俱乐部，我们在那里阅读各种关于测试、设计和编程的技术书籍，它运作良好。

包装

模块 - PowerShell 模块是最好的打包形式。它们非常易于使用，并提供了一些不错的功能，例如易于部署和私有(private)变量/函数。

脚本 - 脚本是进行中或开始工作的好主意，因为您的同事肯定会对脚本感到满意。

部署

目前有几个部署选项。

部署到每台机器 - 这可以避免一些网络问题，并为每台机器提供更大的灵 active ，但缺点是更新模块可能更痛苦。

中央存储库 (又名网络共享) - 您还可以将所有模块存储在中央网络共享上。这将避免部署到每台机器的问题，并且如果您想控制修改，您可以将模块设为只读。但是您仍然需要为每台机器部署一个配置文件才能将网络共享添加到 $env:PSModulePath 多变的。最好在 all-users-all-hosts 配置文件中进行设置。从那时起，除非路径更改，否则您不需要更新它。

NuGet - NuGet是一个将包管理引入 .NET 开发的开源项目。它的好处是能够拥有公共(public)存储库和本地/私有(private)存储库。已经有一个initial version的 PowerShell module这将利用 NuGet 进行 PowerShell 模块部署。

远程访问

作为一名构建工程师，我拥有相对较少的机器并且可以完全控制它们。所以我启用了远程处理。您将不得不向一些 IT 人员寻求更好的建议。