mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-12 20:17:13 +00:00
Updating notes
This commit is contained in:
Jennifer Travinski
@@ -211,7 +211,11 @@ spec:
|
||||
|
||||
For the final example, we create an `Output` to write logs to a destination that is not supported out of the box:
|
||||
|
||||
> **Note on syslog** `syslog` is a supported `Output`. However, this example still provides an overview on using unsupported plugins.
|
||||
:::note Note on syslog:
|
||||
|
||||
`syslog` is a supported `Output`. However, this example still provides an overview on using unsupported plugins.
|
||||
|
||||
:::
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
|
||||
@@ -20,7 +20,11 @@ By default, Windows node logging will be enabled if the Cluster Dashboard UI is
|
||||
In this scenario, setting `global.cattle.windows.enabled` to `false` will disable Windows node logging on the cluster.
|
||||
When disabled, logs will still be collected from Linux nodes within the Windows cluster.
|
||||
|
||||
> Note: Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists where Windows nodeAgents are not deleted when performing a `helm upgrade` after disabling Windows logging in a Windows cluster. In this scenario, users may need to manually remove the Windows nodeAgents if they are already installed.
|
||||
:::note
|
||||
|
||||
Currently an [issue](https://github.com/rancher/rancher/issues/32325) exists where Windows nodeAgents are not deleted when performing a `helm upgrade` after disabling Windows logging in a Windows cluster. In this scenario, users may need to manually remove the Windows nodeAgents if they are already installed.
|
||||
|
||||
:::
|
||||
|
||||
### Working with a Custom Docker Root Directory
|
||||
|
||||
@@ -38,7 +42,11 @@ You can add your own `nodeSelector` settings and add `tolerations` for additiona
|
||||
|
||||
### Enabling the Logging Application to Work with SELinux
|
||||
|
||||
> **Requirements:** Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
|
||||
:::note Requirements:
|
||||
|
||||
Logging v2 was tested with SELinux on RHEL/CentOS 7 and 8.
|
||||
|
||||
:::
|
||||
|
||||
[Security-Enhanced Linux (SELinux)](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) is a security enhancement to Linux. After being historically used by government agencies, SELinux is now industry standard and is enabled by default on CentOS 7 and 8.
|
||||
|
||||
@@ -84,8 +92,12 @@ K3s and RKE2 Kubernetes distributions log to journald, which is the subsystem of
|
||||
* If `/var/log/journal` exists, then use `/var/log/journal`.
|
||||
* If `/var/log/journal` does not exist, then use `/run/log/journal`.
|
||||
|
||||
> **Note:** If any value not described above is returned, Rancher Logging will not be able to collect control plane logs. To address this issue, you will need to perform the following actions on every control plane node:
|
||||
:::note Notes:
|
||||
|
||||
> * Set `Storage=volatile` in journald.conf.
|
||||
> * Reboot your machine.
|
||||
> * Set `systemdLogPath` to `/run/log/journal`.
|
||||
If any value not described above is returned, Rancher Logging will not be able to collect control plane logs. To address this issue, you will need to perform the following actions on every control plane node:
|
||||
|
||||
* Set `Storage=volatile` in journald.conf.
|
||||
* Reboot your machine.
|
||||
* Set `systemdLogPath` to `/run/log/journal`.
|
||||
|
||||
:::
|
||||
@@ -27,7 +27,11 @@ To install logging in Rancher v2.5+, refer to the [installation instructions]({{
|
||||
|
||||
In v2.5+, logging configuration in the **Cluster Dashboard**. To configure logging custom resources after the Logging application is installed, go to the left navigation bar and click **Logging**. It is from this menu option that logging for both cluster and namespace is configured.
|
||||
|
||||
> Note: Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster.
|
||||
:::note
|
||||
|
||||
Logging is installed on a per-cluster basis. You will need to navigate between clusters to configure logging for each cluster.
|
||||
|
||||
:::
|
||||
|
||||
There are four key concepts to understand for v2.5+ logging:
|
||||
|
||||
@@ -51,7 +55,11 @@ There are four key concepts to understand for v2.5+ logging:
|
||||
|
||||
To configure cluster-wide logging for v2.5+ logging, one needs to set up a `ClusterFlow`. This object defines the source of logs, any transformations or filters to be applied, and finally the `Output` (or `Outputs`) for the logs.
|
||||
|
||||
> Important: `ClusterFlows` must be defined within the `cattle-logging-system` namespace. `ClusterFlows` will not work if defined in any other namespace.
|
||||
:::note Important:
|
||||
|
||||
`ClusterFlows` must be defined within the `cattle-logging-system` namespace. `ClusterFlows` will not work if defined in any other namespace.
|
||||
|
||||
:::
|
||||
|
||||
In legacy logging, in order to collect logs from across the entire cluster, one only needed to enable cluster-level logging and define the desired `Output`. This basic approach remains in v2.5+ logging. To replicate legacy cluster-level logging, follow these steps:
|
||||
|
||||
@@ -77,7 +85,11 @@ To collect logs from a specific namespace, follow these steps:
|
||||
|
||||
This will result in logs from all sources in the namespace (pods) being collected and sent to the `Output` (or `Outputs`) you defined in your `Flow`.
|
||||
|
||||
> To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label.
|
||||
:::note
|
||||
|
||||
To collect logs from a project, repeat the above steps for every namespace within the project. Alternatively, you can label your project workloads with a common label (e.g. `project=my-project`) and use a `ClusterFlow` to collect logs from all pods matching this label.
|
||||
|
||||
:::
|
||||
|
||||
# Output Configuration
|
||||
In legacy logging, there are five logging destinations to choose from: Elasticsearch, Splunk, Kafka, Fluentd, and Syslog. With the exception of Syslog, all of these destinations are available in logging v2.5+.
|
||||
|
||||
@@ -9,7 +9,11 @@ Rancher logging has two roles, `logging-admin` and `logging-view`.
|
||||
- `logging-admin` gives users full access to namespaced `Flows` and `Outputs`
|
||||
- `logging-view` allows users to *view* namespaced `Flows` and `Outputs`, and `ClusterFlows` and `ClusterOutputs`
|
||||
|
||||
> **Why choose one role over the other?** Edit access to `ClusterFlow` and `ClusterOutput` resources is powerful. Any user with it has edit access for all logs in the cluster.
|
||||
:::note Why choose one role over the other?
|
||||
|
||||
Edit access to `ClusterFlow` and `ClusterOutput` resources is powerful. Any user with it has edit access for all logs in the cluster.
|
||||
|
||||
:::
|
||||
|
||||
In Rancher, the cluster administrator role is the only role with full access to all `rancher-logging` resources. Cluster members are not able to edit or read any logging resources. Project owners and members have the following privileges:
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ shortTitle: Longhorn Storage
|
||||
weight: 19
|
||||
---
|
||||
|
||||
[Longhorn](https://longhorn.io/) is a lightweight, reliable and easy-to-use distributed block storage system for Kubernetes.
|
||||
[Longhorn](https://longhorn.io/) is a lightweight, reliable, and easy-to-use distributed block storage system for Kubernetes.
|
||||
|
||||
Longhorn is free, open source software. Originally developed by Rancher Labs, it is now being developed as a sandbox project of the Cloud Native Computing Foundation. It can be installed on any Kubernetes cluster with Helm, with kubectl, or with the Rancher UI. You can learn more about its architecture [here.](https://longhorn.io/docs/latest/concepts/)
|
||||
|
||||
|
||||
@@ -7,7 +7,11 @@ It is usually not necessary to directly edit the Alertmanager custom resource. F
|
||||
|
||||
When Receivers and Routes are updated, the monitoring application will automatically update the Alertmanager custom resource to be consistent with those changes.
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../../how-monitoring-works/#3-how-alertmanager-works)
|
||||
:::note
|
||||
|
||||
This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../../how-monitoring-works/#3-how-alertmanager-works)
|
||||
|
||||
:::
|
||||
|
||||
# About the Alertmanager Custom Resource
|
||||
|
||||
|
||||
@@ -5,7 +5,11 @@ weight: 1
|
||||
|
||||
It is usually not necessary to directly edit the Prometheus custom resource because the monitoring application automatically updates it based on changes to ServiceMonitors and PodMonitors.
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information, see [this section.](../../../how-monitoring-works/)
|
||||
:::note
|
||||
|
||||
This section assumes familiarity with how monitoring components work together. For more information, see [this section.](../../../how-monitoring-works/)
|
||||
|
||||
:::
|
||||
|
||||
# About the Prometheus Custom Resource
|
||||
|
||||
|
||||
+9
-2
@@ -5,12 +5,19 @@ weight: 3
|
||||
|
||||
A PrometheusRule defines a group of Prometheus alerting and/or recording rules.
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information, see [this section.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/how-monitoring-works)
|
||||
:::note
|
||||
|
||||
This section assumes familiarity with how monitoring components work together. For more information, see [this section.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/how-monitoring-works)
|
||||
|
||||
:::
|
||||
|
||||
### Creating PrometheusRules in the Rancher UI
|
||||
|
||||
> **Prerequisite:** The monitoring application needs to be installed.
|
||||
:::note Prerequisite:
|
||||
|
||||
The monitoring application needs to be installed.
|
||||
|
||||
:::
|
||||
|
||||
To create rule groups in the Rancher UI,
|
||||
|
||||
|
||||
@@ -11,7 +11,11 @@ For information on configuring custom scrape targets and rules for Prometheus, p
|
||||
|
||||
The resource requests and limits for the monitoring application can be configured when installing `rancher-monitoring`. For more information about the default limits, see [this page.](./helm-chart-options/#configuring-resource-limits-and-requests)
|
||||
|
||||
>**Note:** On an idle cluster, Monitoring V2 has significantly higher CPU usage (up to 70%) as compared to Monitoring V1. To improve performance and achieve similar results as in Monitoring V1, turn off the Prometheus adapter.
|
||||
:::note
|
||||
|
||||
On an idle cluster, Monitoring V2 has significantly higher CPU usage (up to 70%) as compared to Monitoring V1. To improve performance and achieve similar results as in Monitoring V1, turn off the Prometheus adapter.
|
||||
|
||||
:::
|
||||
|
||||
# Prometheus Configuration
|
||||
|
||||
|
||||
@@ -6,7 +6,11 @@ weight: 1
|
||||
|
||||
The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file) Secret contains the configuration of an Alertmanager instance that sends out notifications based on alerts it receives from Prometheus.
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../how-monitoring-works/#3-how-alertmanager-works)
|
||||
:::note
|
||||
|
||||
This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../how-monitoring-works/#3-how-alertmanager-works)
|
||||
|
||||
:::
|
||||
|
||||
- [Creating Receivers in the Rancher UI](#creating-receivers-in-the-rancher-ui)
|
||||
- [Receiver Configuration](#receiver-configuration)
|
||||
@@ -25,10 +29,12 @@ The [Alertmanager Config](https://prometheus.io/docs/alerting/latest/configurati
|
||||
|
||||
# Creating Receivers in the Rancher UI
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
>- The monitoring application needs to be installed.
|
||||
>- If you configured monitoring with an existing Alertmanager Secret, it must have a format that is supported by Rancher's UI. Otherwise you will only be able to make changes based on modifying the Alertmanager Secret directly. Note: We are continuing to make enhancements to what kinds of Alertmanager Configurations we can support using the Routes and Receivers UI, so please [file an issue](https://github.com/rancher/rancher/issues/new) if you have a request for a feature enhancement.
|
||||
:::note Prerequisites:
|
||||
|
||||
- The monitoring application needs to be installed.
|
||||
- If you configured monitoring with an existing Alertmanager Secret, it must have a format that is supported by Rancher's UI. Otherwise you will only be able to make changes based on modifying the Alertmanager Secret directly. Note: We are continuing to make enhancements to what kinds of Alertmanager Configurations we can support using the Routes and Receivers UI, so please [file an issue](https://github.com/rancher/rancher/issues/new) if you have a request for a feature enhancement.
|
||||
|
||||
:::
|
||||
|
||||
To create notification receivers in the Rancher UI,
|
||||
|
||||
|
||||
@@ -10,7 +10,11 @@ When a Route is changed, the Prometheus Operator regenerates the Alertmanager cu
|
||||
|
||||
For more information about configuring routes, refer to the [official Alertmanager documentation.](https://www.prometheus.io/docs/alerting/latest/configuration/#route)
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information, see [this section.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/how-monitoring-works)
|
||||
:::note
|
||||
|
||||
This section assumes familiarity with how monitoring components work together. For more information, see [this section.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/how-monitoring-works)
|
||||
|
||||
:::
|
||||
|
||||
- [Route Restrictions](#route-restrictions)
|
||||
- [Route Configuration](#route-configuration)
|
||||
@@ -45,7 +49,11 @@ The route needs to refer to a [receiver](#receiver-configuration) that has alrea
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.6.5+" %}}
|
||||
|
||||
> **Note** As of Rancher v2.6.5 `Group By` now accepts a list of strings instead of key-value pairs. See the [upstream documentation](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route) for details.
|
||||
:::note
|
||||
|
||||
As of Rancher v2.6.5, `Group By` now accepts a list of strings instead of key-value pairs. See the [upstream documentation](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#route) for details.
|
||||
|
||||
:::
|
||||
|
||||
| Field | Default | Description |
|
||||
|-------|--------------|---------|
|
||||
|
||||
+5
-1
@@ -10,7 +10,11 @@ These configuration objects declaratively specify the endpoints that Prometheus
|
||||
|
||||
ServiceMonitors are more commonly used than PodMonitors, and we recommend them for most use cases.
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../how-monitoring-works/)
|
||||
:::note
|
||||
|
||||
This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../../how-monitoring-works/)
|
||||
|
||||
:::
|
||||
|
||||
### ServiceMonitors
|
||||
|
||||
|
||||
@@ -30,14 +30,21 @@ For information about role-based access control for Grafana, see [this section.]
|
||||
|
||||
When `rancher-monitoring` is installed, the Prometheus Alertmanager UI is deployed, allowing you to view your alerts and the current Alertmanager configuration.
|
||||
|
||||
> This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../how-monitoring-works/#how-alertmanager-works)
|
||||
:::note
|
||||
|
||||
This section assumes familiarity with how monitoring components work together. For more information about Alertmanager, see [this section.](../how-monitoring-works/#how-alertmanager-works)
|
||||
|
||||
:::
|
||||
|
||||
### Accessing the Alertmanager UI
|
||||
|
||||
The Alertmanager UI lets you see the most recently fired alerts.
|
||||
|
||||
> **Prerequisite:** The `rancher-monitoring` application must be installed.
|
||||
:::note Prerequisite:
|
||||
|
||||
The `rancher-monitoring` application must be installed.
|
||||
|
||||
:::
|
||||
|
||||
To see the Alertmanager UI,
|
||||
|
||||
|
||||
@@ -22,7 +22,11 @@ rkeEtcd:
|
||||
useLocalhost: true
|
||||
```
|
||||
|
||||
> **Note:** If you want to set up Alertmanager, Grafana or Ingress, it has to be done with the settings on the Helm chart deployment. It's problematic to create Ingress outside the deployment.
|
||||
:::note
|
||||
|
||||
If you want to set up Alertmanager, Grafana or Ingress, it has to be done with the settings on the Helm chart deployment. It's problematic to create Ingress outside the deployment.
|
||||
|
||||
:::
|
||||
|
||||
# Setting Resource Limits and Requests
|
||||
|
||||
|
||||
@@ -13,11 +13,13 @@ To allow the Grafana dashboard to persist after the Grafana instance restarts, a
|
||||
{{% tabs %}}
|
||||
{{% tab "Rancher v2.5.8+" %}}
|
||||
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The monitoring application needs to be installed.
|
||||
> - To create the persistent dashboard, you must have at least the **Manage Config Maps** Rancher RBAC permissions assigned to you in the project or namespace that contains the Grafana Dashboards. This correlates to the `monitoring-dashboard-edit` or `monitoring-dashboard-admin` Kubernetes native RBAC Roles exposed by the Monitoring chart.
|
||||
> - To see the links to the external monitoring UIs, including Grafana dashboards, you will need at least a [project-member role.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/rbac/#users-with-rancher-cluster-manager-based-permissions)
|
||||
:::note Prerequisites:
|
||||
|
||||
- The monitoring application needs to be installed.
|
||||
- To create the persistent dashboard, you must have at least the **Manage Config Maps** Rancher RBAC permissions assigned to you in the project or namespace that contains the Grafana Dashboards. This correlates to the `monitoring-dashboard-edit` or `monitoring-dashboard-admin` Kubernetes native RBAC Roles exposed by the Monitoring chart.
|
||||
- To see the links to the external monitoring UIs, including Grafana dashboards, you will need at least a [project-member role.]({{<baseurl>}}/rancher/v2.6/en/monitoring-alerting/rbac/#users-with-rancher-cluster-manager-based-permissions)
|
||||
|
||||
:::
|
||||
|
||||
### 1. Get the JSON model of the dashboard that you want to persist
|
||||
|
||||
@@ -30,7 +32,12 @@ To use your own dashboard:
|
||||
1. Click on the link to open Grafana. On the cluster detail page, click **Monitoring**.
|
||||
1. Log in to Grafana. Note: The default Admin username and password for the Grafana instance is `admin/prom-operator`. Alternative credentials can also be supplied on deploying or upgrading the chart.
|
||||
|
||||
> **Note:** Regardless of who has the password, in order to access the Grafana instance, you still need at least the <b>Manage Services</b> or <b>View Monitoring</b> permissions in the project that Rancher Monitoring is deployed into. Alternative credentials can also be supplied on deploying or upgrading the chart.
|
||||
:::note
|
||||
|
||||
Regardless of who has the password, in order to access the Grafana instance, you still need at least the <b>Manage Services</b> or <b>View Monitoring</b> permissions in the project that Rancher Monitoring is deployed into. Alternative credentials can also be supplied on deploying or upgrading the chart.
|
||||
|
||||
:::
|
||||
|
||||
1. Create a dashboard using Grafana's UI. Once complete, go to the dashboard's settings by clicking on the gear icon in the top navigation menu. In the left navigation menu, click **JSON Model**.
|
||||
1. Copy the JSON data structure that appears.
|
||||
|
||||
@@ -84,10 +91,13 @@ Note that the RBAC roles exposed by the Monitoring chart to add Grafana Dashboar
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Rancher before v2.5.8" %}}
|
||||
> **Prerequisites:**
|
||||
>
|
||||
> - The monitoring application needs to be installed.
|
||||
> - You must have the cluster-admin ClusterRole permission.
|
||||
|
||||
:::note Prerequisites:
|
||||
|
||||
- The monitoring application needs to be installed.
|
||||
- You must have the cluster-admin ClusterRole permission.
|
||||
|
||||
:::
|
||||
|
||||
1. In the upper left corner, click **☰ > Cluster Management**.
|
||||
1. On the **Clusters** page, go to the cluster where you want to configure the Grafana namespace and click **Explore**.
|
||||
@@ -95,7 +105,12 @@ Note that the RBAC roles exposed by the Monitoring chart to add Grafana Dashboar
|
||||
1. Click **Grafana**.
|
||||
1. Log in to Grafana. Note: The default Admin username and password for the Grafana instance is `admin/prom-operator`. Alternative credentials can also be supplied on deploying or upgrading the chart.
|
||||
|
||||
> **Note:** Regardless of who has the password, cluster administrator permission in Rancher is still required to access the Grafana instance.
|
||||
:::note
|
||||
|
||||
Regardless of who has the password, cluster administrator permission in Rancher is still required to access the Grafana instance.
|
||||
|
||||
:::
|
||||
|
||||
1. Go to the dashboard that you want to persist. In the top navigation menu, go to the dashboard settings by clicking the gear icon.
|
||||
1. In the left navigation menu, click **JSON Model**.
|
||||
1. Copy the JSON data structure that appears.
|
||||
|
||||
@@ -13,4 +13,8 @@ weight: 2
|
||||
|
||||
**Result:** `rancher-monitoring` is uninstalled.
|
||||
|
||||
> **Note on Persistent Grafana Dashboards:** For users who are using Monitoring V2 v9.4.203 or below, uninstalling the Monitoring chart will delete the cattle-dashboards namespace, which will delete all persisted dashboards, unless the namespace is marked with the annotation `helm.sh/resource-policy: "keep"`. This annotation is added by default in Monitoring V2 v14.5.100+ but can be manually applied on the cattle-dashboards namespace before an uninstall if an older version of the Monitoring chart is currently installed onto your cluster.
|
||||
:::note Persistent Grafana Dashboards:
|
||||
|
||||
For users who are using Monitoring V2 v9.4.203 or below, uninstalling the Monitoring chart will delete the cattle-dashboards namespace, which will delete all persisted dashboards, unless the namespace is marked with the annotation `helm.sh/resource-policy: "keep"`. This annotation is added by default in Monitoring V2 v14.5.100+ but can be manually applied on the cattle-dashboards namespace before an uninstall if an older version of the Monitoring chart is currently installed onto your cluster.
|
||||
|
||||
:::
|
||||
+10
-2
@@ -40,13 +40,21 @@ The following selector fields are recommended to have this value:
|
||||
|
||||
Once this setting is turned on, you can always create ServiceMonitors or PodMonitors that are picked up by the Cluster Prometheus by adding the label `release: "rancher-monitoring"` to them, in which case they will be ignored by Project Monitoring Stacks automatically by default, even if the namespace in which those ServiceMonitors or PodMonitors reside in are not system namespaces.
|
||||
|
||||
> Note: If you don't want to allow users to be able to create ServiceMonitors and PodMonitors that aggregate into the Cluster Prometheus in Project namespaces, you can additionally set the namespaceSelectors on the chart to only target system namespaces (which must contain `cattle-monitoring-system` and `cattle-dashboards`, where resources are deployed into by default by rancher-monitoring; you will also need to monitor the `default` namespace to get apiserver metrics or create a custom ServiceMonitor to scrape apiserver metrics from the Service residing in the default namespace) to limit your Cluster Prometheus from picking up other Prometheus Operator CRs. In that case, it would be recommended to turn `.Values.prometheus.prometheusSpec.ignoreNamespaceSelectors=true` to allow you to define ServiceMonitors that can monitor non-system namespaces from within a system namespace.
|
||||
:::note
|
||||
|
||||
If you don't want to allow users to be able to create ServiceMonitors and PodMonitors that aggregate into the Cluster Prometheus in Project namespaces, you can additionally set the namespaceSelectors on the chart to only target system namespaces (which must contain `cattle-monitoring-system` and `cattle-dashboards`, where resources are deployed into by default by rancher-monitoring; you will also need to monitor the `default` namespace to get apiserver metrics or create a custom ServiceMonitor to scrape apiserver metrics from the Service residing in the default namespace) to limit your Cluster Prometheus from picking up other Prometheus Operator CRs. In that case, it would be recommended to turn `.Values.prometheus.prometheusSpec.ignoreNamespaceSelectors=true` to allow you to define ServiceMonitors that can monitor non-system namespaces from within a system namespace.
|
||||
|
||||
:::
|
||||
|
||||
## Increase the CPU / memory limits of the Cluster Prometheus
|
||||
|
||||
Depending on a cluster's setup, it's generally recommended to give a large amount of dedicated memory to the Cluster Prometheus to avoid restarts due to out-of-memory errors (OOMKilled) usually caused by churn created in the cluster that causes a large number of high cardinality metrics to be generated and ingested by Prometheus within one block of time. This is one of the reasons why the default Rancher Monitoring stack expects around 4GB of RAM to be able to operate in a normal-sized cluster. However, when introducing Project Monitoring Stacks that are all sending `/federate` requests to the same Cluster Prometheus and are reliant on the Cluster Prometheus being "up" to federate that system data on their namespaces, it's even more important that the Cluster Prometheus has an ample amount of CPU / memory assigned to it to prevent an outage that can cause data gaps across all Project Prometheis in the cluster.
|
||||
|
||||
> Note: There are no specific recommendations on how much memory the Cluster Prometheus should be configured with since it depends entirely on the user's setup (namely the likelihood of encountering a high churn rate and the scale of metrics that could be generated at that time); it generally varies per setup.
|
||||
:::note
|
||||
|
||||
There are no specific recommendations on how much memory the Cluster Prometheus should be configured with since it depends entirely on the user's setup (namely the likelihood of encountering a high churn rate and the scale of metrics that could be generated at that time); it generally varies per setup.
|
||||
|
||||
:::
|
||||
|
||||
# Install the Prometheus Federator Application
|
||||
|
||||
|
||||
@@ -11,7 +11,11 @@ Prometheus Federator, also referred to as Project Monitoring v2, deploys a Helm
|
||||
- Default PrometheusRules and Grafana dashboards based on the collection of community-curated resources from [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus/)
|
||||
- Default ServiceMonitors that watch the deployed resources
|
||||
|
||||
> **Important** Prometheus Federator is designed to be deployed alongside an existing Prometheus Operator deployment in a cluster that has already installed the Prometheus Operator CRDs.
|
||||
:::note Important:
|
||||
|
||||
Prometheus Federator is designed to be deployed alongside an existing Prometheus Operator deployment in a cluster that has already installed the Prometheus Operator CRDs.
|
||||
|
||||
:::
|
||||
|
||||
## How does the operator work?
|
||||
|
||||
@@ -35,18 +39,28 @@ The `spec.values` of this ProjectHelmChart's resources will correspond to the `v
|
||||
As a Project Operator based on [rancher/helm-project-operator](https://github.com/rancher/helm-project-operator), Prometheus Federator has three different classifications of namespaces that the operator looks out for:
|
||||
|
||||
1. **Operator / System Namespace**: The namespace that the operator is deployed into (e.g., `cattle-monitoring-system`). This namespace will contain all HelmCharts and HelmReleases for all ProjectHelmCharts watched by this operator. **Only Cluster Admins should have access to this namespace.**
|
||||
|
||||
2. **Project Registration Namespace (`cattle-project-<id>`)**: The set of namespaces that the operator watches for ProjectHelmCharts within. The RoleBindings and ClusterRoleBindings that apply to this namespace will also be the source of truth for the auto-assigned RBAC created in the Project Release Namespace. For details, refer to the [RBAC page](./rbac/). **Project Owners (admin), Project Members (edit), and Read-Only Members (view) should have access to this namespace.**
|
||||
|
||||
> **Note:** Project Registration Namespaces will be auto-generated by the operator and imported into the Project it is tied to if `.Values.global.cattle.projectLabel` is provided, which is set to `field.cattle.io/projectId` by default. This indicates that a Project Registration Namespace should be created by the operator if at least one namespace is observed with that label. The operator will not let these namespaces be deleted unless either all namespaces with that label are gone (e.g., this is the last namespace in that project, in which case the namespace will be marked with the label `"helm.cattle.io/helm-project-operator-orphaned": "true"`, which signals that it can be deleted), or it is no longer watching that project because the project ID was provided under `.Values.helmProjectOperator.otherSystemProjectLabelValues`, which serves as a denylist for Projects. These namespaces will also never be auto-deleted to avoid destroying user data; it is recommended that users clean up these namespaces manually if desired on creating or deleting a project.
|
||||
:::note Notes:
|
||||
|
||||
- Project Registration Namespaces will be auto-generated by the operator and imported into the Project it is tied to if `.Values.global.cattle.projectLabel` is provided, which is set to `field.cattle.io/projectId` by default. This indicates that a Project Registration Namespace should be created by the operator if at least one namespace is observed with that label. The operator will not let these namespaces be deleted unless either all namespaces with that label are gone (e.g., this is the last namespace in that project, in which case the namespace will be marked with the label `"helm.cattle.io/helm-project-operator-orphaned": "true"`, which signals that it can be deleted), or it is no longer watching that project because the project ID was provided under `.Values.helmProjectOperator.otherSystemProjectLabelValues`, which serves as a denylist for Projects. These namespaces will also never be auto-deleted to avoid destroying user data; it is recommended that users clean up these namespaces manually if desired on creating or deleting a project.
|
||||
|
||||
- If `.Values.global.cattle.projectLabel` is not provided, the Operator / System Namespace will also be the Project Registration Namespace.
|
||||
|
||||
:::
|
||||
|
||||
> **Note:** If `.Values.global.cattle.projectLabel` is not provided, the Operator / System Namespace will also be the Project Registration Namespace.
|
||||
3. **Project Release Namespace (`cattle-project-<id>-monitoring`):** The set of namespaces that the operator deploys Project Monitoring Stacks within on behalf of a ProjectHelmChart; the operator will also automatically assign RBAC to Roles created in this namespace by the Project Monitoring Stack based on bindings found in the Project Registration Namespace. **Only Cluster Admins should have access to this namespace; Project Owners (admin), Project Members (edit), and Read-Only Members (view) will be assigned limited access to this namespace by the deployed Helm Chart and Prometheus Federator.**
|
||||
|
||||
> **Note:** Project Release Namespaces are automatically deployed and imported into the project whose ID is specified under `.Values.helmProjectOperator.projectReleaseNamespaces.labelValue`, which defaults to the value of `.Values.global.cattle.systemProjectId` if not specified, whenever a ProjectHelmChart is specified in a Project Registration Namespace.
|
||||
:::note Notes:
|
||||
|
||||
- Project Release Namespaces are automatically deployed and imported into the project whose ID is specified under `.Values.helmProjectOperator.projectReleaseNamespaces.labelValue`, which defaults to the value of `.Values.global.cattle.systemProjectId` if not specified, whenever a ProjectHelmChart is specified in a Project Registration Namespace.
|
||||
|
||||
> **Note:** Project Release Namespaces follow the same orphaning conventions as Project Registration Namespaces (see note above).
|
||||
- Project Release Namespaces follow the same orphaning conventions as Project Registration Namespaces (see note above).
|
||||
|
||||
> **Note:** If `.Values.projectReleaseNamespaces.enabled` is false, the Project Release Namespace will be the same as the Project Registration Namespace.
|
||||
- If `.Values.projectReleaseNamespaces.enabled` is false, the Project Release Namespace will be the same as the Project Registration Namespace.
|
||||
|
||||
:::
|
||||
|
||||
### Helm Resources (HelmChart, HelmRelease)
|
||||
|
||||
@@ -54,11 +68,19 @@ On deploying a ProjectHelmChart, the Prometheus Federator will automatically cre
|
||||
|
||||
- A HelmChart CR (managed via an embedded [k3s-io/helm-contoller](https://github.com/k3s-io/helm-controller) in the operator): This custom resource automatically creates a Job in the same namespace that triggers a `helm install`, `helm upgrade`, or `helm uninstall` depending on the change applied to the HelmChart CR. This CR is automatically updated on changes to the ProjectHelmChart (e.g., modifying the values.yaml) or changes to the underlying Project definition (e.g., adding or removing namespaces from a project).
|
||||
|
||||
> **Important:** If a ProjectHelmChart is not deploying or updating the underlying Project Monitoring Stack for some reason, the Job created by this resource in the Operator / System namespace should be the first place you check to see if there's something wrong with the Helm operation. However, this is generally only accessible by a **Cluster Admin.**
|
||||
:::note Important:
|
||||
|
||||
If a ProjectHelmChart is not deploying or updating the underlying Project Monitoring Stack for some reason, the Job created by this resource in the Operator / System namespace should be the first place you check to see if there's something wrong with the Helm operation. However, this is generally only accessible by a **Cluster Admin.**
|
||||
|
||||
:::
|
||||
|
||||
- A HelmRelease CR (managed via an embedded [rancher/helm-locker](https://github.com/rancher/helm-locker) in the operator): This custom resource automatically locks a deployed Helm release in place and automatically overwrites updates to underlying resources unless the change happens via a Helm operation (`helm install`, `helm upgrade`, or `helm uninstall` performed by the HelmChart CR).
|
||||
|
||||
> **Note:** HelmRelease CRs emit Kubernetes Events that detect when an underlying Helm release is being modified and locks it back to place. To view these events, you can use `kubectl describe helmrelease <helm-release-name> -n <operator/system-namespace>`; you can also view the logs on this operator to see when changes are detected and which resources modifications were attempted on.
|
||||
:::note
|
||||
|
||||
HelmRelease CRs emit Kubernetes Events that detect when an underlying Helm release is being modified and locks it back to place. To view these events, you can use `kubectl describe helmrelease <helm-release-name> -n <operator/system-namespace>`; you can also view the logs on this operator to see when changes are detected and which resources modifications were attempted on.
|
||||
|
||||
:::
|
||||
|
||||
Both of these resources are created for all Helm charts in the Operator / System namespaces to avoid escalation of privileges to underprivileged users.
|
||||
|
||||
|
||||
@@ -19,7 +19,11 @@ On observing a change to one of those types of bindings, the Helm Project Operat
|
||||
|
||||
By default, these roleRefs will correspond to `admin`, `edit`, and `view` respectively, which are the [default Kubernetes user-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles).
|
||||
|
||||
> **Note** For Rancher RBAC users, these [default Kubernetes user-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) directly correlate to the `Project Owner`, `Project Member`, and `Read-Only` default Project Role Templates.
|
||||
:::note
|
||||
|
||||
For Rancher RBAC users, these [default Kubernetes user-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) directly correlate to the `Project Owner`, `Project Member`, and `Read-Only` default Project Role Templates.
|
||||
|
||||
:::
|
||||
|
||||
If the `roleRef` matches, the Helm Project Operator will filter the `subjects` of the binding for all Users and Groups and use that to automatically construct a RoleBinding for each Role in the Project Release Namespace with the same name as the role and the following labels:
|
||||
|
||||
|
||||
@@ -28,8 +28,12 @@ Some examples are as follows:
|
||||
- EKS: `docker` for v1.22 and below; `containerd` for v1.23 and up
|
||||
- GKE: `containerd` (see the [Google docs](https://cloud.google.com/kubernetes-engine/docs/concepts/using-containerd) for more)
|
||||
|
||||
>**Note:** Only one container runtime engine may be selected at a time during installation.
|
||||
:::note
|
||||
|
||||
Only one container runtime engine may be selected at a time during installation.
|
||||
|
||||
:::
|
||||
|
||||
**To navigate to and install the NeuVector chart through Cluster Tools:**
|
||||
|
||||
1. Click **☰ > Cluster Management**.
|
||||
|
||||
@@ -24,9 +24,17 @@ OPA Gatekeeper is made available via Rancher's Helm system chart, and it is inst
|
||||
|
||||
# Enabling OPA Gatekeeper in a Cluster
|
||||
|
||||
> In Rancher v2.5, the OPA Gatekeeper application was improved. The Rancher v2.4 feature can't be upgraded to the new version in Rancher v2.5. If you installed OPA Gatekeeper in Rancher v2.4, you will need to uninstall OPA Gatekeeper and its CRDs from the old UI, then reinstall it in Rancher v2.5. To uninstall the CRDs run the following command in the kubectl console `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh`.
|
||||
:::note
|
||||
|
||||
> **Prerequisite:** Only administrators and cluster owners can enable OPA Gatekeeper.
|
||||
In Rancher v2.5, the OPA Gatekeeper application was improved. The Rancher v2.4 feature can't be upgraded to the new version in Rancher v2.5. If you installed OPA Gatekeeper in Rancher v2.4, you will need to uninstall OPA Gatekeeper and its CRDs from the old UI, then reinstall it in Rancher v2.5. To uninstall the CRDs run the following command in the kubectl console `kubectl delete crd configs.config.gatekeeper.sh constrainttemplates.templates.gatekeeper.sh`.
|
||||
|
||||
:::
|
||||
|
||||
:::note Prerequisite:
|
||||
|
||||
Only administrators and cluster owners can enable OPA Gatekeeper.
|
||||
|
||||
:::
|
||||
|
||||
The OPA Gatekeeper Helm chart can be installed from **Apps & Marketplace**.
|
||||
|
||||
@@ -54,7 +62,11 @@ Rancher also provides the ability to create your own constraint templates by imp
|
||||
|
||||
[Constraints](https://github.com/open-policy-agent/gatekeeper#constraints) are Kubernetes custom resources that define the scope of objects to which a specific constraint template applies to. The complete policy is defined by constraint templates and constraints together.
|
||||
|
||||
> **Prerequisites:** OPA Gatekeeper must be enabled in the cluster.
|
||||
:::note Prerequisite:
|
||||
|
||||
OPA Gatekeeper must be enabled in the cluster.
|
||||
|
||||
:::
|
||||
|
||||
To list the constraints installed, go to the left side menu under OPA Gatekeeper, and click on **Constraints**.
|
||||
|
||||
|
||||
@@ -11,7 +11,11 @@ For a list of main features of the Rancher API server, refer to the [overview se
|
||||
|
||||
For guidance about setting up the underlying infrastructure for the Rancher server, refer to the [architecture recommendations.]({{<baseurl>}}/rancher/v2.6/en/overview/architecture-recommendations)
|
||||
|
||||
> This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts]({{<baseurl>}}/rancher/v2.6/en/overview/concepts) page.
|
||||
:::note
|
||||
|
||||
This section assumes a basic familiarity with Docker and Kubernetes. For a brief explanation of how Kubernetes components work together, refer to the [concepts]({{<baseurl>}}/rancher/v2.6/en/overview/concepts) page.
|
||||
|
||||
:::
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
@@ -107,9 +111,13 @@ The `cattle-node-agent` is deployed using a [DaemonSet](https://kubernetes.io/do
|
||||
|
||||
An authorized cluster endpoint allows users to connect to the Kubernetes API server of a downstream cluster without having to route their requests through the Rancher authentication proxy.
|
||||
|
||||
> The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters) to provision the cluster. The ACE is not available for clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
:::note
|
||||
|
||||
> The [ACE is available for registered RKE2 and K3s clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) as of Rancher v2.6.3.
|
||||
- The authorized cluster endpoint only works on Rancher-launched Kubernetes clusters. In other words, it only works in clusters where Rancher [used RKE]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/rke-clusters) to provision the cluster. The ACE is not available for clusters in a hosted Kubernetes provider, such as Amazon's EKS.
|
||||
|
||||
- The [ACE is available for registered RKE2 and K3s clusters]({{<baseurl>}}/rancher/v2.6/en/cluster-provisioning/registered-clusters/#authorized-cluster-endpoint-support-for-rke2-and-k3s-clusters) as of Rancher v2.6.3.
|
||||
|
||||
:::
|
||||
|
||||
There are two main reasons why a user might need the authorized cluster endpoint:
|
||||
|
||||
@@ -120,7 +128,11 @@ The `kube-api-auth` microservice is deployed to provide the user authentication
|
||||
|
||||
Like the authorized cluster endpoint, the `kube-api-auth` authentication service is also only available for Rancher-launched Kubernetes clusters.
|
||||
|
||||
> **Example scenario:** Let's say that the Rancher server is located in the United States, and User Cluster 1 is located in Australia. A user, Alice, also lives in Australia. Alice can manipulate resources in User Cluster 1 by using the Rancher UI, but her requests will have to be sent from Australia to the Rancher server in the United States, then be proxied back to Australia, where the downstream user cluster is. The geographical distance may cause significant latency, which Alice can reduce by using the authorized cluster endpoint.
|
||||
:::note Example scenario:
|
||||
|
||||
Let's say that the Rancher server is located in the United States, and User Cluster 1 is located in Australia. A user, Alice, also lives in Australia. Alice can manipulate resources in User Cluster 1 by using the Rancher UI, but her requests will have to be sent from Australia to the Rancher server in the United States, then be proxied back to Australia, where the downstream user cluster is. The geographical distance may cause significant latency, which Alice can reduce by using the authorized cluster endpoint.
|
||||
|
||||
:::
|
||||
|
||||
With this endpoint enabled for the downstream cluster, Rancher generates an extra Kubernetes context in the kubeconfig file in order to connect directly to the cluster. This file has the credentials for `kubectl` and `helm`.
|
||||
|
||||
@@ -134,7 +146,11 @@ The files mentioned below are needed to maintain, troubleshoot and upgrade your
|
||||
- `kube_config_cluster.yml`: The Kubeconfig file for the cluster, this file contains credentials for full access to the cluster. You can use this file to authenticate with a Rancher-launched Kubernetes cluster if Rancher goes down.
|
||||
- `rancher-cluster.rkestate`: The Kubernetes cluster state file. This file contains credentials for full access to the cluster. Note: This state file is only created when using RKE v0.2.0 or higher.
|
||||
|
||||
> **Note:** The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
:::note
|
||||
|
||||
The "rancher-cluster" parts of the two latter file names are dependent on how you name the RKE cluster configuration file.
|
||||
|
||||
:::
|
||||
|
||||
For more information on connecting to a cluster without the Rancher authentication proxy and other configuration options, refer to the [kubeconfig file]({{<baseurl>}}/rancher/v2.6/en/cluster-admin/cluster-access/kubectl/) documentation.
|
||||
|
||||
|
||||
@@ -20,7 +20,11 @@ This section covers the following topics:
|
||||
|
||||
Docker is the container packaging and runtime standard. Developers build container images from Dockerfiles and distribute container images from Docker registries. [Docker Hub](https://hub.docker.com) is the most popular public registry. Many organizations also set up private Docker registries. Docker is primarily used to manage containers on individual nodes.
|
||||
|
||||
>**Note:** Although Rancher 1.6 supported Docker Swarm clustering technology, it is no longer supported in Rancher 2.x due to the success of Kubernetes.
|
||||
:::note
|
||||
|
||||
Although Rancher 1.6 supported Docker Swarm clustering technology, it is no longer supported in Rancher 2.x due to the success of Kubernetes.
|
||||
|
||||
:::
|
||||
|
||||
# About Kubernetes
|
||||
|
||||
|
||||
@@ -3,12 +3,15 @@ title: Pipelines
|
||||
weight: 10
|
||||
---
|
||||
|
||||
> As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet]({{<baseurl>}}/rancher/v2.6/en/deploy-across-clusters/fleet). To get to Fleet in Rancher, click <b>☰ > Continuous Delivery</b>.
|
||||
>
|
||||
>**Notice:**
|
||||
>
|
||||
> - Pipelines in Kubernetes 1.21+ are no longer supported.
|
||||
> - Fleet does not replace Rancher pipelines; the distinction is that Rancher pipelines are now powered by Fleet.
|
||||
:::note Notes
|
||||
|
||||
- As of Rancher v2.5, Git-based deployment pipelines are now deprecated. We recommend handling pipelines with Rancher Continuous Delivery powered by [Fleet]({{<baseurl>}}/rancher/v2.6/en/deploy-across-clusters/fleet). To get to Fleet in Rancher, click <b>☰ > Continuous Delivery</b>.
|
||||
|
||||
- Pipelines in Kubernetes 1.21+ are no longer supported.
|
||||
|
||||
- Fleet does not replace Rancher pipelines; the distinction is that Rancher pipelines are now powered by Fleet.
|
||||
|
||||
:::
|
||||
|
||||
Rancher's pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds or scripts, publish Docker images or catalog applications, and deploy the updated software to users.
|
||||
|
||||
@@ -22,13 +25,17 @@ After configuring Rancher and GitHub, you can deploy containers running Jenkins
|
||||
- Run unit tests.
|
||||
- Run regression tests.
|
||||
|
||||
>**Note:** Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.
|
||||
:::note
|
||||
|
||||
Rancher's pipeline provides a simple CI/CD experience, but it does not offer the full power and flexibility of and is not a replacement of enterprise-grade Jenkins or other CI tools your team uses.
|
||||
|
||||
:::
|
||||
|
||||
This section covers the following topics:
|
||||
|
||||
- [Concepts](#concepts)
|
||||
- [How Pipelines Work](#how-pipelines-work)
|
||||
- [Roles-based Access Control for Pipelines](#roles-based-access-control-for-pipelines)
|
||||
[Roles-based Access Control for Pipelines](#role-based-access-control-for-pipelines)
|
||||
- [Setting up Pipelines](#setting-up-pipelines)
|
||||
- [Configure version control providers](#1-configure-version-control-providers)
|
||||
- [Configure repositories](#2-configure-repositories)
|
||||
@@ -56,7 +63,11 @@ When you configure a pipeline in one of your projects, a namespace specifically
|
||||
|
||||
The pipeline's build engine. Because project users do not directly interact with Jenkins, it's managed and locked.
|
||||
|
||||
>**Note:** There is no option to use existing Jenkins deployments as the pipeline engine.
|
||||
:::note
|
||||
|
||||
There is no option to use existing Jenkins deployments as the pipeline engine.
|
||||
|
||||
:::
|
||||
|
||||
- **Docker Registry:**
|
||||
|
||||
@@ -66,9 +77,13 @@ When you configure a pipeline in one of your projects, a namespace specifically
|
||||
|
||||
Minio storage is used to store the logs for pipeline executions.
|
||||
|
||||
>**Note:** The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components]({{<baseurl>}}/rancher/v2.6/en/pipelines/storage).
|
||||
:::note
|
||||
|
||||
The managed Jenkins instance works statelessly, so don't worry about its data persistency. The Docker Registry and Minio instances use ephemeral volumes by default, which is fine for most use cases. If you want to make sure pipeline logs can survive node failures, you can configure persistent volumes for them, as described in [data persistency for pipeline components]({{<baseurl>}}/rancher/v2.6/en/pipelines/storage).
|
||||
|
||||
# Roles-based Access Control for Pipelines
|
||||
:::
|
||||
|
||||
# Role-based Access Control for Pipelines
|
||||
|
||||
If you can access a project, you can enable repositories to start building pipelines.
|
||||
|
||||
@@ -80,11 +95,15 @@ Project members can only configure repositories and pipelines.
|
||||
|
||||
### Prerequisite
|
||||
|
||||
> **Prerequisite:** Because the pipelines app was deprecated in favor of Fleet, you will need to turn on the feature flag for legacy features before using pipelines. Note that pipelines in Kubernetes 1.21+ are no longer supported.
|
||||
>
|
||||
> 1. In the upper left corner, click **☰ > Global Settings**.
|
||||
> 1. Click **Feature Flags**.
|
||||
> 1. Go to the `legacy` feature flag and click **⋮ > Activate**.
|
||||
:::note Legacy Feature Flag:
|
||||
|
||||
Because the pipelines app was deprecated in favor of Fleet, you will need to turn on the feature flag for legacy features before using pipelines. Note that pipelines in Kubernetes 1.21+ are no longer supported.
|
||||
|
||||
1. In the upper left corner, click **☰ > Global Settings**.
|
||||
1. Click **Feature Flags**.
|
||||
1. Go to the `legacy` feature flag and click **⋮ > Activate**.
|
||||
|
||||
:::
|
||||
|
||||
1. [Configure version control providers](#1-configure-version-control-providers)
|
||||
2. [Configure repositories](#2-configure-repositories)
|
||||
@@ -127,9 +146,13 @@ Select your provider's tab below and follow the directions.
|
||||
1. If you're using GitLab for enterprise setup, select **Use a private gitlab enterprise installation**. Enter the host address of your GitLab installation.
|
||||
1. Click **Authenticate**.
|
||||
|
||||
>**Note:**
|
||||
> 1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
|
||||
> 2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
|
||||
:::note Notes:
|
||||
|
||||
1. Pipeline uses Gitlab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html) and the supported Gitlab version is 9.0+.
|
||||
2. If you use GitLab 10.7+ and your Rancher setup is in a local network, enable the **Allow requests to the local network from hooks and services** option in GitLab admin settings.
|
||||
|
||||
:::
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Bitbucket Cloud" %}}
|
||||
|
||||
@@ -253,7 +276,11 @@ Available Events:
|
||||
* **Pull Request**: Whenever a pull request is made to the repository, the pipeline is triggered.
|
||||
* **Tag**: When a tag is created in the repository, the pipeline is triggered.
|
||||
|
||||
> **Note:** This option doesn't exist for Rancher's [example repositories]({{<baseurl>}}/rancher/v2.6/en/pipelines/example-repos/).
|
||||
:::note
|
||||
|
||||
This option doesn't exist for Rancher's [example repositories]({{<baseurl>}}/rancher/v2.6/en/pipelines/example-repos/).
|
||||
|
||||
:::
|
||||
|
||||
### Modifying the Event Triggers for the Repository
|
||||
|
||||
|
||||
Reference in New Issue
Block a user