Combining multiple orchestrators
This topic describes how to specify multiple orchestrators for each deployment to achieve complex use cases.
Guidelines when using multiple orchestrators:
-
Order matters: The order in which multiple orchestrators are specified will affect the final execution plan. The first orchestrator in the list will be applied first.
-
Recursion: Orchestrators create execution plans represented as trees. For example: the
parallel-by-composite-packageorchestrator creates a parallel block with interleaved blocks for each member of the composite package. The subsequent orchestrator uses the execution plan of the preceding orchestrator and scans it for interleaved blocks. When it finds one, it will apply its rules independently of each interleaved block. As a consequence, the execution tree becomes deeper. -
Two are enough: Specifying a maximum of two orchestrators should cover majority of use cases.
Example with multiple orchestrators
In this example, a composite package must be deployed to an environment that consists of many multiple containers. Each member of the package must only be deployed when the previous member has been deployed. To decrease the deployment time, each member must be deployed in parallel to the containers.
The solution is to use two orchestrators: sequential-by-composite-package and parallel-by-container.
This is a step by step representation of how the orchestrators are applied and how the execution plan changes.
Deploying a composite package to an environment with multiple containers require steps as these:
When the sequential-by-composite-package orchestrator is applied to that list the execution plan changes:
In the final stage of orchestration, the parallel-by-container orchestrator is applied to all interleaved blocks separately. This is the final result:
