diff --git a/content/rancher/v2.x/en/admin-settings/_index.md b/content/rancher/v2.x/en/admin-settings/_index.md index b586648bd6f..45e20daebd2 100644 --- a/content/rancher/v2.x/en/admin-settings/_index.md +++ b/content/rancher/v2.x/en/admin-settings/_index.md @@ -4,20 +4,40 @@ weight: 1100 aliases: - /rancher/v2.x/en/concepts/global-configuration/ - /rancher/v2.x/en/tasks/global-configuration/ + - /rancher/v2.x/en/concepts/global-configuration/server-url/ + - /rancher/v2.x/en/tasks/global-configuration/server-url/ + - /rancher/v2.x/en/admin-settings/server-url/ + - /rancher/v2.x/en/admin-settings/log-in/ --- -After installation, the system administrator should configure Rancher to configure security, default settings, and user access. +After installation, the [system administrator]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/global-permissions/) should configure Rancher to configure authentication, authorization, security, default settings, security policies, drivers and global DNS entries. -## Drivers +## First Log In -Drivers in Rancher allow you to manage which providers can be used to deploy [hosted Kubernetes clusters]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes. +After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself. -For more information, see [Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/). +>**Important!** After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care. -## Global DNS +## Authentication -_Available as v2.2.0_ +One of the key features that Rancher adds to Kubernetes is centralized user authentication. This feature allows to set up local users and/or connect to an external authentication provider. By connecting to an external authentication provider, you can leverage that provider's user and groups. -When creating applications that span multiple Kubernetes clusters, a Global DNS entry can be created to route traffic to the endpoints in all of the different clusters. An external DNS server will need be programmed to assign a fully qualified domain name (a.k.a FQDN) to your application. Rancher will use the FQDN you provide and the IP addresses where your application is running to program the DNS. Rancher will gather endpoints from all the Kubernetes clusters running your application and program the DNS. +For more information how authentication works and how to configure each provider, see [Authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/). -For more information on how to use this feature, see [Global DNS]({{< baseurl >}}/rancher/v2.x/en/admin-settings/globaldns/). +## Authorization + +Within Rancher, each person authenticates as a _user_, which is a login that grants you access to Rancher. Once the user logs in to Rancher, their _authorization_, or their access rights within the system, is determined by the user's role. Rancher provides built-in roles to allow you to easily configure a user's permissions to resources, but Rancher also provides the ability to customize the roles for each Kubernetes resource. + +For more information how authorization works and how to customize roles, see [Roles Based Access Control (RBAC)]({{< baseurl >}}/rancher/v2.x/en/admin-settings/rbac/). + +## Pod Security Policies + +_Pod Security Policies_ (or PSPs) are objects that control security-sensitive aspects of pod specification, e.g. root privileges. If a pod does not meet the conditions specified in the PSP, Kubernetes will not allow it to start, and Rancher will display an error message. + +For more information how to create and use PSPs, see [Pod Security Policies]({{< baseurl >}}/rancher/v2.x/en/admin-settings/pod-security-policies/). + +## Provisioning Drivers + +Drivers in Rancher allow you to manage which providers can be used to provision [hosted Kubernetes clusters]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/hosted-kubernetes-clusters/) or [nodes in an infrastructure provider]({{< baseurl >}}rancher/v2.x/en/cluster-provisioning/rke-clusters/node-pools/) to allow Rancher to deploy and manage Kubernetes. + +For more information, see [Provisioning Drivers]({{< baseurl >}}/rancher/v2.x/en/admin-settings/drivers/). diff --git a/content/rancher/v2.x/en/admin-settings/drivers/_index.md b/content/rancher/v2.x/en/admin-settings/drivers/_index.md index 6455e4d2b05..b0a4104093b 100644 --- a/content/rancher/v2.x/en/admin-settings/drivers/_index.md +++ b/content/rancher/v2.x/en/admin-settings/drivers/_index.md @@ -1,5 +1,5 @@ --- -title: Drivers +title: Provisioning Drivers weight: 1140 --- diff --git a/content/rancher/v2.x/en/admin-settings/log-in/_index.md b/content/rancher/v2.x/en/admin-settings/log-in/_index.md deleted file mode 100644 index c0adacd6d85..00000000000 --- a/content/rancher/v2.x/en/admin-settings/log-in/_index.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: First Log In -weight: 1105 -aliases: - - /rancher/v2.x/en/concepts/global-configuration/server-url/ - - /rancher/v2.x/en/tasks/global-configuration/server-url/ - - /rancher/v2.x/en/admin-settings/server-url ---- - -After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself. - ->**Important!** After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care. diff --git a/content/rancher/v2.x/en/admin-settings/rbac/_index.md b/content/rancher/v2.x/en/admin-settings/rbac/_index.md index 62867a8418e..f3aedf6b0d6 100644 --- a/content/rancher/v2.x/en/admin-settings/rbac/_index.md +++ b/content/rancher/v2.x/en/admin-settings/rbac/_index.md @@ -1,5 +1,5 @@ --- -title: Roles +title: Roles Based Access Control (RBAC) weight: 1120 aliases: - /rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/ diff --git a/content/rancher/v2.x/en/backups/_index.md b/content/rancher/v2.x/en/backups/_index.md index 64e2cebf6ef..35e829bb1b5 100644 --- a/content/rancher/v2.x/en/backups/_index.md +++ b/content/rancher/v2.x/en/backups/_index.md @@ -3,12 +3,16 @@ title: Backups and Disaster Recovery weight: 1000 --- -This section is devoted to protecting your Rancher Server data in a disaster scenario. +This section is devoted to protecting your data in a disaster scenario. -- [Backups]({{< baseurl >}}/rancher/v2.x/en/backups/backups) - To protect yourself from a disaster scenario, you should create Rancher backups on a regular basis. +To protect yourself from a disaster scenario, you should create backups on a regular basis. -- [Restorations]({{< baseurl >}}/rancher/v2.x/en/backups/restorations) + - [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/) - In a disaster scenario, you can restore your `etcd` database by restoring a backup. + +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/) diff --git a/content/rancher/v2.x/en/backups/backups/_index.md b/content/rancher/v2.x/en/backups/backups/_index.md index 750477f8fcb..aaf8226cd97 100644 --- a/content/rancher/v2.x/en/backups/backups/_index.md +++ b/content/rancher/v2.x/en/backups/backups/_index.md @@ -9,3 +9,5 @@ This section contains information about how to create backups of your Rancher da - [Single Node Install Backups](./single-node-backups/) - [High Availability Install Backups](./ha-backups/) + +If you are looking to back up your [Rancher launched Kubernetes cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), please refer [here]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/). diff --git a/content/rancher/v2.x/en/backups/restorations/_index.md b/content/rancher/v2.x/en/backups/restorations/_index.md index ccfb75a22e8..7dc3294f1bd 100644 --- a/content/rancher/v2.x/en/backups/restorations/_index.md +++ b/content/rancher/v2.x/en/backups/restorations/_index.md @@ -6,3 +6,5 @@ If you lose the data on your Rancher Server, you can restore it if you have back - [Restoring Backups—Single Node Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/single-node-restoration/) - [Restoring Backups—High Availability Installs]({{< baseurl >}}/rancher/v2.x/en/backups/restorations/ha-restoration/) + +If you are looking to restore your [Rancher launched Kubernetes cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/), please refer [here]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/). diff --git a/content/rancher/v2.x/en/catalog/_index.md b/content/rancher/v2.x/en/catalog/_index.md index a4461b48260..57d577713a2 100644 --- a/content/rancher/v2.x/en/catalog/_index.md +++ b/content/rancher/v2.x/en/catalog/_index.md @@ -144,3 +144,11 @@ In Rancher, applications are deployed from the templates in a catalog. Rancher s * [Multi-cluster applications]({{< baseurl >}}/rancher/v2.x/en/catalog/multi-cluster-apps/) * [Applications deployed in a specific Project]({{< baseurl >}}/rancher/v2.x/en/catalog/apps) + +## Global DNS + +_Available as v2.2.0_ + +When creating applications that span multiple Kubernetes clusters, a Global DNS entry can be created to route traffic to the endpoints in all of the different clusters. An external DNS server will need be programmed to assign a fully qualified domain name (a.k.a FQDN) to your application. Rancher will use the FQDN you provide and the IP addresses where your application is running to program the DNS. Rancher will gather endpoints from all the Kubernetes clusters running your application and program the DNS. + +For more information on how to use this feature, see [Global DNS]({{< baseurl >}}/rancher/v2.x/en/admin-settings/globaldns/). diff --git a/content/rancher/v2.x/en/admin-settings/globaldns/_index.md b/content/rancher/v2.x/en/catalog/globaldns/_index.md similarity index 99% rename from content/rancher/v2.x/en/admin-settings/globaldns/_index.md rename to content/rancher/v2.x/en/catalog/globaldns/_index.md index 4e64e7aeafb..b70643d86c1 100644 --- a/content/rancher/v2.x/en/admin-settings/globaldns/_index.md +++ b/content/rancher/v2.x/en/catalog/globaldns/_index.md @@ -1,6 +1,6 @@ --- title: Global DNS -weight: 1145 +weight: 5010 --- _Available as of v2.2.0_ diff --git a/content/rancher/v2.x/en/cluster-admin/_index.md b/content/rancher/v2.x/en/cluster-admin/_index.md index 81b13b1540f..7ad6b56ebf8 100644 --- a/content/rancher/v2.x/en/cluster-admin/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/_index.md @@ -55,7 +55,7 @@ After clusters have been [provisioned into Rancher]({{< baseurl >}}/rancher/v2.x | [Cloning Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cloning-clusters/)| | * | * | | [Ability to rotate certificates]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/certificate-rotation/) | * | | | | [Ability to back up your Kubernetes Clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/) | * | | | -| [Recovering etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/recovering-etcd/) | * | | | +| [Ability to recover and restore etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/) | * | | | | [Cleaning Kubernetes components when clusters are no longer reachable from Rancher]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/cleaning-cluster-nodes/) | * | | | ## Configuring Tools diff --git a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md index 94b2df550e4..abd405351fb 100644 --- a/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/backing-up-etcd/_index.md @@ -9,9 +9,12 @@ In the Rancher UI, etcd backup and recovery for [Rancher launched Kubernetes clu Rancher recommends enabling the ability to set up recurring snapshots, but one-time snapshots can easily be taken as well. +>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, you must [edit the existing cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and save it in order to enable the new snapshot features. Even if you had already enabled snapshots prior to v2.2.0, you must do this step as the old snapshots will not be available to [back up and restore etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/restoring-etcd/). + ## Configuring Recurring Snapshots for the Cluster -By default, any [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) are enabled to take recurring snapshots that are saved locally. If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, you can enable recurring snapshots by editing the existing cluster. +By default, any [Rancher launched Kubernetes clusters]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning/rke-clusters/) are enabled to take recurring snapshots that are saved locally. + During cluster provisioning or editing the cluster, the configuration about snapshots are in the advanced section for **Cluster Options**. Click on **Show advanced options**. diff --git a/content/rancher/v2.x/en/cluster-admin/recovering-etcd/_index.md b/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md similarity index 89% rename from content/rancher/v2.x/en/cluster-admin/recovering-etcd/_index.md rename to content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md index 3f15a194e89..81517fef33c 100644 --- a/content/rancher/v2.x/en/cluster-admin/recovering-etcd/_index.md +++ b/content/rancher/v2.x/en/cluster-admin/restoring-etcd/_index.md @@ -1,5 +1,5 @@ --- -title: Recovering etcd +title: Restoring etcd weight: 2050 --- @@ -9,6 +9,8 @@ etcd backup and recovery for [Rancher launched Kubernetes clusters]({{< baseurl Rancher recommends enabling the [ability to set up recurring snapshots of etcd]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/#configuring-recurring-snapshots-for-the-cluster), but [one-time snapshots]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/#one-time-snapshots) can easily be taken as well. Rancher allows restore from [saved snapshots](##restoring-your-cluster-from-a-snapshot) or if you don't have any snapshots, you can still [restore etcd](#recovering-etcd-without-a-snapshot). +>**Note:** If you have any Rancher launched Kubernetes clusters that were created prior to v2.2.0, you must [edit the existing cluster]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/editing-clusters/) and save it in order to [enable the new snapshot features]({{< baseurl >}}/rancher/v2.x/en/cluster-admin/backing-up-etcd/). Even if you had already enabled snapshots prior to v2.2.0, you must do this step as the old snapshots will not be available to back up and restore etcd. + ## Viewing Available Snapshots The list of all available snapshots for the cluster is available. diff --git a/content/rancher/v2.x/en/installation/requirements/_index.md b/content/rancher/v2.x/en/installation/requirements/_index.md index e60b199ffa4..0a79919978e 100644 --- a/content/rancher/v2.x/en/installation/requirements/_index.md +++ b/content/rancher/v2.x/en/installation/requirements/_index.md @@ -8,6 +8,7 @@ Whether you're configuring Rancher to run in a single-node or high-availability {{% tabs %}} {{% tab "Operating Systems and Docker" %}} +
Rancher is tested on the following operating systems and their subsequent non-major releases with a supported version of [Docker](https://www.docker.com/). * Ubuntu 16.04 (64-bit) @@ -33,91 +34,44 @@ sudo ros engine switch docker-18.09.2 ``` [Docker Documentation: Installation Instructions](https://docs.docker.com/) - +
+
{{% /tab %}} {{% tab "Hardware" %}} +
Hardware requirements scale based on the size of your Rancher deployment. Provision each individual node according to the requirements. + **[HA Node]({{< baseurl >}}/rancher/v2.x/en/installation/ha/create-nodes-lb/) Requirements** - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Deployment SizeClustersNodesvCPUsRAM
SmallUp to 5Up to 5028GB
MediumUp to 15Up to 200416GB
LargeUp to 50Up to 500832GB
X-LargeUp to 100Up to 100032128GB
XX-Large100+1000+ Contact Rancher
+ +Deployment Size | Clusters | Nodes | vCPUs | RAM | +--- | --- | --- | --- | --- | +Small | Up to 5 | Up to 50 | 2 | 8 GB | +Medium | Up to 15 | Up to 200 | 4 | 16 GB | +Large | Up to 50 | Up to 500 | 8 | 32 GB | +X-Large | Up to 100 | Up to 1000 | 32 | 128 GB | +XX-Large | 100+ | 1000+ | [Contact Rancher](https://rancher.com/contact/) | [Contact Rancher](https://rancher.com/contact/) | + +
**[Single Node]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/) Requirements** - - - - - - - - - - - - - - - - - - - - - - -
Deployment SizeClustersNodesvCPUsRAM
SmallUp to 5Up to 5014GB
MediumUp to 15Up to 20028GB
+ +Deployment Size | Clusters | Nodes | vCPUs | RAM | +--- | --- | --- | --- | --- | +Small | Up to 5 | Up to 50 | 1 | 4 GB | +Medium | Up to 15 | Up to 200 | 2 | 8 GB |
{{% /tab %}} {{% tab "Networking" %}} +
-

Node IP address

+### Node IP Address Each node used (either for the Single Node Install, High Availability (HA) Install or nodes that are used in clusters) should have a static IP configured. In case of DHCP, the nodes should have a DHCP reservation to make sure the node gets the same IP allocated. -

Port requirements

+### Port Requirements When deploying Rancher in an HA cluster, certain ports on your nodes must be open to allow communication with Rancher. The ports that must be open change according to the type of machines hosting your cluster nodes. For example, if your are deploying Rancher on nodes hosted by an infrastructure, port `22` must be open for SSH. The following diagram depicts the ports that are opened for each [cluster type]({{< baseurl >}}/rancher/v2.x/en/cluster-provisioning). @@ -125,7 +79,6 @@ When deploying Rancher in an HA cluster, certain ports on your nodes must be ope ![Basic Port Requirements]({{< baseurl >}}/img/rancher/port-communications.svg) - {{< requirements_ports_rancher >}} {{< requirements_ports_rke >}} {{< ports_aws_securitygroup_nodedriver >}} diff --git a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md index 8372a9ee509..c80da4b7af3 100644 --- a/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md +++ b/content/rancher/v2.x/en/k8s-in-rancher/pipelines/_index.md @@ -241,6 +241,30 @@ During this initial run, your pipeline is tested, and the following [pipeline co This process takes several minutes. When it completes, you can view each pipeline component from the project **Workloads** tab. +## Pipeline Setting + +When a repository is enabled, a webhook is automatically set in the version control provider. By default, the pipeline is triggered by a **push** event to a repository, but you can modify the event(s) that trigger running the pipeline. + +Available Events: + +* **Push**: Whenever a commit is pushed to the branch in the repository, the pipeline is triggered. +* **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.x/en/k8s-in-rancher/pipelines/example/). + +### Modifying the Event Triggers for the Repository + +1. From the **Global** view, navigate to the project that you want to modify the event trigger for the pipeline. + +1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab. + +1. Find the repository that you want to modify the event triggers. Select the vertical **Ellipsis (...) > Setting**. + +1. Select which event triggers (**Push**, **Pull Request** or **Tag**) you want for the repository. + +1. Click **Save**. + ## Step Types Within each stage, you can add as many steps as you'd like. When there are multiple steps in one stage, they run concurrently. @@ -272,7 +296,7 @@ The **Run Script** step executes arbitrary commands in the workspace inside a sp {{% /tab %}} {{% tab "By YAML" %}} - +
```yaml # example stages: @@ -282,6 +306,7 @@ stages: image: golang shellScript: go build ``` +
{{% /tab %}} {{% /tabs %}} @@ -307,6 +332,7 @@ The **Build and Publish Image** step builds and publishes a Docker image. This p {{% /tab %}} {{% tab "By YAML" %}} +
```yaml # example stages: @@ -329,7 +355,7 @@ PLUGIN_DEBUG | Docker daemon executes in debug mode PLUGIN_MIRROR | Docker daemon registry mirror PLUGIN_INSECURE | Docker daemon allows insecure registries PLUGIN_BUILD_ARGS | Docker build args, a comma separated list - +
{{% /tab %}} {{% /tabs %}} @@ -365,7 +391,7 @@ The **Publish Catalog Template** step publishes a version of a catalog app templ {{% /tab %}} {{% tab "By YAML" %}} - +
You can add **Publish Catalog Template** steps directly in the `.rancher-pipeline.yml` file. Under the `steps` section, add a step with `publishCatalogConfig`. You will provide the following information: @@ -396,6 +422,8 @@ stages: - sourceName: publish-keys sourceKey: DEPLOY_KEY ``` + +
{{% /tab %}} {{% /tabs %}} @@ -417,7 +445,7 @@ This step deploys arbitrary Kubernetes resources to the project. This deployment {{% /tab %}} {{% tab "By YAML" %}} - +
```yaml # example stages: @@ -426,7 +454,7 @@ stages: - applyYamlConfig: path: ./deployment.yaml ``` - +
{{% /tab %}} {{% /tabs %}} @@ -440,7 +468,6 @@ The **Deploy Catalog App** step deploys a catalog app in the project. It will in {{% tabs %}} {{% tab "By UI" %}} -
1. From the **Step Type** drop-down, choose **Deploy Catalog App**. @@ -459,7 +486,7 @@ The **Deploy Catalog App** step deploys a catalog app in the project. It will in {{% /tab %}} {{% tab "By YAML" %}} - +
You can add **Deploy Catalog App** steps directly in the `.rancher-pipeline.yml` file. Under the `steps` section, add a step with `applyAppConfig`. You will provide the following information: @@ -483,6 +510,7 @@ stages: name: testmysql targetNamespace: test ``` +
{{% /tab %}} {{% /tabs %}} @@ -490,27 +518,13 @@ stages: Within a pipeline, there are multiple advanced options for different parts of the pipeline. -- [Pipeline Trigger Rules](#trigger-rules) +- [Trigger Rules](#trigger-rules) - [Environment Variables](#configuring-environment-variables) - [Secrets](#configuring-pipeline-secrets) ### Trigger Rules -When a repository is enabled, a webhook for it is automatically set in the version control system. By default, the project pipeline is triggered by a push event to a specific repository, but you can add (or change) events that trigger a build, such as a pull request or a tagging. When an event type is disabled, pipeline executions will not be triggered by the wehook of that event type. - -To change event triggers for a repository: - -1. From the **Global** view, navigate to the project that you want to configure pipelines. - -1. Select **Workloads** in the navigation bar and then select the Pipelines tab. - -1. From the repository for which you want to change the event triggers, select **Ellipsis (...) > Setting**. - -1. Click on the check box to enable/disable triggering for **Push**, **Pull Request** or **Tag** event. - -1. Click **Save**. - -You can also set trigger rules to have fine-grained control of pipeline executions in pipeline configurations. Trigger rules come in two types: +Trigger rules can be created to have fine-grained control of pipeline executions in your pipeline configuration. Trigger rules come in two types: - **Run this when:** @@ -520,17 +534,18 @@ You can also set trigger rules to have fine-grained control of pipeline executio This type of rule skips the pipeline, stage, or step when a trigger explicitly occurs. -If all conditions evaluate to true, then the pipeline/stage/step is executed. Otherwise it is skipped. When a pipeline is skipped, no execution will be triggered. When a stage/step is skipped, it is considered successful and follow-up stages/steps continue to run. Wildcard character (`*`) expansion is supported in conditions. +If all conditions evaluate to `true`, then the pipeline/stage/step is executed. Otherwise it is skipped. When a pipeline is skipped, none of the pipeline is executed. When a stage/step is skipped, it is considered successful and follow-up stages/steps continue to run. + +Wildcard character (`*`) expansion is supported in `branch` conditions. -#### Pipeline Trigger {{% tabs %}} {{% tab "Pipeline Trigger" %}} -1. From the **Global** view, navigate to the project that you want to configure pipelines. +1. From the **Global** view, navigate to the project that you want to configure a pipeline trigger rule. 1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab. -1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Edit Config**. +1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**. 1. Click on **Show Advanced Options**. @@ -544,21 +559,21 @@ If all conditions evaluate to true, then the pipeline/stage/step is executed. Ot {{% /tab %}} {{% tab "Stage Trigger" %}} -1. From the **Global** view, navigate to the project that you want to configure pipelines. +1. From the **Global** view, navigate to the project that you want to configure a stage trigger rule. 1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab. -1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Edit Config**. +1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**. -1. Find the **stage** that you want to configure a trigger rule for, click the **Edit** icon. +1. Find the **stage** that you want to manage trigger rules, click the **Edit** icon for that stage. 1. Click **Show advanced options**. -1. In the **Trigger Rules** section, configure rules to run or skip the pipeline. +1. In the **Trigger Rules** section, configure rules to run or skip the stage. 1. Click **Add Rule**. - 1. Choose the **Type** that triggers the step and enter a value. + 1. Choose the **Type** that triggers the stage and enter a value. | Type | Value | | ------ | -------------------------------------------------------------------- | @@ -569,17 +584,17 @@ If all conditions evaluate to true, then the pipeline/stage/step is executed. Ot {{% /tab %}} {{% tab "Step Trigger" %}} -1. From the **Global** view, navigate to the project that you want to configure pipelines. +1. From the **Global** view, navigate to the project that you want to configure a stage trigger rule. 1. Select **Workloads** in the navigation bar and then select the **Pipelines** tab. -1. From the pipeline for which you want to edit build triggers, select **Ellipsis (...) > Edit Config**. +1. From the repository for which you want to manage trigger rules, select the vertical **Ellipsis (...) > Edit Config**. -1. Within one of the stages, find the **step** that you want to configure a trigger for, click the **Edit** icon. +1. Find the **step** that you want to manage trigger rules, click the **Edit** icon for that step. 1. Click **Show advanced options**. -1. Add one or more trigger rules. +1. In the **Trigger Rules** section, configure rules to run or skip the step. 1. Click **Add Rule**. @@ -587,12 +602,14 @@ If all conditions evaluate to true, then the pipeline/stage/step is executed. Ot | Type | Value | | ------ | -------------------------------------------------------------------- | - | Branch | The name of the branch that triggers the stage. | - | Event | The type of event that triggers the stage. Values are: `Push`, `Pull Request`, `Tag` | + | Branch | The name of the branch that triggers the step. | + | Event | The type of event that triggers the step. Values are: `Push`, `Pull Request`, `Tag` | 1. Click **Save**. + {{% /tab %}} {{% tab "By YAML" %}} +
```yaml # example stages: @@ -615,6 +632,7 @@ branch: include: [ master, feature/*] exclude: [ dev ] ``` +
{{% /tab %}} {{% /tabs %}} @@ -643,6 +661,7 @@ When configuring a pipeline, certain [step types](#step-types) allow you to use {{% /tab %}} {{% tab "By YAML" %}} +
```yaml # example stages: @@ -655,6 +674,7 @@ stages: FIRST_KEY: VALUE SECOND_KEY: VALUE2 ``` +
{{% /tab %}} {{% /tabs %}} @@ -663,9 +683,11 @@ stages: If you need to use security-sensitive information in your pipeline scripts (like a password), you can pass them in using Kubernetes [secrets]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/secrets/). ->**Prerequisite:** Create a secret in the same project as your pipeline, or explicitly in the namespace where pipeline build pods run. +#### Prerequisite +Create a secret in the same project as your pipeline, or explicitly in the namespace where pipeline build pods run. +
->**Note:** Secret injection is disabled on pull request events. +>**Note:** Secret injection is disabled on [pull request events](#pipeline-setting). {{% tabs %}} {{% tab "By UI" %}} @@ -685,6 +707,7 @@ If you need to use security-sensitive information in your pipeline scripts (like {{% /tab %}} {{% tab "By YAML" %}} +
```yaml # example stages: @@ -699,6 +722,7 @@ stages: sourceKey: secret-key targetKey: ALIAS_ENV ``` +
{{% /tab %}} {{% /tabs %}} diff --git a/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md b/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md index 722918ea5a3..d869a54b726 100644 --- a/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md +++ b/content/rancher/v2.x/en/project-admin/tools/pipelines/_index.md @@ -169,9 +169,9 @@ _Available as of v2.2.0_ **Result:** After the version control provider is authenticated, you will be automatically re-directed to start [configuring which repositories]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#configuring-repositories) that you want start using with a pipeline. Once a repository is enabled, you can start to [configure the pipeline]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/#pipeline-configuration). -## Managing Pipeline Settings +## Managing Global Pipeline Execution Settings -After configuring a version control provider, there are several options that can be configured for all pipelines. +After configuring a version control provider, there are several options that can be configured globally on how [pipelines]({{< baseurl >}}/rancher/v2.x/en/k8s-in-rancher/pipelines/) are executed in Rancher. 1. From the **Global** view, navigate to the project that you want to configure pipelines.