【问题标题】:Desired state configuration所需的状态配置
【发布时间】:2018-08-07 15:21:31
【问题描述】:

我有两台 Web 服务器、一台服务服务器和一台数据库服务器,所有这些服务器都加入了域。我已经从 VSTS 设置了我的私有构建代理,我可以在其中构建我的工件并基于构建配置。我所有的 DEV、QA 和 STAGING 环境都设置在这些服务器上。

我的问题是我正在寻找一种使用 PowerShell 所需状态配置的方法,这种方式基于环境工件(DEV、QA 和 STAGING),脚本必须将工件复制到那些“两个 Web 服务器上的特定位置” " 并确保网站正确配置了所有必需的权限,其中这些工件用于托管 IIS 网站并在 "SERVICE 服务" 上执行特定 Windows 服务的删除和创建操作,还应在 "DATABASE server" 上执行迁移活动对于特定的数据库。因为我已经为每个单独的环境分离了数据库。

任何形式的帮助或建议将不胜感激。谢谢。

【问题讨论】:

  • 环境 DEV、QA 和 STAGING 是否需要由不同的工件部署?如果是这样,如果您分别使用三个发布定义怎么办?您能分享一下您现在使用的发布定义吗?
  • 是的,但问题是我不想使用 VSTS 进行部署,我希望通过 power shell 脚本完成部署。

标签: powershell azure-devops continuous-deployment dsc


【解决方案1】:

我的建议是:

  • 不要使用 DSC 进行部署(即部署应用程序或数据库)
  • 使用 DSC 进行配置(例如安装 IIS)
  • 以部署组模式在每台服务器上安装 VSTS 代理,作为具有本地管理员权限的服务运行
  • 使用为部署组设计的 IIS 部署任务
  • 使用 Powershell 任务管理 Windows 服务(提示。help *-Service

【讨论】:

  • 感谢 Giulio 的建议,但我的要求是我不应该使用 VSTS 进行部署。相反,它必须通过 power shell 脚本来完成。这就是我选择 DSC 配置的原因。我可以在那里配置服务器并从脚本部署我的东西。
  • 我的前两点仍然适用:使用 DSC 配置服务器,使用简单的 Powershell 部署应用程序。主要理由是更改频率不同,安全性不同(DSC 授予部署用户特定权限)
  • 谢谢朱利奥。我会考虑的
猜你喜欢
  • 2014-07-18
  • 1970-01-01
  • 1970-01-01
  • 2017-08-22
  • 2018-07-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多