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

Question

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

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

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

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

您是否为PowerShell提供了某种标准软件包,并在每台服务器上部署了一组模块？如果这样做,那么如何部署已安装模块的新版本？
您是否已将中央PowerShell存储库放在存储所有PowerShell模块的位置？如果是这样,该存储库是全局可访问的,还是您同步的辅助存储库？

我已经习惯了Maven,Ivy和其他依赖管理软件这样的工具,这就是为什么我对PowerShell在这方面提供的东西感到有点失望.

我找到了一篇关于这个主题的非常好的文章,可能会走同一条道路,因为它符合我的要求.
你使用WinRM吗？您是直接从工作站连接还是有中央管理服务器？您是否限制对这些管理服务器的WinRM访问？
您是否在非托管环境(不在AD域中的服务器)中使用WinRM？你如何配置WinRM？

我们有一个网络区域,其中服务器不属于AD域,因此我不能依赖WinRM的Kerberos身份验证.
在全球范围内,您的经验是什么,您对结果满意吗？

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

我们的想法是拥有一个将受版本控制(GIT)的主存储库,并且我们将成为唯一具有写访问权限的存储库.

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

我们还将发布我们的版本,因此在存储库中,将提供多个版本:开发,集成和生产.

Answer 1

让我们按类别涵盖每个问题.

福音主义

为了让您对同事们开始对PowerShell感兴趣,我建议您先从自动化的角度出发.找到一个相对容易实现的常见痛点(快速在同事面前展示一些东西)并使用PowerShell实现自动化.然后从那里扩展.

另一个好主意是在您的办公室启动一个"脚本俱乐部",在那里您可以进行一些培训,并在PowerShell中分享有关脚本编写的想法或问题.你可以每隔几周开始一次,看看它是怎么回事.在我的工作中,我们有一个读书俱乐部,在那里我们会阅读各种关于测试,设计和编程的技术书籍,它运作良好.

打包

部署

目前有一些部署选项.

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

远程访问

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