Publish OCI images for teleport plugins

[wadells]

Summary

This is a sub-issue of making our teleport plugins more user friendly (#160). This ticket tracks the following dev tasks:

• develop OCI images for all teleport plugins
• make sure these images are validated via CI
• automatically publishing images to a staging location during tag build and master push builds
  • we may need to ensure unique build ids for all commits -- to accommodate pushing untagged commits without overwrite
• copy images from the staging location to the customer facing distribution during promotion
• write dev facing documentation about the images/publishing in this repo
• write customer facing documentation about using images in the teleport docs
• backport all the above to the appropriate branches (probably v9, but worth double checking v8 and prior can be excluded)

[logand22]

For the CI portion of this. I noticed both drone and cloudbuild being used in this repository. Should I lean towards one or the other?

Make sure these images are validated via CI

Can you clarify what you mean by this?

[wadells]

For the CI portion of this. I noticed both drone and cloudbuild being used in this repository. Should I lean towards one or the other?

Use cloudbuild for CI. I think we still prefer Drone for publishing, as the point of this project isn't to refactor the publishing/promotion pipleline.

Make sure these images are validated via CI

Can you clarify what you mean by this?

Ideally, we'd build the docker images before merge, such that if there was a syntax error in the dockerfiles, we'd catch it.

My general thought is:

• PR -> build image, do not publish anywhere, throw it away after completion
• Merge to master / branch/* or push a tag -> build an image and push to an internal private repo
• Promote a build -> copy the bits from the internal private repo to a customer facing repo

My concern here would be: Can we safely build an image at the CI stage. DinD hasn't been sufficient isolation previously, and I'm not sure what options GCB offers for building images at the CI phase. Build after approval (for external contributors) is fine.

[tcsc]

Use cloudbuild for CI. I think we still prefer Drone for publishing

Yeah. The eventual goal is GCB for everything, but we're a long, long way from there.

Can we safely build an image at the CI stage

GCB can definitely build/push images to a docker repo, so the question becomes can we do it safely. Reasonably sure that it's done by mounting the docker socket into the build container (i.e. Docker-out-of-Docker), with whatever implications that has (and I don't know enough about that to comment on off the top of my head).

[logand22]

Cloud Build executes your build as a series of build steps, where each build step is run in a Docker container. Executing build steps is analogous to executing commands in a script.¹

The question I'd like to attempt to answer is: Is each build isolated from other builds?

For instance, is the lint and unit-tests-linux builds run in separate environments but the steps in each build are isolated only by containers?

The machineType option discusses setting the type of virtual machine your build is run on. This to me seems to indicate a virtual machine is used.

[logand22]

An update:

Merging via tag and promoting to quay have been merged. See #456 and #466

#460 tracks the issue of building and pushing docker images on push to master. This would allow developers to test their changes without having to create a tag.

I'm independently verified the pipeline but am waiting for #469 (Release 9.0.2) to be merged in order to verify if it "just works" for other people.

I will start work on documenting these changes now.

[logand22]

Docs Update:

Merged: #473 which contained updates for README files in the different plugin directories

Descriptions in Quay now available for following repositories:

• https://quay.io/repository/gravitational/access-plugin-email
• https://quay.io/repository/gravitational/access-plugin-mattermost
• https://quay.io/repository/gravitational/access-plugin-pagerduty
• https://quay.io/repository/gravitational/access-plugin-slack
• https://quay.io/repository/gravitational/access-plugin-jira
• https://quay.io/repository/gravitational/event-handler-plugin

Next Steps:
Update documentation within guides on goteleport.com

[logand22]

With:

• Update teleport-plugin guides to reference docker images for downloads teleport#11617
• [branch/v9] Update teleport-plugin guides to reference docker images for downloads teleport#11934

Documentation + backports for the above repos is added to goteleport.com in their corresponding guide sections.