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

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

python manage.py celeryd

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

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

Является ли это "правильным" способом, или я чего-то не хватает? Просто подумал, что это не очень безопасно (без ssl), но, возможно, это так, как должно быть.

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

ОТВЕТЫ

Ответ 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, и LOCK TABLES. (Команда migrate от South.) Это дает мне некоторую защиту от jango-кода во время выполнения моей схемы во время выполнения, и это ограничивает повреждение, которое может вызвать атака SQL-инъекций (хотя вы все равно должны проверить и отфильтровать все входные данные пользователя).

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