Define your environments
For feature teams. This page explains the environments key: how to describe a place such as test or prod, and what stays inside it.
An environment is a boundary
An environment is a place where your service runs, for example test or prod. Each environment has its own resources. A resource in one environment is not the same thing as a resource in another environment, even when both have the same id.
The key environments is a map, not a list. Each key is the name of an environment. Each value holds up to four lists.
environments:
test:
# Where the service runs.
targets:
| List | What it holds |
|---|---|
targets | The places where your service runs. |
deployments | Your artifacts on those targets. |
managed-resources | Resources that Joomiz creates and owns for your service. |
consumed-resources | Resources that another team owns and your service uses. |
A list is optional. The quick start file has only targets and deployments. Choose where your service runs and Request and use resources explain the lists.
Name an environment
The name of an environment follows the rule for ids. This name is invalid on purpose:
Test_Env:
You see:
error: the control plane found 1 problem in joomiz.yaml (checked by https://joomiz.example.com/validate)
environments:
Test_Env:
name: environment name must be kebab-case (lower-case letters, digits and single hyphens), but was 'Test_Env'
You use the name in the commands. joomiz plan --environment test plans the environment test. If the file has no environment with that name, the command stops:
error: the control plane found 1 problem in joomiz.yaml (checked by https://joomiz.example.com/plan?environment=prod)
environment: this file declares no environment named 'prod'
Ids inside an environment
An id must be unique in its own list of its own environment. The test and the prod environment can both have a managed resource named billing-service-db:
- id: billing-service-db
type: postgres
spec:
Each environment holds its own database with that id. A reference can name only the resources of the environment in which it is written. Point one value at another explains this.
The example billing-service is a complete file with the environments test and prod.
Limits
A file has at most 25 environments. Each list of an environment has at most 50 entries.
A file with 51 entries in one list is refused. This is the message for consumed-resources:
error: the control plane could not validate joomiz.yaml (HTTP 400)
Invalid application
The submitted joomiz.yaml is not valid.
environments[test].consumedResources: at most 50 consumed resources may be submitted for one environment
Each environment has its own apply lock
Only one apply can be active for an application and an environment. If you start a second apply for the same environment, the control plane refuses it at once. An apply in test does not stop an apply in prod.
A plan never takes the lock. You can plan an environment while an apply runs in it.
Next
Say where an artifact runs in Choose where your service runs.