Container Registry Repositories and CI Push Access
Get a container image repository for a new application, give your CI pipeline push access, and set retention so running images are kept.
This article explains how a new application gets its own container image
repository (Amazon ECR on AWS, Google Artifact Registry or Container Registry on
GCP), how your CI pipeline gets permission to push images to it, and how to set
up image retention so an image you still run is never deleted.
How images reach your cluster
Your pipeline builds the image and pushes it to your registry. From there the
platform pulls it into your cluster over a private network path, so the cluster
itself needs no registry credentials from you.
flowchart LR A[Your CI pipeline builds the image] --> B[Push to your registry repository] B --> C[Component configuration points at the new tag] C --> D[Platform pulls the image into the cluster]
Everything up to and including the push is yours: the Dockerfile, the build,
the pipeline, and your tagging scheme. The registry and the pull into the
cluster are managed by the platform. See
What You Can Do vs. What We Manage.
Before you start
- Decide the repository name for each Environment the application will run in.
Use one repository per application per Environment, for example
orders-api-prodandorders-api-dev. See Retention and lifecycle
policies for why this matters. - Decide whether you need a specific encryption key for the repository. The
encryption setting cannot be changed after the repository is created;
changing it later means deleting the repository and every image in it.
Create a repository
On AWS, creating a repository is self-service and needs no request:
- Go to Applications → Deployments, choose the Environment in the
Environment filter, and typeecrin the search bar to find its
ECR Component. It is usually in thesharednamespace, but the
namespace differs between Environments, so search rather than browse.
Open the Component. - Click Edit and add the new repository name to the list.
- Click Save.
The repository is available for your pipeline to push to within a few
minutes. Repeat for each Environment.
On GCP, raise a request in your dedicated Slack channel with the application
name and the Environments it needs a repository in.
Get push access for your CI pipeline
On AWS, your pipeline pushes with a dedicated set of registry push
credentials that we issue. If your pipeline does not have them yet, raise a
request in your dedicated Slack channel (see
Access Requests). You receive an AWS_ACCESS_KEY_ID and
an AWS_SECRET_ACCESS_KEY.
- Store both values as CI/CD variables in your CI system, never in the
repository or the pipeline file. In GitLab this is Settings → CI/CD →
Variables. - Mask the key and the secret.
- If the pipeline runs on branches that are not protected, clear the
Protected variable option. A protected variable is empty on an
unprotected branch, and the push fails with a blank username. - Set the registry region as a separate variable, and do not mask it. A
masked region can resolve to an empty value, which produces an endpoint
such asapi.ecr..amazonaws.comwith two dots.
The push credentials can push and pull images, but cannot list or browse
repositories. If someone on your team needs to view repositories and images
in the cloud console, request read-only console access for them instead of
reusing the pipeline credentials.
On GCP, raise a request for pipeline push access to Artifact Registry and say
which CI system runs the pipeline. We agree the authentication method with
you for that pipeline, and you never need a personal account's credentials in
CI.
The deploy step of your pipeline authenticates to SVIEW with its own token.
That token is separate from the registry push credentials: rotating or losing
one does not affect the other.
A public reference pipeline covering build, scan, push, and deploy through
SVIEW is available at
gitlab.com/cto2bpublic/public/generic-pipeline.
Image tags
- Push every build with a unique tag, such as a version number or a commit
hash, and point the Component at that tag. Avoidlatest: you cannot tell
which build is running, and you cannot roll back to it. - Treat a tag as immutable once it has been deployed. Rolling back is then just
a matter of pointing the Component at the previous tag. See
Configuration Versions and Rollback. - Make sure every branch in your pipeline pushes to the repository its
Environment deploys from. A pipeline that reports a successful push while the
pod showsmanifest unknownhas usually pushed to a different repository,
often because one branch is missing an override for the image name.
Retention and lifecycle policies
A new repository keeps every image forever until a retention (lifecycle)
policy is added to it. Retention is not a toggle in SVIEW: raise a request in
your dedicated Slack channel with the repository name and the rule you want.
A retention rule applies to all tags in the repository together. A rule
such as "keep the last 3 images" does not know which tags are production and
which are development. If production and development share one repository, a
run of development builds pushes the production image out of the window and it
is deleted.
A deleted image cannot be recovered. The pod that runs it keeps working, so
nothing looks wrong, until the pod is rescheduled onto a new node, for example
during node maintenance or scaling. The new node cannot pull the image and the
pod fails withImagePullBackOff. The only fix is to rebuild that version from
source and push it again.
To stay safe:
- Keep one repository per application per Environment. "Keep the last 3 images"
is then a reasonable rule, because it counts one Environment's builds only. - If a shared repository cannot be avoided, ask for a rule scoped by tag
prefix, so that production tags (for exampleprod-*) are kept by a separate,
more generous rule than development tags. - Keep enough images to cover your rollback window. A count of 3 is too low if
you push several times a day and may need to roll back further.
Image scanning
Scanning images on push is not enabled on a new repository by default. If you
want the registry to scan each pushed image, raise a request naming the
repository. Fixing the vulnerabilities found remains part of your own
development work; see Vulnerability Management.
What to include in a request
| You need | Include |
|---|---|
| A repository on GCP | Application name and target Environments |
| Push credentials for CI | Environment (or AWS account) and the CI system that will use them |
| A retention policy | Repository name, number of images to keep, and any tag prefixes |
| Scanning on push | Repository name |
| Read-only console access to images | Who needs it and in which Environment |
| Pulling from a repository in another cloud account | Source repository, target Environment |
Related articles
- Components and Deployments — pointing a Component at a new image tag
- Troubleshooting Common Issues —
ErrImagePullandImagePullBackOff - Configuration Versions and Rollback — rolling back to a known-good tag
- Access Requests — how to request access
- Workload Resources and Health Checks — replicas and resources for the running application
Updated 26 days ago