You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Orkestra is a cloud-native **Release Orchestration** and **Lifecycle Management (LCM)** platform for a related group of [Helm](https://helm.sh/) releases and their subcharts.
10
+
Orkestra is a cloud-native **Release Orchestration** and **Lifecycle Management (LCM)** platform for a related group of [Helm](https://helm.sh/) releases and their subcharts
11
11
12
12
Orkestra is built on top of popular [CNCF](https://cncf.io/) tools and technologies like,
13
13
@@ -17,7 +17,47 @@ Orkestra is built on top of popular [CNCF](https://cncf.io/) tools and technolog
-[Reporting security issues and security bugs](#reporting-security-issues-and-security-bugs)
47
+
48
+
## Overview
49
+
50
+
Orkestra is one solution to introduce Helm release orchestration. Orkestra provides this by building on top of **Argo Workflows**, a workflow engine on top of Kubernetes for workflow orchestration, where each step in a workflow is executed by a Pod. As such, Argo Workflow engine is a more powerful, more flexible adaptation of what **Init Containers** and **Kubernetes Jobs** provide without the orchestration.
51
+
52
+
Argo enables a DAG based dependency graph with defined workflow steps and conditions to transition through the graph, as well as detailed insight into the graph and its state. Helm releases matching transitions in the graph are executed by the FluxCD Helm controller operator. The FluxCD Helm controller operator is a Kubernetes operator that is responsible for executing Helm releases in a consistent manner.
53
+
54
+
### How it works
55
+
56
+
The unit of deployment for Orkestra based Helm releases is based on a workflow definition with a custom resource type that models the relationship between individual Helm releases making up the whole. The workflow definition is a **DAG** with defined workflow steps and conditions.
57
+
58
+
The `ApplicationGroup` spec allows to structure an orchestrated set of releases through grouping Helm releases into an group, either through defining a sequence on non-related charts and/or charts with subcharts, where subcharts are not merged into a single release but are executed as a release of their own inside a workflow step. The `ApplicationGroup` spec also allows to define a set of conditions that are evaluated at the beginning of the workflow and if any of the conditions fail, the whole workflow is aborted.
59
+
60
+
This gives you the ability to define a set of Helm releases that are orchestrated in a way that is easy to understand and to debug without having to modify the Helm release itself.
21
61
22
62
## Background and Motivation
23
63
@@ -33,21 +73,6 @@ Using **Helm Hooks**, **Kubernetes Jobs** and **Init Containers**, you might end
33
73
34
74
To manage a group of Helm releases with a parent/subchart relationship or using a dependency relation, you need to use a dependency relation at Helm release time and not a dependency relation at Helm package time.
35
75
36
-
## What is Orkestra?
37
-
38
-
Orkestra is one solution to introduce Helm release orchestration. Orkestra provides this by building on top of **Argo Workflows**, a workflow engine on top of Kubernetes for workflow orchestration, where each step in a workflow is executed by a Pod. As such, Argo Workflow engine is a more powerful, more flexible adaptation of what **Init Containers** and **Kubernetes Jobs** provide without the orchestration.
39
-
40
-
Argo enables a DAG based dependency graph with defined workflow steps and conditions to transition through the graph, as well as detailed insight into the graph and its state. Helm releases matching transitions in the graph are executed by the FluxCD Helm controller operator. The FluxCD Helm controller operator is a Kubernetes operator that is responsible for executing Helm releases in a consistent manner.
41
-
42
-
### How it works
43
-
44
-
The unit of deployment for Orkestra based Helm releases is based on a workflow definition with a custom resource type that models the relationship between individual Helm releases making up the whole. The workflow definition is a **DAG** with defined workflow steps and conditions.
45
-
46
-
The `ApplicationGroup` spec allows to structure an orchestrated set of releases through grouping Helm releases into an group, either through defining a sequence on non-related charts and/or charts with subcharts, where subcharts are not merged into a single release but are executed as a release of their own inside a workflow step. The `ApplicationGroup` spec also allows to define a set of conditions that are evaluated at the beginning of the workflow and if any of the conditions fail, the whole workflow is aborted.
47
-
48
-
This gives you the ability to define a set of Helm releases that are orchestrated in a way that is easy to understand and to debug without having to modify the Helm release itself.
49
-
50
-
51
76
## Features 🌟
52
77
53
78
-**Layers** - Deploy and manage 'layers' on top of Kubernetes. Each layer is a collection of addons and can have dependencies established between the layers.
@@ -67,28 +92,28 @@ This gives you the ability to define a set of Helm releases that are orchestrate
67
92
apiVersion: orkestra.azure.microsoft.com/v1alpha1
68
93
kind: ApplicationGroup
69
94
metadata:
70
-
name: bookinfo
95
+
name: bookinfo
71
96
spec:
72
97
applications:
73
98
- name: ambassador
74
99
dependencies: []
75
100
spec:
76
101
chart:
77
102
url: "https://nitishm.github.io/charts"
78
-
name: ambassador
103
+
name: ambassador
79
104
version: 6.6.0
80
105
release:
81
106
timeout: 10m
82
-
targetNamespace: ambassador
107
+
targetNamespace: ambassador
83
108
values:
84
109
service:
85
110
type: ClusterIP
86
-
- name: bookinfo
111
+
- name: bookinfo
87
112
dependencies: [ambassador]
88
113
spec:
89
114
chart:
90
115
url: "https://nitishm.github.io/charts"
91
-
name: bookinfo
116
+
name: bookinfo
92
117
version: v1
93
118
subcharts:
94
119
- name: productpage
@@ -100,7 +125,7 @@ spec:
100
125
- name: details
101
126
dependencies: []
102
127
release:
103
-
targetNamespace: bookinfo
128
+
targetNamespace: bookinfo
104
129
values:
105
130
productpage:
106
131
replicaCount: 1
@@ -127,12 +152,28 @@ The default executor is responsible for deploying the HelmRelease object passed
127
152
128
153
Source code for the HelmRelease executor is available [here](https://github.com/Azure/helmrelease-workflow-executor)
129
154
130
-
### Keptn Executor (Work in progress)
155
+
### Keptn Executor
131
156
132
157
The Keptn executor is an evaluation executor responsible for running tests on the deployed helm release using the Keptn API and Keptn evaluations engine. The Keptn executor is a custom executor that is chained to the default HelmRelease executor. This allows each release to be evaluated against a set of SLOs/SLIs before it is deployed/updated.
133
158
134
159
Source code for the Keptn executor is available [here](https://github.com/Azure/keptn-workflow-executor)
0 commit comments