Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared config repo promotion settings #1050

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion _docs/installation/gitops/monitor-manage-runtimes.md
Original file line number Diff line number Diff line change
Expand Up @@ -101,7 +101,7 @@ Here is a description of the information in the Topology view.
|**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> {:/}|

## Designating Configuration Runtimes
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-->.
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.

##### Single vs multiple Configuration Runtimes
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.
Expand Down
48 changes: 36 additions & 12 deletions _docs/installation/gitops/shared-configuration.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,6 +29,12 @@ Here are a few types of configuration definitions stored in the Shared Configura
* [Git Sources]({{site.baseurl}}/docs/installation/gitops/git-sources/)
* [Integrations]({{site.baseurl}}/docs/gitops-integrations/image-enrichment-overview/) between Codefresh and third-parties for GitOps
* [OAuth2]({{site.baseurl}}/docs/administration/account-user-management/oauth-setup/) authentication applications
* Manifests for promotion entities: NIMA: TBD
* Products
* Promotion Workflows
* Promotion Policies
* Promoton Flows


## GitOps Runtimes & Shared Configuration Repos

Expand All @@ -46,24 +52,34 @@ Here are a few types of configuration definitions stored in the Shared Configura
-->

## Shared Configuration Repo structure
Below is a representation of the structure of the repository with the shared configuration.
See a [sample repo](https://github.com/codefresh-contrib/example-shared-config-repo){:target="\_blank"}.
Below is a representation of the structure of the repository with the shared configuration in the GitOps Runtime designated as the Configuration Runtime.
<!--- See a [sample repo](https://github.com/codefresh-contrib/example-shared-config-repo){:target="\_blank"}.-->

```

├── resources <───────────────────┐
│   ├── all-runtimes-all-clusters │
│   │   ├── cm-all.yaml │
│   │   └── subfolder │
│   │   └── manifest2.yaml │
│   ├── control-planes │
│   │ └── manifest3.yaml │
│ │ └── promotion-workflows │ # stores promotion workflow manifests available to all runtimes
│   │   └── smoke-tests.yaml │
│   ├── runtimes │
│   │ ├── runtime1 │
│   │ │ └── manifest4.yaml │
│   │ └── runtime2 │
│   │ └── manifest5.yaml │
│   └── manifest6.yaml │
└── app-projects │
└── configurations │ # syncs to cluster by runtimes designated as Configuration Runtime
│   ├── products │ # stores product manifests with all product settings except assigned applications
│   │   └── loans.yaml │
│   ├── promotion-flows │ # stores promotion flow manifests with promotion orchestration settings
│   │   ├── base-flow.yaml │
│   │   └── hot-fix.yaml │
│   └── promotion-policies │ # stores promotion policy manifests for products/environments with promotion workflows & promotion action
│   └── prod-pr.yaml │
│   └── loan-policy.yaml │
└── runtimes │
├── runtime1 │ # referenced by "production-isc" argo-cd application, applied to the cluster by "cap-app-proxy"
│   ├── in-cluster.yaml ─┤ # manage `include` field determines which dirs/files to sync to cluster
Expand All @@ -75,21 +91,28 @@ See a [sample repo](https://github.com/codefresh-contrib/example-shared-config-r

### `resources` directory

The `resources` directory holds the resources shared by _all_ clusters managed by the GitOps Runtimes:
The `resources` directory contains the resources shared by _all_ clusters managed by GitOps Runtimes.

* `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`.
* `resources/control-planes`: Optional. When defined, every resource manifest in this subdirectory is applied to each Runtime’s `in-cluster`.
Config map resources for example, when committed to this subdirectory, are deployed to each Runtime’s `in-cluster`.
* `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`.
{: .table .table-bordered .table-hover}
| Shared Configuration Repo | Description |
| ---------- | -------- |
| `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`. |
|`resources/all-runtimes-all-clusters/promotion-workflows` | Stores manifests of Promotion Workflows, available to all Runtimes in the account. |
|`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`. |
| `resources/app-projects` | Contains application project resources which control deployment destinations for applications. |
| `resources/configurations` | Contains platform-level resources which are Runtime-agnostic, essential for functionality related to product and promotion entities in GitOps. |
| `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/).|
|`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. See TBD.|
| `resources/configurations/promotion-flows`| Contains manifests of promotion flows with the trigger and target environments, and custom promotion policy settings, if any. See TBD.|
|`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`. |



### `runtimes` directory
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.
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.

**Example application manifest for in-cluster.yaml**
##### Example application manifest for in-cluster.yaml

```yaml
apiVersion: argoproj.io/v1alpha1
Expand Down Expand Up @@ -140,14 +163,15 @@ Here's how to do this with the Shared Configuration Repo:

{{site.data.callout.callout_tip}}
**TIP**
You can then monitor these applications in the GitOps Overview Dashboard, and drill down to each application in the GitOps Apps dashboard.
You can then monitor these applications in the GitOps Apps dashboard, and drill down to each application in the GitOps Apps dashboard.
{{site.data.callout.end}}


## Related articles
[Hosted GitOps Runtime installation]({{site.baseurl}}/docs/installation/gitops/hosted-runtime/)
[Hybrid GitOps Runtime installation]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops-helm-installation/)





Expand Down