Repository navigation
[shared] restaurar o S3 de integração: imagens minio/minio e minio/mc não são mais baixáveis do Docker Hub #1026
Description
Activity
Investigação: causa e hipóteses testadas em containers isolados
Causa
A MinIO apagou os repositórios
minio/minioeminio/mcdo Docker Hub em 2026-09-11 (entre 18:31 e 19:36 UTC), sem anúncio oficial. Isso fecha uma sequência:- out/2025: a edição comunitária passa a ser "source-only", sem imagens nem binários publicados;
- dez/2025: entra em modo manutenção;
- 2026: os repositórios
minio/minioeminio/mcsão arquivados (o GitHub mostraarchived: true, último push em 2026-04-24).
O espelho
quay.io/minio/*também não serve: medido aqui,docker pull quay.io/minio/minio:RELEASE.2025-09-07T16-13-09Zrespondeunauthorized. Fixar outra tag ou outro digest não resolve.Fontes: StableBuild, vonng.com, byteiota, milvus#53430.
Método
Dois harnesses, um container isolado por candidato.
- API S3: as 4 suítes reais do CI:
s3.integration,van-storage.s3.integration,profile-photo-storage.s3.integrationelogo-storage.s3.integration. - Compatibilidade com o
compose.yamlde dev:- credenciais por
MINIO_ROOT_*_FILE; curl+/minio/health/readydentro da imagem;- o
command: server /data --console-address ":9001"; - bootstrap
mc(mb,version enable,anonymous set download) seguido de GET anônimo.
- credenciais por
Controle: a imagem original (
minio/minio@sha256:14cea493…, ainda em cache local) passou em tudo: 22/22 nas suítes e 4/4 no compose. O harness está validado.Resultados
Hipótese Imagem Pull anônimo Suítes S3 Drop-in no compose Licença · manutenção H1 espelho oficial quay.io/minio/minio❌ unauthorized— — — H2 Bitnami legacy bitnamilegacy/minio✅ ✅ 22/22 ⚠️ não: com ocommanddo compose o container morre; sem ele passa em tudo (inclusive*_FILE); caminho de dados mudacongelada, sem patches (anúncio da Bitnami, ago/2025) H3 fork Silo pgsty/silo✅ ✅ 22/22 ✅ 4/4 sem mudar nada além da imagem AGPL-3.0 (igual ao MinIO); fork ativo, releases mensais (última RELEASE.2026-09-16)H4 MinIO do fonte build local da tag RELEASE.2025-10-15T17-29-55Zn/a (build de 2m26s) ✅ 22/22 ✅ 4/4 AGPL-3.0; upstream arquivado: ninguém corrige CVE, o build fica conosco H5 RustFS rustfs/rustfs✅ ✅ 22/22 ⚠️ não lêMINIO_ROOT_*_FILE(usaRUSTFS_*); bootstrap e envs a refazerApache-2.0; muito ativo (34k★) H6 SeaweedFS chrislusf/seaweedfs✅ ✅ 22/22 (com -s3.configem JSON)❌ outro modelo de credencial e de comando Apache-2.0; maduro (desde 2014, 35k★) Cliente
mcpara o bootstrap:pgsty/mc(AGPL-3.0) ebitnamilegacy/minio-clientfuncionam contra o controle e contra os candidatos MinIO-compatíveis.Não testado aqui: o
no-new-privilegesdo compose. O Docker local é snap e não executa nenhum container com essa flag (nemalpine). Fica para o CI do PR do conserto provar.Recomendação
H3 (Silo +
pgsty/mc) como conserto imediato. É a única opção ao mesmo tempo drop-in (troca só a linhaimage:dos dois serviços), mantida e com a mesma licença já analisada no ADR-0019. Pins multi-arch (amd64 + arm64) medidos hoje:image: pgsty/silo:latest@sha256:635197cb9f36d01bee221d34d1c7d7960f6a95c48b0b6c01d99cd13bdae51a46 image: pgsty/mc:latest@sha256:cfc83108c3abb371f8fb84d99c1fdc88f8c237e022409b0081fb7c0a3be634dd
Ponto fraco declarado: é um fork de um mantenedor principal (bus factor baixo), criado em out/2025.
Saída de médio prazo, se esse risco não for aceito: H5 (RustFS, Apache-2.0, comunidade grande). Exige reescrever o serviço e o bootstrap no compose, e um ADR que supersede o ADR-0019 na escolha do S3 de dev.
H2 está descartada: é imagem congelada, sem patches. H4 está descartada: compilar um upstream arquivado nos põe na posição de mantenedores de segurança de um servidor S3.
🎯 Problema (uma frase, sem ambiguidade)
As imagens
minio/minioeminio/mcpinadas nocompose.yamldeixaram de ser acessíveis no Docker Hub, e o workflowintegrationfalha todo dia namaindesde 2026-09-12 nos jobs que sobem o MinIO.📍 Localização
compose.yaml:98(minio/minio:latest@sha256:14cea493…),compose.yaml:136(minio/mc:latest@sha256:a7fe349e…)shared· infra (compose / CI)🔍 Atual vs. Esperado
docker compose up miniofalha compull access denied for minio/minio; jobsintegração (storage),(logo),(photo)e(gate)vermelhos🧠 Por quê (causa-raiz + impacto)
minio/minioeminio/mcnão respondem mais publicamente no Docker Hub —pulledocker manifest inspectfalham inclusive pelos digests pinados (denied: requested access to the resource is denied/unauthorized: authentication required). Não é rate limit nem credencial do runner: reproduz numa máquina de dev.mainvermelha há semanas; ADR-0019 (MinIO como S3 de dev/teste) e ADR-0011 (pin de imagem) assumem uma fonte que deixou de existir.integrationvermelho, o que treina o time a ignorar o check. Clone novo sem cache local também não sobe o MinIO.🔁 Reprodução / evidência
integração (storage)):minio Error pull access denied for minio/minio, repository does not exist or may require 'docker login'.gh run list --workflow integration: último sucesso em 2026-09-11 (main); falha diária noscheduledamainde 2026-09-12 em diante, sempre nos mesmos 4 jobs.✅ Critérios de aceite
node scripts/ci/test-integration.ts storageroda, Então o serviço S3 sobe saudável e a suíte passa (idemlogoephoto).compose.yaml, Quando se inspeciona a imagem do serviço S3 e do bootstrap, Então ambas estão pinadas por digest de uma fonte acessível sem login, edocker manifest inspect <imagem@digest>responde 0.supersedes.🧪 Definition of Done
integrationverde namain(schedule) e no PR do conserto, nos jobsstorage,logo,photoegate.pnpm run typecheck+pnpm run format:check+pnpm run lint+pnpm test.🏷️ Classificação
bugalta(CI da main vermelho há semanas; storage sem cobertura de integração)Mshared:ci:minio-image-unavailable