Skip to main content

Decide How to distribute Docker Images

Choosing the right method to distribute Docker images is crucial for efficient deployment and management.There are various options, including AWS ECR, GitHub Container Registry, DockerHub, Artifactory/Nexus, and self-hosted registries, with multiple advantages and drawbacks.

Use AWS ECR

This is by far the most common approach we see taken. Our typical implementation includes a single ECR in the automation account. Read-only access granted to other accounts as necessary. Push images with commit sha’s and stage tag. Use lifecycle rules on stage tag to avoid eviction. The main downside with ECR, is each image repository in the registry must be explicitly provisioned. If we decide to go with ECR, we’ll also want to Decide on ECR Strategy .

Use GitHub Container Registry

https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-docker-registry

Use Dockerhub

DockerHub is well suited for public images because it’s the default registry, however, images are aggressively rate limited for anonymous pulls, and no longer recommended. Additionally, as a private registry, it’s a bit dated and requires static credentials, unlike with ECR. One nice thing DockerHub is repositories do not need to be explicitly created.

Use Artifactory/Nexus/etc

This is more common for traditional artifact storage in Java shops. We don’t see this typically used with Docker, but it is supported.

Self-hosted Registries (e.g. Quay, Docker Registry, etc)

We don’t recommend this approach because, at the very least, we’ll need to use something else like ECR for bootstrapping.