filebump — хостинг файлов по API / свой локальный upload.io

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

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

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

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

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

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

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

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

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

Чем‑то напоминает пользовательские файлопомойки в расшаренных директориях в локальной сети. Но здесь нет 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 хранилища.

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

@antirek
13.02.2023 07:25 UTC
Первоисточник

Комментарии

@dimkus
13.02.2023 04:03 UTC
+5

Чем не устроил S3 или ему подобный Minio? или подобные fileshare?

@antirek
13.02.2023 04:14 UTC
-8

что такое S3? AWS? там вроде платить надо? т.е. не был знаком, отсюда надо время разобраться. или свой http по-быстрому запустить? или с minio разбираться? или взять zenko? на начальном этапе было проще свое на коленке сделать, два метода и готово, закрыть потребность, протестировать такой вынос файлообмена. А вот сейчас, когда растет список пожеланий и хотелок, понемногу появляется вопрос - улучшать свое или выбросить и взять что-то уже существующее?

вы используете minio? или подобные fileshare? удобно? а для чего? какие кейсы использования?

13.02.2023 08:33 UTC
+3

Это был сарказм с множеством вопросительных знаков?

13.02.2023 15:31 UTC
-1

вообще нет. скорее, ход рассуждения, но да ладно, заминусили знатно ))

@ArkadiyShuvaev
13.02.2023 09:32 UTC
+2

А я бы тоже проголосовал за что-то подобное AWS S3 / Azure Blob. Стоит реально копейки, а фич очень много.

Вряд ли можно разработать даже близко похожее по фичам и уровню доступности / надёжности самостоятельно.

@antirek
13.02.2023 15:35 UTC
0

А что вы используете? А какие кейсы? Так-то голосовать можно за что угодно. Были ли примерно схожие задачи?

@lair
13.02.2023 13:58 UTC
+1

У каждого сервиса, работающего с filebump, свой ключ. Список ключей задается в конфиге.

А что с разделением доступа per user?

@antirek
13.02.2023 15:38 UTC
0

Его нет. Это не пользовательское хранилище файлов, а такое общее служебное для сервисов. Сервисы хранят уникальные ссылки. Примерно как ролики на Ютубе с доступом по ссылке. Есть ссылка? можешь скачать. Нет ссылки? Тогда и не знаешь, что качать. И пользовательские списки файлов и доступ к ним контролируют уже сервисы сами, filebump - это некоторая такая замена файловой системы для сервиса.

13.02.2023 15:39 UTC
0

...ну вот поэтому и для кучи кейсов и не подойдет.

@antirek
04.03.2023 14:24 UTC
0

Нашел подобный сервис https://upload.io/ , а filebump - это свой локальный вариант.