rp-registry
Назначение
Реестр модулей и решений: что существует, из чего состоит каждое решение,
а также сами байты. Он отвечает двум читателям, у которых больше нет ничего
общего. Ptah запрашивает индекс, а затем объекты по дайджесту, никогда не узнавая
имя и проверяя каждый полученный байт. Портал и чат задают противоположный
вопрос — какие решения существуют, что даст это решение и что ему нужно
сначала.
Оба работают в одном сервисе, потому что каталог, называющий модули, которых
нет в хранилище объектов, — это как раз та ошибка, которую призвано предотвратить
это решение; проверить её можно только там, где видны обе составляющие.
Граница ответственности
rp-registry никогда не взаимодействует с кластером. Он публикует каталог и
обслуживает байты; превращение выбора в работающую платформу выполняет, записывая пользовательские ресурсы lm-kubernetes, а их согласованиеSolution
— задача ptah. Такая граница позволяет одному реестру обслуживать множество
кластеров, не храня учётные данные ни для одного из них.
Хранилище
Два хранилища — намеренно не больше.
— это единое KV-хранилище, содержащее два вида значений под двумяobjects
префиксами: байты модулей по дайджесту () и документы решений по слою иobj
имени (). Оба значения целиком читаются по точному ключу, поэтому это одинsol
и тот же тип хранилища, использованный дважды. различает бинарныеKVStore
данные и JSON по заголовку, который записывает сам, поэтому здесь ни одному
префиксу не требуется декодирование.
— это SQL, поскольку он хранит изменяемую и запрашиваемую части:catalog
какому дайджесту в данный момент соответствует каждый артефакт и в каком слое.
Байты неизменяемы и адресуются по содержимому, поэтому им не нужна таблица;
имена меняются при каждой публикации, а запрашиваются по слою, по типу и между
слоями.
Опубликованное отображение не хранится. Оно вычисляется по запросу как свёртка
над и layers, а его дайджест — это modules. Хранение отображенияrevision
создало бы вторую копию истины, которая устаревает именно тогда, когда только
что произошла публикация и кластер спрашивает, почему не может её увидеть.
Слои
Слой — это результат одной сборки. публикует свои модули, convergedclub
публикует собственные и объявляет , а отображение,extends: ["converged"]
которое читает каждый потребитель, составляется из всех них — слой продукта
следует после расширяемого им базового слоя, поэтому модуль, который он намеренно
заменяет, побеждает. Порядок публикации перестаёт иметь значение, и ни одна
сборка не может удалить имена, которые она не создавала.
Публикация полностью заменяет слой, а не объединяет его: публикация — это весь
результат данного слоя, поэтому имя, которое новая сборка больше не создаёт,
должно исчезнуть. Объединение оставило бы его указывающим на байты, которые
больше ничто не собирает.
Обслуживание байтов
возвращает ключ Valkey, а не сам объект. БайтыensureObjectCached
материализуются в кэше с заданной областью видимости и читаются оттуда ui — это
та же передача, которую gallery использует для изображений, и по той же причине:
размер модуля может достигать 2 MiB, а ответ с полезной нагрузкой при каждом
промахе кэша протащил бы её через storage → ms → ui по каналу, предназначенному
для запросов.
Два маршрута, которые использует кластер, — и/registry/index.json — обслуживаются хостом ui клуба, а не этим сервисом/registry/<digest>
(). ptah говорит только поclub/core/frontend/landing/src/ptah-registry.ts
обычному HTTP и больше никак, поэтому отвечать за него должен компонент с
HTTP-интерфейсом — это ui; базовый образ остаётся в стороне, поскольку продукту
без реестра нечего обслуживать. Маршруты анонимны, потому что подлинность
обеспечивается дайджестом: ptah проверяет каждый полученный байт по дайджесту,
который запросил, поэтому общий секрет добавил бы необходимость распространять
и отзывать его, не добавив никаких гарантий.
Дайджест, который не назван ни в одном слое, не обслуживается, даже если байты
сохранены. Объекты без имени — это либо мусор от прерванной публикации, либо то,
что угадал вызывающий, а их обслуживание превратило бы это хранилище в открытое
blob-хранилище.
Ограничения
Размер объекта ограничен 2 MiB. Настоящие модули занимают десятки килобайт —
весь набор бэкендов converged занимает около 0.44 MiB в сжатом виде, — а ptah
отказывается принимать всё, что больше 64 MiB, так что этот предел значительно
ниже обоих. Это не оптимизация: реестр предназначен для хранения модулей
сообщества, и загрузка размером с образ контейнера означает, что кто-то
опубликовал неправильный артефакт.
Объекты хранятся ровно в том виде, в каком поступают. Реестр их не сжимает и не
распаковывает: пакеты модулей используют brotli, исходники рабочих процессов
хранятся без обработки, поскольку centimanus исполняет их сам, а дайджест в
обоих случаях охватывает сохранённые байты. Любое перекодирование нарушило бы
адресацию по содержимому на том единственном переходе, который она призвана
защищать.
Исходный код
modules/repositories/rp-registry