Django 服务器结构和约定

Question

我有兴趣找出在服务器上组织 Django 应用程序的最佳实践方法。

• 你把 Django 代码放在哪里？ (现在旧的)年鉴说/home/django/domains/somesitename.com/但我也看到了放置在/opt/apps/somesitename/中的东西。我认为/opt/想法听起来更好，因为它不是全局的，但我以前没有见过 opt，大概应用程序进入特定于站点的部署者用户主目录可能会更好。

• 您是否建议拥有一名全局部署者用户、每个站点一名用户或每个站点环境一名用户(例如 sitenamelive、sitenamestaging)。我想每个网站一个。

• 如何对配置文件进行版本控制？我目前将它们放在源代码管理顶层的/etc/文件夹中。例如，/etc/nginc/somesite-live.conf。

• 您如何配置服务器并进行部署？多年来我一直抵制 Chef 和 Puppet，希望能有基于 Python 的东西。 Silver Lining 似乎还没有准备好，我对 Patchwork (https://github.com/fabric/patchwork/) 寄予厚望。目前，我们只是使用一些自定义 Fabric 脚本进行部署，但“服务器配置”是由 bash 脚本和一些用于添加 key 和创建用户的手动步骤来处理的。我即将研究 Silk Deployment (https://bitbucket.org/btubbs/silk-deployment)，因为它似乎最接近我们的设置。

谢谢!

Answer 1

我认为必须有更多关于您正在部署的网站类型的信息:根据网站之间的关系，无论是编程上的还是“合法的”(如在业务关系中)，都会存在差异:

• 如果网站由不同的人“拥有”，那么为每个“网站”拥有一个系统帐户会很方便 - 如果您是一名拥有几个客户的网页设计师或程序员，那么您可能会从分离中受益。
• 如果您的网站是相关的，即论坛网站、博客网站等，您可能会从单一部署系统(如我们的系统)中受益。
• 对于库，如果它们托管在信誉良好的来源(pypy、github 等)上，那么将它们留在那里并从它们进行部署可能是可以的 - 如果它们位于运行或关闭的可疑主机上，我们会获取一个副本并将它们放入我们的 git 存储库中的/thirdparty 文件夹中。

Fabric Fabric 非常棒 - 如果它的设置和配置适合您:

• 我们这里有一个政策，这意味着没有人需要登录服务器(这大部分都是正确的 - 有时我们想要查看原始 nginx 日志文件，但它很少见)。
• 我们已经配置了结构，以便有单独的功能 block (restart_nginx、restart_uwsgi 等)，而且
• 更高级别的“业务”功能，以正确的顺序运行所有小块 - 为了我们更新所有服务器，我们只需键入“fab -i Secretkey live deploy” - 实时设置实时服务器的设置，并且部署 ldeploys(如果您正确设置了 .ssh key ，则 -i 是可选的)
• 我们甚至有一个控制标志，如果使用实时设置，它会在执行部署之前询问“您确定吗”。

我们的代码布局

所以我们的代码库布局看起来有点像这样:

/         <-- folder containing readme file etc
/bin/     <-- folder containing nginx & uwsgi binaries (!)
/config/  <-- folder containing nginx config and pip list but also things like pep8 and pylint configs 
/fabric/  <-- folder containing fabric deployment
/logs/    <-- holding folder that nginx logs get written into (but not committed)
/src/     <-- actual source is in here!
/thirdparty/ <-- third party libs that we didn't trust the hosting of for pip

可能有争议，因为我们将二进制文件加载到我们的存储库中，但这意味着如果我升级机器上的 nginx，并且想要回滚，我只需通过操作 git 来完成。我知道什么与什么构建相悖。

我们的部署工作原理:

我们所有的源代码都托管在一个私有(private)的 bitbucket 存储库上(我们有很多存储库和一些用户，这就是为什么 bitbucket 比 github 更适合我们)。我们有一个“服务器”用户帐户，它有自己的 bitbucket ssh key 。

在结构中部署在每台服务器上执行以下操作:

• irc 机器人宣布开始进入 irc channel
• git 拉
• pip 部署(来 self 们存储库中的 pip 列表)
• 同步数据库
• 向南迁徙
• uwsgi 重新启动
• celery 重启
• irc 机器人宣布完成进入 irc channel
• 开始可用性测试
• 宣布可用性测试结果(并将报告发布到私有(private)粘贴箱中)

“可用性测试”(考虑单元测试，但针对实时服务器) - 访问“测试”帐户上的所有网页和 API，以确保它在不影响实时统计信息的情况下返回正常的数据。

我们还有一个备份 git 服务，因此如果 bitbucket 关闭，它会优雅地切换到该服务，我们甚至有 jenkins 集成，在提交到“部署”分支时，它会导致部署完成

可怕的一点

因为我们使用云计算并期望高吞吐量，所以我们的盒子会自动生成。有一个默认镜像，其中包含 git 存储库等的副本，但它总是会过时，因此有一个启动脚本可以对其自身进行部署，这意味着添加到集群的新框会自动更新。