Background
After migration, registry.drycc.cc should remain a stable entrypoint. It will reverse-proxy to GHCR/Quay/other registries and select backend by GeoIP for better latency and resilience.
Goals
- Keep
registry.drycc.cc as a unified registry endpoint
- Route by GeoIP/region policy
- Provide backend failover, observability, and optional caching
- Keep client usage as transparent as possible
Scope
- Routing policy
- Region → backend mapping (e.g., CN/APAC/EU/US)
- Primary + secondary backend priorities
- Health-check-based failover
- Proxy implementation
- Select stack: Nginx/OpenResty/Envoy/Caddy
- Ensure OCI Registry API compatibility (auth, redirects, blob pulls)
- Performance and caching
- Optional hot-image cache strategy
- Optimize HEAD/GET request handling
- TLS termination + HTTP/2 support
- Observability
- Metrics: hit ratio, upstream latency, error rate, region split
- Logs: request ID, routing decision, failure reason
- Alerts: backend outage/error spikes
- Security
- Secure upstream credentials/token flow
- Rate limiting and abuse protection
Definition of Done
Risks / Notes
- OCI auth/redirect edge cases (token realm / 302 flow)
- GeoIP misclassification impact
- Cache consistency and storage pressure under high load
Background
After migration,
registry.drycc.ccshould remain a stable entrypoint. It will reverse-proxy to GHCR/Quay/other registries and select backend by GeoIP for better latency and resilience.Goals
registry.drycc.ccas a unified registry endpointScope
Definition of Done
registry.drycc.cccan transparently serve images from GHCR/QuayRisks / Notes