在 Heroku 上热部署，无需停机
推送到 Heroku 的一个缺点是我必须在运行数据库迁移之前推送代码（并且服务器会自动重新启动）。
这显然会导致用户在没有新表/属性的情况下浏览具有新代码的网站时出现大约 500 个错误：Heroku 提出的解决方案是使用维护模式，但我想要一种没有任何缺点的方法，让我的 web 应用程序每次都运行！
有办法吗？例如，使用 Capistrano：
- 我准备要在新目录中部署的代码
- 我运行（向后）迁移并且旧代码继续完美工作
- 我将 mongrel 实例切换到新目录并重新启动服务器
......而且我没有停机时间！
A bad side of pushing to Heroku is that I must push the code (and the server restarts automatically) before running my db migrations.
This can obviously cause some 500 errors on users navigating the website having the new code without the new tables/attributes: the solution proposed by Heroku is to use the maintenance mode, but I want a way with no downside letting my webapp running everytime!
Is there a way? For example with Capistrano:
- I prepare the code to deploy in a new dir
- I run (backward) migrations and the old code continue to work perfectly
- I swith mongrel instance to the new dir and restart the server
...and I have no downtime!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您可以设置第二个 Heroku 应用程序，它指向与主生产应用程序相同的数据库，并使用辅助应用程序运行数据库迁移而不会中断生产（假设迁移不会破坏应用程序的先前版本）。
我们将 Heroku 应用程序称为 Production 和 STAGING。
您的部署顺序将类似于：
git push heroku stagingheroku run -a staging-app rake db:migrategit push heroku production登台应用程序不会花费您任何费用，因为您不需要超出 Heroku 的免费套餐，而且设置一个 rake 部署脚本来自动为您执行此操作将非常简单。
祝你好运！
You could setup a second Heroku app which points to the same DB as your primary production app and use the secondary app to run your DB migrations without interrupting production (assuming the migrations don't break the previous version of your app).
Let's call the Heroku apps PRODUCTION and STAGING.
Your deploy sequence would become something like:
git push heroku stagingheroku run -a staging-app rake db:migrategit push heroku productionThe staging app won't cost you anything since you won't need to exceed Heroku's free tier and it would be pretty trivial to setup a rake deploy script to do this for you automatically.
Good luck!
如果您能够同时使用同一应用程序的两个版本，Heroku 现在具有预启动功能。
https://devcenter.heroku.com/articles/preboot
If you're able to live with two versions of the same app live at the same time, Heroku now has a preboot feature.
https://devcenter.heroku.com/articles/preboot
稍微改进这个过程的唯一方法就是这个人建议的。但这仍然不是一个热门部署场景：
http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/
我建议的一件事是首先将您的迁移推送到 Heroku并在推送代码库之前运行它们。这将需要将迁移作为独立提交进行提交，并每次手动推送它们（这并不理想）。我很惊讶现在 Heroku 上托管的所有大型应用程序都没有更好的解决方案。
The only method to improve the process somewhat is what this guy suggests. This is still not a hot deploy scenario though:
http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/
One thing I would suggest is pushing only your migrations up to Heroku first and running them before you push your codebase. This would entail committing the migrations as standalone commits and manually pushing them each time (which is not ideal). I'm very surprised there is not a better solution to this issue with all of the large apps hosted on Heroku now.
当 Heroku 重新启动您的应用程序时，您实际上会有一些停机时间。他们有一个名为 Preboot 的新功能，可以在删除旧的 dyno 之前启动新的 dyno：https:// /devcenter.heroku.com/articles/labs-preboot/
至于数据库迁移，该文章链接到这篇关于如何处理该问题的文章：http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
You actually will have some downtime when Heroku restarts your app. They have a new feature called Preboot that starts up new dynos before taking out the old ones: https://devcenter.heroku.com/articles/labs-preboot/
As for database migrations, that article links to this one on how to deal with that issue: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
我首先提交迁移，运行它们，然后推送其余的代码。添加一个文件，如下所示：
I first commit the migrations, run them, then push the rest of the code. Add a single file like so:
Heroku 无法通过 capistrano 部署。你被heroku发布的工具阻止了。
不停机系统在所有情况下都是不可能的。如何在不停止服务器的情况下对架构进行重大更改。如果您不停止它，您可以避免一些更改，并且您的数据库可能会不一致。所以使用维护页面是一个正常的解决方案。
如果您想要一个小的解决方案来避免问题，那就是平衡两台服务器。一种在迁移期间仅读取数据库的数据库。您可以在迁移期间切换到此实例，从而避免维护页面。迁移后，您将回到您的主人身边。
Heroku can't deploy by capistrano. You are block by tool released by heroku.
The no downtime system is impossible in all cases. How change your schema with big change without stop your server. If you don't stop it, you can avoid some change and your database can be inconsistent. SO the using of maintenance page is a normal solution.
If you want a little solution to avoid problem is a balancing in two server. One with only read database during your migration. You can switch to this instance during your migration avoiding the maintenance page. After your migration you come back to your master.
目前我认为没有任何可能在不停机的情况下做到这一点。我也讨厌它。
这个控制台命令在我能想到的最短的时间内完成了
herokumaintenance:on进行维护，所以没有500ssleep 5让dynos启动新代码（没有它，迁移可能会失败）heroku run Rails db:migrate进行实际迁移heroku ps:restart出于经验，重新启动可确保新的测功机具有最新的架构heroku Maintenance:off维护轮次您可能需要添加
-a; 如果您有多个应用程序，则位于所有 heroku 命令后面。只需一个命令即可在 Mac OSX 的终端中连续运行这些命令。
Right now I don't see any possibility to do this without downtime. I hate it too.
This console command does it in the smallest amount of time I can think of
git push heroku masterto push the master branch to herokuheroku maintenance:onto put on maintenance so no 500ssleep 5to let the dynos start up the new code (without it, the migration might fail)heroku run rails db:migrateto do the actual migrationheroku ps:restartout of experience the restart makes sure the new dynos have the latest schemaheroku maintenance:offturns of the maintenanceYou might have to add
-a <app name>behind all heroku commands if you have multiple apps.Just one command will run these in series in terminal on Mac OSX.