Open piontec opened 4 months ago
The git tag prefix / mono repo support was released as of:
The POC can be found at: https://github.com/giantswarm/laszlo-monorepo
This only solves custom image builds. There are a bunch of images in the customised images yaml file that are repo renames only. Reason they are there because everything else uses skopeo sync
that does not support renames (see: https://github.com/containers/skopeo/issues/1998). The custom image build uses skope copy
that does support rename. We have to figure out something for those.
- We want to be able to tell if an image is copied from upstream or really a Giant Swarm specific image, so we want to use proper repositories and their names (so postresql/postgresql image from docker hub synchronized to gsoci.azurecr.io becomes gsoci.azurecr.io/postgresql/postgresql and not gsoci.azurecr.io/giantswarm/postgresql.
This will require some wider communication, since there are customer image policies that rely on using the giantswarm organization.
It is also important to check whether this assumption can be safely held for other registries (China, zot, etc.) and whether that will have consequences (e.g. could zot contain a mix of retagged and direct upstream images?)
As part of our registries efforts, we wanted to improve retagger as well. This ticket catches more details about that task.
How retagger currently works
Retagger is a go CLI and a huge circle CI build pipeline. In general, there are 2 modes, executed in the CI pipeline one after the other:
skopeo-*.yaml
files. They are synced in the following way:retagger filter
is invoked for eachskopeo-*.yaml
file. Internally, thisretagger
command works as follows:skopeo sync
with the singleskopeo-*.yaml
file in dry mode. This lists all the tags available for all the images in the source repository (so it "expands" semver ranges and tags with regular expressions into specific tags).skopeo-*.yaml.filtered
retagger sync
is run for that*.filtered
file to do actual synchronization.split
thensync
above comes, AFAIR, from two sources, the main one being that some time ago it was impossible to runsync
on semver ranges, and we had to discover and list the images before we were able to useskopeo
for sync. There was something about better performance as well, but I'm not sure if that argument holds after semver ranges are now supported in scopeo.USER <UID>
),retagger
can do this as well: it will build the image, then upload it to a target registry. It is important to note, that majority of "custom images" actually only include image rename. The main reason for that seems to be to avoid the confusion about what this image does (if we replicatebitnami/postgresql
intogiantswarm/postgres
, we no longer know which build of postgres is that, so to avoid that we rename the image intogiantswarm/bitnami-postgres
; this is no longer need - see "current problems" below). The rest of customized images actually mutates the source image. The build works like this, in a loop for each image in thecustomized-images.yaml
retagger
creates aDockerfile
, that hasFROM <src image>
set using thecustomized-images.yaml
entry, then runsdocker build + tag
anddocker push
on it.Current problems
retagger
synchronizes all the images into the target repositorygiantswarm/*
, so the original repository name is lost, for ex.postresql/postgresql
image from dockerhub becomesgiantswarm/postgresql
. This was necessary when we were replicating images from docker hub to our own docker hub account, as all of the docker hub is available as a single domain. Unfortunately, this creates a problem, as by looking at images in a registry, it is impossible to tell if a specific image is really custom and build by Giant Swarm, or a verbatim copy from upstream.retagger
is building images. This is a problem on a complexity level (a lot has to be setup and working forretagger
to do that), and also on a logical level (retagger is supposed to synchronize images, not build them). It is also super important to note, that right now this "customized images" support is the only real difference betweenretagger
and just plain upstreamskopeo
. If we stop doing this, we don't need retagger at all. Also, this build process makes it harder to prepare images for security extensions we have in mind (singing and clear ownership).Desired state
retagger
and replace it with vanilla upstreamskopeo
.postresql/postgresql
image from docker hub synchronized togsoci.azurecr.io
becomesgsoci.azurecr.io/postgresql/postgresql
and notgsoci.azurecr.io/giantswarm/postgresql
.Migration plan
skopeo sync
runsskopeo copy
runs - necessary renamesskopeo
for themcustomized-images.yaml
into a new repo with everything already (mostly) set up for building the image (should this be a single repo for all the images?). Make sure repos have owners and renovate for automated images updates.customized-images.yaml
Tasks