filebump — хостинг файлов по API

У нас есть несколько сервисов, где пользователи загружают файлы, отправляют файлы, обмениваются файлами.

И делать в каждом сервисе свой сервер, где можно было бы получить ссылку на файл, передать через очередь, отправить, обработать — может быть не надо?

В одном сервисе — это загрузка аватарок, в другом — это различные пользовательские файлы, по сути в транзите, в третьем — это файлы, загружаемые для конфигурирования сервиса, используются время от времени.

В каждом сервисе надо было делать директорию для файлов, следить чтобы там было достаточно места, выставить права на запись, монтировать или синхронизировать с хранилищем по необходимости.

Поэтому появился filebump — простой http сервер, где мы можем загружать, хранить и скачивать файлы.

В принципе, это простая файлопомойка. Куда можно скинуть файл и позже забрать его. Возможно, неоднократно.

Как это работает?

Сервис выполняет одну функцию — хостинга файлов по API.

Схема работы:

— у вас в сервисе появился файл (или от пользователя, или прилетел с другого сервиса),

— вы сохраняете файл в filebump,

— в сервисе сохраняете полученныую ссылку от filebump,

— по потребности загружаете файл с filebump,

— или отправляете ссылку на файл в filebump.

Чем-то напоминает пользовательские файлопомойки в расшаренных директориях в локальной сети. Но здесь нет API, которое показывает все файлы на filebump. Только что загрузил — на то и получил свою уникальную ссылку. Сохранил? Да, тогда можешь использовать. А если нет, то все файл где-то там канул в filebump’е.

Что и как можно загружать?

Есть два метода — загрузка файла (upload) и загрузка файла по url (download).

Upload file — загрузкой файлов вы пользуетесь, когда у вас уже есть файл.

Download file — а загрузкой файла по url вы пользуетесь, например, когда вам прилетела ссылка с файлом, и вместо того чтобы скачать и зааплоадить на filebump, вы поручаете эту загрузку самому filebump.

Загружать можно любые файлы.

И удобно пользоваться?

Да, вполне, работает схема полтора года. Сейчас немного причесал и добавил в npm клиента. Удобно. Каждый день прилетают сотни файлов, сотни и тысячи файлов скачиваются.

В разрабатываемых проектах просто подключаете клиент filebump’а, и просто работаете по сути только со ссылками на файлы. В некоторых случаях все файлы как бы вообще мимо разрабатываемого сервиса проходят.

Безопасность?

Использую во внутреннем периметре. Также есть ключи, т.е. http-запросы для upload’а и download’а обязательно содержат API-key. Чтобы никто посторонний не начал лить свои файлы. У каждого сервиса, работающего с filebump, свой ключ. Список ключей задается в конфиге.

Что можно улучшить?

Улучшать можно много чего.

Во-первых, схему хранения файлов. Если их много, то надо как-то оптимизировать структуру директорий. Сейчас обхожусь тем, что просто удаляю все файлы старше 3-х месяцев скриптом по крону.

Во-вторых, хочу разделить на зоны хранения файлов. Т.е. часть файлов хочется хранить долго (вечно), а часть как транзитные файлы, которые нужны только чтоб скачать и отправить дальше, то их можно удалять. Тут или метод добавить, или также по крону в этой зоне хранения просто чистить файлы. Либо пока просто раздельные filebump’ы поставить и сделать свои условные политики хранения файлов.

В-третьих, добавить таки UI и аналитику. Для управления, подсчетов, какой-то визуализации.

Как установить?

В репозитории проекта — docker-compose.yml, в котором есть пример настройки filebump. Образ filebump есть на docker hub.

Подробнее по методам, установке и коду — в гитхабе проекта filebump, написан на javascript под node.js.

Была мысль переписать на Go, чтоб докер образ был не такой жирный. Но, вероятно, если сильно заморочиться да еще и на хотелки и улучшения, то получится какой-нибудь аналог s3 хранилища.

Идеи, мнения приветствуются. Может и не воспользуетесь, но наведет на какую-то дельную мысль — тоже буду рад ))