Choosing a Container Registry

[rbadillap]

Inspired by #424 and #429, it is a good time to define which container registry we can use for all our services, thinking about the unification and standardization of our processes.

Currently, for the frontend service we use AWS ECR which has allowed us to automate deployments to different environments through events in a workflow built almost automatically by AWS and following its best practices.

We currently have other services such as the API that are starting to integrate with the native GitHub service, ghcr.io. Much of the automation already done through AWS should be implemented here, e.g: to notify when an image has been pushed or removed from the registry.

The question we have for the general public is, what opinion do you have of each of the registries mentioned here, any particular preference? feedback to share?

[zackkrida]

I see two options:

1. We duplicate/mirror containers in ghcr.io
2. We modify any AWS integrations to work with ghcr.io, which probably means triggering AWS Code Pipeline or whatever services we're using with a webhook sent by our GitHub actions.

[dhruvkb]

2️⃣ I'd really not prefer two sources from which to download images as it can lead to a lot of effort on our part to maintain two sources of truth. The second option is the more elegant one in my opinion.

[zackkrida]

2. Is more up-front work, but 1. Would really only involve having two few-line steps in a GitHub action.

[AetherUnbound]

One of the big reasons I would prefer ghcr.io over AWS ECR is that I know for certain our published images will be public and accessible to anyone for download. They're also tied directly with our repositories (see ghcr.io/wordpress/openverse-api). This makes it very clear for folks how they can download the images and where they can be found. If the images were in ECR, it seems that making them public/accessible would be difficult or not as concise as ghcr.io.

[dhruvkb]

With all our code hosted in GitHub, it makes logical sense for images built out of that code to be hosted there as well. I have built workflows in the past where images pushed outside ECR can still trigger CodeDeploy to run the deployment pipeline so that should not be a deal-breaker.

[dhruvkb]

In support of GHCR, I have a couple of points

• easy publishing: the workflow for pushing images to GHCR is very simple, no need to manage credentials for ECR as GitHub's built-in token can be used for this
• tighter integration: the images pushed to GHCR are directly linked to our repo so links for opening issues, participating in discussions and info like the README/license are all easy to find in a familiar UI

[zackkrida]

We've built consensus around ghcr.io and have already started using it.