У нас есть несколько сервисов, где пользователи загружают файлы, отправляют файлы, обмениваются файлами.
И делать в каждом сервисе свой сервер, где можно было бы получить ссылку на файл, передать через очередь, отправить, обработать - может быть не надо?
В одном сервисе - это загрузка аватарок, в другом - это различные пользовательские файлы, по сути в транзите, в третьем - это файлы, загружаемые для конфигурирования сервиса, используются время от времени.
В каждом сервисе надо было делать директорию для файлов, следить чтобы там было достаточно места, выставить права на запись, монтировать или синхронизировать с хранилищем по необходимости.
Поэтому появился 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 хранилища.
Идеи, мнения приветствуются. Может и не воспользуетесь, но наведет на какую‑то дельную мысль — тоже буду рад ))
Комментарии (10)
ArkadiyShuvaev
00.00.0000 00:00+2А я бы тоже проголосовал за что-то подобное AWS S3 / Azure Blob. Стоит реально копейки, а фич очень много.
Вряд ли можно разработать даже близко похожее по фичам и уровню доступности / надёжности самостоятельно.
antirek Автор
00.00.0000 00:00А что вы используете? А какие кейсы? Так-то голосовать можно за что угодно. Были ли примерно схожие задачи?
lair
00.00.0000 00:00+1У каждого сервиса, работающего с filebump, свой ключ. Список ключей задается в конфиге.
А что с разделением доступа per user?
antirek Автор
00.00.0000 00:00Его нет. Это не пользовательское хранилище файлов, а такое общее служебное для сервисов. Сервисы хранят уникальные ссылки. Примерно как ролики на Ютубе с доступом по ссылке. Есть ссылка? можешь скачать. Нет ссылки? Тогда и не знаешь, что качать. И пользовательские списки файлов и доступ к ним контролируют уже сервисы сами, filebump - это некоторая такая замена файловой системы для сервиса.
antirek Автор
00.00.0000 00:00Нашел подобный сервис https://upload.io/ , а filebump - это свой локальный вариант.
dimkus
Чем не устроил S3 или ему подобный Minio? или подобные fileshare?
antirek Автор
что такое S3? AWS? там вроде платить надо? т.е. не был знаком, отсюда надо время разобраться. или свой http по-быстрому запустить? или с minio разбираться? или взять zenko? на начальном этапе было проще свое на коленке сделать, два метода и готово, закрыть потребность, протестировать такой вынос файлообмена. А вот сейчас, когда растет список пожеланий и хотелок, понемногу появляется вопрос - улучшать свое или выбросить и взять что-то уже существующее?
вы используете minio? или подобные fileshare? удобно? а для чего? какие кейсы использования?
mgis
Это был сарказм с множеством вопросительных знаков?
antirek Автор
вообще нет. скорее, ход рассуждения, но да ладно, заминусили знатно ))