GPII-3641, we pulled all images from public repos (mostly Docker Hub).
GPII-3641, we pull all images from a single production GCR instance (gcr.io/gpii-common-prd).
Because Docker tags are mutable, it is possible with either of these arrangements to deploy an image to production that has not moved through the pipeline.
 We also have a staging GCR instance (gcr.io/gpii2test-common-stg), but nothing uses it.
 A scenario:
- Pod uses couchdb:2.2, which is sha256:11111
- couchb:2.2 changes upstream to sha256:22222
- Pod crashes and restarts, pulls couchdb:2.2 which is now sha256:22222
This problem is mitigated by a few factors:
- For "internal" components (e.g. gpii/universal), we use sha256 directly rather than a tag. These components are not susceptible to this problem.
- In practice, I do not expect projects to change the tag of a published image, so this problem should be rare.
Here's one way it could work:
- gpii-version-updater runs as today, but pushes new images to the common-stg GCR and writes to versions.common-stg.yml.
- dev environments (including CI dev environments like dev-doe and dev-gitlab-runner) get image information from versions.common-stg.yml.
- Once dev environments pass, a pipeline step pushes image to the common-prd GCR and writes to versions.common-prd.yml.
- This will require granting gcr_uploader privileges to the CI worker, probably via ansible-gpii-ci-worker (there is code to do something similar for i46 in ansible-gpii-version-updater).
- stg and prd get image information from versions.common-prd.yml.