База данных Django Celery для моделей на продюсера и работника

Question

Я хочу разработать приложение, которое использует Django в качестве Fronted и Celery для фоновой работы.Теперь иногда работникам Celery на разных машинах нужен доступ к базе данных на моей машине внешнего интерфейса django (два разных сервера).Им нужно знать кое-что в реальном времени, и для запуска django-приложения с

python manage.py celeryd 

им нужен доступ к базе данных со всеми доступными моделями.

Нужен ли мне доступ к моей базе данных MySQL черезпрямая связь?Таким образом, я должен разрешить пользователю «my-django-app» доступ не только с localhost на моем внешнем компьютере, но и с другого ips другого рабочего сервера?

Это «правильный» способ, или я что-то упустил?Просто подумал, что это не совсем безопасно (без ssl), но, может быть, так оно и должно быть.

Спасибо за ваши ответы!

Answer 1

Им потребуется доступ к базе данных. Этот доступ будет осуществляться через серверную часть базы данных, которая может поставляться с 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',
            # ...
        }
    }

Нет необходимости говорить, что вам нужно убедиться, что файл в DB_CONFIG не доступен ни одному пользователю, кроме администраторов db и самого Django. Случай по умолчанию должен отсылать 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 и ЗАКРЫТЫЕ СТОЛЫ. (Команда migrate от Юг .) Это дает мне некоторую защиту от попадания кода Django в мою схему во время выполнения и ограничивает ущерб, который может вызвать атака с использованием SQL-инъекции (хотя вы все равно должны проверить и фильтровать все пользовательские данные).

Это не решение вашей конкретной проблемы, но может дать вам несколько идей о том, как улучшить настройку доступа к базе данных Django для ваших целей.