通过扩建和最少的停机时间部署到生产环境?
我用 django + wsgi 进行了构建,在开发和生产方面运行良好。唯一的问题是,当我对 buildout.cfg 进行更改或添加并且必须运行 bin/buildout 时,该网站从 buildout 开始到完成都处于离线状态。这可能需要 5 分钟以上。
有没有办法在生产中优雅地运行构建?也许我不知道的一个参数会在不先卸载所有内容的情况下运行构建?该网站在一台网络服务器上运行。负载均衡器和额外的 Web 服务器将是一个很好的解决方案,但目前不可行。
欢迎对我的构建脚本提出任何其他评论/建议/批评。
谢谢!
这是我的 buildout.cfg:
[buildout]
download-cache = downloads
unzip = true
parts =
scripts
django
djangoprod
eggs =
${scripts:eggs}
${pipscripts:eggs}
[scripts]
recipe = zc.recipe.egg
unzip = true
download-cache = ${buildout:download-cache}
eggs =
ipython
docutils
feedparser
pygments
South
django-grappelli
django-extensions
django-mobile
django-photologue
django-filebrowser
django-indexer
django-paging
django-templatetag-sugar
django-sentry
MySQL-python
find-links =
http://dist.repoze.org/
http://github.com/
http://bitbucket.org/
http://googlecode.com/
http://surfnet.dl.sourceforge.net/
[pipscripts]
recipe = gp.recipe.pip
unzip = true
download-cache = ${buildout:download-cache}
editables =
hg+https://bitbucket.org/ubernostrum/django-registration#egg=django_registration
git://github.com/jtauber/django-mailer.git#egg=django_mailer
eggs =
django-registration
django-mailer
PIL
install =
http://effbot.org/downloads/Imaging-1.1.7.tar.gz
[django]
recipe = djangorecipe
download-cache = ${buildout:download-cache}
eggs = ${buildout:eggs}
version = 1.3
project = project
[djangoprod]
recipe = djangorecipe
download-cache = ${django:download-cache}
version = ${django:version}
settings = production
wsgi = true
eggs = ${django:eggs}
project = ${django:project}
I've got a buildout with django + wsgi that's working nicely on dev and production. The only issue is that when I make a change or addition to the buildout.cfg and have to run bin/buildout, the website goes offline from the time buildout starts till the time it finishes. This can take upwards of 5 minutes.
Is there a way to run buildout gracefully in production? Maybe a parameter I'm unaware of that will run the buildout without uninstalling everything first? This site is running on one web server. A load balancer and extra web server would be a nice fix, but not feasible at this point.
Any other comments/suggestions/criticism on my buildout script are welcome.
Thanks!
Here's my buildout.cfg:
[buildout]
download-cache = downloads
unzip = true
parts =
scripts
django
djangoprod
eggs =
${scripts:eggs}
${pipscripts:eggs}
[scripts]
recipe = zc.recipe.egg
unzip = true
download-cache = ${buildout:download-cache}
eggs =
ipython
docutils
feedparser
pygments
South
django-grappelli
django-extensions
django-mobile
django-photologue
django-filebrowser
django-indexer
django-paging
django-templatetag-sugar
django-sentry
MySQL-python
find-links =
http://dist.repoze.org/
http://github.com/
http://bitbucket.org/
http://googlecode.com/
http://surfnet.dl.sourceforge.net/
[pipscripts]
recipe = gp.recipe.pip
unzip = true
download-cache = ${buildout:download-cache}
editables =
hg+https://bitbucket.org/ubernostrum/django-registration#egg=django_registration
git://github.com/jtauber/django-mailer.git#egg=django_mailer
eggs =
django-registration
django-mailer
PIL
install =
http://effbot.org/downloads/Imaging-1.1.7.tar.gz
[django]
recipe = djangorecipe
download-cache = ${buildout:download-cache}
eggs = ${buildout:eggs}
version = 1.3
project = project
[djangoprod]
recipe = djangorecipe
download-cache = ${django:download-cache}
version = ${django:version}
settings = production
wsgi = true
eggs = ${django:eggs}
project = ${django:project}
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
构建只会更新配置已更改的部分(或者在愚蠢的配方实现的情况下)。一种选择是将构建配置复制/检出到新位置,重新运行构建,然后停止旧实例,然后在新安装上重新启动实例。在某些情况下,我们维护安装,例如
“current”是当前“buildout_”安装的符号链接。
当然:在负载均衡器后面运行多个实例,您可以在构建阶段从均衡器中删除一个实例。
Buildout will only update parts where the configuration has changed (or in case of a stupid recipe implementation). One option is to copy/checkout the buildout configuration into a new location re-run buildout and then stop the old instance and then restart the instance on the new installation. In some case we maintain installations like
where 'current' is a symlink to the current 'buildout_' installation.
And of course: running multiple instances behind a load-balancer where you take down an instance out of the balancer during the buildout phase is an option.