Combining multiple orchestrators

You can 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-package orchestrator 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:

Steps needed for composite package

When the sequential-by-composite-package orchestrator is applied to that list the execution plan changes:

Sequential by composite package

In the final stage of orchestration, the parallel-by-container orchestrator is applied to all interleaved blocks separately. This is the final result:

Parallel by composite package