Показать HN: S3mini – маленький и быстрый клиент, совместимый с S3, без зависимостей, готовый к работе на Edge ( github.com/good-lly )
libcurl также имеет AWS auth с –aws-sigv4, что дает вам полностью совместимый S3-клиент без установки чего-либо! (Вероятно, у вас уже установлен curl)
Да, но это не будет работать в Cloudflare, Vercel или любой другой бессерверной среде, потому что в лучшем случае у вас будет доступ только к API узлов.
Должно работать на Vercel, у вас есть доступ к полному API Node.js в функциях.
Это потрясающе! Ждал чего-то подобного, чтобы заменить раздутый SDK, который предоставляет Amazon. Важный вопрос — есть ли способ получить подписанные URL?
Я создал клиент S3 с похожими целями, как у TFA, но поддерживающий предварительное подписание:
https://github.com/nikeee/lean-s3
Предварительное подписание примерно в 30 раз быстрее, чем AWS SDK, и не является асинхронным.
О том, почему это так выглядит, можно прочитать здесь: https://github.com/nikeee/lean-s3/blob/main/DESIGN_DECISIONS…
FYI, вы можете добавить поддержку браузера, используя noble-heshes[1] для SHA256/HMAC — это хорошо сделанная библиотека, которая обеспечивает производительность, неотличимую от нативной криптографии в любом масштабе, соответствующем операциям S3. Мы используем ее для нашего внутреннего клиента S3.
[1] https://github.com/paulmillr/noble-hashes
SHA256 и HMAC широко доступны в API браузеров: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypt…
SublteCrypto является асинхронным, и автор специально указал, что хочет, чтобы его API был синхронным.
На данный момент, к сожалению, нет – не поддерживаются подписанные URL. Это не было моей целью (вариант использования), но если вы найдете простой/минималистичный способ его реализовать, я могу помочь вам с интеграцией.
С моей точки зрения, это добавляет дополнительную сложность и размер, что, возможно, было бы идеальным вариантом для отдельного форка/проекта?
Подписанные URL-адреса хороши тем, что позволяют третьим лицам получать доступ к файлу без необходимости проходить аутентификацию в AWS.
Наш основной вариант использования — загрузки через браузер. Вы не хотите, чтобы люди загружали все подряд, например, папку загрузки WordPress. И это ограничено по времени, так что вам не придется беспокоиться о том, что кто-то повторно использует URL.
Вы можете просто использовать вызовы s3 vis rest, если вам не нравится их SDK.
Выглядит круто.
Что я также хотел бы увидеть, так это простой, однобинарный S3-сервер, альтернативный Minio. Возможно, небольшой встроенный UI, похожий на DuckDB UI.
> Мне бы также хотелось увидеть простую альтернативу Minio в виде однобинарного сервера S3
Garage[1] не имеет веб-интерфейса, но я считаю, что он соответствует вашим требованиям. Это реализация S3, которая компилируется в один статический двоичный файл, и она специально разработана для случаев использования, когда узлы не обязательно имеют одинаковое оборудование (т. е. разные ЦП, разная ОЗУ, разные размеры хранилища и т. д.). В целом, Garage — это мое решение для хранения объектов в масштабе «домашнего сервера» и для быстрой настройки настоящего сервера S3.
Кажется, есть неофициальный веб-интерфейс[2] для Garage, но если вы его используете, вы больше не запускаете один исполняемый файл. Не так удобно, как встроенный веб-интерфейс.
[1] https://garagehq.deuxfleurs.fr/
[2] https://github.com/khairul169/garage-webui
Предположительно, он меньше и быстрее, поскольку не выполняет никаких контрольных сумм.
имеет ли это смысл или это должно быть необязательным?
Контрольная сумма имеет смысл, поскольку она гарантирует, что переданный вами файл является полным и соответствует ожиданиям. Если контрольная сумма загруженного вами файла отличается от той, которую вам предоставил сервер, вам не следует обрабатывать файл дальше и выдавать ошибку (худшим случаем, вероятно, будет атака «человек посередине», не таким уж и плохим случаем будет потеря пакетов, я полагаю).
> Контрольное суммирование имеет смысл, поскольку оно гарантирует, что переданный вами файл является полным и соответствует ожидаемому.
TCP имеет контрольную сумму на случай потери пакетов, а TLS защищает от MITM.
Я всегда считал этот аспект дизайна S3 сомнительным. Отправка и content-md5, и заголовка x-amz-content-sha256 и использование кучи вычислений в этом процессе, бля…
Это также одна из причин, по которой запуск minio в режиме одного узла и одного диска является пожирателем ресурсов.
У меня есть некоторые эмпирические данные по этому поводу!
Служба копирования файлов Effingo выполняет строгие контрольные суммы на уровне приложений и обнаруживает около 4,5 повреждений на каждый переданный эксабайт (рисунок 9, раздел 6.2 в [1]).
Это поверх контрольных сумм TCP, контрольных сумм/шифрования транспортного уровня (gRPC), ECC RAM и других уровней по пути.
Многие из них можно было отследить до «сломанной» машины, которая в конечном итоге была выведена из эксплуатации.
[1] https://dl.acm.org/doi/abs/10.1145/3651890.3672262
По моему мнению, одна из причин — обеспечение целостности в дальнейшем. Вы хотите, чтобы контрольная сумма файла оставалась той же, когда вы его загружаете, может быть, годы спустя. Если это не так, вы получаете предупреждение об этом. Без контрольной суммы, как вы узнаете наверняка? Вести собственную базу данных контрольных сумм? 🙂
Если мы говорим о защите от bitrot, я почти уверен, что S3 будет использовать какую-то форму контрольной суммы (например, crc32 или xxhash) для каждого внутреннего блока, чтобы облегчить процесс Рида-Соломона.
Если это проверка того, является ли это тем же файлом, вы можете использовать заголовок Etag, который вычисляется на стороне сервера S3. Хотя мне не нравится этот дизайн, так как он костенеет алгоритм контрольной суммы.
Вам может быть интересно это https://aws.amazon.com/blogs/aws/introducing-default-data-in…
Хорошо известно (а может, и нет?), что приложения не могут полагаться на контрольные суммы TCP.
TLS гарантирует, что поток не был изменен. Любые дополнительные контрольные суммы излишни.
На самом деле это не так. Поток TLS гарантирует, что пакеты, передаваемые между вашей машиной и S3, не будут повреждены, но это не защищает от переворотов битов, которые могут (хотя, очевидно, не должны) происходить внутри самого S3. Преимущество такой сквозной контрольной суммы заключается в том, что система S3 может хранить ее непосредственно рядом с данными, проверять ее при обратном считывании данных (убедившись, что ничего не изменилось с момента вашего исходного PutObject), а затем возвращать ее вам по запросу (чтобы вы также могли проверить ее в своем клиенте). Это единственный способ для вашего клиента иметь абсолютную уверенность в целостности в течение всего времени, пока данные находятся в системе.
Это правда, но разве это не будет все равно необходимо, если у вас есть внутренняя служба S3, которая используется внутренними службами и не имеет HTTPS (так как она не открыта для общественности)? Я понимаю, что лучшей практикой было бы также использовать HTTPS там, но я предполагаю, что это не норма?
Теоретически пакеты TCP имеют контрольные суммы, однако они довольно слабы. Так что для HTTP дополнительные контрольные суммы имеют смысл. Хотя я не уверен, есть ли какие-либо внутренние развертывания AWS S3, работающие по HTTP, и зачем им усложнять свой протокол для всех, чтобы помочь такому узкоспециализированному варианту использования.
Я уверен, что у них есть причины для всей этой схемы подписи запросов вместо традиционного заголовка «Authorization: Bearer $token», но я никогда этого не понимал.
Где-то на AWS есть видео об этом, но в целом это связано с тем, что S3 был разработан в мире, где не все браузеры/клиенты имели HTTPS, и шифрование было достаточно дорогой операцией (например, мир IE6). SigV4 (и его предшественники) дешевы и просты, если вы понимаете код.
https://youtube.com/watch?v=tPr1AgGkvc4 , думаю, минут через 10.
Потому что токен на предъявителя — это токен на предъявителя, позволяющий выполнить любой запрос, в то время как предварительно подписанный запрос позволяет вам предоставить возможность выполнить _только этот конкретный запрос_.
Токены на предъявителя имеют определенную область действия, которую можно использовать для ограничения функциональности аналогично предварительно подписанным запросам.
Однако функционал предварительно подписанных запросов s3 был запущен в 2011 году, а вот токен Bearer RFC 6750 не был стандартизирован до 2012 года…
Не всегда. Многие компании перехватывают и потенциально изменяют трафик TLS между границами сетей.
да, ты прав!
С другой стороны, S3 использует контрольные суммы только для проверки ожидаемой загрузки (при записи с клиента на сервер)… и, что удивительно, вы можете сделать это параллельно после загрузки – проверив MD5-хэш блоба в ETag (*с некоторыми оговорками)
Контрольная сумма вам понадобится только в том случае, если файл большой и вы загружаете его на диск, или если вы опасаетесь, что какое-то вредоносное ПО с правами root может изменить содержимое вашей памяти.
Или вы действительно заботитесь о данных и осознаете статистическую неизбежность смены бита где-то по ходу дела, если вы работаете достаточно долго.
Я имею в виду, если вредоносная программа имеет права root и изменяет вашу память, то вы вряд ли находитесь в положении, когда эта проверка имеет смысл, хаха
> https://raw.githubusercontent.com/good-lly/s3mini/dev/perfor…
Он становится медленнее, когда экземпляр становится быстрее? Я смотрю на ops/sec и time/op. Как я это неправильно понимаю?
Я читал, что из-за размера передаваемого файла каждая операция будет больше и, следовательно, медленнее.
Он измеряет производительность PutObject[0] для разных размеров объектов (1, 8, 100MiB)[1]. Кажется, это странный скриншот текста в терминале.
[0] https://github.com/good-lly/s3mini/blob/30a751cc866855f783a1… [1] https://github.com/good-lly/s3mini/blob/30a751cc866855f783a1…
для узла.
Это хорошие проекты. У меня было несколько раундов с библиотеками Rust S3, и наличие простого клиента с низкой или нулевой зависимостью крайне необходимо. Проблема в том, что вы начинаете поддерживать определенные функции (async, http2 и т. д.), и ваш хороший проект nodep начинает расти.
У меня недавно была такая же проблема, и я использовал https://crates.io/crates/rusty-s3
также: https://crates.io/crates/object_store
для JS
> Работает на Node, Bun, Cloudflare Workers и других периферийных платформах
Но не в браузере… потому что он зависит от API node.js.
Всегда есть https://github.com/mhart/aws4fetch/
Насколько мне известно, рабочие процессы Cloudflare не используют API Node.
Cloudflare Workers теперь имеет широкую совместимость с Node API.
ах, ТИЛЬ!
Интересный проект, хотя немного забавно, что вы анонсировали его до того, как фактически подтвердили его работу с AWS?
Лично мне AWS не очень нравится. Я пытался его настроить, но нашел его «ужасно нудным» и бросил эту идею, сосредоточившись на других платформах.
Прямо сейчас я тестирую/настраиваю Ceph… но он с открытым исходным кодом! Каждый талантливый чудак со свободным временем может внести свой вклад!
Попробуйте также Гараж.
Хорошо, что об этом упомянули. Мы думаем запустить его для некоторых внутренних целей, вместе с Harbor. Тот факт, что ресурсный след рекламируется как достаточно небольшой, убедителен.
Каков ваш опыт управления им?
Как это соотносится с obstore? [1]
[1] https://developmentseed.org/obstore/latest/
Немного по теме: я только что наткнулся на s5cmd[1], который в основном ориентирован на производительность и быструю загрузку/выгрузку и синхронизацию контейнеров s3.
> В 32 раза быстрее, чем s3cmd и в 12 раз быстрее, чем aws-cli. Для загрузок s5cmd может заполнить канал 40 Гбит/с (~4,3 ГБ/с), тогда как s3cmd и aws-cli могут достичь только 85 МБ/с и 375 МБ/с соответственно.
[1] https://github.com/peak/s5cmd
s5cmd встроен в платформу rsync.net. Смотрите:
https://news.ycombinator.com/item?id=44248372
То же самое, что и https://github.com/minio/minio ?
minio — это хранилище объектов, совместимое с S3, связанный s3mini — это просто клиент для хранилищ, совместимых с S3.
Нет, это S3-совместимый клиент, minio — это S3-совместимый бэкэнд
Это хорошо иметь. Несколько месяцев назад я тестировал альтернативу S3, но столкнулся с проблемами при ее работе. Оказалось, это произошло из-за того, что AWS внесла изменения в инструмент, которые привели к блокировке не-первичных клиентов. Просто чистая случайность с моей стороны, но я представляю, как это раздражало людей, которым приходится полагаться на этот клиент. Существует очевидная потребность в совместимом клиенте, с которым AWS не справляется.
это выглядит круто.
но делал ли кто-нибудь сравнение цен на периферийные вычисления и, скажем, ваш скучный Hetzner VPS?
Позволяет ли это генерировать подписанные URL-адреса для загрузок с ограничением по размеру и проверкой имени?
Знаете, что было бы действительно круто? Сделать замену fuse-based drop-in для сопоставления папки с бакетом, как goofys. Может быть, процесс node.js может следить за файлами, например, и делать резервные копии, или, что еще лучше, он может делать резервные копии папки и фактически не занимать место на локальной машине (кроме кэша).
https://github.com/kahing/goofys
Кажется, это совершенно не связано с целью библиотеки OP?
Кажется, это связано с тем, чего хотят многие люди, и теперь, когда у него есть эта библиотека, это легко достижимо!
Вы имеете в виду https://github.com/s3fs-fuse/s3fs-fuse ? Он настолько старый, что даже в Debian есть предварительно скомпилированные пакеты 😉
Я говорил о goofys, потому что он не совместим с POSIX, поэтому он намного быстрее, чем s3fs-fuse
Но любой из них может работать только с s3. Его библиотека работает со многими другими бэкендами. Понял? Я говорю, что ему стоит рассмотреть возможность интеграции с goofys!
Я нашел слова, используемые для описания этого, раздражающие – для меня имеет смысл иметь клиент s3 на моем компьютере, но менее – клиентскую часть в веб-приложении. При дальнейшем чтении это имеет смысл, но выделение того, какую проблему решает этот пакет, в первых нескольких строках readme было бы ценно для таких людей, как я, по крайней мере
Я думаю, что «для платформ node и edge» и «Без поддержки браузеров!» это довольно ясно говорят? Они есть в заголовке и первом абзаце.
Думаю, если вы спросите среднестатистического ИТ-специалиста, что означают эти модные словечки, ответ вам будет непонятен…
У меня есть серьезные подозрения, что это было написано с помощью LLM. Обильное использование эмодзи и сильный гиперуверенный язык выдают это. Доказательство: мои собственные репозитории выглядят так после того, как к ним прикоснулись курсором / виндсерфингом и т. д., но это не умаляет того, полезен ли код или хорош.
честно говоря, английский не мой родной язык, поэтому я помогаю себе с текстом и опечатками… но если вам некомфортно, смело открывайте PR – я хочу, чтобы все было максимально разумно
> для меня имеет смысл иметь клиент s3 на моем компьютере, но не имеет смысла иметь клиентскую часть в веб-приложении
Что вы подразумеваете под веб-приложением?
он ожидал быть клиентом s3 на настольном компьютере/локальной машине
Кажется, это клиент typescript. Хотя вы можете объединить его в веб-приложение, приложение typescript выходит за рамки просто веб-приложений, поэтому я и был сбит с толку.
Ощутимо связано: Bun имеет встроенный клиент, совместимый с S3. Bun — это подарок, если вы используете npm, рассмотрите возможность перехода.
Я пытался пойти по этому пути, используя Bun для всего (Bun.serve, Bun.s3 и т. д.), но был вынужден вернуться к использованию NodeJS и Express/aws-sdk из-за того, что Bun не полностью реализует API Nodes.
Какие наиболее существенные недостающие части были обнаружены?
Хуже всего — это проблемы, которые не видны.
На днях я игрался с сервером MCP ( https://github.com/modelcontextprotocol/typescript-sdk ). В последнее время я использую bun по умолчанию, и сервер на основе http просто не регистрировался в claude или любом другом клиенте. Никаких журналов ошибок, ничего.
Повозившись с кодом, я просто попробовал node, и он заработал.
Он определенно отлично работает в Bun. У меня есть построенный на производстве сервер mcp с аутентификацией, работающий под Bun.
Теперь, если вы преобразуете типы запросов/ответов в собственные типы Bun Server, это может быть сложно.
Но он отлично работает при использовании Express в Bun с официальной реализацией протокола для TypeScript.
На самом деле я тоже пишу об этом книгу и буду использовать для этого Bun https://leanpub.com/creatingmcpserverswithoauth
Не уверен насчет конкретного API, но на момент моей последней попытки Bun все еще не поддерживает PDF.js (pdfjs-dist), ssh2 или playwright.
localAddress не поддерживается на сокетах, то есть вы не можете указать исходящий интерфейс, что полезно, если у вас несколько сетевых карт.
По моему мнению, одним из самых интересных аспектов Bun является предоставление встроенных API, не зависящих от NPM.
Может ли кто-нибудь объяснить, в чем преимущество этого?
Если мне нужен доступ к S3, я могу просто использовать NPM
Если мне не нужен доступ к S3, я не хочу, чтобы он был интегрирован в мою среду выполнения.
Что бы вы предпочли: использовать официально поддерживаемое решение или какой-то случайный пакет случайного автора, который может бросить проект (или сделать что-то похуже)?
Пакеты S3 на NPM поддерживаются AWS
Конечно, но я рассуждал об общем вопросе.
Я был бы удивлен, если бы в каком-либо из ваших проектов Node было менее 100 общих зависимостей, большая часть из которых будет поддерживаться одним человеком.
См. пример Express. Всего 66 зависимостей, из которых 26 зависят от одного сопровождающего.
https://npmgraph.js.org/?q=express
Но даже в случае официального aws-sdk они недавно устарели v2. Теперь мне нужно обновить все мои не очень старые проекты Node для работы с новой версией. Возможно, этого бы не произошло, если бы я использовал клиент S3 Бана.
Так давайте же поместим все возможные пакеты в клиентскую базу?
Такой подход не масштабируется. Нам следует улучшить NPM.
Как улучшить NPM?
Кстати, я не говорю, что нам следует убивать NPM. Я говорю, что нам следует уменьшить нашу зависимость от случайных пакетов.
Bun не нужно добавлять все в ядро движка. Например: при использовании .NET вы все равно добавляете множество официальных зависимостей Microsoft из Nuget.
есть ли способ обернуть их клиент s3 для использования в рабочих процессах HonoJS/CF?
Нет. Он реализован в машинном коде (Zig) внутри самого Bun и доступен разработчикам только как JavaScript API.
Исходный код: https://github.com/oven-sh/bun/tree/6ebad50543bf2c4107d4b4c2…
10/10 Мне нравится (и то, как быстро он работает!) — просто это не тот вариант использования, который мне нужен.
Я хочу иметь максимальную возможность «перемещать» свои проекты между службами/поставщиками/провайдерами
Я пришел сюда, чтобы сказать то же самое.
Вместо использования node лучше отправить oven/bun через docker и получить контейнер размером 90 МБ.
Source: news.ycombinator.com