Puppet may seem daunting and overkill for small projects since it's so often used for huge deployments, but I use it to manage just one machine in standalone mode without a client server setup so that I don't have to deal with SSL certs and multiple machines, which keeps things a lot simpler, but still gives me the benefit that I can do really fast disaster recovery or move my hosting without a lot of effort. There's some great reasons (idempotency, cross platform support, full lifecycle management, abstraction, concise DSLs) for using modern configuration management systems over systems that are essentially scripts that do ssh in a loop or relying on platforms that lock you in.
Check out learning puppet for a quick ramp up including examples and a VM playground. You can get really useful things done with simple Puppet scripts (manifests) that run standalone, and then start learning all the advanced features once you need them.
Another nice thing is that a lot of Puppet manifests and modules have already been written by others, and they're shared on the Puppet Forge and by many other advanced Puppet users.
We currently do it with fabric+buildout. Others say Chef or Puppet is better suited (and it probably is, if you want to do server level stuff, not only app-level).
Also for Django there's a few dedicated hosters which take a lot of load off you, I especially like http://ep.io which we use to power our fully automated deployements for the demos of the django-cms, so maybe you should look into those hosting providers too rather than limiting yourself to VPSs which are more overhead for you.
I put together something similar that allows me to get up and running quickly, but also to separate the server stuff from the project stuff. This is very important as it allows you to version control every project without including system/server files. It's here (still very much in progress). This takes care of folder layout, extra css, boilerplate html stuff, grid/960 stuff, jquery, development vs production settings, database settings (mostely), default installed apps etc. Here is the layout explained
Using Virtualenv, Virtualenvwrapper & pip allows you to set up standalone, encapsulated python enviroments which are great for running multiple projects on one VPS. Pip allows you to install packages to a particular virualenv and also to output all your packages to a textfile that can be imported later on. This makes redeploying code from development to production very quick. It also allows you to write a generic Requirements file in your skeleton code that automatically installs all your normal django apps i.e. django-tagging etc.
In terms of databases, I've stopped trying to have development databases and production databases on different machines, it's too hard to import/export fixtures. Now I just have separate production & dev databases on the VPS and connect remotely (over ssh) to the dev one when developing. You can easily copy one to another which is nice also.
When everything is ready then, you can deploy from development to production using fabric (i'm yet to get stuck into this so I'm not sure of its ease of use)
I'd be very interested to hear other peoples thoughts about this as I was about to post something simliar!
发布评论
评论（4）
对于小型项目来说，Puppet 可能看起来令人畏惧且矫枉过正，因为它经常用于大型部署，但我用它来管理 独立模式，无需客户端服务器设置，这样我就不必处理 SSL 证书和多台机器，这使得事情变得简单多了，但仍然给我带来了好处，我可以非常快速地进行灾难恢复或移动我的主机而不需要太多的努力。有一些重要原因（幂等性、跨平台支持、完整的生命周期管理、抽象、简洁的 DSL），用于在本质上是循环执行 ssh 的脚本或依赖锁定您的平台的系统上使用现代配置管理系统。
查看 学习木偶，用于快速入门，包括示例和 VM 游乐场。您可以使用独立运行的简单 Puppet 脚本（清单）完成真正有用的事情，然后在需要时开始学习所有高级功能。
另一个好处是，许多 Puppet 清单和模块已经由其他人编写，并且在 Puppet Forge 上共享 以及许多其他高级 Puppet 用户。
Puppet may seem daunting and overkill for small projects since it's so often used for huge deployments, but I use it to manage just one machine in standalone mode without a client server setup so that I don't have to deal with SSL certs and multiple machines, which keeps things a lot simpler, but still gives me the benefit that I can do really fast disaster recovery or move my hosting without a lot of effort. There's some great reasons (idempotency, cross platform support, full lifecycle management, abstraction, concise DSLs) for using modern configuration management systems over systems that are essentially scripts that do ssh in a loop or relying on platforms that lock you in.
Check out learning puppet for a quick ramp up including examples and a VM playground. You can get really useful things done with simple Puppet scripts (manifests) that run standalone, and then start learning all the advanced features once you need them.
Another nice thing is that a lot of Puppet manifests and modules have already been written by others, and they're shared on the Puppet Forge and by many other advanced Puppet users.
我们目前采用的是 Fabric+buildout 来实现。其他人说 Chef 或 Puppet 更适合（如果您想做服务器级别的事情，而不仅仅是应用程序级别，那么可能确实如此）。
另外，对于 Django，有一些专门的托管服务商可以减轻您的负担，我特别喜欢 http://ep.io我们用它来支持 django-cms< 演示的全自动部署/a>，所以也许您也应该研究一下这些托管提供商，而不是将自己限制在 VPS 上，因为这对您来说开销更大。
We currently do it with fabric+buildout. Others say Chef or Puppet is better suited (and it probably is, if you want to do server level stuff, not only app-level).
Also for Django there's a few dedicated hosters which take a lot of load off you, I especially like http://ep.io which we use to power our fully automated deployements for the demos of the django-cms, so maybe you should look into those hosting providers too rather than limiting yourself to VPSs which are more overhead for you.
作为处于类似职位的人，我最近一直在考虑很多这个问题。
您提到的很多内容都可以通过设置一些好的框架代码来帮助解决，这些框架代码可以从 git 中为每个新项目提取。
看看这个，作为通用 django 项目框架代码的良好起点
http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/
我整理了一些类似的东西，让我能够快速启动和运行，同时也将服务器的东西与项目的东西。这非常重要，因为它允许您对每个项目进行版本控制，而无需包括系统/服务器文件。 就在这里（仍在进行中）。这负责文件夹布局、额外的 CSS、样板 html 内容、grid/960 内容、jquery、开发与生产设置、数据库设置（主要）、默认安装的应用程序等。 Creativecollective.ie/sculpt/changeset/6dd556848d03#chg-README.txt" rel="nofollow">布局说明
使用 Virtualenv、Virtualenvwrapper & pip 允许您设置独立的、封装的 python 环境，这非常适合在一个 VPS 上运行多个项目。 Pip 允许您将软件包安装到特定的 virtualenv，并将所有软件包输出到稍后可以导入的文本文件。这使得将代码从开发重新部署到生产变得非常快。它还允许您在骨架代码中编写通用需求文件，自动安装所有正常的 django 应用程序，即 django 标记等。
在数据库方面，我已经停止尝试在不同的机器上拥有开发数据库和生产数据库，它是导入/导出装置太难。现在我只有单独的生产和销售。 VPS 上的开发数据库并在开发时远程（通过 ssh）连接到开发数据库。您可以轻松地将一个复制到另一个，这也很好。
当一切准备就绪后，您可以使用 Fabric 从开发部署到生产（我还没有陷入困境，所以我不确定它的易用性）
我很想听听其他人对此的想法因为我正要发布类似的内容！
I've been considering a lot of this recently as someone in a similar position.
A lot of what you have mentioned can be helped along by setting up some good skeleton code that can be pulled from git for every new project.
Have a look at this for a good starting point for a generic django project skeleton code
http://blog.zacharyvoase.com/2010/02/03/django-project-conventions/
I put together something similar that allows me to get up and running quickly, but also to separate the server stuff from the project stuff. This is very important as it allows you to version control every project without including system/server files. It's here (still very much in progress). This takes care of folder layout, extra css, boilerplate html stuff, grid/960 stuff, jquery, development vs production settings, database settings (mostely), default installed apps etc. Here is the layout explained
Using Virtualenv, Virtualenvwrapper & pip allows you to set up standalone, encapsulated python enviroments which are great for running multiple projects on one VPS. Pip allows you to install packages to a particular virualenv and also to output all your packages to a textfile that can be imported later on. This makes redeploying code from development to production very quick. It also allows you to write a generic Requirements file in your skeleton code that automatically installs all your normal django apps i.e. django-tagging etc.
In terms of databases, I've stopped trying to have development databases and production databases on different machines, it's too hard to import/export fixtures. Now I just have separate production & dev databases on the VPS and connect remotely (over ssh) to the dev one when developing. You can easily copy one to another which is nice also.
When everything is ready then, you can deploy from development to production using fabric (i'm yet to get stuck into this so I'm not sure of its ease of use)
I'd be very interested to hear other peoples thoughts about this as I was about to post something simliar!
查看 Silk Deployment，它基于 Fabric，用于部署 Django（或任何 WSGI）+ Nginx + Gunicorn：
http://pypi.python.org/pypi/silk-deployment/
Check out Silk Deployment, which is based on Fabric and is used to deploy Django (or any WSGI) + Nginx + Gunicorn:
http://pypi.python.org/pypi/silk-deployment/