Dependencies¶
Dependencies allows you to specify DAG and how different service components are dependent on each other. The dependency structure is inturn used to determine the order across service components during several operations like provisioning, patching, scaling etc. As an example, if service component Child (say Zookeeper) depends on service component Parent (say Kafka), then Omnistrate will make sure to provision Zookeeper first before Kafka is deployed to make sure Zookeeper is available when Kafka tries to come up.
Note
- Dependencies are different from resource linking. To learn more about linking service components, please see this page. For comparison between the two, see this
- Note that some of the resources (service components) can be internal in your DAG. To learn more about internal vs external resources, please see this page
- Note that some of the resources can be passive resources in your DAG. To learn more about passive vs active resources, please see this page
Configuring dependencies¶
You can define dependencies using depends_on
tag in your compose specification. Here is a more concrete example:
PGAdmin:
image: omnistrate/pgadmin4:7.5
x-omnistrate-mode-internal: true
Writer:
image: 'bitnami/postgresql:latest'
x-omnistrate-mode-internal: true
Reader:
image: 'bitnami/postgresql:latest'
x-omnistrate-mode-internal: true
Cluster:
image: omnistrate/noop
depends_on:
- Writer
- Reader
- PGAdmin
Alternatively, you can configure it using our API/CTL/UI. In the above example, Cluster resource depends on 3 resources: Writer, Reader and PGAdmin. The relationship between them will look like the following:
Note
Note that Writer, Reader and PGAdmin are all internal resources and so Omnistrate will NOT generate API/CLI/UI for your customers to directly provision or perform other management operations. Instead the lifecycle of these resources will be managed through Cluster parent resource, which is external.
Note
Also, note that Cluster is a passive resource and so creating an instance of just Cluster resource will NOT provision any infrastructure. However, Cluster resource depends on the other 3 resources and, so when create is invoked on the Cluster resource, it will create an instance of other 3 resources which are active resources with their associated infrastructure.
Configuring dependency parameters¶
As part of defining dependencies, you may also want to map dependency parameters. It allows you to map API parameters to configure dependent components to the parent component through dependency mapping. As an example:
Cluster:
image: omnistrate/noop
x-omnistrate-api-params:
- key: instanceType
description: Instance Type
name: Instance Type
type: String
modifiable: true
required: true
export: true
defaultValue: t4g.small
parameterDependencyMap:
Writer: writerInstanceType
Reader: readerInstanceType
PGAdmin: instanceType
In the above example, the instanceType
param of Cluster resource is mapped to writerInstanceType
of Writer resource, readerInstanceType
of Reader resource, and instanceType
of PGAdmin resource.
Note
In case, you have two service components, A and B, which rely on a third service component, C. If they both define the parameterDependencyMap to service component C, then depending on whether the user is creating an instance of A or of B, C will use the corresponding value.
References¶
For a hello world example, please see this
For video walkthrough, see this