Closed Bug 1156319 Opened 8 years ago Closed 4 years ago
Define deployment orchestration of taskcluster stack
Using either docker orchestration tools, aws cloud formation, or some similar technology, define an orchestrated deployment of as much of the task cluster stack as possible, to simplify and standardise taskcluster setup. The measurable outcomes of this bug would be: * Is it trivial to deploy a task cluster stack locally for development? * Is it easy to spin up a new task cluster environment in the cloud? Pulse/AMQP setup is likely to be non trivial, and might not be an initial deliverable. However, a simple deployment of Queue, Scheduler (so long as it exists), Provisioner, Docs, Status, Tools, the reference schemas and manifests, would be a useful start.
Q2 has now come and gone, so no need to track this as a Q2 stretch goal any more.
No longer blocks: tc-2015-q2
Summary: meta: [pmoore-Q2/2015-goal] [garndt-Q2/2015-goal] [stretch goal] Define deployment orchestration of taskcluster stack - *STRETCH* goal → Define deployment orchestration of taskcluster stack - *STRETCH* goal
Summary: Define deployment orchestration of taskcluster stack - *STRETCH* goal → Define deployment orchestration of taskcluster stack
Component: TaskCluster → General
Product: Testing → Taskcluster
The plan is to start attacking this in 2018 Q1. \o/
At the AllHands we talked about this being split into multiple stages illustrated as follows: > [source] -> build -> [binaries] -> deploy -> [cluster] > ^ ^ ^--------- (runtime configuration/data lives here) > (build configuration) (deployment configuration) , where: build configuration: * services to enable / disable * docker images hashes pinning images to be pulled * pinning of AMIs * default configuration values for some deployment config options * ... deployment configuration: * aws root credentials * ec2 regions to use (things like that) * domain name * built-in runtime configuration, such as: roles, clients, secrets, workerTypes, (built-in runtime configuration cannot be modified at runtime) runtime configuration: (these are things that can be changed at runtime) * roles, clients, workerTypes, hooks, etc. runtime data: (ideally, this is immutable) * tasks, artifacts, index entries [source]: (the input when building) * A github repository referencing all our repositories * Scripts for building docker images, AMIs using our repositories * Scripts for building a Helm recipe for deployment on kubernetes * Scripts for building a terraform module for deploying taskcluster using kubernetes [binaries]: (the output from building, input for deployment) * docker images, AMIs, and other machine images * Helm recipe for deployment on kubernetes * terraform module for deployment an entire cluster [cluster]: (the result of deployment) * A collection of taskcluster services and workers Notice: terraform is needed for cross-cloud provisioning, setup of not just core taskcluster services, but also: * built-in worker-types, * cross-region replication of object storage, * webhooktunnel (maybe), * other snowflakes that don't fit in k8s The Helm recipe will probably give a set of taskcluster core services, without advanced things like EC2 spot workers, etc. But this will be sufficient for local development of the services.
Component: General → Redeployability
Depends on: 1428417
Brian, is this something you're working on?
https://github.com/taskcluster/taskcluster-terraform && https://github.com/taskcluster/taskcluster-mozilla-terraform Both exist and "work" still need to make them work better, but this no longer blocks things.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.