mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-24 20:18:18 +00:00
Merge pull request #1315 from deniseschannon/pipeline
Updates around lots of areas
This commit is contained in:
Denise
@@ -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/).
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Drivers
|
||||
title: Provisioning Drivers
|
||||
weight: 1140
|
||||
---
|
||||
|
||||
|
||||
@@ -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.
|
||||
@@ -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/
|
||||
|
||||
@@ -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/)
|
||||
|
||||
@@ -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/).
|
||||
|
||||
@@ -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/).
|
||||
|
||||
@@ -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/).
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Global DNS
|
||||
weight: 1145
|
||||
weight: 5010
|
||||
---
|
||||
|
||||
_Available as of v2.2.0_
|
||||
@@ -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
|
||||
|
||||
@@ -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**.
|
||||
|
||||
|
||||
+3
-1
@@ -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.
|
||||
@@ -8,6 +8,7 @@ Whether you're configuring Rancher to run in a single-node or high-availability
|
||||
|
||||
{{% tabs %}}
|
||||
{{% tab "Operating Systems and Docker" %}}
|
||||
<br>
|
||||
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/)
|
||||
|
||||
<br>
|
||||
<br>
|
||||
{{% /tab %}}
|
||||
{{% tab "Hardware" %}}
|
||||
<br>
|
||||
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**
|
||||
<table>
|
||||
<tr>
|
||||
<th>Deployment Size</th>
|
||||
<th>Clusters</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPUs</th>
|
||||
<th>RAM</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Small</td>
|
||||
<td>Up to 5</td>
|
||||
<td>Up to 50</td>
|
||||
<td>2</td>
|
||||
<td>8GB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Medium</td>
|
||||
<td>Up to 15</td>
|
||||
<td>Up to 200</td>
|
||||
<td>4</td>
|
||||
<td>16GB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Large</td>
|
||||
<td>Up to 50</td>
|
||||
<td>Up to 500</td>
|
||||
<td>8</td>
|
||||
<td>32GB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>X-Large</td>
|
||||
<td>Up to 100</td>
|
||||
<td>Up to 1000</td>
|
||||
<td>32</td>
|
||||
<td>128GB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>XX-Large</td>
|
||||
<td>100+</td>
|
||||
<td>1000+</td>
|
||||
<td colspan="2"><a href="https://rancher.com/contact/"> Contact Rancher</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
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/) |
|
||||
|
||||
<br>
|
||||
|
||||
**[Single Node]({{< baseurl >}}/rancher/v2.x/en/installation/single-node/) Requirements**
|
||||
<table>
|
||||
<tr>
|
||||
<th>Deployment Size</th>
|
||||
<th>Clusters</th>
|
||||
<th>Nodes</th>
|
||||
<th>vCPUs</th>
|
||||
<th>RAM</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Small</td>
|
||||
<td>Up to 5</td>
|
||||
<td>Up to 50</td>
|
||||
<td>1</td>
|
||||
<td>4GB</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Medium</td>
|
||||
<td>Up to 15</td>
|
||||
<td>Up to 200</td>
|
||||
<td>2</td>
|
||||
<td>8GB</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
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 |
|
||||
|
||||
<br/>
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Networking" %}}
|
||||
<br>
|
||||
|
||||
<h2>Node IP address</h2>
|
||||
### 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.
|
||||
|
||||
<h2>Port requirements</h2>
|
||||
### 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
|
||||
|
||||
|
||||
|
||||
|
||||
{{< requirements_ports_rancher >}}
|
||||
{{< requirements_ports_rke >}}
|
||||
{{< ports_aws_securitygroup_nodedriver >}}
|
||||
|
||||
@@ -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" %}}
|
||||
|
||||
<br>
|
||||
```yaml
|
||||
# example
|
||||
stages:
|
||||
@@ -282,6 +306,7 @@ stages:
|
||||
image: golang
|
||||
shellScript: go build
|
||||
```
|
||||
<br>
|
||||
{{% /tab %}}
|
||||
|
||||
{{% /tabs %}}
|
||||
@@ -307,6 +332,7 @@ The **Build and Publish Image** step builds and publishes a Docker image. This p
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab "By YAML" %}}
|
||||
<br>
|
||||
```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
|
||||
|
||||
<br>
|
||||
{{% /tab %}}
|
||||
|
||||
{{% /tabs %}}
|
||||
@@ -365,7 +391,7 @@ The **Publish Catalog Template** step publishes a version of a catalog app templ
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab "By YAML" %}}
|
||||
|
||||
<br>
|
||||
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
|
||||
```
|
||||
|
||||
<br>
|
||||
{{% /tab %}}
|
||||
|
||||
{{% /tabs %}}
|
||||
@@ -417,7 +445,7 @@ This step deploys arbitrary Kubernetes resources to the project. This deployment
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab "By YAML" %}}
|
||||
|
||||
<br>
|
||||
```yaml
|
||||
# example
|
||||
stages:
|
||||
@@ -426,7 +454,7 @@ stages:
|
||||
- applyYamlConfig:
|
||||
path: ./deployment.yaml
|
||||
```
|
||||
|
||||
<br>
|
||||
{{% /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" %}}
|
||||
<br/>
|
||||
|
||||
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" %}}
|
||||
|
||||
<br>
|
||||
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
|
||||
```
|
||||
<br>
|
||||
{{% /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" %}}
|
||||
<br>
|
||||
```yaml
|
||||
# example
|
||||
stages:
|
||||
@@ -615,6 +632,7 @@ branch:
|
||||
include: [ master, feature/*]
|
||||
exclude: [ dev ]
|
||||
```
|
||||
<br>
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
@@ -643,6 +661,7 @@ When configuring a pipeline, certain [step types](#step-types) allow you to use
|
||||
{{% /tab %}}
|
||||
|
||||
{{% tab "By YAML" %}}
|
||||
<br>
|
||||
```yaml
|
||||
# example
|
||||
stages:
|
||||
@@ -655,6 +674,7 @@ stages:
|
||||
FIRST_KEY: VALUE
|
||||
SECOND_KEY: VALUE2
|
||||
```
|
||||
<br>
|
||||
{{% /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.
|
||||
<br>
|
||||
|
||||
>**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" %}}
|
||||
<br>
|
||||
```yaml
|
||||
# example
|
||||
stages:
|
||||
@@ -699,6 +722,7 @@ stages:
|
||||
sourceKey: secret-key
|
||||
targetKey: ALIAS_ENV
|
||||
```
|
||||
<br>
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user