如何在企业中使用 PowerShell 和 PowerShell 模块 [英] How to use PowerShell and PowerShell modules in the enterprise

问题描述

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

Recently, I've joined the Windows team in my enterprise and with my developer background (Java, .NET and Web in general), I was pretty quickly interested in PowerShell. I can see its value over plain old batch files, VB, ... which is why I'd like to promote its usage and, little by little, push people to favor it over the rest unless there's a reason not to do so.

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

Deploying PowerShell seems pretty straightforward since we can easily approve the relevant patches in WSUS and configure the execution policy via GPO for the AD integrated servers.

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

My questions are in fact more about the distribution and usage of PowerShell and PowerShell modules (e.g., PCSX, PowerShellPack, home made, ...).

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

For those of you who have already deployed PowerShell in your enterprise:

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

1. Do you have some sort of standard package for PowerShell with a set of modules that you deploy on each server? If you do, then how do you deploy new versions of the installed modules?

您是否在存储所有 PowerShell 模块的地方放置了一个中央 PowerShell 存储库?如果是这样，该存储库是可全局访问的还是您同步的辅助存储库?

Did you put a central PowerShell repository in place where you store all your PowerShell modules? If so, is that repository accessible globally or do you also secondary repositories that you synchronize?

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

I'm pretty used to tools such as Maven, Ivy and other dependency management software, which is why I'm a bit disappointed by what PowerShell has to offer in this regard.

我发现一个非常关于这个主题的好文章并且可能会沿着相同的路径走下去，因为它符合我的要求.

I've found a very nice article about this subject and will probably go down the same path, as it corresponds to my requirements.

您使用 WinRM 吗?您是直接从工作站连接还是有中央管理服务器?您是否将 WinRM 的访问权限限制为这些管理服务器?

Do you use WinRM? Do you connect directly from workstations or do you have central management servers? Did you limit access to WinRM to those management servers?

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

Do you use WinRM in a non-managed environment (servers not in an AD domain)? How do you configure WinRM?

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

We have a network zone in which the servers aren't part of an AD domain, thus I can't rely on the Kerberos authentication for WinRM.

在全球范围内，您的体验如何，您对结果满意吗?

Globally, what is your experience, are you satisfied with the results?

关于问题 2，我们决定建立一个中央存储库.

Regarding question 2, we've decided to put a central repository in place.

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

The idea will be to have a main repository which will be under version control (GIT) and to which we'll be the only ones to have write access.

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

From that repository, we will copy the modules using an rsync like tool (in our case that'll be robocopy) to other secondary repositories (which will be read-only copies). Only those repositories will be accessible by the clients (we'll just have to update the PSModulePath on those clients to make sure they can access the repository).

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

We'll also stage our releases, thus in the repository, there'll be multiple versions available: Development, Integration and Production.

推荐答案

让我们按类别介绍每个问题.

Let's cover each issue by category.

传福音

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

To start off interest in PowerShell to your coworkers, I would suggest starting off with the bread and butter of automation. Find a common pain point that is relatively easy to implement (to get something out there in front of your coworkers quickly) and automate it with PowerShell. Then expand from there.

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

Another good idea is to start a "Script Club" at your office where you do some training and share ideas or problems about scripting in PowerShell. You can start out with once every few weeks and see how it goes. At my work, we have a book club where we go through various technical books on testing, design, and programming, it works well.

包装

• 模块 - PowerShell 模块是最好的打包形式.它们非常易于使用，并提供了一些不错的功能，例如易于部署和私有变量/函数.
• 脚本 - 对于正在进行的工作或开始工作，脚本是一个好主意，因为您的同事肯定会对脚本感到满意.

• Modules - PowerShell modules are the best form of packaging. They are quite easy to use and offer some nice features such as easy deployment and private variables/functions.
• Scripts - Scripts are a good idea for work-in-progress or to start off since your coworkers will certainly be comfortable with scripts.

部署

目前有几个部署选项.

• 部署到每台机器 - 这可以避免一些网络问题，并为每台机器提供更大的灵活性，但缺点是更新模块可能更麻烦.
• 中央存储库(又名网络共享)- 您还可以将所有模块存储在中央网络共享上.这将避免部署到每台机器时出现的问题，如果您想控制修改，您可以将模块设为只读.但是您仍然需要为每台机器部署一个配置文件，以将网络共享添加到 $env:PSModulePath 变量.最好在 all-users-all-hosts 配置文件中设置它.从那时起，除非路径发生变化，否则您不需要更新它.
• NuGet - NuGet 是一个开源项目，它将包管理引入.NET 开发.它的优点在于能够拥有公共存储库和本地/私有存储库.已经有一个初始版本一个 PowerShell 模块 将利用 NuGet 进行 PowerShell 模块部署.

• Deploy to every machine - This could avoid some network issues and gives you more flexibility with each machine, but the downside is that updating modules may be more of a pain.
• Central repository (a.k.a. a network share) - You could also store all your modules on a central network share. This would avoid issues with deploying to every machine and you can make the modules read-only if you want to control modifications. But you would still have to deploy a profile to each machine to add the network share to the $env:PSModulePath variable. It would be best to set this in the all-users-all-hosts profile. From then on you shouldn't need to update it unless the path changes.
• NuGet - NuGet is an open source project that is bringing package management to .NET development. What is nice about it is the ability to have public repositories and local/private repositories. There is already an initial version of a PowerShell module that will leverage NuGet for PowerShell module deployment.

远程访问

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

Being a build engineer, I have relatively few machines and full control over them. So I have remoting enabled. You would have to ask some IT guys for better advice.

这篇关于如何在企业中使用 PowerShell 和 PowerShell 模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！