
Комментарии 37
А где ссылка на репозиторий? Думаю стоит расписать побольше о проекте
Похоже вот этот: https://github.com/getnora-io/nora
Проксировать в апстрим всё, чего не нашлось локально - потенциально небезопасно. Разработчик опечатался и вот он уже тянет заботливо подложенный в апстрим mycorp-comon вместо локального mycorp-common. Приходится анализировать по маскам "похоже на внутренние - ищи локально или бросай 404".
Всё верно. Нужный механизм уже реализовывал, правда, с Нексусом, перед которым отлавливали все обращения и сличали с тем, что есть в разрешенных списках, только после этого давали возможность скачать. В этом софте такая фича будет, но чуть позже.
Отличный проект!
Если добавите еще APT и RPM - цены вам не будет :)
Спасибо за обратную связь!
Будут, скорее всего, но чуть позже.
Обновление: APT и RPM запланировал на v0.8. Сложность на порядок выше остальных форматов (GPG-подпись, InRelease/repomd.xml, специфичные ожидания apt/yum), поэтому выделил в отдельный релиз после security-фич. Issue: https://github.com/getnora-io/nora/issues/128
не знаю поможет ли у меня вот так упаковывает в deb
https://github.com/gitavk/KubeTile/blob/main/.github/workflows/release.yml#L51
там тоже на rust
И nuget было бы приятно.
Спасибо за запрос! NuGet proxy будет в v0.7, ближайшем security-релизе. Появится кэширование пакетов с nuget.org через NuGet V3 API (Service Index, Package Content, Registration). Issue: https://github.com/getnora-io/nora/issues/140
Спасибо за статью, и за проект.
Возник вопрос - как масштабировать?
Правильно ли я понял что приложение масштабируется просто - кол-вом инстансов + rwm хранилище? Какие вообще сценарии масштабирования тестировались?
RWM с несколькими инстансами не поддерживается, можете попробовать пока масштабирование чтения через S3 + CDN/кэш перед NORA.
HA в roadmap.
А производительность тестировали?
Формального нагрузочного тестирования пока не проводил, вот завёл ишуйку: https://github.com/getnora-io/nora/issues/130
Пробовал неделю назад 0.4 с docker и pypi, работало всё и правда шустро.
Документация на сайте не поспевала до актуальной версии, но в целом не проблема.
А вот S3 (RustFS) как storage у меня совсем не взлетел, сегодня попробую ещё раз и сделаю нормальный issue
Спасибо за обратную связь. Вот здесь описал то, что у вас, скорее всего, было и как настроить https://getnora.dev/ru/configuration/s3-storage/
Я правильно понял, что эту штуку можно развернуть локально и при некоторых настройках оно будет кэшировать то, что dockerfile пытается тащить из внешних сервисов?
Тогда бы неплохо добавить поддержку mise
Всё верно вот посмотрите описание конкретного функционала
https://getnora.dev/ru/configuration/docker-proxy/
По mise - пока сложно сказать, посмотрите в сторону Raw.
А возможна ли в будущем поддержка следующих форматов?
- Terrafrom registry (hosted и proxy);
- Ansible galaxy (proxy).
Да, оба формата в планах.
github.com/getnora-io/nora/issues/133
github.com/getnora-io/nora/issues/134
Выглядит интересно. Хоть кто-то начал делать систему не от максимального количества свистелок
Кладбище альтернатив
Смело вы их всех похоронили. А вот ещё из живых:
Мы недавно себе тоже выбирали, куда сбежать от JFrog Artifactory, которые каждый год стоимость подписки увеличивали на всю большую и большую сумму. Правда, дальше Gitea особо ничего не стали смотреть, потому что на бесплатном Free / Open Source self-hosted варианте все наши форматы пакетов есть, так что про остальных кандидатов из списка ничего сказать не могу, но выглядят они вполне бодро.
Спасибо за дополнение, справедливое замечание.
Gitea - отличный выбор, если команда уже на нём сидит и форматы совпадают. Для вашего кейса (уйти от JFrog и не платить) совершенно логичное решение.
NORA про другой сценарий: отдельный реестр без Git-сервера вокруг.
Пара вещей, которые в Gitea пока не завезли:
- Проксирование upstream-реестров - NORA кэширует пакеты из Docker Hub, npmjs, PyPI локально. В Gitea это открытый тикет https://github.com/go-gitea/gitea/issues/21223 с 2022 года до сих пор не реализовано.
- Большие образы - в Gitea пуш образов больше 800 МБ падает с ошибкой 500, и это актуально для свежей v1.25.5 (https://github.com/go-gitea/gitea/issues/36945).
В NORA ограничение только по диску.
- Очистка мусора - multi-arch образы в Gitea никогда не удаляются, пользователи сообщают о терабайтах мусора (https://github.com/go-gitea/gitea/issues/32053). Автоочистка без тегов - открытый тикет с 2022 года (https://github.com/go-gitea/gitea/issues/21673).
Вишенка - архитектурное решение. Реестр в Gitea - это плагин внутри монолита. Авторизация через токен в CI до сих пор ломается (https://github.com/go-gitea/gitea/issues/23642). Контейнерный реестр нельзя сделать приватным (https://github.com/go-gitea/gitea/issues/24174). В отдельном реестре этих проблем нет по определению,соответственно, падение реестра не утащит за собой Git-сервер.
Если Gitea у вас для кода и пакеты не нагружают, тогда нет вопросов, всё ок. Но если реестр под нагрузкой в CI, закономерно, что стоит держать его отдельно. NORA стартует за 3 секунды, ест 12 МБ памяти и не роняет ваш Git-сервер.
По остальным из списка: Cloudsmith и Buildkite - облачные сервисы, другая категория. ProGet - больше Windows/.NET мир. RepoFlow - 2 тысячи убитых енотов в год.
Добавлю Gitea в сравнение, спасибо за наводку.
https://alternativeto.net/software/nora-registry/
Да, там у Gitea (и, скорее всего, у Forgejo тоже), на самом деле, есть ещё ряд проблем, как-то: нельзя указать свой PGP ключ для подписи APT/deb пакетов (генерируется новый по умолчанию и поменять его никакого API нет), какие-то косяки с видимостью Conan пакетов для разных платформ в пределах одной и той же версии пакета, и другие особенности. Ну за бесплатно можно и потерпеть, да.
Собственно, если бы в Норе были APT/deb и Conan, я бы уже бежал ставить, волосы назад.
Обе фичи в плане на v0.8:
- deb/APT https://github.com/getnora-io/nora/issues/128
- Conan (C/C++) https://github.com/getnora-io/nora/issues/142
В NORA ограничение только по диску.
На больших объемах, когда со стороны источника идет долгая загрузка - падает на timeout. Приходится поднимать до 1800 сек и запускать сборку еще раз (на память вроде NORA_DOCKER_PULL_TIMEOUT или NORA_DOCKER_PROXY_TIMEOUT на сервере).
Может имеет смысл добавить режим - прокачать/прогреть зависимости подав на вход Nora Dockerfile/Compose файлы?
Спасибо за фидбек!
NORA_DOCKER_PROXY_TIMEOUT=300 (или выше) решает проблему уже прямо сейчас. А вот Default 60s, действительно, маловато для больших образов, подниму в следующем релизе.
Еще хардкод timeout в nora mirror - баг, поправлю.
Идея с warmup интересная, записал в roadmap.
Скорее всего будет в формате nora warmup image1 image2 --from-compose compose.yml
Можно ещё сравнить с https://github.com/pulp
Я хотел его добавить в список, но это изделие для очень смелых и сильных программистов. Когда я пытался с ним познакомиться в прошлом году, в документации превалировали статьи-плейсхолдеры (со ссылками на задачи по написанию этих статей) вместо реального контента, а без документации я не осилил.
Кроме того, NuGet в список поддерживаемых не завезли, когда я смотрел. Хотел сейчас ещё раз проверить, да у них сайт что-то не открывается.
Очень не хватает политики хранения (авто очистки), как в gitlab или harbor. Частые коммиты и последующие сборки образов забивают хранилище
Вопрос снимается, вижу в планах retention policy https://github.com/getnora-io/nora/issues/123
Колобок-стек: от Nexus ушёл, от Artifactory ушёл — написал свой реестр на Rust