- Aggregated Blueprint
- Blueprint
- Cluster
- Components and Component Descriptors
- Context
- DataObject
- Deployer
- DeployExecution
- DeployItem
- Execution
- Export
- ExportExecution
- Import
- Installation
- SubinstallationExecution
- Target
- Template
Aggregated Blueprints are Blueprints that bundle the execution of multiple other blueprints. They contain an orchestration pattern for nested Installations.
Their practical use is to install multiple components that depend on each other.
Blueprints are entities, which contain the instructions and steps about how to deploy a software component in the form of DeployItems. As these instructions are expected to be idempotent, Blueprints can be defined as descriptions of the target state for the software component. These Blueprints define an interface for import data, as required by its DeployItems. It can also define an export interface to expose output data of its DeployItems.
In other words, Blueprints are reusable collections of installation tasks, which could be parameterized through import parameters. Several DeployItems can be defined in a Blueprint at once. Also, the execution order of these DeployItems in a Blueprint can be specified.
Blueprints in a nutshell:
- Configuration Data (Imports)
- Installation instructions
There are 3 different cluster types mentioned throughout the documentation: Landscaper Host Cluster, Landscaper Resource Cluster, Target Cluster
The Landscaper Host Cluster, is the cluster on which the Landscaper runs.
The Landscaper Resource Cluster, is the cluster on which custom resources like Targets and Installations can be created, that are watched by the Landscaper.
A target cluster is a cluster on which the Landscaper deploys applications. One Landscaper can deploy applications to different target clusters.
A component descriptor describes a component, or rather, a specific component version. In general, a component version is a container for all required resources for the deployment of a specific version of an application or software system. A component version may either contain a resource through referencing it at an external location (e.g. an OCI registry) or through embedding it as a local blob (e.g. as an additional layer of the component version's OCI artifact).
For more details on ocm components in general, see here. For more details on the usage of ocm components in the context of the landscaper, check out the blueprint and components section of the guided tour here.
The Landscaper defines 2 different kind of contexts.
One context is an actual resource that is referenced by an Installation and defines common configuration.
The other context is a logical object that defines the scope in which an Installation runs and all of its data lives. For every Installation a dedicated logical context is created and data can only be accessed within the same context. Data can be exchanged between contexts via Import and Export declarations.
Since Installations can be nested, the resulting contexts are nested as well.
DataObjects are vehicles to store arbitrary kinds of data. They exist in a Context and provide data to Imports / receive data from Exports. They can be considered to be the implementation of the data flow in an installation.
Deployer are highly specialized controllers that act on DeployItems of a certain type. They execute the installation instructions and aim to maintain the declared desired state.
A DeployExecution is a dedicated instantiation of a template to generate deploy items as part of a Blueprint. Mainly used to describe the installation instructions and customize it using the data provided as imports.
It is used in list of such execution under the field deployExecutions in a blueprint descriptor.
The main objective of Landscaper is to set up large cloud environments with complex relationships consisting of many small installation tasks like Helm deployments, network setup etc. These elementary installation tasks are defined by DeployItems. There are different types of DeployItems for example for deploying Helm charts, plain kubernetes manifests or terraform configurations.
A DeployItem can be described as the interface between the Landscaper controller and the Deployers. It contains input data and a set of Deployer-specific instructions on how to install a component (e.g. install a helm chart with some custom values). Additionally, it is used to record the status as returned by the Deployer.
These DeployItems can be configured such that they can be used in different scenarios. Typical examples of configurable parts of a DeployItem are the target cluster or namespace where a helm chart should be deployed to. A DeployItem can also define output parameters for data it creates and which can be consumed by others.
An Execution describes the instantiation of a template in a Blueprint. There are several purposes for those templates:
- DeployExecutions are used to render _DeployItems
- ExportExecutions are used to render exports of a Blueprint.
- SubinstallationExecutions are used to render nested Installations
Export has 2 ambiguous meanings, whether we are talking about Blueprints or Installations.
Exports declare the output expected from a processed Blueprint.
Exports of an Installation pick up actual values and make them accessible for a user, parent or sibling Installation.
Background Knowledge:
An ExportExecution is the instantiation of a template to generate exports as part of a Blueprint.
These templates contain the instructions which data gets written into the exports and how it might be preprocessed.
They are specified as lists of executions under the field exportExecutions in a blueprint descriptor.
Import has 2 ambiguous meanings, whether we are talking about Blueprints or Installations.
Imports declare what data will be required to process the Blueprint. Part of the declaration is also the format, which can either be of type Target or any valid jsonschema.
Imports in an Installation assign actual values and make them accessible for further processing. They satisfy the requirements (imports) defined in the Blueprint.
An installation is the parameterized instance of a Blueprint deployed by a user. Landscaper acts upon creation or update and creates or updates dependent Execution and Sub-Installations.
Sibling Installations refer to Installations belonging to the same parent.
Sub-installations are Installations that are automatically created by the landscaper as part of a running installation (the installation references a Aggregated Blueprint).
Background Knowledge:
A SubinstallationExecution is the instantiation of a template to generate nested installations as part of a Blueprint.
These templates contain installation descriptions and their wiring, that is instantiated in an own context whenever a blueprint is instantiated.
It is used in list of such execution under the field exportExecutions in a blueprint descriptor.
A Target defines the system in which Landscaper will run the installation steps. Target resources contain all relevant data to access this environment including credentials.
Templates are used to render other elements for various purposes based on a dedicated value binding provided by a Blueprint. The instantiation context of a template is called Execution. There are DeployExecutions, ExportExecutions and SubinstallationExecutions. The Landscaper supports two kinds of template processors to process those templates: Go templates and Spiff templates.