mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-10 11:15:49 +00:00
more 404 fixes
This commit is contained in:
Denise Schannon
@@ -9,10 +9,10 @@ This section is devoted to protecting your data in a disaster scenario.
|
||||
To protect yourself from a disaster scenario, you should create backups on a regular basis.
|
||||
|
||||
- [Rancher Server Backups]({{< baseurl >}}/rancher/v2.x/en/backups/backups)
|
||||
- [Backing up Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/rancher/v2.x/en/cluster-admin/backing-up-etcd/)
|
||||
- [Backing up Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/)
|
||||
|
||||
|
||||
In a disaster scenario, you can restore your `etcd` database by restoring a backup.
|
||||
|
||||
- [Rancher Server Restorations]({{< baseurl >}}/rancher/v2.x/en/backups/restorations)
|
||||
- [Restoring Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/rancher/v2.x/en/cluster-admin/restoring-etcd/)
|
||||
- [Restoring Rancher Launched Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/)
|
||||
|
||||
@@ -7,6 +7,6 @@ When installing Rancher, there are several advanced options that can be enabled
|
||||
|
||||
| Advanced Option | Available as of |
|
||||
| --- | ---|
|
||||
| [Custom CA Certificate]({{< baseurl >}}/rancher/v2.x/en/installation/options/options/) | v2.0.0 |
|
||||
| [Custom CA Certificate]({{< baseurl >}}/rancher/v2.x/en/installation/options/custom-ca-root-certificate/) | v2.0.0 |
|
||||
| [API Audit Log]({{< baseurl >}}/rancher/v2.x/en/installation/options/api-audit-log/) | v2.0.0 |
|
||||
| [TLS Settings]({{< baseurl >}}/rancher/v2.x/en/installation/options/tls-settings/) | v2.1.7 |
|
||||
|
||||
@@ -25,7 +25,7 @@ The usage below defines rules about what the audit log should record and what da
|
||||
|
||||
Parameter | Description |
|
||||
---------|----------|
|
||||
<a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.</br>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-level-logging) for a table that displays what each setting logs. |
|
||||
<a id="audit-level"></a>`AUDIT_LEVEL` | `0` - Disable audit log (default setting).<br/>`1` - Log event metadata.<br/>`2` - Log event metadata and request body.</br>`3` - Log event metadata, request body, and response body. Each log transaction for a request/response pair uses the same `auditID` value.<br/><br/>See [Audit Level Logging](#audit-log-levels) for a table that displays what each setting logs. |
|
||||
`AUDIT_LOG_PATH` | Log path for Rancher Server API. Default path is `/var/log/auditlog/rancher-api-audit.log`. You can mount the log directory to host. <br/><br/>Usage Example: `AUDIT_LOG_PATH=/my/custom/path/`<br/> |
|
||||
`AUDIT_LOG_MAXAGE` | Defined the maximum number of days to retain old audit log files. Default is 10 days. |
|
||||
`AUDIT_LOG_MAXBACKUP` | Defines the maximum number of audit log files to retain. Default is 10.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Choosing a Version
|
||||
title: Choosing a Version
|
||||
weight: 230
|
||||
---
|
||||
|
||||
@@ -49,16 +49,9 @@ Instructions on when to select these repos are available below in [Switching to
|
||||
|
||||
### Helm Chart Versions
|
||||
|
||||
Up until the initial release of the Helm chart for Rancher v2.1.0, the version of the Helm chart matched the Rancher version (i.e `appVersion`).
|
||||
Rancher Helm chart versions match the Rancher version (i.e `appVersion`).
|
||||
|
||||
Since there are times where the Helm chart will require changes without any changes to the Rancher version, we have moved to a versioning scheme using `yyyy.mm.<build-number>` for the Helm charts.
|
||||
|
||||
Run `helm search rancher` to view which Rancher version will be launched for the your Helm chart.
|
||||
|
||||
```
|
||||
NAME CHART VERSION APP VERSION DESCRIPTION
|
||||
rancher-latest/rancher 2018.10.1 v2.1.0 Install Rancher Server to manage Kubernetes clusters acro...
|
||||
```
|
||||
For the Rancher v2.1.x versions, there were some Helm charts, that were using a version that was a build number, i.e. `yyyy.mm.<build-number>`. These charts have been replaced with the equivalent Rancher version and are no longer available.
|
||||
|
||||
### Switching to a Different Helm Chart Repository
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ For security purposes, SSL (Secure Sockets Layer) is required when using Rancher
|
||||
>- Use a proxy? See [HTTP Proxy Configuration]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/proxy/)
|
||||
>- Configure custom CA root certificate to access your services? See [Custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate/)
|
||||
>- Complete an Air Gap Installation? See [Air Gap: Single Node Install]({{< baseurl >}}/rancher/v2.x/en/installation/air-gap-single-node/)
|
||||
>- Record all transactions with the Rancher API? See [API Auditing](#api-auditing)
|
||||
>- Record all transactions with the Rancher API? See [API Auditing](#api-audit-log)
|
||||
>
|
||||
|
||||
Choose from the following options:
|
||||
|
||||
@@ -97,7 +97,7 @@ Edit [resource quotas]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-a
|
||||
|
||||
1. Expand **Resource Quotas** and click **Add Quota**. Alternatively, you can edit existing quotas.
|
||||
|
||||
1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
|
||||
1. Select a [Resource Type]({{< baseurl >}}/rancher/v2.x/en/project-admin/resource-quotas/#resource-quota-types).
|
||||
|
||||
1. Enter values for the **Project Limit** and the **Namespace Default Limit**.
|
||||
|
||||
|
||||
@@ -68,7 +68,7 @@ If there is a [resource quota]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pr
|
||||
|
||||
1. Find the namespace for which you want to edit the resource quota. Select **Ellipsis (...) > Edit**.
|
||||
|
||||
1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured [project limits]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#project-limits).
|
||||
1. Edit the Resource Quota **Limits**. These limits determine the resources available to the namespace. The limits must be set within the configured project limits.
|
||||
|
||||
For more information about each **Resource Type**, see [Resource Quota Types]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/resource-quotas/#resource-quota-types).
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@ In the following diagram, a Kubernetes admin is trying to enforce a resource quo
|
||||
<sup>Base Kubernetes: Unique Resource Quotas Being Applied to Each Namespace</sup>
|
||||
|
||||
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces you limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#namespace-default-limit-overrides).
|
||||
Resource quotas are a little different in Rancher. In Rancher, you apply a resource quota to the [project]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/projects-and-namespaces/#projects), and then the quota propagates to each namespace, whereafter Kubernetes enforces you limits using the native version of resource quotas. If you want to change the quota for a specific namespace, you can [override it](#overriding-the-default-limit-for-a-namespace).
|
||||
|
||||
The resource quota includes two limits, which you set while creating or editing a project:
|
||||
<a id="project-limits"></a>
|
||||
|
||||
@@ -22,7 +22,7 @@ At the project level, Rancher monitors specific deployments and sends alerts for
|
||||
|
||||
## Adding Project Alerts
|
||||
|
||||
>**Prerequisite:** Before you can receive project alerts, you must [add a notifier]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/notifiers/#adding-notifiers).
|
||||
>**Prerequisite:** Before you can receive project alerts, you must [add a notifier]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/tools/notifiers/#adding-notifiers).
|
||||
|
||||
1. From the **Global** view, navigate to the project that you want to configure project alerts for. Select **Tools > Alerts**. In versions prior to v2.2.0, you can choose **Resources > Alerts**.
|
||||
|
||||
@@ -99,13 +99,16 @@ This alert type monitors for the availability of all workloads marked with tags
|
||||
|
||||
{{% /accordion %}}
|
||||
{{% accordion id="project-expression" label="Metric Expression Alerts" %}}
|
||||
This alert type monitors for the overload from Prometheus expression querying, it would be available after you enable monitoring.
|
||||
<br>
|
||||
_Available as of v2.2.0_
|
||||
|
||||
If you enable [project monitoring]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/#monitoring), this alert type monitors for the overload from Prometheus expression querying.
|
||||
|
||||
1. Input or select an **Expression**, the drop down shows the original metrics from Prometheus, including:
|
||||
|
||||
- [**Container**](https://github.com/google/cadvisor)
|
||||
- [**Kubernetes Resources**](https://github.com/kubernetes/kube-state-metrics)
|
||||
- [**Customize**]({{< baseurl >}}/rancher/v2.x/en/tools/monitoring/#custom-metrics)
|
||||
- [**Customize**]({{< baseurl >}}/rancher/v2.x/en/project-admin/tools/monitoring/#project-metrics)
|
||||
- [**Project Level Grafana**](http://docs.grafana.org/administration/metrics/)
|
||||
- **Project Level Prometheus**
|
||||
|
||||
@@ -138,7 +141,7 @@ This alert type monitors for the overload from Prometheus expression querying, i
|
||||
- **Group Wait Time**: How long to wait to buffer alerts of the same group before sending initially, default to 30 seconds.
|
||||
- **Group Interval Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 30 seconds.
|
||||
- **Repeat Wait Time**: How long to wait before sending an alert that has been added to a group which contains already fired alerts, default to 1 hour.
|
||||
|
||||
<br>
|
||||
{{% /accordion %}}
|
||||
|
||||
1. Continue adding more **Alert Rule** to the group.
|
||||
|
||||
@@ -51,19 +51,15 @@ When you configure a pipeline in one of your projects, a namespace specifically
|
||||
|
||||
>**Note:** There is no option to use existing Jenkins deployments as the pipeline engine.
|
||||
|
||||
<a id="reg"></a>
|
||||
|
||||
- **Docker Registry:**
|
||||
|
||||
Out-of-the-box, the default target for your build-publish step is an internal Docker Registry. However, you can make configurations to push to a remote registry instead. The internal Docker Registry is only accessible from cluster nodes and cannot be directly accessed by users. Images are not persisted beyond the lifetime of the pipeline and should only be used in pipeline runs. If you need to access your images outside of pipeline runs, please push to an external registry.
|
||||
|
||||
<a id="minio"></a>
|
||||
|
||||
- **Minio:**
|
||||
|
||||
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](#data-persistency-for-pipeline-components).
|
||||
>**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](#configuring-persistent-data-for-pipeline-components).
|
||||
|
||||
## Pipeline Triggers
|
||||
|
||||
@@ -250,15 +246,13 @@ If you want to use a version control provider with a certificate from a custom/i
|
||||
|
||||
## Configuring Persistent Data for Pipeline Components
|
||||
|
||||
The internal [Docker registry]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#reg) and the [Minio]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/#minio) workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
|
||||
|
||||
Complete both [A—Configuring Persistent Data for Docker Registry](#a—configuring-persistent-data-for-docker-registry) _and_ [B—Configuring Persistent Data for Minio](#b—configuring-persistent-data-for-minio).
|
||||
The internal [Docker registry](#how-pipelines-work) and the [Minio](#how-pipelines-work) workloads use ephemeral volumes by default. This default storage works out-of-the-box and makes testing easy, but you lose the build images and build logs if the node running the Docker Registry or Minio fails. In most cases this is fine. If you want build images and logs to survive node failures, you can configure the Docker Registry and Minio to use persistent volumes.
|
||||
|
||||
>**Prerequisites (for both parts A and B):**
|
||||
>
|
||||
>[Persistent volumes]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/volumes-and-storage/#persistent-volumes) must be available for the cluster.
|
||||
|
||||
#### A. Configuring Persistent Data for Docker Registry
|
||||
### A. Configuring Persistent Data for Docker Registry
|
||||
|
||||
1. From the project that you're configuring a pipeline for, select the **Workloads** tab.
|
||||
|
||||
@@ -305,7 +299,7 @@ Complete both [A—Configuring Persistent Data for Docker Registry](#a—configu
|
||||
|
||||
1. Click **Upgrade**.
|
||||
|
||||
#### B. Configuring Persistent Data for Minio
|
||||
### B. Configuring Persistent Data for Minio
|
||||
|
||||
1. From the **Workloads** tab, find the `minio` workload and select **Ellipsis (...) > Edit**.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user