用于生产者和工人模型的 Django Celery 数据库

发布于 2024-09-26 21:02:56 字数 403 浏览 1 评论 0 原文

我想开发一个使用 Django 作为 Fronted 和 Celery 来做后台工作的应用程序。 现在,有时不同机器上的 Celery 工作人员需要访问我的 django 前端机器(两个不同的服务器)的数据库。 他们需要了解一些实时的东西,并运行 django 应用程序,

python manage.py celeryd 

他们需要访问包含所有可用模型的数据库。

我必须通过直接连接访问我的 MySQL 数据库吗?因此,我必须允许用户“my-django-app”不仅从我的前端计算机上的本地主机访问,而且还从我的其他工作服务器 ips 访问?

这是“正确”的方式,还是我错过了一些东西?只是认为它并不真正安全(没有 ssl),但也许这就是它必须的方式。

感谢您的回复!

I want to develop an application which uses Django as Fronted and Celery to do background stuff.
Now, sometimes Celery workers on different machines need database access to my django frontend machine (two different servers).
They need to know some realtime stuff and to run the django-app with

python manage.py celeryd 

they need access to a database with all models available.

Do I have to access my MySQL database through direct connection? Thus I have to allow user "my-django-app" access not only from localhost on my frontend machine but from my other worker server ips?

Is this the "right" way, or I'm missing something? Just thought it isn't really safe (without ssl), but maybe that's just the way it has to be.

Thanks for your responses!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

℡寂寞咖啡 2024-10-03 21:02:56

他们需要访问数据库。该访问将通过数据库后端进行,该后端可以是 Django 或 来自第三方

我在 Django 站点的 settings.py 中所做的一件事是从 /etc 中的文件加载数据库访问信息。这样,每台计算机的访问设置(数据库主机、端口、用户名、密码)都可以不同,并且密码等敏感信息不在我的项目存储库中。您可能希望以类似的方式限制对工作人员的访问,让他们使用不同的用户名进行连接。

您还可以通过环境变量传入数据库连接信息,甚至只是配置文件的键或路径,并在 settings.py 中处理它。

例如,以下是我提取数据库配置文件的方法:

g = {}
dbSetup = {}
execfile(os.environ['DB_CONFIG'], g, dbSetup)
if 'databases' in dbSetup:
    DATABASES = dbSetup['databases']
else:
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.mysql',
            # ...
        }
    }

不用说,您需要确保除数据库管理员和 Django 本身之外的任何用户都无法访问 DB_CONFIG 中的文件。默认情况下,Django 应该引用开发人员自己的测试数据库。使用 ast 模块代替 execfile 可能还有更好的解决方案,但我还没有研究过。

我做的另一件事是使用单独的用户来执行数据库管理任务而不是其他任务。在我的 manage.py 中,我添加了以下序言:

# Find a database configuration, if there is one, and set it in the environment.
adminDBConfFile = '/etc/django/db_admin.py'
dbConfFile = '/etc/django/db_regular.py'
import sys
import os
def goodFile(path):
    return os.path.isfile(path) and os.access(path, os.R_OK)
if len(sys.argv) >= 2 and sys.argv[1] in ["syncdb", "dbshell", "migrate"] \
    and goodFile(adminDBConfFile):
    os.environ['DB_CONFIG'] = adminDBConfFile
elif goodFile(dbConfFile):
    os.environ['DB_CONFIG'] = dbConfFile

/etc/django/db_regular.py 中的配置适用于只能访问 Django 数据库的用户SELECT、INSERT、UPDATE 和 DELETE,/etc/django/db_admin.py 适用于具有这些权限以及 CREATE、DROP、INDEX、ALTER 和 LOCK TABLES 权限的用户。 (migrate 命令来自 South。)这为我提供了一些针对 Django 代码的保护在运行时扰乱我的模式,并且它限制了 SQL 注入攻击可能造成的损害(尽管您仍然应该检查和过滤所有用户输入)。

这并不能解决您的具体问题,但它可能会为您提供一些想法,帮助您根据您的目的优化 Django 的数据库访问设置。

They will need access to the database. That access will be through a database backend, which can be one that ships with Django or one from a third party.

One thing I've done in my Django site's settings.py is load database access info from a file in /etc. This way the access setup (database host, port, username, password) can be different for each machine, and sensitive info like the password isn't in my project's repository. You might want to restrict access to the workers in a similar manner, by making them connect with a different username.

You could also pass in the database connection information, or even just a key or path to a configuration file, via environment variables, and handle it in settings.py.

For example, here's how I pull in my database configuration file:

g = {}
dbSetup = {}
execfile(os.environ['DB_CONFIG'], g, dbSetup)
if 'databases' in dbSetup:
    DATABASES = dbSetup['databases']
else:
    DATABASES = {
        'default': {
            'ENGINE': 'django.db.backends.mysql',
            # ...
        }
    }

Needless to say, you need to make sure that the file in DB_CONFIG is not accessible to any user besides the db admins and Django itself. The default case should refer Django to a developer's own test database. There may also be a better solution using the ast module instead of execfile, but I haven't researched it yet.

Another thing I do is use separate users for DB admin tasks vs. everything else. In my manage.py, I added the following preamble:

# Find a database configuration, if there is one, and set it in the environment.
adminDBConfFile = '/etc/django/db_admin.py'
dbConfFile = '/etc/django/db_regular.py'
import sys
import os
def goodFile(path):
    return os.path.isfile(path) and os.access(path, os.R_OK)
if len(sys.argv) >= 2 and sys.argv[1] in ["syncdb", "dbshell", "migrate"] \
    and goodFile(adminDBConfFile):
    os.environ['DB_CONFIG'] = adminDBConfFile
elif goodFile(dbConfFile):
    os.environ['DB_CONFIG'] = dbConfFile

Where the config in /etc/django/db_regular.py is for a user with access to only the Django database with SELECT, INSERT, UPDATE, and DELETE, and /etc/django/db_admin.py is for a user with these permissions plus CREATE, DROP, INDEX, ALTER, and LOCK TABLES. (The migrate command is from South.) This gives me some protection from Django code messing with my schema at runtime, and it limits the damage an SQL injection attack can cause (though you should still check and filter all user input).

This isn't a solution to your exact problem, but it might give you some ideas for ways to smarten up Django's database access setup for your purposes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文