изменение django-storage backend от s3 до облачных файлов и обработка старых файлов

У меня есть приложение django, которое я перехожу в rackspace. У меня есть модель, которая использует FileFields, и я использую библиотеку django-storages s3/boto. Я хочу использовать cloudfiles для хранения, и мне нужно иметь возможность обслуживать старый контент s3.изменение django-storage backend от s3 до облачных файлов и обработка старых файлов

На странице шаблона, где я обеспечиваю ссылки на файлы, я делаю это:

href="{{ static_url }}{{ article.code_archive_file}}"

static_url устанавливается с точки зрения и составляет settings.STATIC_URL. Очевидно, что это не сработает, так как settings.STATIC_URL будет меняться при переключении с s3.

Нужно ли писать сценарий для переноса всех моих файлов s3 вручную в облачные файлы, а также просматривать и обновлять все файлы в моих таблицах? (Тьфу). Я бы предпочел изменить хранилище хранилища и оставить старый материал в ведро s3.

Если мне нужно перенести файлы и поля, кто-то уже написал для этого сценарий?

вопрос о бонусе: Какие лучшие практики я не соблюдал при этом? Я использую django уже около полугода.

источник

2014-01-03 skm

С помощью манжеты я рекомендую использовать [django-cumulus] (https://github.com/richleland/django-cumulus) для взаимодействия с CloudFiles. Для переноса я настоятельно рекомендую использовать [wonton] (https://github.com/rackerlabs/wonton) для быстрой передачи файлов с помощью gevent. –

В качестве альтернативы тому, что предлагает @KyleKelley, вы можете добавить шаблон try-except-try, который сначала попытается захватить файл с S3, если он получит 404, он пытается использовать CloudFiles, и если это не удается, тогда файл isn ' где угодно. Мы должны были сделать что-то подобное с S3 и облачным хранилищем Google. – rdodev

Кроме того, я должен сказать, что я имел в виду чистую миграцию файлов, а не миграцию базы данных. Эта часть звучит отнимает много времени (но доступна для сценариев). –

Вариант A: Вы можете использовать несколько разных путей на старых и новых хранилищах и иметь возможность решить, откуда должен быть подан файл. Что-то может быть настраиваемый класс хранения, я думаю: вы создаете класс хранения, унаследованный от CloudFilesStorage, и в переопределенном методе url он либо вызовет супер (если файл находится в новом хранилище), либо вызовет метод url из S3BotoStorage (если файл находится в старом место хранения).

Вариант B: Вы можете перемещать файлы в облачные файлы. Я не думаю, что вам действительно нужно что-то изменить в БД после этого, если вы придерживаетесь подобных путей. Может быть, вам даже не нужен сценарий, просто загружайте файлы, а затем загружайте (s3cmd можно использовать для загрузки, облачные файлы, вероятно, получили некоторый инструмент для загрузки).

О лучших практиках: вы должны были использовать media_url и DEFAULT_FILE_STORAGE вместо static_url и статического хранилища. Рекомендуется сохранять статические файлы проекта (css/js/icons) и загруженные медиаданные.

источник

2014-01-09 11:51:51

My media_url построен на основе static_url, и у обоих будет URL-адрес, основанный на ведре s3, из-за того, как работают django-хранилища. Я предпочел бы использовать два ведра (или контейнеры, на языке cloudfiles). – skm

Хорошо. Почему бы вам не сделать это? –

Я использую boto s3 backend для django-хранилищ, который, насколько я могу судить, не поддерживает несколько ведер. Я думаю, что решение будет состоять в том, чтобы переключиться на django-cumulus или посмотреть, будет ли libcloud backend для хранилищ django разрешать несколько ведер/контейнеров. Документы неясны, поэтому мне нужно будет копать. – skm

изменение django-storage backend от s3 до облачных файлов и обработка старых файлов

ответ

Смежные вопросы