Choose where your service runs
For feature teams. This page explains targets and deployments. A target says where a service runs. A deployment says which artifact runs on which target.
Targets
A target is a place where your service runs, for example a Cloud Foundry space or a Kubernetes namespace.
| Field | Required | Format | Meaning |
|---|---|---|---|
id | Yes | An id, unique in targets of this environment | The name that a deployment uses. |
type | Yes | A type of your platform | The kind of place. |
spec | Yes | A map | The settings of the place. The type decides which settings it needs. |
Deployments
A deployment puts one artifact on one target.
| Field | Required | Format | Meaning |
|---|---|---|---|
id | Yes | An id, unique in deployments of this environment | The name of the deployment. |
type | Yes | A type of your platform | The way the artifact runs. |
artifact | Yes | The id of an entry in artifacts | The artifact to run. |
target | Yes | The id of an entry in targets of the same environment | The place to run it. |
spec | Yes | A map | The settings of the deployment. |
The field artifact looks in the artifacts list of the whole file, because artifacts is not part of an environment. The field target looks only in the same environment. A deployment cannot name a target of another environment.
A deployment that names a target that does not exist is refused:
error: the control plane found 1 problem in joomiz.yaml (checked by https://joomiz.example.com/validate)
environments:
test:
partner-api-test-deployment (cloud-foundry-app): partner-api-jar -> test-foundry
target: no target with id 'test-foundry' is declared in this environment
Which artifacts and targets fit together
A deployment type accepts one type of artifact and one type of target. joomiz validate checks this.
| Deployment type | Artifact type | Target type |
|---|---|---|
cloud-foundry-app | jar | cloud-foundry-space |
kubernetes-deployment | container-image | kubernetes-namespace |
kong-api | kong-oas | kong-gateway |
Your platform can offer other pairings. The schema of your platform lists them. Which types can you use shows how to read it.
A wrong pairing is refused. In this example, a cloud-foundry-app deployment names an OpenAPI artifact:
error: the control plane found 1 problem in joomiz.yaml (checked by https://joomiz.example.com/validate)
environments:
test:
partner-api-test-deployment (cloud-foundry-app): partner-api-oas -> test-foundation
artifact: 'partner-api-oas' is of type 'kong-oas', which a deployment of type 'cloud-foundry-app' may not use
Cloud Foundry
A cloud-foundry-space target needs the address of the foundation, the organization and the space. A cloud-foundry-app deployment needs the number of instances, the memory and disk for each instance, and the buildpack. It can also have an env map of environment variables. The complete file is the example quick-start.
targets:
- id: test-foundation
type: cloud-foundry-space
spec:
api-endpoint: https://api.cf.test.internal
org: example-org
space: quick-start-shop-test
# What runs there: the jar, on that target.
deployments:
- id: shop-test-deployment
type: cloud-foundry-app
artifact: shop-jar
target: test-foundation
spec:
instances: 1
memory: 1G
disk-quota: 1G
buildpack: java_buildpack
| Setting | Format | Meaning |
|---|---|---|
instances | A whole number from 0 to 1000 | How many instances run. |
memory | Text, for example 512M or 2G | Memory for each instance. |
disk-quota | Text, for example 1G | Disk for each instance. |
buildpack | Text, for example java_buildpack | The buildpack that stages the archive. |
env | A map of text values | Environment variables of the application. A value can be a reference. |
If a required setting is missing, validate names it:
error: the control plane found 1 problem in joomiz.yaml (checked by https://joomiz.example.com/validate)
environments:
test:
partner-api-test-deployment (cloud-foundry-app): partner-api-jar -> test-foundation
spec: required property 'buildpack' not found
Kubernetes
A kubernetes-namespace target needs the name of the cluster and the namespace. A kubernetes-deployment needs the number of replicas, and the CPU and memory requests. The complete file is the example container-service.
targets:
- id: test-cluster
type: kubernetes-namespace
spec:
cluster: eu-west-1-test
namespace: container-shop-test
deployments:
- id: shop-test-deployment
type: kubernetes-deployment
artifact: shop-image
target: test-cluster
spec:
replicas: 1
cpu: 250m
memory: 512Mi
| Setting | Format | Meaning |
|---|---|---|
replicas | A whole number from 0 to 1000 | How many pods run. |
cpu | Text, a Kubernetes quantity such as 250m or 1 | The CPU request. |
memory | Text, a Kubernetes quantity such as 512Mi | The memory request. |
Kong
A kong-gateway target names a Kong control plane. A kong-api deployment publishes the API that a kong-oas artifact describes. It also lists the consumers that may call the API.
- id: test-gateway
type: kong-gateway
spec:
control-plane-name: partner-apis-test
# The API itself, published on the gateway from the OpenAPI document.
- id: partner-api-test-gateway-api
type: kong-api
artifact: partner-api-oas
target: test-gateway
spec:
consumers:
- id: partner-portal
name: Partner Portal
roles:
- read
- write
- id: warehouse-scanner
name: Warehouse Scanner App
roles:
- read
| Setting | Format | Meaning |
|---|---|---|
consumers | A list | The consumers that may call the API. One deployment can list up to 100. |
consumers[].id | Text | The id of the consumer. |
consumers[].name | Text | The name that people read. |
consumers[].roles | A list of text values, optional | The roles of the consumer on the API. |
The complete file is the example partner-api. joomiz validate accepts it:
joomiz.yaml is valid (checked by https://joomiz.example.com/validate)
application: no problems
tooling: no problems
environments: no problems in 1 environment (2 targets, 2 deployments, 0 managed-resources, 0 consumed-resources)
Next
Add a database or declare a topic that another team owns in Request and use resources.