Service Dependencies
Understand Service dependencies, their effects, and configuration.
Lifecycle has different controls for selecting Services and ordering their deployment:
environment.defaultServicesandenvironment.optionalServicesselect the Environment’s starting catalog.services[].requiresincludes a service dependency.services[].deploymentDependsOnorders deployment of Services in the Environment.
environment.{defaultServices,optionalServices}
These lists select the Services offered by the current repository’s Environment:
- Lifecycle selects
defaultServicesinitially. - Users can select
optionalServices.
They do not rewrite the default or optional lists in a different repository, and they do not change an existing static Environment.
services.requires
If a selected Service must include a different Service from the same
lifecycle.yaml, use requires. For example, an API can include its database:
Selecting api includes database when a different repository references
api as a default or optional Service.
requires resolves only one level. If api has a direct requires entry for
database, and database has one for storage, selecting api does not
include storage automatically.
For a deeper dependency, add a direct requirement to the selected Service. You can also list the dependency explicitly in the consuming Environment.
services[].deploymentDependsOn
When one selected Service must finish before a different Service starts, use
deploymentDependsOn. Its values are Service names:
Lifecycle deploys services at the same dependency level in parallel, then moves
to the next level. A dependency cycle marks the affected deploys as
deploy_failed with a cycle error.
requires does not guarantee deployment order. If the API needs the database
included and must wait for it, use requires and deploymentDependsOn. Each
name must match a selected Service.
Reference a Service from a different repository
A consuming repository can select a Service defined elsewhere:
Lifecycle reads api and its direct requires entries from that repository.
The consuming repository does not have to duplicate those direct dependencies.
It must list each dependency that requires does not resolve.
Check the graph
After changing dependencies:
- Validate
lifecycle.yaml. - Examine the selected Service set in Mission Control.
- Check that the selected Service set contains all direct requirements.
- Check that deployment starts in the order declared by
deploymentDependsOn.
If a Service is missing, check for a direct requirement. Then, check for an
unsupported transitive dependency. If deployment starts before its dependency,
add deploymentDependsOn. Do not add a requires entry only for ordering.