Windows环境拉取部署

发布于 2024-09-13 04:18:52 字数 863 浏览 4 评论 0原文

我正在寻找一种设置拉式部署的方法,而不是 Windows 下传统的推式部署模型。

最佳情况是:

  • 将文件部署到主服务器
  • 子服务器将检查主服务器在给定时间或时间间隔是否有更新。
  • 如果主服务器包含更新,那么它将下载更新和/或执行脚本(类似于 nant?)

该解决方案需要尽可能轻量,并且必须在 Windows 环境下运行。

我看过 ChefSmartFrog 但不适合这种特殊情况。

编辑:正在部署多个软件。它们是数据库脚本、Windows 服务和网站。每个孩子都会有自己独特的脚本,因为它的要求和身份验证详细信息与其他孩子不同。

编辑2: 到目前为止,人们已经提出了很好的答案,但最终的解决方案确实需要安全、内部运行并且所有事情同时发生。这是由于合规性、行业法规和版本问题(例如数据库服务器与服务不同步)。我想到的最终解决方案类似于主服务器上的 FPT 服务器和子服务器上运行的 Nant 来执行安装例程(启动、停止服务、安装 SQL 脚本、记录安装)。这是当前可用的最接近的东西,但并不理想,因为 nant 在推送基础上工作(仅在某人或程序(例如 Cruisecontrol)运行脚本时执行)。我确信必须有一个解决方案来为 Windows 进行正确的 PULL 部署。如果您可以同时在多个服务器上进行部署,Windows 更新和 Linux 上的 APT 都是拉式部署的绝佳示例。

I'm looking for a way to setup pull deployment as apposed to the traditional push deployment model under Windows.

The optimal situation would be:

  • Deploy the file(s) to the master server
  • The child server would check to see if the master had an update at a given time or time interval.
  • If the master server contains an update, then it would download the update and/or execute a script (something like nant?)

The solution needs to be as light weight as possible and must run under a Windows environment.

I've taken a look at Chef and SmartFrog but are not suited for this particular situation.

Edit: There are multiple pieces of software being deployed. These are database scripts, windows services and a web site. Each child will have it's own unique script as it's requirements and authentication details are different from the rest.

Edit 2:
So far people have come up with great answers but the end solution really does need to be secure, run internally and all happen at the same time. This is due to compliancing, industry regulations and version issues (eg. db server out of sync with services). The end solution that I have in mind would be something like an FPT server on the master and Nant running on the children to execute the install routines (starting, stopping services, installing sql scripts, logging installs). This is the closest thing currently available, but is not ideal as nant works on a push basis (only executes when someone or program, eg. cruisecontrol, runs the script). I'm sure there has to be a solution to do a proper PULL deployment for Windows. Windows update and APT on Linux are great examples of pull deployment if you could do the the deployment across multiple servers all at the same time.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

以歌曲疗慰 2024-09-20 04:18:52

您说您想要进行 Windows 软件部署,但您却谈论了构建脚本语言,例如 NAnt。如果是我,我会使用 InstallShield 编写一个 Windows Installer 程序包,并利用它的 UpdateManager 服务让客户端从更新服务器提取更新。这些工具已经存在并经过了很长一段时间的验证,并且比您重新发明的任何工具都要安全得多。

You say you want to do Windows Software Deployment and yet you talk about build scripting languages such as NAnt. If it was me, I'd write a Windows Installer package using InstallShield and take advantage of it's UpdateManager service to get the clients pulling updates from your update server. These tools have been around and proven for a long time and will be far more secure then anything that you reinvent.

海未深 2024-09-20 04:18:52

我不是 100% 清楚要部署的应用程序类型 - 但如果这是要分发给客户端/最终用户的 Windows 窗体应用程序,那么您已经查看了 ClickOnce?它具有自动轮询和从客户端拉取增量的模式。不过好像你是分发到其他服务器了?

I'm not 100% clear on the type of app to be deployed - but if this is a Windows Forms application to be distributed to clients / end users, then you have looked at ClickOnce? This has modes for automatically polling and pulling down deltas from clients. But it seems that you are distributing to other servers?

戴着白色围巾的女孩 2024-09-20 04:18:52

几年前,我实现了一个系统,可以满足您的需求。

对于客户端应用程序,我们使用 ClickOnce 部署,效果非常好。对于 Windows 服务和网站,我们必须实现自己的系统,因为我们找不到任何适合我们的系统。

对于我们尝试复制的数据库(sql2005),这并没有成功,需要花费大量的时间和处理器能力。我们选择进行备份和恢复数据(在客户端服务器上都是只读的)

简而言之

1) 主服务器将保存多个包含新版本 Web 服务、网站和数据库的 zip 文件。

2) 客户端服务器 Windows 服务每天扫描主服务器(使用 ftp)以获取新版本的软件。

3)当发现它时
- 卸载Windows服务并替换文件并重新安装
- 替换网站文件
- 更换数据库

A couple of years ago I've implemented a system that did about what you are looking for.

For the client application we used ClickOnce deployment which just works great. For the windows services and websites we had to implement our own system because we could find nothing that would work for us.

For the database we tried replication (sql2005), this didn't work out to well took a lot of time and processor power. We chose to make a backup and restore data (it was all readonly on client servers)

In a nutshell

1) The master server will hold several zipfiles with the new version of Webservices, Websites and databases.

2) The client servers windows service daily scan the master server (using ftp) for new versions of the software.

3) When found it would
- uninstall the windows service and replace the files and reinstall it
- replace website files
- replace the database

贱人配狗天长地久 2024-09-20 04:18:52

Windows Live Sync

您是否考虑过 Windows Live Sync?

它是免费的,您所要做的就是设置两个文件夹。一台在您的主服务器中,一台在您的子服务器中。

设置完成后,所有文件将自动同步。

更新应该非常容易,一旦更新主文件夹,它将自动复制到子端。

这完全是一劳永逸。

我使用这个系统(一个部署在服务器上)和六个“子”节点,每天轻松同步 1000 个文件。

编辑1:

忘了说了,文件是加密的,并且使用反向连接,所以路由器/防火墙配置为零。

Windows Live Sync

Have you given any thought to windows live Sync?

Its free, and all you would have to do is set up two folders. One in your Master server and one in your Child server.

Once set up, all files will be automatically synced.

Update should be really easy, once you update your Master folder, it will automatically be replicated in the Child end.

It is totally fire and forget.

I use this system (one deployed on a server) with six 'child' nodes, syncing 1000's files daily with ease.

Edit 1:

Forgot to mention, the files are encrypted, and it uses reverse connection, so there is zero router/firewall configuration.

っ〆星空下的拥抱 2024-09-20 04:18:52

哟哟正在运行域控制器吗?这样你就可以给他们“做广告”了吗?没有比这更轻松的了。修改此行以获取 UI 的路径,但它也应该是可编写脚本的 - 至少在 PowerShell 中是这样。

"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\shell32.dll",#44 "C:\Windows\SysWOW64\CCM\SMSRAP.cpl",运行广告程序

Are yoy running domain controller? So that you can jsut "advertise" them? Doesn;t get any lighter that that. Modify this line for your path to see the UI, but it should be scriptable as well - at leas in PowerShell.

"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\shell32.dll",#44 "C:\Windows\SysWOW64\CCM\SMSRAP.cpl",Run Advertised Programs

眼泪淡了忧伤 2024-09-20 04:18:52

我过去曾结合使用 Cruise Control .net 和 Subversion 来实现这一精确用法,并取得了很大成功。

Subversion 是安全的并将充当主服务器。 Cruise control .net 完全支持 subversion 和 nant。当然它还可以做更多的事情。由于我们所处的行业及其要求(实用性),我们曾经有非常复杂的逻辑。

I have used a combination of cruise control .net and subversion for this exact usage with lot success in the past.

Subversion is secure and will act as the master server. Cruise control .net fully support both subversion and nant. Of course it can do a lot more. We used to have very complicated logic due to the industry we were in and its requirements (utility).

飞烟轻若梦 2024-09-20 04:18:52

我以前在圣路易斯参加他们网站的“生日聚会”时与某人交谈时听说过这种情况。我想知道那是不是你。

无论如何,我都会使用 Web 部署工具 (MSDeploy) 来实现此目的。 MSDeploy 更像是一个同步工具,而不是其他工具。这个概念是你有一个源和一个目标,你想要同步它们。如果您正在进行正常的推送部署,您的构建服务器会将某些构建的输出与每个目标服务器同步。如果您想进行拉式部署,只需将所需的文件放入共享位置(您称为此主服务器),然后您的客户端计算机就可以将其自身同步到该主服务器。

以下是您在问题中提到的更多详细信息:

将文件部署到主服务器
您的构建服务器可以使用 MSDeploy 将文件部署到主服务器

子服务器将检查主服务器是否在给定时间或时间间隔有更新。
对此没有直接支持,但这里确实有两件事。 第一件事:您可以从脚本 (.cmd/PowerShell/MSBuild/etc) 运行 MSDeploy,它可以确定是否有更新的版本。我将通过在输出文件夹的顶层放置一个版本文件来完成此操作。然后,当您的脚本启动时,只需读取服务器上的版本即可。如果有更新的可用,则启动新的部署。 第二件事:MSDeploy 支持增量部署,因此即使您启动新的部署,它也不会进行任何更改。当您开始谈论数据库部署时,这很棘手,因此在您的情况下可能是不明智的,我会选择一些第一件事

如果主服务器包含更新,那么它将下载更新和/或执行脚本
这就是 msdeploy.exe 将为您做的事情。

其他相关项目

  • 增量发布:如果您的网站包含 1000 个文件,但只有 5 个发生更改,则仅部署这 5 个文件
  • 自定义:MSDeploy 支持参数化,因此当客户端开始同步时,您可以为以下内容提供特定值:那个客户。通过这些,您可以更改所有类型的文件,包括 web.conig/.xml 文件/文本文件/等。您甚至可以提供自定义 IIS 设置
  • 身份验证:如果您使用的是 IIS 7,则可以使用普通的 Windows 身份验证,您可以创建 WMSvc 用户并使用它们。
  • 安全性: WMSvc 可用于此目的

这符合您的需求吗?

I've heard of this situation before when I was talking to someone when I was in St. Louis for the "birthday party" of their website. I wonder if that was you.

In any case, I would use the Web Deployment Tool (MSDeploy) for this. MSDeploy is more like a sync tool then anything else. The concept is that you have a source and a dest, you want to sync them up. If you are doing a normal push deployment your build server would sync the output of some build with each target server. If you want to do a pull deployment, just drop the files you want into a shared location (you're calling this master server) then your client machine can sync itself to that master server.

Here are some more details which you mentioned in your question:

Deploy files to master server
Your build server can use MSDeploy to deploy files to master server

The child server would check to see if the master had an update at a given time or time interval.
There is no direct support for this, but there are really two things here. Thing one: You can run MSDeploy from a script (.cmd/PowerShell/MSBuild/etc) and it can determine if there is a newer version. I would do this by dropping a version file at the top level of your output folder. Then when your script kicks off just read what version is on the server. If a newer one is available then kick off a new new deployment. Thing two: MSDeploy supports incremental deployment so even if you kick off a new deploy it will just not make any changes. This is tricky when you start talking about DB deployments though so in your case probably ill-advised, I would go with some flavor of Thing one.

If the master server contains an update, then it would download the update and/or execute a script
This is what msdeploy.exe is going to do for you.

Other related items

  • Incremental publishing: If your web contains 1000 files but only 5 changed, then only those 5 get deployed
  • Customization: MSDeploy supports parametrization, so when a client starts a sync you can provide the specific values for that client. With these you can change all types of files including web.conig/.xml files/text files/etc. You can even provide custom IIS settings
  • Authentication: You can use normal windows auth if you are using IIS 7 you can create WMSvc users and use those.
  • Security: WMSvc can be used for this

Does this suit your needs?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文