rp-registry

Finalidade

O registro de módulos e soluções: o que existe, do que cada solução é composta,
e os próprios bytes. Ele responde a dois leitores que não compartilham mais nada. Ptah
solicita um índice e depois objetos por digest, sem nunca descobrir um nome e
verificando cada byte que recebe. O portal e o chat fazem a pergunta oposta — quais
soluções existem, o que esta traria, do que ela precisa primeiro.

Ambos vivem em um único serviço porque um catálogo que nomeia módulos que o
armazenamento de objetos não contém é justamente a falha que isto existe para
impedir, e isso só pode ser verificado onde as duas metades estão visíveis.

Limite de responsabilidade

rp-registry nunca toca em um cluster. Ele publica um catálogo e serve bytes;
transformar uma seleção em uma plataforma em execução é responsabilidade de lm-kubernetes,
que escreve recursos personalizados Solution, e reconciliá-los é responsabilidade
do ptah. Manter essa separação significa que um único registro pode atender a vários
clusters sem possuir credenciais para nenhum deles.

Armazenamento

Dois armazenamentos, deliberadamente não mais que isso.

objects é um único armazenamento KV que contém dois tipos de valor sob dois prefixos:
bytes de módulos por digest (obj) e documentos de solução por camada e nome (sol).
Ambos são lidos integralmente por uma chave exata, portanto são o mesmo tipo de
armazenamento usado duas vezes. KVStore identifica binário e JSON por meio de um
cabeçalho que ele próprio grava, então nenhum dos prefixos precisa ser decodificado aqui.

catalog é SQL, porque contém a parte que muda e a parte que é consultada: qual artefato
atualmente resolve para qual digest, em qual camada. Bytes são imutáveis e endereçados
por conteúdo, então não precisam de uma tabela; nomes mudam a cada publicação e são
consultados por camada, por tipo e entre camadas.

O mapeamento publicado não é armazenado. Ele é uma dobra sobre layers e modules
calculada sob demanda, e seu digest é a revision. Armazená-lo manteria uma segunda
cópia da verdade que fica obsoleta exatamente quando uma publicação acabou de acontecer
e um cluster está perguntando por que não consegue vê-la.

Camadas

Uma camada é a saída de uma compilação. converged publica seus módulos, club publica
os próprios e declara extends: ["converged"], e o mapeamento que todo consumidor
lê é composto de todas elas — uma camada de produto sendo aplicada depois da base que
estende, de modo que um módulo que ela substitui deliberadamente prevalece. A ordem de
publicação deixa de importar, e nenhuma compilação pode apagar nomes que não criou.

A publicação substitui uma camada por completo em vez de mesclá-la: uma publicação é
a saída inteira daquela camada, então um nome que a nova compilação deixou de produzir
tem de desaparecer. Mesclar deixaria o nome apontando para bytes que já não são
produzidos por nenhuma compilação.

Servindo os bytes

ensureObjectCached devolve uma chave Valkey, não o objeto. Os bytes são materializados
no cache com escopo e lidos dali pela ui, que é a mesma transferência usada pela galeria
para imagens e pelo mesmo motivo: um módulo pode ter até 2 MiB, e responder com o payload
faria com que ele passasse por armazenamento → ms → ui a cada falha de cache, por um canal
destinado a requisições.

As duas rotas que um cluster usa — /registry/index.json e /registry/<digest> —
são servidas pelo host de ui do club, não por este serviço
(club/core/frontend/landing/src/ptah-registry.ts). ptah fala HTTP simples e nada mais,
então algo com uma superfície HTTP precisa responder por ele, e esse algo é a ui; a imagem
base fica fora disso, porque um produto sem um registro não tem nada para servir. As rotas
são anônimas, porque a autenticidade depende do digest: ptah verifica cada byte que recebe
contra o digest solicitado, então um segredo compartilhado acrescentaria algo para
distribuir e revogar sem acrescentar uma garantia.

Um digest que nenhuma camada nomeia não é servido, mesmo quando os bytes estão armazenados.
Objetos sem nome são lixo de uma publicação interrompida ou algo que um chamador adivinhou,
e servi-los transformaria isto em um armazenamento aberto de blobs.

Limites

Um objeto é limitado a 2 MiB. Módulos reais têm dezenas de kilobytes — todo o conjunto de
back-end do converged tem cerca de 0.44 MiB comprimido — e ptah recusa qualquer coisa
acima de 64 MiB, portanto isto fica muito abaixo de ambos. Não é uma otimização: o registro
deve armazenar módulos da comunidade, e um upload do tamanho de uma imagem de contêiner
significa que alguém publicou o artefato errado.

Os objetos são armazenados exatamente como chegam. O registro não comprime nem
descomprime: pacotes de módulos são brotli, fontes de workflow são brutas porque
centimanus as executa diretamente, e o digest cobre os bytes armazenados nos dois casos.
Qualquer re- codificação quebraria o endereçamento por conteúdo no único ponto em que ele
existe para proteger.

Fonte

modules/repositories/rp-registry