Обновить

Комментарии 37

А где ссылка на репозиторий? Думаю стоит расписать побольше о проекте

Проксировать в апстрим всё, чего не нашлось локально - потенциально небезопасно. Разработчик опечатался и вот он уже тянет заботливо подложенный в апстрим mycorp-comon вместо локального mycorp-common. Приходится анализировать по маскам "похоже на внутренние - ищи локально или бросай 404".

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

Если позволите, ещё понужу: хочется уметь блокировать пакеты по имени+версии или хешам. Если известно, что использованный кем-либо внутри пакет преисполнился дюжиной CVE - хочется намертво его забанить, а не просто поднять логи кто его скачал.

Успехов в Вашем начинании!

Спасибо!
Добавил в роудмапу.

Отличный проект!

Если добавите еще APT и RPM - цены вам не будет :)

Спасибо за обратную связь!
Будут, скорее всего, но чуть позже.

Обновление: APT и RPM запланировал на v0.8. Сложность на порядок выше остальных форматов (GPG-подпись, InRelease/repomd.xml, специфичные ожидания apt/yum), поэтому выделил в отдельный релиз после security-фич. Issue: https://github.com/getnora-io/nora/issues/128

И 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).

Обновление: оба формата перенесены с v0.8 на v0.7, выйдут вместе с security-фичами. Terraform Registry (providers + modules) и Ansible Galaxy (collections) будут за cargo features, так что можно будет отключить при сборке, если не нужны. Issues: #133, #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, я бы уже бежал ставить, волосы назад.

Для nix окружений тоже подходит? Отдельно наверное можно посмотреть на штуки типа chocolatey/scoop.

В 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. Частые коммиты и последующие сборки образов забивают хранилище

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации