将 Django 部署为独立的内部应用程序？
Deploying Django as standalone internal app?
我正在使用 Django 开发一个工具供我的组织内部使用。它用于搜索和标记文档（使用 Haystack 和 Solr），并将用于不同的项目。我的团队目前有一个工作原型，我们想部署它 'in the wild.'
我们的安全环境是严格的。项目文档位于网络驱动器的子文件夹中，并且根据用户的 Windows 凭据限制对这些文件夹的访问（我们还有一个使用相同凭据的 MS SQL 服务器）。一个用户只能访问他们参与的项目。由于我们是一家微软专卖店，如果我们想在公司内网部署我们的应用程序，我们将需要使用 IIS 服务器来处理这些权限。团队中没有人具备使用 IIS、Active Directory 的必要知识，而且我们的 IT 部门已经超负荷运转。简而言之，我们不是网络开发人员，我们无法立即访问任何有经验的人。
我的 hacky 解决方案是完全放弃 IIS，让每个最终用户 运行 在本地有一个轻量级服务器（即 CherryPy），同时每个最终用户都保留对公共项目特定数据库（例如 SQLite 数据库位于网络驱动器上或 MS SQL 服务器上的数据库）。为了使用该工具，他们只需启动一个一体化批处理脚本并将浏览器指向 127.0.0.1:8000。我知道这有多丑陋，但我觉得它利用了已经存在的安全措施（请注意，永远不要期望一个给定项目同时有超过 10 个用户）。这是一个糟糕的想法吗？如果是这样，什么是更好的解决方案？
我遇到过类似情况（初级开发是针对正常部署情况，但有些用户要求在独立工作站上使用该应用程序）。我没有在独立的工作站上部署 Web 和数据库服务器，而是 运行 带有 Django 内部开发服务器和 SQLite 数据库的应用程序。我没有使用 CherryPy，但希望这对您有所帮助。
我当前的解决方案为不熟悉命令行的用户（他们也难以记住要在浏览器中输入的 URL）创建了一个很好的可执行文件，但也相对容易开发：
- 使用 PyInstaller 将 Django 应用程序打包成单个可执行文件。一旦你想通了，就不要继续手工去做，把它添加到你的持续集成系统中（或者至少写一个脚本）。
- 将
manage.py 修改为：
- 检测应用程序是否由 PyInstaller
frozen 并且没有参数（即：用户通过双击执行它），如果是，则 运行 execute_from_command_line(..) 带参数启动 Django 开发服务器。
- 就在 运行 启动
execute_from_command_line(..) 之前，弹出一个执行 time.sleep(2) 的线程（让开发服务器完全启动）然后 webbrowser.open_new("http://127.0.0.1:8000")。
- 修改应用程序的
settings.py 以检测是否冻结并更改周围的内容，例如数据库服务器的路径、启用开发服务器等。
一些补充说明。
- 如果您使用 SQLite，Windows file locking on network shares may not be adequate如果您同时写入数据库；并发读者应该没问题。此外，由于您将针对不同的项目使用不同的数据库文件，因此您必须想出一种方法让用户指示要使用哪个文件。也许在应用程序中提示，或者使用不同的
settings.py 文件多次构建相同的应用程序。打这个钉子的方法有很多种...
- 如果您使用 MSSQL（或任何 client/server 数据库），应用程序将必须知道数据库凭据（这意味着它们可以由知识渊博的用户提取）。这带来了可能无法接受的安全风险。基本上，不要试图在用户正在执行的应用程序中拥有唯一的安全层。用户正在执行的应用程序使用的数据库凭据应该只具有允许用户访问的权限。
我正在使用 Django 开发一个工具供我的组织内部使用。它用于搜索和标记文档（使用 Haystack 和 Solr），并将用于不同的项目。我的团队目前有一个工作原型，我们想部署它 'in the wild.'
我们的安全环境是严格的。项目文档位于网络驱动器的子文件夹中，并且根据用户的 Windows 凭据限制对这些文件夹的访问（我们还有一个使用相同凭据的 MS SQL 服务器）。一个用户只能访问他们参与的项目。由于我们是一家微软专卖店，如果我们想在公司内网部署我们的应用程序，我们将需要使用 IIS 服务器来处理这些权限。团队中没有人具备使用 IIS、Active Directory 的必要知识，而且我们的 IT 部门已经超负荷运转。简而言之，我们不是网络开发人员，我们无法立即访问任何有经验的人。
我的 hacky 解决方案是完全放弃 IIS，让每个最终用户 运行 在本地有一个轻量级服务器（即 CherryPy），同时每个最终用户都保留对公共项目特定数据库（例如 SQLite 数据库位于网络驱动器上或 MS SQL 服务器上的数据库）。为了使用该工具，他们只需启动一个一体化批处理脚本并将浏览器指向 127.0.0.1:8000。我知道这有多丑陋，但我觉得它利用了已经存在的安全措施（请注意，永远不要期望一个给定项目同时有超过 10 个用户）。这是一个糟糕的想法吗？如果是这样，什么是更好的解决方案？
我遇到过类似情况（初级开发是针对正常部署情况，但有些用户要求在独立工作站上使用该应用程序）。我没有在独立的工作站上部署 Web 和数据库服务器，而是 运行 带有 Django 内部开发服务器和 SQLite 数据库的应用程序。我没有使用 CherryPy，但希望这对您有所帮助。
我当前的解决方案为不熟悉命令行的用户（他们也难以记住要在浏览器中输入的 URL）创建了一个很好的可执行文件，但也相对容易开发：
- 使用 PyInstaller 将 Django 应用程序打包成单个可执行文件。一旦你想通了，就不要继续手工去做，把它添加到你的持续集成系统中（或者至少写一个脚本）。
- 将
manage.py修改为：- 检测应用程序是否由 PyInstaller
frozen并且没有参数（即：用户通过双击执行它），如果是，则 运行execute_from_command_line(..)带参数启动 Django 开发服务器。 - 就在 运行 启动
execute_from_command_line(..)之前，弹出一个执行time.sleep(2)的线程（让开发服务器完全启动）然后webbrowser.open_new("http://127.0.0.1:8000")。
- 检测应用程序是否由 PyInstaller
- 修改应用程序的
settings.py以检测是否冻结并更改周围的内容，例如数据库服务器的路径、启用开发服务器等。
一些补充说明。
- 如果您使用 SQLite，Windows file locking on network shares may not be adequate如果您同时写入数据库；并发读者应该没问题。此外，由于您将针对不同的项目使用不同的数据库文件，因此您必须想出一种方法让用户指示要使用哪个文件。也许在应用程序中提示，或者使用不同的
settings.py文件多次构建相同的应用程序。打这个钉子的方法有很多种... - 如果您使用 MSSQL（或任何 client/server 数据库），应用程序将必须知道数据库凭据（这意味着它们可以由知识渊博的用户提取）。这带来了可能无法接受的安全风险。基本上，不要试图在用户正在执行的应用程序中拥有唯一的安全层。用户正在执行的应用程序使用的数据库凭据应该只具有允许用户访问的权限。