Lower the cost of the registry by improving storage management
## Problem to solve The GitLab Container Registry allows you to build, push and share Docker images/tags using the Docker client or GitLab CI/CD. As adoption has grown, we have seen a drastic increase in the amount of storage being used by the registry. However our tools for managing the container registry do not meet GitLab's or our customer needs. This epic will give administrators more tools for pruning the registry. The goal will be to provide: 1. An improved user experience for removing tags/images from the UI 1. An expanded API that allows for the bulk removal of images/tags at the group level 1. An optimized garbage collection process that can handle terabytes of data without long windows of downtime 1. UI driven retention and expiration policies for images 1. The ability to expire images from CI/CD 1. Automated/scheduled garbage collection ## Target audience and experience - [Systems Administrator](https://design.gitlab.com/getting-started/personas#persona-sidney): Although developers will be able to remove images leveraging the UI, the primary user this epic is focused on is the system administrator. ## Outcomes - Reduce the amount of time required to untag images by 30% - Reduce storage costs on behalf of our customers by 30% ## Further details ### Important decisions In https://gitlab.com/gitlab-org/gitlab-ce/issues/62885# we decided what, architecturally, needed to be done to take the container registry from [viable](https://about.gitlab.com/direction/maturity/) to [complete](https://about.gitlab.com/direction/maturity/). We evaluated building our own container registry, forking Docker's open-source [Docker Registry](https://github.com/docker/distribution) or integrating with an existing product, such as [Harbor](https://goharbor.io/) or [Docker Trusted Registry](https://docs.docker.com/ee/dtr/). We decided to [fork docker registry](https://gitlab.com/gitlab-org/gitlab-ce/issues/66062) for the following reasons: - Concerns about integrating other products within GitLab and the duplication/removal of features - Risk of building our own registry from scratch and the unknown unknowns. - Forking seemed like the most iterative approach we could take to solving the storage management problem as fast as possible. ### Think BIG discussions As a team, the Package group holds regular "Think BIG" discussions, where we review planned work and ensure we are moving in the right direction. [Video: Think BIG - Lower the cost of the Registry](https://www.youtube.com/watch?v=43A-OE5xT2Q&list=PL05JrBw4t0KoPiSySNHTfvxC20i0LppMf&index=41)
epic