Django服务器结构和约定

Question

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

• 你在哪里放置Django代码？ （旧的）Almanac说/home/django/domains/somesitename.com/但我也看到了/ opt / apps / somesitename /中的内容。我认为/ opt / idea听起来更好，因为它不是全球性的，但我之前没有看到过选择，并且可能更适合应用程序进入特定于站点的用户主页目录。

  < / LI>

• 您是否建议拥有一个全局部署用户，每个站点一个用户，或每个站点env一个（例如，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仓库中的/ thirdparty文件夹中。

<强>织物 面料是惊人的 - 如果它的设置和配置适合你：

• 我们这里有一个策略，这意味着没有人需要登录到服务器（主要是真的 - 有时我们想查看原始的nginx日志文件，但它很少见）。
• 我们已经配置了结构，以便有单独的功能块（restart_nginx，restart_uwsgi等），但
• 更高级别的“业务”功能，以正确的顺序运行所有小块 - 我们更新所有服务器，我们只需输入'fab -i secretkey live deploy' - 实时设置实时服务器的设置，以及deploy ldeploys（ -i是可选的，如果你的.ssh键设置正确）
• 我们甚至有一个控制标志，如果使用了实时设置，它会在执行部署之前询问“你确定”。

我们的代码布局

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

/         <-- 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来实现。我知道什么对构建什么有用。

我们的部署工作方式：

我们所有的源代码都托管在一个私人bitbucket repo上（我们有很多repos和一些用户，这就是为什么bitbucket对我们来说比github更好）。我们有一个'服务器'的用户帐户，它有自己的bitbucket的ssh密钥。

在Fabric中部署在每台服务器上执行以下操作：

• irc bot宣布开始进入irc频道
• git pull
• pip deploy（来自我们仓库中的点子列表）
• 执行syncdb
• 南迁移
• uwsgi restart
• 芹菜重启
• irc bot宣布完成进入irc频道
• 开始可用性测试
• 公布可用性测试结果（并将报告发布到私人pastebin中）

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

我们还有一个备份git服务，所以如果bitbucket关闭，它会优雅地落到那，我们甚至有jenkins集成，在提交到'deploy'分支时，它会导致部署通过

可怕的位

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