所需反馈：生产 Lisp Web 应用程序的无中断部署策略
我有兴趣听听人们如何在生产中进行 Lisp webapp 部署和更新（尤其是更新）。
在 Ruby 中，许多人（包括我自己）都使用 Capistrano 进行部署。它提供了一些很好的间接性和远程执行命令的能力，最重要的是（在我看来）回滚到工作代码库的能力。
我知道长期运行的 Lisp 进程通过 SSH 隧道通过 Swank 连接并就地修改的想法是一个流行的想法，但我还没有喝过 Koolaid，主要是因为更新有状态的问题过程（这似乎是在出现问题时自找麻烦 - 例如内存中的当前状态与很快将在内存中的新对象定义之间出现不可预见的阻抗不匹配）。
鉴于您可以使用 hunchentoot 创建几乎无状态（或完全）的 Web 应用程序（或在此处插入您最喜欢的 Lisp 应用程序服务器），如果 Lisp 进程（es ）隐藏在其上游通道中的 nginx 后面，如果您可以正确地编排关闭 hunchentoot 进程并在更新代码后将它们重新启动，例如，始终将它们重新启动，同时让至少一个 hunchentoot 进程在集群中运行任何给定的时刻（可以使用 CGI 或 mod_lisp，但我对这种方法不是特别感兴趣 - 尽管如果你真的喜欢这种方法，请至少说一些关于它的内容，我想学习）。例如，使用 Passenger（将橙子与苹果进行比较，因为它按需启动进程），您触摸 tmp/restart.txt 并且应用程序服务器这次会使用新更新的代码重新启动 - 从用户的角度来看没有中断。
好吧，这有点漫无目的，实际上我正准备尝试所有这些，但我想从其他人那里得到一些关于这些想法的反馈。也许你有更好的主意。
谢谢
I am interested in hearing how people do their Lisp webapp deployments and updates (especially updates) in production.
In Ruby many, myself included, use Capistrano for deployments. It provides some nice indirection and the ability to execute commands remotely and most importantly (in my mind) the ability to rollback to a working code base.
I know that the idea of a long running Lisp process being connected to via Swank through an SSH tunnel and modified in place is a popular idea that's knocked around, but I haven't drunk that Koolaid, mostly because of the issue of updating a stateful process (which seems like asking for trouble if something goes wrong - like unforeseen impedance mismatches between current state in memory and new object definitions that will soon be in memory).
Given that you can create nearly stateless (or completely) webapps using hunchentoot (or insert your favorite Lisp app server here), it seems like using something like Capistrano could be used for non-disruptive updates to Lisp code too if the Lisp process(es) hide behind nginx in its upstream channel and if you can correctly choreograph taking down the hunchentoot processes and spin them back up after an update to code, e.g., bring them back up all the while leaving at least one hunchentoot process running in the cluster at any given moment (CGI or mod_lisp could be used, but I am not particularly interested in that approach - though if you really like that approach, please at least say something about it, I want to learn). For instance, using Passenger (which is comparing oranges to apples since it spins up processes on demand), you touch tmp/restart.txt and the app server restarts this time with freshly updated code - no interruptions from the users perspective.
Well, this is a bit of a ramble, and actually I am about to try all this out, but I'd like to get some feedback on these ideas from others. Maybe you have a better idea.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以通过为 HAProxy 等智能前端/负载均衡器编写 capistrano 脚本来完成无中断（零停机）部署，该脚本使应用程序服务器停止旋转，使用新部署的代码重新启动它们，然后将它们放回混合状态。
通过在应用程序服务器不在生产中实时轮换时逐步滚动应用程序服务器，您可以实现平稳部署。
这并不涉及具有特定状态的持久应用程序服务器循环，这看起来很可怕，正是您提到的原因。 REPL 对于调试和调整来说很酷，但是您在磁盘上运行代码的直觉似乎是有根据的。
You can accomplish non-disruptive (zero downtime) deployments by writing capistrano scripts for an intelligent front-end/load balancer like HAProxy that pulls app servers out of rotation, restarts them with the newly deployed code, and puts them back in the mix.
By incrementally rolling your appservers while they are out of live rotation in production you can achieve smooth deployments.
This doesn't touch on having persistent app server loops with specific state, that seems scary for exactly the reasons you mentioned. REPLs are cool for debugging and tweaking, but your instincts to run the code on disk seem well founded.