mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-24 20:18:18 +00:00
pipeline fixes
This commit is contained in:
Denise Schannon
@@ -5,77 +5,72 @@ aliases:
|
||||
- /rancher/v2.x/en/concepts/ci-cd-pipelines/
|
||||
- /rancher/v2.x/en/tasks/pipelines/
|
||||
---
|
||||
>**Notes:**
|
||||
>**Notes:**
|
||||
>
|
||||
>- Pipelines are new and improved for Rancher v2.1! Therefore, if you configured pipelines while using v2.0.x, you'll have to reconfigure them after upgrading to v2.1.
|
||||
>- Still using v2.0.x? See the pipeline documentation for [previous versions]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/docs-for-v2.0.x).
|
||||
|
||||
A _pipeline_ is a software delivery process that is broken into different stages, allowing developers to deliver new software as quickly and efficiently as possible. Within Rancher, you can configure a pipeline for each of your Rancher projects.
|
||||
A _pipeline_ is a software delivery process that is broken into different stages and steps. Setting up a pipeline can help developers deliver new software as quickly and efficiently as possible. Within Rancher, you can configure pipelines for each of your Rancher projects.
|
||||
|
||||
The pipeline stages are:
|
||||
Typically, pipeline stages include:
|
||||
|
||||
- **Build:**
|
||||
- **Build:**
|
||||
|
||||
Each time code is checked into your repository, the pipeline automatically clones the repo and builds a new iteration of your software. Throughout this process, the software is typically reviewed by automated tests.
|
||||
|
||||
- **Publish:**
|
||||
|
||||
After each build is completed, it's automatically published to a Docker registry, where it can be pulled for manual testing.
|
||||
After the build is completed, either a Docker image is built and published to a Docker registry or a catalog template is published.
|
||||
|
||||
- **Deploy:**
|
||||
|
||||
A natural extension of the publish stage, the deploy stage lets you release your software to customers with the click of a button.
|
||||
|
||||
After the artifacts are published, you would release your application so users could start using the updated product.
|
||||
|
||||
## Overview
|
||||
|
||||
Rancher Pipeline provides a simple CI/CD experience. Use it to automatically checkout code, run builds, perform tests, publish docker images, and deploy Kubernetes resources to your clusters.
|
||||
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.
|
||||
|
||||
You can configure a pipeline for each project in Rancher. Every project can have individual configurations and setups.
|
||||
After enabling the ability to use pipelines in a project, you can configure multiple pipelines in each project. Each pipeline is unique and can be configured independently.
|
||||
|
||||
Pipelines are represented as pipeline files that are checked into source code repositories. Users can read and edit the pipeline configuration by either:
|
||||
A pipeline is conifgured off of a group of files that are checked into source code repositories. Users can configure their pipelines either through the Rancher UI or by adding a `.rancher-pipeline.yml` into the repository.
|
||||
|
||||
- Using the Rancher UI.
|
||||
- Updating the configuration in the repository, using tools like Git CLI to trigger a build with the latest CI definition.
|
||||
|
||||
>**Note:** Rancher 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.
|
||||
|
||||
## Supported Version Control Platforms
|
||||
|
||||
Rancher pipelines currently supports GitHub and GitLab (available as of Rancher v2.1.0).
|
||||
Rancher pipelines currently supports a couple of different repositories.
|
||||
|
||||
>**Note:** Additions to pipelines are scoped for future releases of Rancher, such as:
|
||||
>
|
||||
>- Additional version control systems such as BitBucket
|
||||
>- Deployment via Helm charts
|
||||
>- Deployment via Rancher catalog
|
||||
|
||||
| Platform | Available as of |
|
||||
| --- | --- |
|
||||
| GitHub | v2.0.0 |
|
||||
| GitLab | v2.1.0 |
|
||||
| Bitbucket | v2.2.0 |
|
||||
|
||||
## How Pipelines Work
|
||||
|
||||
When you configure a pipeline in one of your projects, a namespace specifically for the pipeline is automatically created. The following components are deployed to it:
|
||||
When you configure a pipeline in one of your projects, a namespace specifically for the pipeline is automatically created. The following components are deployed to it:
|
||||
|
||||
- **Jenkins:**
|
||||
- **Jenkins:**
|
||||
|
||||
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.
|
||||
|
||||
|
||||
<a id="reg"></a>
|
||||
|
||||
- **Docker Registry:**
|
||||
- **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:**
|
||||
|
||||
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.x/en/tools/pipelines/configurations/#data-persistency-for-pipeline-components).
|
||||
|
||||
|
||||
## Pipeline Triggers
|
||||
|
||||
After you configure a pipeline, you can trigger it using different methods:
|
||||
@@ -87,6 +82,6 @@ After you configure a pipeline, you can trigger it using different methods:
|
||||
|
||||
- **Automatically:**
|
||||
|
||||
When you enable a repository for a pipeline, webhooks are automatically added to the version control system. When project users interact with the repo—push code, open pull requests, or create a tag—the version control system sends a webhook to Rancher Server, triggering a pipeline execution.
|
||||
When you enable a repository for a pipeline, webhooks are automatically added to the version control system. When project users interact with the repo—push code, open pull requests, or create a tag—the version control system sends a webhook to Rancher Server, triggering a pipeline execution.
|
||||
|
||||
To use this automation, webhook management permission is required for the repo. Therefore, when users authenticate and fetch their repositories, only those on which they have admin permission will be shown.
|
||||
|
||||
@@ -26,7 +26,6 @@ Initial configuration of a pipeline in a production environment involves complet
|
||||
- [4. Configuring Persistent Data for Pipeline Components](#4-configuring-persistent-data-for-pipeline-components)
|
||||
- [Advanced Configuration](#advanced-configuration)
|
||||
|
||||
|
||||
<!-- /TOC -->
|
||||
|
||||
### 1. Configuring Version Control Providers
|
||||
@@ -41,9 +40,7 @@ Select your provider's tab below and follow the directions.
|
||||
|
||||
1. From the main menu, select **Tools > Pipelines**. In versions prior to v2.2.0, you can select **Resources > Pipelines**.
|
||||
|
||||
1. Follow the directions displayed to setup an OAuth application in GitHub.
|
||||
|
||||
|
||||
1. Follow the directions displayed to **Setup a Github application**. Rancher redirects you to Github to setup an OAuth App in Github.
|
||||
|
||||
1. From GitHub, copy the **Client ID** and **Client Secret**. Paste them into Rancher.
|
||||
|
||||
@@ -51,17 +48,16 @@ Select your provider's tab below and follow the directions.
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
1. Enable the repository for which you want to run a pipeline. Then click **Done**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "GitLab" %}}
|
||||
|
||||
_Available as of v2.1.0_
|
||||
|
||||
1. From the context menu, open the project for which you're configuring a pipeline.
|
||||
|
||||
1. From the main menu, select **Tools > Pipelines**. In versions prior to v2.2.0, you can select **Resources > Pipelines**.
|
||||
|
||||
1. Follow the directions displayed to setup a GitLab application.
|
||||
|
||||
|
||||
1. Follow the directions displayed to **Setup a GitLab application**. Rancher redirects you to GitLab.
|
||||
|
||||
1. From GitLab, copy the **Application ID** and **Secret**. Paste them into Rancher.
|
||||
|
||||
@@ -69,8 +65,6 @@ Select your provider's tab below and follow the directions.
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
1. Enable the repository for which you want to run a pipeline. Then click **Done**.
|
||||
|
||||
>**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.
|
||||
@@ -83,18 +77,14 @@ _Available as of v2.2.0_
|
||||
|
||||
1. From the main menu, select **Tools > Pipelines**.
|
||||
|
||||
1. Choose the **Use public Bitbucket Cloud** option(the default).
|
||||
1. Choose the **Use public Bitbucket Cloud** option.
|
||||
|
||||
1. Follow the directions displayed to setup an OAuth consumer in Bitbucket.
|
||||
|
||||
|
||||
1. Follow the directions displayed to **Setup a Bitbucket Cloud application**. Rancher redirects you to Bitbucket to setup an OAuth consumer in Bitbucket.
|
||||
|
||||
1. From Bitbucket, copy the consumer **Key** and **Secret**. Paste them into Rancher.
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
1. Enable the repository for which you want to run a pipeline. Then click **Done**.
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab "Bitbucket Server" %}}
|
||||
|
||||
@@ -104,18 +94,14 @@ _Available as of v2.2.0_
|
||||
|
||||
1. From the main menu, select **Tools > Pipelines**.
|
||||
|
||||
1. Choose the **Use private Bitbucket Server steup** option.
|
||||
1. Choose the **Use private Bitbucket Server setup** option.
|
||||
|
||||
1. Follow the directions displayed to setup an application link in Bitbucket.
|
||||
|
||||
|
||||
1. Follow the directions displayed to **Setup a Bitbucket Server application**.
|
||||
|
||||
1. Enter the host address of your Bitbucket server installation.
|
||||
|
||||
1. Click **Authenticate**.
|
||||
|
||||
1. Enable the repository for which you want to run a pipeline. Then click **Done**.
|
||||
|
||||
>**Note:**
|
||||
> Bitbucket server needs to do SSL verification when sending webhooks to Rancher. Please ensure that Rancher server's certificate is trusted by the Bitbucket server. There are two options:
|
||||
>
|
||||
@@ -125,18 +111,13 @@ _Available as of v2.2.0_
|
||||
{{% /tab %}}
|
||||
{{% /tabs %}}
|
||||
|
||||
**Result:** A pipeline is added to the project.
|
||||
**Result:** After the version control provider is authenticated, you will be automatically re-directed to start configuring which repositories that you want start using pipelines against. The list of repositories displayed are based on the user that setup the version control provider. Enable which repositories that you want to start using with a pipeline. Then click **Done**. You will be re-directed to the **Workloads > Pipelines** page and can start configuring your pipeline stages and steps.
|
||||
|
||||
<!-- What happens if you change this value while builds are running? -->
|
||||
#### Using Self-Signed-Certificate with Version Control Providers
|
||||
|
||||
#### Integrate with self-signed-certificate version control providers
|
||||
If you want to use a version control provider with a certificate from a custom/internal CA root, the CA root certificates need to be added to the pipeline build pods. After configuring the version control provider, you will need to add the CA root certificate to the setting of the pipeline.
|
||||
|
||||
If you configure your version control providers with a certificate from a custom/internal CA root, the CA root certificates need to be added to Rancher and pipeline build pods.
|
||||
|
||||
|
||||
1. Follow instructions to [use custom CA root certificate]({{< baseurl >}}/rancher/v2.x/en/admin-settings/custom-ca-root-certificate) to set up Rancher.
|
||||
|
||||
1. Follow instructions to [configure your version control providers](#1-configuring-version-control-providers).
|
||||
1. Follow the instructions to [configure your version control providers](#1-configuring-version-control-providers).
|
||||
|
||||
1. From the context menu, open the project for which you're configuring a pipeline.
|
||||
|
||||
@@ -146,7 +127,7 @@ If you configure your version control providers with a certificate from a custom
|
||||
|
||||
1. Paste in the CA root certificates and click **Save cacerts**.
|
||||
|
||||
1. Start using pipelines.
|
||||
**Result:** Pipelines can be used and will be able to work with the self-signed-certificate.
|
||||
|
||||
### 2. Configuring Pipeline Stages and Steps
|
||||
|
||||
@@ -156,11 +137,13 @@ Now that the pipeline is added to your project, you need to configure its automa
|
||||
|
||||
>**Note:** When configuring a pipeline, it takes a few moments for Rancher to check for an existing pipeline configuration.
|
||||
|
||||
1. Click **Configure pipeline for this branch**.
|
||||
1. Select the **branch** you want to configure your pipeline for.
|
||||
|
||||
1. Add stages to your pipeline execution by clicking **Add Stage**.
|
||||
1. If you are not configuring your pipeline using a yaml file, i.e. `.rancher-pipeline.yml`, click **Configure pipeline for this branch**.
|
||||
|
||||
1. Add steps to each stage by clicking **Add a Step**. You can add multiple steps to each stage.
|
||||
1. Add stages to your pipeline execution by clicking **Add Stage**. Select names for each stage of your pipeline.
|
||||
|
||||
1. After the stages are created, start adding steps to each stage by clicking **Add a Step**. You can add multiple steps to each stage.
|
||||
|
||||
>**Note:** As you build out each stage and step, click `Show advanced options` to make [Advanced Configurations](#advanced-configuration), such as rules to trigger or skip pipeline actions, add environment variables, or inject environment variables using secrets. Advanced options are available the pipeline, each stage, and each individual step.
|
||||
|
||||
@@ -255,7 +238,7 @@ PLUGIN_BUILD_ARGS | Docker build args, a comma separated list
|
||||
|
||||
_Available as of v2.2.0_
|
||||
|
||||
The **Publish Catalog Template** step publishes a version of catalog app template(helm chart) to a [git hosted chart repository]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/). It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. [Pipeline variable substitution]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/reference/) is supported for any file in the chart folder.
|
||||
The **Publish Catalog Template** step publishes a version of a catalog app template (i.e. Helm chart) to a [git hosted chart repository]({{< baseurl >}}/rancher/v2.x/en/catalog/custom/). It generates a git commit and pushes it to your chart repository. This process requires a chart folder in your source code's repository and a pre-configured secret in the dedicated pipeline namespace to complete successfully. [Pipeline variable substitution]({{< baseurl >}}/rancher/v2.x/en/tools/pipelines/reference/) is supported for any file in the chart folder.
|
||||
|
||||
{{% tabs %}}
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 62 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 71 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 70 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 50 KiB |
Reference in New Issue
Block a user