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
* Update shared-configuration.md* Update ISC with promotion infoUpdated ISC structure with new promotion subfolders and descriptions* Update shared-configuration.md* Update shared-configuration.mdFixed table row and replaced CRDs with manifests, and updated names* Update shared-configuration.mdCommented out link to sample ISC repo* Update shared-configuration.md* Update shared-configuration.md* Update shared-configuration.md* Update shared-configuration.md
Copy file name to clipboardExpand all lines: _docs/installation/gitops/monitor-manage-runtimes.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -102,7 +102,7 @@ Here is a description of the information in the Topology view.
102
102
|**Search and View options**| {::nomarkdown}<ul><li>Find a Runtime or its clusters by typing part of the Runtime/cluster name, and then navigate to the entries found. </li> <li>Topology view options: Resize to window, zoom in, zoom out, full screen view.</li></ul> {:/}|
103
103
104
104
##Designating Configuration Runtimes
105
-
Designate any GitOps Runtime, including the Hosted GitOps Runtime, as a Configuration Runtime to manage platform-level resources which are Runtime-agnostic. These resources are crucial for functionality related to Products in GitOps<!---, and Promotions such as Promotion Policies, Promotion Templates, and Promotion Flows-->.
105
+
Designate any GitOps Runtime, including the Hosted GitOps Runtime, as a Configuration Runtime to manage platform-level resources which are Runtime-agnostic. These resources are crucial for functionality related to Products in GitOps, and Promotions such as Promotion Policies, Promotion Templates, and Promotion Flows.
106
106
107
107
#####Single vs multiple Configuration Runtimes
108
108
You can designate a single Runtime or multiple Runtimes as Configuration Runtimes. You may want to designate more than one Configuration Runtime for redundancy. Codefresh makes sure that there are no duplicate resources among the designated Configuration Runtimes if there are multiple such Runtimes.
Copy file name to clipboardExpand all lines: _docs/installation/gitops/shared-configuration.md
+54-20Lines changed: 54 additions & 20 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,27 @@ While it is useful to understand its structure, we recommend using it for refere
27
27
***Runtime-specific configuration**
28
28
With the Shared Configuration Repository, you can create subdirectories for different GitOps Runtimes, and place configuration manifests that are only applied to specific GitOps Runtimes. You have fine-grained control over the configuration of individual Runtimes without affecting others.
Below is a representation of the structure of the repository with the shared configuration.
93
-
See a[sample repo](https://github.com/codefresh-contrib/example-shared-config-repo){:target="\_blank"}.
105
+
Below is a representation of the structure of the repository with the shared configuration in the GitOps Runtime designated as the Configuration Runtime.
94
106
95
107
```
96
108
97
109
├── resources <───────────────────┐
98
110
│ ├── all-runtimes-all-clusters │
99
111
│ │ ├── cm-all.yaml │
100
112
│ │ └── subfolder │
101
-
│ │ └── manifest2.yaml │
102
-
│ ├── control-planes │
103
113
│ │ └── manifest3.yaml │
114
+
│ │ └── promotion-workflows │ # stores promotion workflow manifests available to all runtimes
115
+
│ │ └── smoke-tests.yaml │
104
116
│ ├── runtimes │
105
117
│ │ ├── runtime1 │
106
118
│ │ │ └── manifest4.yaml │
107
119
│ │ └── runtime2 │
108
120
│ │ └── manifest5.yaml │
109
121
│ └── manifest6.yaml │
122
+
└── app-projects │
123
+
└── configurations │ # syncs to cluster by runtimes designated as Configuration Runtime
124
+
│ ├── products │ # stores product manifests with all product settings except assigned applications
│ └── promotion-policies │ # stores promotion policy manifests for products/environments with promotion workflows & promotion action
130
+
│ │ ├── base-flow.yaml │
131
+
│ │ └── prod-pr.yaml │
132
+
│ │ └── loan-policy.yaml │
133
+
│ └── promotion-templates │ # stores promotion template manifests for products with source info for version & properties to promote
134
+
│ └── demo-template.yaml │
110
135
└── runtimes │
111
136
├── runtime1 │ # referenced by "production-isc" argo-cd application, applied to the cluster by "cap-app-proxy"
112
137
│ ├── in-cluster.yaml ─┤ # manage `include` field determines which dirs/files to sync to cluster
@@ -118,21 +143,29 @@ See a [sample repo](https://github.com/codefresh-contrib/example-shared-config-r
118
143
119
144
###`resources` directory
120
145
121
-
The`resources` directoryholds the resources shared by_all_ clusters managed bytheGitOps Runtimes:
146
+
The`resources` directorycontains the resources shared by_all_ clusters managed by GitOps Runtimes.
122
147
123
-
*`resources/all-runtimes-all-clusters`: Every resource manifest in this subdirectory is applied to all the GitOps Runtimes in the account, and to all the clusters managed by those Runtimes. In the above example,`manifest2.yaml` is applied to both`runtime1` and`runtime2`.
124
-
*`resources/control-planes`: Optional. When defined, every resource manifest in this subdirectory is applied to each Runtime’s`in-cluster`.
125
-
Config map resources for example, when committed to this subdirectory, are deployed to each Runtime’s`in-cluster`.
126
-
*`resources/runtimes/<runtime_name>`: Optional. Runtime-specific subdirectory. Every resource manifest in a runtime-specific subdirectory is applied to only the GitOps Runtime defined by`<runtime_name>`.
127
-
In the above example,`manifest4.yaml` is applied only to`runtime1`, and`manifest5.yaml` is applied only to`runtime2`.
148
+
{: .table .table-bordered .table-hover}
149
+
| Shared Configuration Repo| Description|
150
+
| ----------| --------|
151
+
|`resources/all-runtimes-all-clusters`| Contains resource manifests applied to all the GitOps Runtimes in the account and to all the clusters managed by those Runtimes. In the above example,`manifest2.yaml` is applied to both`runtime1` and`runtime2`.|
152
+
|`resources/all-runtimes-all-clusters/promotion-workflows`| Stores manifests of Promotion Workflows, available to all Runtimes in the account.<br>See[Promotion Workflows]({{site.baseurl}}/docs/configuration/promotion-workflow).|
153
+
|`resources/control-planes`| Optional. When defined, applies every resource manifest to each Runtime’s`in-cluster`. Config map resources for example, when committed to this subdirectory, are deployed to each Runtime’s`in-cluster`.|
154
+
|`resources/app-projects`| Contains application project resources which control deployment destinations for applications.|
155
+
|`resources/configurations`| Contains platform-level resources which are Runtime-agnostic, essential for functionality related to product and promotion entities in GitOps.|
156
+
|`resources/configurations/products`|Contains manifests of product entities. All settings including source location for application version, promotable properties, promotion flows with trigger conditions if defined are saved. Note that applications assigned to products are not saved in the manifest. Product manifests are available to users with the required ABAC permissions. <br>See[Product Settings]({{site.baseurl}}/docs/products/configure-product-settings/) and[Product YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/product-crd/).|
157
+
|`resources/configurations/promotion-flows`| Contains manifests of promotion flows with the trigger and target environments, and custom promotion policy settings, if any.<br>See[Promotion Flow configuration]({{site.baseurl}}/docs/promotions/configuration/promotion-flow/) and[Promotion Flow YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/promotion-flow-crd/).|
158
+
|`resources/configurations/promotion-policies`| Contains manifests of promotion policies with the Pre- and Post-Action Workflows if defined, the Promotion Action, and target products and environments.<br>See[Promotion Policy configuration]({{site.baseurl}}/docs/promotions/configuration/promotion-policy/) and[Promotion Policy YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/product-crd/).|
159
+
|`resources/configurations/promotion-templates`| Contains manifests of promotion templates defining the sources for the release version and the properties to be promoted. <br>See[Promotion Template configuration]({{site.baseurl}}/docs/products/configure-product-settings/#configure-promotion-settings) and[Promotion Template YAML]({{site.baseurl}}/docs/promotions/configuration/yaml/promotion-template-crd/).|
160
+
|`resources/runtimes/<runtime_name>`| Optional. Runtime-specific subdirectory. Every resource manifest in a runtime-specific subdirectory is applied to only the GitOps Runtime defined by`<runtime_name>`. In the above example,`manifest4.yaml` is applied only to`runtime1`, and`manifest5.yaml` is applied only to`runtime2`.|
128
161
129
162
130
163
131
164
###`runtimes` directory
132
165
The`runtimes` directory includes subdirectories specific to each GitOps Runtime installed in the cluster. Every subdirectory always has an`in-cluster.yaml`, and optionally, application manifest YAMLs for other clusters.
133
166
The`runtimes/<runtime1>` subdirectory for example, includes the`in-cluster.yaml`, and a`remote-cluster.yaml` for the remote cluster also managed by the same Runtime.
134
167
135
-
**Example application manifest for in-cluster.yaml**
168
+
#####Example application manifest for in-cluster.yaml
136
169
137
170
```yaml
138
171
apiVersion:argoproj.io/v1alpha1
@@ -264,7 +297,7 @@ Here's how to do this with the Shared Configuration Repo:
264
297
265
298
{{site.data.callout.callout_tip}}
266
299
**TIP**
267
-
You can then monitor these applications in the GitOpsOverview Dashboard, and drill down to each application in the GitOps Apps dashboard.
300
+
You can then monitor these applications in the GitOpsApps dashboard, and drill down to each application in the GitOps Apps dashboard.
268
301
{{site.data.callout.end}}
269
302
270
303
@@ -274,6 +307,7 @@ You can then monitor these applications in the GitOps Overview Dashboard, and dr