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 脚本和一些用于添加密钥和创建用户的手动步骤处理。我即将调查 Silk Deployment (https://bitbucket.org/btubbs/silk-deployment)，因为它似乎最接近我们的设置。

谢谢！

Answer 1

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

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

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

• 我们这里有一个政策，这意味着没有人需要登录到服务器（大部分是这样的 - 有时我们想查看原始 nginx 日志文件，但这种情况很少见)。
• 我们已经配置了结构，以便有单独的功能块（restart_nginx、restart_uwsgi 等），而且
• 更高级别的“业务”功能，以正确的顺序运行所有小块 - 为了更新我们所有的服务器，我们只需键入“fab -i secretkey live deploy” - 实时设置实时服务器的设置，并且部署 ldeploys（如果您的 .ssh 密钥设置正确，则 -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

可能会引起争议，因为我们将二进制文件加载到我们的 repo 中，但这意味着如果我在盒子上升级 nginx，并且想要回滚，我只需通过操作 git 来完成。我知道什么对什么构建有效。

我们的部署如何工作：

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

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

• irc bot 宣布开始进入 irc 频道
• git 拉
• pip deploy（来自我们 repo 中的 pip 列表）
• 同步数据库
• 南迁
• uwsgi 重启
• 芹菜重启
• irc bot 在 irc 频道中宣布完成
• 开始可用性测试
• 公布可用性测试结果（并将报告发布到私人粘贴箱）

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

我们还有一个备份 git 服务，所以如果 bitbucket 出现故障，它会优雅地倒下，我们甚至有 jenkins 集成，在提交到“部署”分支时，它会导致部署通过

可怕的一点

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