Drone publishing for Amazon ECR

[logand22]

The goal of this PR is to update the existing drone pipelines and workflows to publish docker images to both quay.io and Amazon ECR.

This is a part of RFD 73 and https://github.com/gravitational/cloud/issues/1839.

Care was taken to minimize any and all changes to pre-existing workflows.

This PR depends on:

• https://github.com/gravitational/cloud-terraform/pull/712.
• https://github.com/gravitational/teleport.e/pull/489

What Changes

There are currently 3 ways the teleport or teleport-ent image are published to quay.io:

• git tag
• Drone promotion
• Drone cronjob

Tagging

Images were originally published to quay.io/gravitational/teleport-ci. This was to distinguish between staged images and production-ready images. Due to the new architecture in RFD 73. teleport-ci will no longer be required. Images will now be pushed to the internal aws ECR repository.

Promotion

Images will be promoted from the internal staging repository to both quay and amazon ECR Public.

Promoting in drone

You can now specifically promote the docker image pipelines by promoting to promote-docker or promote-docker-ecr or promote-docker-quay. This will run just those pipelines respectively vs promoted the entire pipeline.

Cronjob

Images will be built and pushed to both quay.io and amazon ECR Public.

Testing

• Cronjob - Successful drone run shown here: https://drone.platform.teleport.sh/gravitational/teleport/13738/1/6
• Tagging - Successful drone run with tagged images shown here: https://drone.platform.teleport.sh/gravitational/teleport/13800/22/1
• Promoting - Successful drone run with promoted images shown here: https://drone.platform.teleport.sh/gravitational/teleport/13801 for ecr and https://drone.platform.teleport.sh/gravitational/teleport/13802/1/4 for quay.

[logand22]

CC: @tcsc @fheinecke @marcoandredinis What other areas should I look out for regarding potentially decommissioning the staging repository: quay.io/gravitational/teleport-ci?

[wadells]

What other areas should I look out for regarding potentially decommissioning the staging repository: quay.io/gravitational/teleport-ci?

GitHub code search is sufficient for tracking down the use cases: https://github.com/search?q=org%3Agravitational+teleport-ci&type=code

If you want to be extra diligent, check through the issues as well, and make sure that there aren't any that are made irrelevant or misleading after this change.

[marcoandredinis]

What other areas should I look out for regarding potentially decommissioning the staging repository: quay.io/gravitational/teleport-ci?

I didn't find any other references to it

With this change we'll have staging images only in ECR and production images in both ECR and Quay. Is that so?
I would rather see both repos with both images first

I'm a bit out of place here 😅 take my suggestions with a grain of salt

I'm curious of what this means to the Teleport Operator image (cc @hugoShaka )
Our current developments (the PR is yet to be merged) create a quay.io/gravitational/teleport-operator-ci and quay.io/gravitational/teleport-operator for staging and production images
Per the RFD - the image is marked as Repositories to migrate, but not mirror, we would publish the image only to ECR (staging -> internal and production -> public)
Can you please confirm?

[logand22]

With this change we'll have staging images only in ECR and production images in both ECR and Quay. Is that so?
I would rather see both repos with both images first

This can still happen if desired. I was originally thinking that since teleport-ci is internal only, and seemingly not used by many people it would be easier to go ahead and "get rid of". The risk being anyone who does use the internal image for any type of testing pre-release of official images would have to pull them from this registry instead.

Keeping teleport-ci would minimize any workflow interruptions but would prolong the deprecation of Quay.io.

@marcoandredinis What do you think?

[marcoandredinis]

Keeping teleport-ci would minimize any workflow interruptions but would prolong the deprecation of Quay.io.

@marcoandredinis What do you think?

I'm ok with removing it 👍
I don't know who uses the teleport-ci, but I assume it's always internal/development so even if someone gets caught by surprise, it should be low impact

[webvictim]

AFAIK nobody directly uses teleport-ci, it's just the staging ground so that we don't make images public until the promotion step runs.

[fheinecke]

Just FYI this will have some merge conflicts with my open PR (#14203) which is about ready to merge

[fheinecke]

LGTM