unregistry

Unregistry é um registro de imagens de contêiner leve que armazena e serve imagens diretamente do armazenamento do daemon Docker (armazenamento de imagens containerd). Ele foi projetado para eliminar a necessidade de um registro externo ao mover imagens entre máquinas. O projeto inclui um comando de plugin da CLI do Docker, `docker pussh` (o 's' extra significa SSH), que envia imagens diretamente para um servidor Docker remoto via SSH. Apenas camadas ausentes no lado remoto são transferidas, o que o README descreve como tornando a operação rápida e eficiente. Como funciona, conforme o README: o comando estabelece um túnel SSH para o servidor remoto, inicia um contêiner unregistry temporário lá, encaminha uma porta localhost aleatória para a porta do unregistry através do túnel, executa `docker push` para o unregistry através dessa porta encaminhada (transferindo apenas camadas ainda não presentes remotamente), então para o contêiner unregistry e fecha o túnel. A imagem transferida fica disponível no daemon Docker remoto. O README compara a abordagem ao rsync para imagens Docker. Motivação: o README lista alternativas comuns e suas desvantagens — registros públicos (exposição de código ou repositórios privados pagos), registros auto-hospedados (serviço extra para manter e proteger), `docker save | ssh ... docker load` (transfere a imagem inteira mesmo quando a maioria das camadas já existe remotamente) e reconstruções remotas (tempo e recursos desperdiçados). Unregistry foi originalmente criado para Uncloud, uma ferramenta para implantar contêineres em vários hosts Docker. Requisitos: localmente, uma CLI do Docker com suporte a plugins (Docker 19.03+) e um cliente OpenSSH. No servidor remoto, o Docker deve estar instalado e em execução, o usuário SSH deve ser capaz de executar comandos docker (root ou um usuário no grupo docker), e `sudo docker` sem senha é necessário se sudo for exigido. O servidor precisa de acesso à internet para ghcr.io para puxar a imagem unregistry no primeiro uso, a menos que a imagem seja pré-carregada manualmente para ambientes isolados ou restritos. O contêiner unregistry precisa de acesso ao socket containerd em /run/containerd/containerd.sock e executa como root. Opções de instalação documentadas: Homebrew (`brew install psviderski/tap/docker-pussh`, além de um symlink em ~/.docker/cli-plugins), download direto do script docker-pussh no diretório de plugins e pacotes Debian não oficiais mantidos em um repositório separado. O Windows não é suportado atualmente, embora WSL 2 com as instruções Linux seja sugerido. A instalação pode ser verificada com `docker pussh --help`. Um tópico de configuração notável é o armazenamento de imagens containerd. Unregistry armazena imagens no armazenamento de imagens do containerd, mas por padrão o Docker mantém sua própria camada de armazenamento separada. Com o armazenamento de imagens containerd habilitado no Docker, as imagens enviadas ficam imediatamente disponíveis para o Docker sem duplicação e operações pussh mais rápidas. Sem ele, o pussh executa um `docker pull` adicional no host remoto, as imagens são armazenadas duas vezes e imagens containerd não gerenciadas podem se acumular; o README mostra `ctr -n moby images ls` e `ctr -n moby images rm` para limpeza manual. Habilitar o armazenamento de imagens containerd é documentado como causando perda temporária de imagens e contêineres criados com o driver de armazenamento clássico. Exemplos de uso incluem enviar para um host remoto, autenticação por chave SSH com `-i`, uma porta SSH personalizada, um arquivo de configuração SSH personalizado com `-F`, selecionar uma plataforma para imagens multi-plataforma (exigindo o armazenamento de imagens containerd localmente) e substituir a versão da imagem unregistry via variável de ambiente UNREGISTRY_IMAGE. Casos de uso documentados são implantação em servidores de produção, pipelines CI/CD e ambientes homelab ou isolados. Unregistry também pode ser executado de forma autônoma como um registro local na porta 5000 montando o socket containerd. O README vincula projetos de terceiros: uma GitHub Action para enviar imagens com docker-pussh, uma GitHub Action para instalar o plugin e uma ferramenta Python para limpar imagens em registros auto-hospedados. Ele credita Spegel como inspiração para usar o armazenamento de imagens containerd como backend de registro e Docker Distribution como a implementação de registro na qual o unregistry é baseado.