Multi-tenant deployments
The default deployment process will create an instance of the component as an unnamed global tenant, but you can deploy a separate instance by providing a tenanat name. Having multiple instances of a component deployed in this manner is called a “multi-tenant deployment”.
architect deploy react-app@app1
This process works for updating existing deployments as well. If an “app1”
tenant of the examples/react-app
component had already been deployed, the
above command would have deployed to that same tenant, leaving any other
instances of the component untouched.
Deployments and management lifecycle
When you view your deployed components, you’ll see that the react-app has the name “app1” whereas the typical deployment without a tenant name will show only the component. In this example we’ve deployed the example React App twice with the tenant names “app1” and “app2”, and once without a tenant name.
Secrets and values
Configuring individual tenants works the same way as deploying those tenants: by providing the tenant name. Secrets use the component scopes to specify which values will be applied to which components, so setting a secret for a tenant is as simple as providing the tenant name in the component scope.
In the case of the example React App, the following will override the
world_text
secret for just the sandiego
tenant.
"react-app@sandiego":
world_text: San Diego
This enables minimal duplication of configuration, as you can specify any
necessary values in a generic component scope, but then override specific values
on a tenant-by-tenant basis. In the following example, the planetearth
tenant
would have the foo
secret as configured in the first scope, but would have the
overwritten values for world_text
set in the second scope.
"react-app":
foo: bar
world_text: world!
"react-app@planetearth":
world_text: Planet Earth
Automating deployments
Want to make it as easy as possible for your team to create tenants? Try creating a tenant file in your repository that gets read in by your CI jobs to automate deployments.
[
{
"name": "cool-customer",
"description": "The coolest of customers",
"owner": "thor@architect.io"
},
{
"name": "rad-customer",
"description": "The raddest of customers",
"owner": "ironman@architect.io"
}
]
Setting up the workflow
With a file like that in the root of your repository, you can iterate over the list of tenants directly in your CI workflow.