[image-generation] automated baking of worker images
Categories
(Taskcluster :: Workers, enhancement)
Tracking
(Not tracked)
People
(Reporter: miles, Unassigned)
References
(Depends on 2 open bugs, Blocks 1 open bug)
Details
Attachments
(3 files)
This bug covers automating the generation of production taskcluster worker images.
At a high level, we will need:
- Workers in AWS and GCP with cloud permissions to spin up other instances, snapshot, etc.
- Due to security concerns, these instances should probably live in an independent AWS account from taskcluster-prod, and a separate GCP project
- Support retrying image generation failures
This probably looks like a main task that farms out individual builder tasks to generate images, so that each can be retried individually.
Comment 1•5 years ago
|
||
Reporter | ||
Comment 2•5 years ago
|
||
We have a worker-pool created for this, but a few more steps to take:
- we need AWS and GCP credentials for baking images that workers in the worker-pool can access (stored as tc secrets)
- it would probably be easiest to use the taskcluster-staging AWS account for this as it doesn't require creating a new account
- see bug 1580571
- it would probably be easiest to use the taskcluster-staging AWS account for this as it doesn't require creating a new account
- implement the task that builds images, or a decision style task that triggers image building subtasks
- more, probably
Comment 3•5 years ago
|
||
Comment 4•5 years ago
|
||
Reporter | ||
Comment 5•5 years ago
|
||
We have a preliminary pass of this baking GCP images in taskcluster here: https://github.com/taskcluster/monopacker/pull/22.
Reporter | ||
Comment 6•5 years ago
|
||
Here is an example task triggered by a commit to the master branch of monopacker:
The task has an artifact generated by Packer that details the output image IDs. For now, do not have production secrets in place - that is the next and hopefully last step towards real production images being generated automatically in CI.
Reporter | ||
Comment 7•5 years ago
•
|
||
We've run into a blocker for automating this process in taskcluster: storing the CoT key in taskcluster secrets violates the independent second factor intent of chain of trust.
Per aki: "The CoT key is supposed to be a second factor, separate from Taskcluster scopes. If it's deployable with Taskcluster scopes, it's no longer an independent second factor."
There are changes to the chain of trust implementation in the works that would make automating this in the taskcluster platform more feasible in the future.
For now, any kind of automation can be used to trigger monopacker - as long as there is a secure place to store secrets and run jobs that is independent of taskcluster, that should be sufficient.
Description
•