Continental Innovates with Rancher and Kubernetes
In this section, you’ll learn how to configure pipelines.
Within each stage, you can add as many steps as you’d like. When there are multiple steps in one stage, they run concurrently.
Step types include:
If you haven’t added any stages, click Configure pipeline for this branch to configure the pipeline through the UI.
Add stages to your pipeline execution by clicking Add Stage.
After you’ve created a stage, start adding steps by clicking Add a Step. You can add multiple steps to each stage.
For each stage, you can add multiple steps. Read more about each step type and the advanced options to get all the details on how to configure the YAML. This is only a small example of how to have multiple stages with a singular step in each stage.
# example stages: - name: Build something # Conditions for stages when: branch: master event: [ push, pull_request ] # Multiple steps run concurrently steps: - runScriptConfig: image: busybox shellScript: date -R - name: Publish my image steps: - publishImageConfig: dockerfilePath: ./Dockerfile buildContext: . tag: rancher/rancher:v2.0.0 # Optionally push to remote registry pushRemote: true registry: reg.example.com
The Run Script step executes arbitrary commands in the workspace inside a specified container. You can use it to build, test and do more, given whatever utilities the base image provides. For your convenience, you can use variables to refer to metadata of a pipeline execution. Please refer to the pipeline variable substitution reference for the list of available variables.
From the Step Type drop-down, choose Run Script and fill in the form.
Click Add.
# example stages: - name: Build something steps: - runScriptConfig: image: golang shellScript: go build
Available as of Rancher v2.1.0
The Build and Publish Image step builds and publishes a Docker image. This process requires a Dockerfile in your source code’s repository to complete successfully.
The option to publish an image to an insecure registry is not exposed in the UI, but you can specify an environment variable in the YAML that allows you to publish an image insecurely.
From the Step Type drop-down, choose Build and Publish.
Fill in the rest of the form. Descriptions for each field are listed below. When you’re done, click Add.
./Dockerfile
./path/to/myDockerfile
name:tag
example.com/repo/my-image:dev
repo/my-image:dev
.
You can use specific arguments for Docker daemon and the build. They are not exposed in the UI, but they are available in pipeline YAML format, as indicated in the example below. Available environment variables include:
# This example shows an environment variable being used # in the Publish Image step. This variable allows you to # publish an image to an insecure registry: stages: - name: Publish Image steps: - publishImageConfig: dockerfilePath: ./Dockerfile buildContext: . tag: repo/app:v1 pushRemote: true registry: example.com env: PLUGIN_INSECURE: "true"
Available as of v2.2.0
The Publish Catalog Template step publishes a version of a catalog app template (i.e. Helm chart) to a git hosted chart repository. 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. Any variables in the pipeline variable substitution reference is supported for any file in the chart folder.
From the Step Type drop-down, choose Publish Catalog Template.
Chart.yaml
USERNAME
PASSWORD
DEPLOY_KEY
You can add Publish Catalog Template steps directly in the .rancher-pipeline.yml file.
.rancher-pipeline.yml
Under the steps section, add a step with publishCatalogConfig. You will provide the following information:
steps
publishCatalogConfig
# example stages: - name: Publish Wordpress Template steps: - publishCatalogConfig: path: ./charts/wordpress/latest catalogTemplate: wordpress version: ${CICD_GIT_TAG} gitUrl: git@github.com:myrepo/charts.git gitBranch: master gitAuthor: example-user gitEmail: user@example.com envFrom: - sourceName: publish-keys sourceKey: DEPLOY_KEY
This step deploys arbitrary Kubernetes resources to the project. This deployment requires a Kubernetes manifest file to be present in the source code repository. Pipeline variable substitution is supported in the manifest file. You can view an example file at GitHub. Please refer to the pipeline variable substitution reference for the list of available variables.
From the Step Type drop-down, choose Deploy YAML and fill in the form.
Enter the YAML Path, which is the path to the manifest file in the source code.
# example stages: - name: Deploy steps: - applyYamlConfig: path: ./deployment.yaml
The Deploy Catalog App step deploys a catalog app in the project. It will install a new app if it is not present, or upgrade an existing one.
From the Step Type drop-down, choose Deploy Catalog App.
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:
applyAppConfig
Launch app
View details
# example stages: - name: Deploy App steps: - applyAppConfig: catalogTemplate: cattle-global-data:library-mysql version: 0.3.8 answers: persistence.enabled: "false" name: testmysql targetNamespace: test
By default, each pipeline execution has a timeout of 60 minutes. If the pipeline execution cannot complete within its timeout period, the pipeline is aborted.
Enter a new value in the Timeout field.
In the timeout section, enter the timeout value in minutes.
timeout
# example stages: - name: Build something steps: - runScriptConfig: image: busybox shellScript: ls # timeout in minutes timeout: 30
You can enable notifications to any notifiers based on the build status of a pipeline. Before enabling notifications, Rancher recommends setting up notifiers so it will be easy to add recipients immediately.
Within the Notification section, turn on notifications by clicking Enable.
Select the conditions for the notification. You can select to get a notification for the following statuses: Failed, Success, Changed. For example, if you want to receive notifications when an execution fails, select Failed.
Failed
Success
Changed
If you don’t have any existing notifiers, Rancher will provide a warning that no notifiers are set up and provide a link to be able to go to the notifiers page. Follow the instructions to add a notifier. If you already have notifiers, you can add them to the notification by clicking the Add Recipient button.
Note: Notifiers are configured at a cluster level and require a different level of permissions.
For each recipient, select which notifier type from the dropdown. Based on the type of notifier, you can use the default recipient or override the recipient with a different one. For example, if you have a notifier for Slack, you can update which channel to send the notification to. You can add additional notifiers by clicking Add Recipient.
In the notification section, you will provide the following information:
notification
# Example stages: - name: Build something steps: - runScriptConfig: image: busybox shellScript: ls notification: recipients: - # Recipient recipient: "#mychannel" # ID of Notifier notifier: "c-wdcsr:n-c9pg7" - recipient: "test@example.com" notifier: "c-wdcsr:n-lkrhd" # Select which statuses you want the notification to be sent condition: ["Failed", "Success", "Changed"] # Ability to override the default message (Optional) message: "my-message"
After you configure a pipeline, you can trigger it using different methods:
Manually:
After you configure a pipeline, you can trigger a build using the latest CI definition from Rancher UI. When a pipeline execution is triggered, Rancher dynamically provisions a Kubernetes pod to run your CI tasks and then remove it upon completion.
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 by pushing code, opening pull requests, or creating 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 repository. Therefore, when users authenticate and fetch their repositories, only those on which they have webhook management permission will be shown.
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: This type of rule starts the pipeline, stage, or step when a trigger explicitly occurs.
Do Not Run this when: 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, none of the pipeline is executed. When a stage/step is skipped, it is considered successful and follow-up stages/steps continue to run.
true
Wildcard character (*) expansion is supported in branch conditions.
*
branch
This section covers the following topics:
From the Global view, navigate to the project that you want to configure a pipeline trigger rule.
Click Resources > Pipelines. In versions prior to v2.3.0, click Workloads > Pipelines.
From the repository for which you want to manage trigger rules, select the vertical ⋮ > Edit Config.
Click on Show Advanced Options.
In the Trigger Rules section, configure rules to run or skip the pipeline.
Click Add Rule. In the Value field, enter the name of the branch that triggers the pipeline.
Optional: Add more branches that trigger a build.
Click Done.
From the Global view, navigate to the project that you want to configure a stage trigger rule.
Find the stage that you want to manage trigger rules, click the Edit icon for that stage.
Click Show advanced options.
In the Trigger Rules section, configure rules to run or skip the stage.
Click Add Rule.
Choose the Type that triggers the stage and enter a value.
Push
Pull Request
Tag
Click Save.
Find the step that you want to manage trigger rules, click the Edit icon for that step.
In the Trigger Rules section, configure rules to run or skip the step.
Choose the Type that triggers the step and enter a value.
# example stages: - name: Build something # Conditions for stages when: branch: master event: [ push, pull_request ] # Multiple steps run concurrently steps: - runScriptConfig: image: busybox shellScript: date -R # Conditions for steps when: branch: [ master, dev ] event: push # branch conditions for the pipeline branch: include: [ master, feature/*] exclude: [ dev ]
When configuring a pipeline, certain step types allow you to use environment variables to configure the step’s script.
From the Global view, navigate to the project that you want to configure pipelines.
From the pipeline for which you want to edit build triggers, select ⋮ > Edit Config.
Within one of the stages, find the step that you want to add an environment variable for, click the Edit icon.
Click Add Variable, and then enter a key and value in the fields that appear. Add more variables if needed.
Add your environment variable(s) into either the script or file.
# example stages: - name: Build something steps: - runScriptConfig: image: busybox shellScript: echo ${FIRST_KEY} && echo ${SECOND_KEY} env: FIRST_KEY: VALUE SECOND_KEY: VALUE2
If you need to use security-sensitive information in your pipeline scripts (like a password), you can pass them in using Kubernetes secrets.
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.
Within one of the stages, find the step that you want to use a secret for, click the Edit icon.
Click Add From Secret. Select the secret file that you want to use. Then choose a key. Optionally, you can enter an alias for the key.
# example stages: - name: Build something steps: - runScriptConfig: image: busybox shellScript: echo ${ALIAS_ENV} # environment variables from project secrets envFrom: - sourceName: my-secret sourceKey: secret-key targetKey: ALIAS_ENV
For your convenience, the following variables are available for your pipeline configuration scripts. During pipeline executions, these variables are replaced by metadata. You can reference them in the form of ${VAR_NAME}.
${VAR_NAME}
CICD_GIT_REPO_NAME
CICD_GIT_URL
CICD_GIT_COMMIT
CICD_GIT_BRANCH
CICD_GIT_REF
CICD_GIT_TAG
CICD_EVENT
push
pull_request
tag
CICD_PIPELINE_ID
CICD_EXECUTION_SEQUENCE
CICD_EXECUTION_ID
{CICD_PIPELINE_ID}-{CICD_EXECUTION_SEQUENCE}
CICD_REGISTRY
Deploy YAML
CICD_IMAGE
After configuring a version control provider, there are several options that can be configured globally on how pipelines are executed in Rancher. These settings can be edited by selecting Tools > Pipelines in the navigation bar. In versions prior to v2.2.0, you can select Resources > Pipelines.
Select the maximum number of pipeline executors. The executor quota decides how many builds can run simultaneously in the project. If the number of triggered builds exceeds the quota, subsequent builds will queue until a vacancy opens. By default, the quota is 2. A value of 0 or less removes the quota limit.
2
0
Configure compute resources for Jenkins agent containers. When a pipeline execution is triggered, a build pod is dynamically provisioned to run your CI tasks. Under the hood, A build pod consists of one Jenkins agent container and one container for each pipeline step. You can manage compute resources for every containers in the pod.
Edit the Memory Reservation, Memory Limit, CPU Reservation or CPU Limit, then click Update Limit and Reservation.
To configure compute resources for pipeline-step containers:
You can configure compute resources for pipeline-step containers in the .rancher-pipeline.yml file.
In a step, you will provide the following information:
CpuRequest
CpuLimit
MemoryRequest
MemoryLimit
# example stages: - name: Build something steps: - runScriptConfig: image: busybox shellScript: ls cpuRequest: 100m cpuLimit: 1 memoryRequest:100Mi memoryLimit: 1Gi - publishImageConfig: dockerfilePath: ./Dockerfile buildContext: . tag: repo/app:v1 cpuRequest: 100m cpuLimit: 1 memoryRequest:100Mi memoryLimit: 1Gi
Note: Rancher sets default compute resources for pipeline steps except for Build and Publish Images and Run Script steps. You can override the default value by specifying compute resources in the same way.
Build and Publish Images
Run Script
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 as part of the version control provider configuration in order for the pipeline build pods to succeed.
Click Edit cacerts.
Paste in the CA root certificates and click Save cacerts.
Result: Pipelines can be used and new pods will be able to work with the self-signed-certificate.
The internal Docker registry and the 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.
For details on setting up persistent storage for pipelines, refer to this page.
An example pipeline configuration file is on this page.