mirror of
https://github.com/rancher/rancher-docs.git
synced 2026-09-25 04:28:15 +00:00
Remove deleted v2.7 docs
This commit is contained in:
vickyhella
-15
@@ -1,15 +0,0 @@
|
||||
---
|
||||
title: Rancher CI/CD 流水线
|
||||
description: 使用 Rancher 的 CI/CD 流水线自动检出代码、运行构建或脚本、发布 Docker 镜像以及向用户部署软件
|
||||
---
|
||||
你可以使用 Rancher 与 GitHub 仓库集成，从而设置持续集成（CI）流水线。
|
||||
|
||||
配置 Rancher 和 GitHub 后，你可以部署运行 Jenkins 的容器来自动化执行流水线：
|
||||
|
||||
- 将应用代码构建为镜像。
|
||||
- 验证构建。
|
||||
- 将构建的镜像部署到集群。
|
||||
- 运行单元测试。
|
||||
- 运行回归测试。
|
||||
|
||||
有关详细信息，请参阅[流水线](../../../pages-for-subheaders/pipelines.md)。
|
||||
-129
@@ -1,129 +0,0 @@
|
||||
---
|
||||
title: 迁移到 Rancher 2.5+ Monitoring
|
||||
---
|
||||
|
||||
如果你在 Rancher 2.5 之前启用了 Monitoring、Alerting 或 Notifiers，则无法自动升级到新的监控/告警解决方案。在 Cluster Explorer 中部署新的监控解决方案之前，你需要禁用并删除整个集群所有项目中的所有自定义告警、通知器和监控安装。
|
||||
|
||||
|
||||
## Rancher 2.5 之前的 Monitoring
|
||||
|
||||
从 2.2.0 开始，旧版 Rancher UI 中的全局视图允许用户在集群内独立启用 Monitoring & Alerting V1（均由 [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) 提供支持）。
|
||||
|
||||
启用 Monitoring 后，Monitoring V1 会将 [Prometheus](https://prometheus.io/) 和 [Grafana](https://grafana.com/docs/grafana/latest/getting-started/what-is-grafana/) 部署到集群上，从而监控集群节点、Kubernetes 组件和软件部署的进程状态，并创建自定义仪表板来简化指标的可视化。
|
||||
|
||||
Monitoring V1 可以在集群级别和项目级别进行配置，并且会自动抓取 Rancher 集群上部署为应用的某些工作负载。
|
||||
|
||||
如果启用了 Alerts 或 Notifiers，Alerting V1 将 [Prometheus Alertmanager](https://prometheus.io/docs/alerting/latest/alertmanager/) 和一组 Rancher 控制器部署到集群上，允许用户定义告警并配置电子邮件、Slack、PagerDuty 等告警通知。用户可以根据需要监控的内容（例如系统服务、资源、CIS 扫描等）创建不同类型的告警。但是，只有在启用 Monitoring V1 时才能创建基于 PromQL 表达式的告警。
|
||||
|
||||
## 通过 Rancher 2.5 中的 Cluster Explorer 进行监控和告警
|
||||
|
||||
从 2.5.0 开始，Rancher 的 Cluster Explorer 允许用户在集群内同时启用 Monitoring & Alerting V2（均由 [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator) 提供支持）。
|
||||
|
||||
与 Monitoring & Alerting V1 不同，现在这两个功能都打包在[此处](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring)的单个 Helm Chart 中。此 Chart 和可配置字段与 Prometheus 社区 Helm Chart [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack) 非常匹配，与上游 Chart 的任何偏差都可以在 [CHANGELOG.md](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring/CHANGELOG.md) 中找到。
|
||||
|
||||
Monitoring V2 只能在集群级别进行配置。不再支持项目级别的监控和告警。
|
||||
|
||||
有关如何配置 Monitoring & Alerting V2 的更多信息，请参阅[此页面](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md)。
|
||||
|
||||
## RBAC 的更改
|
||||
|
||||
默认情况下，项目所有者和成员不再可以访问 Grafana 或 Prometheus。如果只读用户有权访问 Grafana，他们将能够查看任何命名空间的数据。对于 Kiali，任何用户都可以在任何命名空间中编辑不属于该用户的东西。
|
||||
|
||||
有关 `rancher-monitoring` 中 RBAC 的更多信息，请参阅[此页面](../../../integrations-in-rancher/monitoring-and-alerting/rbac-for-monitoring.md)。
|
||||
|
||||
## 从 Monitoring V1 迁移到 Monitoring V2
|
||||
|
||||
虽然没有可用的自动迁移方案，但你可以手动将在 Monitoring V1 中创建的自定义 Grafana 仪表板和告警迁移到 Monitoring V2。
|
||||
|
||||
在安装 Monitoring V2 之前，你需要完全卸载 Monitoring V1。要卸载 Monitoring V1：
|
||||
|
||||
* 删除所有集群和项目特定的告警和告警组。
|
||||
* 删除所有通知。
|
||||
* 禁用**集群 > 项目 > 工具 > Monitoring** 下的所有项目监控安装。
|
||||
* 确保所有项目中的所有项目监控应用都已删除，并且在几分钟后不会重新创建。
|
||||
* 在**集群 > 工具 > Monitoring** 下禁用集群监控安装。
|
||||
* 确保 System 项目中的 cluster-monitoring 应用和 monitoring-operator 应用已被删除，并且在几分钟后不会重新创建。
|
||||
|
||||
#### RKE 模板集群
|
||||
|
||||
要避免重新启用 Monitoring V1，请通过修改 RKE 模板 yaml 来禁用监控以及后续的 RKE 模板修订：
|
||||
|
||||
```yaml
|
||||
enable_cluster_alerting: false
|
||||
enable_cluster_monitoring: false
|
||||
```
|
||||
|
||||
#### 迁移 Grafana 仪表板
|
||||
|
||||
你可以将在 Monitoring V1 中添加到 Grafana 的仪表板迁移到 Monitoring V2。在 Monitoring V1 中，你可以这样导出现有仪表板：
|
||||
|
||||
* 登录 Grafana
|
||||
* 导航到要导出的仪表板
|
||||
* 转到仪表板设置
|
||||
* 复制 [JSON 模型](https://grafana.com/docs/grafana/latest/dashboards/json-model/)
|
||||
|
||||
在 JSON 模型中，将所有 `datasource` 字段从 `RANCHER_MONITORING` 更改为 `Prometheus`。你可以将所有出现的 `"datasource": "RANCHER_MONITORING"` 替换为 `"datasource": "Prometheus"`。
|
||||
|
||||
如果 Grafana 由持久卷支持，你可以将此 JSON 模型[导入](https://grafana.com/docs/grafana/latest/dashboards/export-import/)到 Monitoring V2 Grafana UI 中。
|
||||
建议使用 `cattle-dashboards` 命名空间具有 `grafana_dashboard: "1"` 标签的 ConfigMap，来为 Grafana 提供仪表板：
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: custom-dashboard
|
||||
namespace: cattle-dashboards
|
||||
labels:
|
||||
grafana_dashboard: "1"
|
||||
data:
|
||||
custom-dashboard.json: |
|
||||
{
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
创建此 ConfigMap 后，仪表板将自动添加到 Grafana。
|
||||
|
||||
### 迁移告警
|
||||
|
||||
只有基于表达式的告警能直接迁移到 Monitoring V2。幸运的是，基于事件的告警可以设置为对系统组件、节点或工作负载事件的告警，而 Monitoring V2 中的告警已覆盖这些告警。所以没有必要迁移它们。
|
||||
|
||||
如果要迁移以下表达式告警：
|
||||
|
||||
|
||||
|
||||
你必须在任意命名空间中创建如下 PrometheusRule 配置：
|
||||
|
||||
```yaml
|
||||
apiVersion: monitoring.coreos.com/v1
|
||||
kind: PrometheusRule
|
||||
metadata:
|
||||
name: custom-rules
|
||||
namespace: default
|
||||
spec:
|
||||
groups:
|
||||
- name: custom.rules
|
||||
rules:
|
||||
- alert: Custom Expression Alert
|
||||
expr: prometheus_query > 5
|
||||
for: 5m
|
||||
labels:
|
||||
severity: critical
|
||||
annotations:
|
||||
summary: "The result of prometheus_query has been larger than 5 for 5m. Current value {{ $value }}"
|
||||
```
|
||||
|
||||
或通过 Cluster Explorer 添加 Prometheus Rule：
|
||||
|
||||
|
||||
|
||||
有关如何在 Monitoring V2 中配置 PrometheusRules 的更多详细信息，请参阅 [Monitoring 配置](../../../pages-for-subheaders/monitoring-v2-configuration-guides.md)。
|
||||
|
||||
### 迁移 Notifiers
|
||||
|
||||
Monitoring V1 中没有直接对应 Notifiers 的工作方式。相反，你必须使用 Monitoring V2 中的路由和接收器复制所需的设置。
|
||||
|
||||
|
||||
### 为 RKE 模板用户迁移
|
||||
|
||||
如果集群是使用 RKE 模板管理的，你需要在后续的 RKE 模板修订版中禁用 Monitoring，以防止重新启用旧版 Monitoring。
|
||||
-188
@@ -1,188 +0,0 @@
|
||||
---
|
||||
title: 迁移到 Rancher 2.5 Logging
|
||||
---
|
||||
Rancher 2.5 彻底修改了 Logging 功能。我们现在使用了 Banzai Cloud 的 [logging operator](https://github.com/banzaicloud/logging-operator)，Rancher 配置了此工具以供部署 Logging 使用。
|
||||
|
||||
在新的 Logging 功能的众多特性和变化中，其中一项是取消了项目级别的 Logging 配置。取而代之的是在命名空间级别配置 Logging。集群级日志仍然可用，但配置选项不同。
|
||||
|
||||
## 安装
|
||||
|
||||
要在 Rancher 2.5+ 中安装 Logging，请参阅[安装说明](../../pages-for-subheaders/logging.md#启用-logging)。
|
||||
|
||||
### 名词解释
|
||||
|
||||
在 Rancher 2.5+ 中，你需要在**集群仪表板**中配置 Logging。要在安装 Logging 应用程序后配置 Logging 自定义资源，请转到左侧导航栏并单击 **Logging**。这个菜单的选项可以配置集群和命名空间的 Logging。
|
||||
|
||||
:::note
|
||||
|
||||
Logging 是按集群安装的。你将需要在集群之间切换以配置每个集群的 Logging。
|
||||
|
||||
:::
|
||||
|
||||
对于 Rancher 2.5+ 中的 Logging 应用程序，你需要了解以下四个关键概念：
|
||||
|
||||
1. Outputs
|
||||
|
||||
`Outputs` 是一种配置资源，用于确定收集日志的目的位置。这是存储 ElasticSearch、Kafka 等聚合器设置的地方。`Outputs` 是命名空间资源。
|
||||
|
||||
2. Flows
|
||||
|
||||
`Flows` 是一种配置资源，用于确定日志的收集、过滤和目标位置规则。在一个 Flow 中，你需要配置要收集哪些日志、如何改变或过滤它们，以及将日志发送到哪个 `Output`。`Flows` 是命名空间资源，可以连接到同一命名空间中的 `Output` 或 `ClusterOutput`。
|
||||
|
||||
3. ClusterOutputs
|
||||
|
||||
`ClusterOutputs` 的功能与 `Outputs` 相同，但 ClusterOutput 是集群级别资源。在集群范围内收集日志或要为集群中的所有命名空间提供 `Output` 时，`ClusterOutput` 是必需的。
|
||||
|
||||
4. ClusterFlows
|
||||
|
||||
`ClusterFlows` 的功能与 `Flows` 相同，但 ClusterFlow 是集群级别资源。它们用于为整个集群配置日志收集，而不是在命名空间级别进行逐个配置。`ClusterFlows` 也是定义改变和过滤器的地方，在功能上与 `Flows` 相同。
|
||||
|
||||
## 集群日志
|
||||
|
||||
要在 Rancher 2.5+ 中配置集群级别的 Logging，你需要设置 `ClusterFlow`。此对象定义了日志的来源、要应用的转换或过滤器，以及日志的一个或多个 `Output`。
|
||||
|
||||
:::note 重要提示：
|
||||
|
||||
`ClusterFlow` 必须在 `cattle-logging-system` 命名空间中定义。如果在其他命名空间中定义，`ClusterFlow` 将不起作用。
|
||||
|
||||
:::
|
||||
|
||||
在旧版 Logging 中，如果要收集整个集群的日志，你只需要启用集群级别的 Logging 并定义所需的 `Output`。Rancher 2.5+ Logging 保留了这个基本方法。要复制旧版集群级别日志，请执行以下步骤：
|
||||
|
||||
1. 根据[输出配置](#输出配置)下的说明定义 `ClusterOutput`。
|
||||
2. 创建一个 `ClusterFlow`，确保它在 `cattle-logging-system` 命名空间中创建。
|
||||
1. 删除 `Flow` 定义的所有 _Include_ 和 _Exclude_ 规则。这将确保能收集所有日志。
|
||||
2. 如果不需要，你可以不配置任何过滤器（默认不需要创建）。
|
||||
3. 定义你的集群 `Output`。
|
||||
|
||||
操作完成后，集群中所有源（所有 pod 和所有系统组件）上收集的日志都会发送到定义在 `ClusterFlow` 中的 `Output` 处。
|
||||
|
||||
## 项目日志
|
||||
|
||||
Rancher 2.5+ Logging 不支持项目。换言之，如果要收集运行在项目命名空间中的 pod 日志，你需要为这些命名空间定义 `Flow`。
|
||||
|
||||
要收集指定命名空间的日志，请执行以下步骤：
|
||||
|
||||
1. 根据[输出配置](#输出配置)下的说明定义 `Output` 或 `ClusterOutput`。
|
||||
2. 创建一个 `Flow`，确保它在你要收集日志的命名空间中创建。
|
||||
1. 如果有需要，你可以定义 _Include_ 或 _Exclude_ 规则。如果删除所有规则，则会收集目标命名空间中的所有 pod 日志。
|
||||
2. 如果不需要，你可以不配置任何过滤器（默认不需要创建）。
|
||||
3. 定义你的 Output，可以是 `ClusterOutput` 或 `Output` 对象。
|
||||
|
||||
操作完成后，命名空间中所有源（pod）上收集的日志都会发送到你在 `Flow` 中定义的 `Output` 处。
|
||||
|
||||
:::note
|
||||
|
||||
要收集项目中的日志，请在项目中的每个命名空间中重复上述步骤。你也可以使用通用标签（例如 `project=my-project`）标记你的项目工作负载，并使用 `ClusterFlow` 收集匹配此标签的所有 pod 的日志。
|
||||
|
||||
:::
|
||||
|
||||
## 输出配置
|
||||
旧版 Logging 中有五个日志目标位置可供选择，分别是 Elasticsearch、Splunk、Kafka、Fluentd 和 Syslog。除 Syslog 外，这些目标位置都可用于 2.5+ Logging。
|
||||
|
||||
|
||||
### Elasticsearch
|
||||
|
||||
| 旧版 Logging | 2.5+ Logging | 注意 |
|
||||
|-----------------------------------------------|-----------------------------------|-----------------------------------------------------------|
|
||||
| 端点 | Target -> Host | 确保指定了协议 (https/http) 以及端口。 |
|
||||
| X-Pack Security -> Username | Access -> User | |
|
||||
| X-Pack Security -> Password | Access -> Password | 密码必须存储在密文中。 |
|
||||
| SSL Configuration -> Client Private Key | SSL -> Client Key | 密钥必须存储在密文中。 |
|
||||
| SSL Configuration -> Client Certificate | SSL -> Client Cert | 证书必须存储在密文中。 |
|
||||
| SSL Configuration -> Client Key Password | SSL -> Client Key Pass | 密码必须存储在密文中。 |
|
||||
| SSL Configuration -> Enabled SSL Verification | SSL -> Certificate Authority File | 证书必须存储在密文中。 |
|
||||
|
||||
|
||||
在旧版 Logging 中，索引是根据“索引模式”中的格式自动创建的。在 2.5 Logging 中，默认的操作已更改为记录单个索引。你仍然可以编辑 YAML 并输入以下值，从而在 `Output` 对象上配置索引模式功能：
|
||||
|
||||
```yaml
|
||||
...
|
||||
spec:
|
||||
elasticsearch:
|
||||
...
|
||||
logstash_format: true
|
||||
logstash_prefix: <desired prefix>
|
||||
logstash_dateformat: "%Y-%m-%d"
|
||||
```
|
||||
|
||||
将 `<desired prefix>` 替换为要创建的索引的前缀。在旧版 Logging 中，默认值是集群的名称。
|
||||
|
||||
### Splunk
|
||||
|
||||
| 旧版 Logging | 2.5+ Logging | 注意 |
|
||||
|------------------------------------------|----------------------------------------|----------------------------------------------------------------------------------------|
|
||||
| HEC Configuration -> Endpoint | Target -> Host | 协议（https/http）和端口必须与主机分开定义。 |
|
||||
| HEC Configuration -> Token | Access -> Token | 令牌必须作为密文存储。 |
|
||||
| HEC Configuration -> Index | Edit as YAML -> `index` | `index` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。 |
|
||||
| HEC Configuration -> Source | Edit as YAML -> `source` | `source` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。 |
|
||||
| SSL Configuration -> Client Private Key | Edit as YAML -> `client_key` | `client_key` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（1）。 |
|
||||
| SSL Configuration -> Client Certificate | Edit as YAML -> `client_cert` | `client_cert` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（1）。 |
|
||||
| SSL Configuration -> Client Key Password | _Not Supported_ | 现在不支持为客户端私钥指定密码。 |
|
||||
| SSL Configuration -> SSL Verify | Edit as YAML -> `ca_file` or `ca_path` | `ca_file` 或 `ca_path` 字段必须作为 YAML 键添加到 `spec.splunkHec` 下。详见（2）。 |
|
||||
|
||||
_(1) `client_key` 和 `client_cert` 的值必须分别是密钥和证书文件的路径。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用_。
|
||||
|
||||
_(2) 用户可以配置 `ca_file`（PEM 编码的 CA 证书的路径）或 `ca_path`（包含 PEM 格式的 CA 证书的目录路径）。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用_。
|
||||
|
||||
### Kafka
|
||||
|
||||
| 旧版 Logging | 2.5+ Logging | 注意 |
|
||||
|-----------------------------------------|----------------------------|------------------------------------------------------|
|
||||
| Kafka Configuration -> Endpoint Type | - | 不再支持将 Zookeeper 作为端点类型。 |
|
||||
| Kafka Configuration -> Endpoint | Target -> Brokers | 逗号分隔的 Broker 列表（host:port）。 |
|
||||
| Kafka Configuration -> Topic | Target -> Default Topic | |
|
||||
| SSL Configuration -> Client Private Key | SSL -> SSL Client Cert | 证书必须作为密文存储。 |
|
||||
| SSL Configuration -> Client Certificate | SSL -> SSL Client Cert Key | 密钥必须作为密文存储。 |
|
||||
| SSL Configuration -> CA Certificate PEM | SSL -> SSL CA Cert | 证书必须作为密文存储。 |
|
||||
| SASL Configuration -> Username | Access -> Username | 用户名必须存储在密文中。 |
|
||||
| SASL Configuration -> Password | Access -> Password | 密码必须存储在密文中。 |
|
||||
| SASL Configuration -> Scram Mechanism | Access -> Scram Mechanism | 输入机制为字符串，例如“sha256”或“sha512”。 |
|
||||
|
||||
### Fluentd
|
||||
|
||||
v2.5.2 开始只支持使用“以表单编辑”选项来添加单个 Fluentd 服务器。要添加多个服务器，请将 `Output` 编辑为 YAML 并输入多个服务器。
|
||||
|
||||
| 旧版 Logging | 2.5+ Logging | 注意 |
|
||||
|------------------------------------------|-----------------------------------------------------|----------------------------------------------------------------------|
|
||||
| Fluentd Configuration -> Endpoint | Target -> Host, Port | 分别输入主机和端口。 |
|
||||
| Fluentd Configuration -> Shared Key | Access -> Shared Key | 共享密钥必须存储为密文。 |
|
||||
| Fluentd Configuration -> Username | Access -> Username | 用户名必须存储为密文。 |
|
||||
| Fluentd Configuration -> Password | Access -> Password | 密码必须存储为密文。 |
|
||||
| Fluentd Configuration -> Hostname | Edit as YAML -> `host` | `host` 字段作为 YAML 键设置在 `spec.forward.servers[n]`下。 |
|
||||
| Fluentd Configuration -> Weight | Edit as YAML -> `weight` | `weight` 字段作为 YAML 键设置在 `spec.forward.servers[n]`下。 |
|
||||
| SSL Configuration -> Use TLS | - | 不需要显式启用。定义客户端证书字段即可。 |
|
||||
| SSL Configuration -> Client Private Key | Edit as YAML -> `tls_private_key_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
|
||||
| SSL Configuration -> Client Certificate | Edit as YAML -> `tls_client_cert_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
|
||||
| SSL Configuration -> Client Key Password | Edit as YAML -> `tls_client_private_key_passphrase` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
|
||||
| SSL Configuration -> SSL Verify | Edit as YAML -> `tls_insecure_mode` | `spec.forward` 下的字段设置为 YAML 键。默认：`false`。 |
|
||||
| SSL Configuration -> CA Certificate PEM | Edit as YAML -> `tls_cert_path` | `spec.forward` 下的字段设置为 YAML 键。详见（1）。 |
|
||||
| Enable Gzip Compression | - | 2.5+ Logging 不再支持。 |
|
||||
|
||||
_(1) 这些值将被指定为文件的路径。这些文件必须挂载到 `rancher-logging-fluentd` pod 中才能使用。_
|
||||
|
||||
### Syslog
|
||||
|
||||
从 v2.5.2 开始，使用 2.5+ Logging 的 `Output` 不支持 syslog。
|
||||
|
||||
## 自定义日志字段
|
||||
|
||||
要添加自定义日志字段，你需要将以下 YAML 添加到你的 `Flow` 配置中：
|
||||
|
||||
```yaml
|
||||
...
|
||||
spec:
|
||||
filters:
|
||||
- record_modifier:
|
||||
records:
|
||||
- foo: "bar"
|
||||
```
|
||||
|
||||
（将 `foo: "bar"` 替换为要添加的自定义日志字段）
|
||||
|
||||
## 系统日志
|
||||
|
||||
在旧版 Logging 中，你需要在设置集群 Logging 时选中“包括系统日志”来收集系统组件的日志。在 v2.5+ Logging 中，系统日志可以通过以下两种方式之一来收集：
|
||||
|
||||
1. 收集所有集群日志，不指定任何匹配或排除规则。该设置会收集集群所有容器的日志，其中包括系统日志。
|
||||
2. 通过为系统组件添加匹配规则来专门收集系统日志。要收集的组件决定了具体的匹配规则。
|
||||
@@ -1,286 +0,0 @@
|
||||
---
|
||||
title: 流水线
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
:::note 注意事项
|
||||
|
||||
- Rancher 2.5 开始已弃用基于 Git 的部署流水线。我们建议使用由 [Fleet](../how-to-guides/new-user-guides/deploy-apps-across-clusters/fleet.md) 提供支持的 Rancher Continuous Delivery (CD) 来处理流水线。如需在 Rancher 中访问 Fleet，请单击 <b>☰ > 持续交付</b>。
|
||||
|
||||
- 不再支持 Kubernetes 1.21+ 中的流水线。
|
||||
|
||||
- Fleet 不会取代 Rancher 流水线，只是 Rancher 流水线现在由 Fleet 提供支持。
|
||||
|
||||
:::
|
||||
|
||||
Rancher 的流水线提供了简单的 CI/CD 体验。你可以使用流水线来自动签出代码、运行构建或脚本、发布 Docker 镜像或商店应用，以及将更新的软件部署给用户。
|
||||
|
||||
设置流水线可以帮助开发者快速高效地上线新软件。你可以使用 Rancher 与 GitHub 仓库集成，从而设置持续集成（CI）流水线。
|
||||
|
||||
配置 Rancher 和 GitHub 后，你可以部署运行 Jenkins 的容器来自动化执行流水线：
|
||||
|
||||
- 将应用代码构建为镜像。
|
||||
- 验证构建。
|
||||
- 将构建的镜像部署到集群。
|
||||
- 运行单元测试。
|
||||
- 运行回归测试。
|
||||
|
||||
:::note
|
||||
|
||||
Rancher 的流水线提供简单的 CI/CD 体验，但不提供完整的功能和灵活性，也不能替代你团队正在使用的企业级 Jenkins 或其他 CI 工具。
|
||||
|
||||
:::
|
||||
|
||||
|
||||
## 概念
|
||||
|
||||
有关本节中使用的概念和术语说明，请参阅[此页面](../reference-guides/pipelines/concepts.md)。
|
||||
|
||||
## 流水线的工作原理
|
||||
|
||||
为项目中启用流水线功能后，你可以在每个项目中配置多个流水线。每个流水线都是独一无二的，可以独立配置。
|
||||
|
||||
流水线是由一组签入源代码仓库的文件配置的。用户可以通过 Rancher UI 或通过将 `.rancher-pipeline.yml` 添加到仓库来配置流水线。
|
||||
|
||||
在配置流水线之前，你需要为版本控制提供商（例如 GitHub、GitLab 或 Bitbucket）配置身份验证。如果你还没有配置版本控制提供商，你可以随时使用 [Rancher 的示例仓库](../reference-guides/pipelines/example-repositories.md)来查看常见的流水线部署。
|
||||
|
||||
在项目中配置流水线时，会自动创建一个专门用于该流水线的命名空间。以下组件部署到它：
|
||||
|
||||
- **Jenkins**：
|
||||
|
||||
流水线的构建引擎。由于项目用户不直接与 Jenkins 交互，因此 Jenkins 是被托管和锁定的。
|
||||
|
||||
:::note
|
||||
|
||||
没有使用现有 Jenkins deployment 作为流水线引擎的选项。
|
||||
|
||||
:::
|
||||
|
||||
- **Docker 镜像仓库**：
|
||||
|
||||
内部 Docker 镜像仓库是开箱即用，用于构建到发布步骤的默认目标。你也可以进行配置以推送到远程镜像仓库。内部 Docker 镜像仓库只能从集群节点访问，用户不能直接访问它。镜像不会在流水线的生命周期之外被持久化，并且只能在流水线运行使用。如果你需要在流水线运行之外访问镜像，请将镜像推送到外部镜像仓库。
|
||||
|
||||
- **Minio**：
|
||||
|
||||
Minio 存储用于存储流水线执行的日志。
|
||||
|
||||
:::note
|
||||
|
||||
托管的 Jenkins 实例是无状态工作的，因此你不用担心它的数据持久性。Docker 镜像仓库和 Minio 实例默认使用临时卷，这种做法适用于大多数用例。如果你想确保流水线日志能够在节点故障的情况下也能保存，你可以为它们配置持久卷（参见[流水线组件的数据持久性](../reference-guides/pipelines/configure-persistent-data.md)）。
|
||||
|
||||
:::
|
||||
|
||||
## 流水线的 RBAC
|
||||
|
||||
如果你可以访问项目，则可以启用仓库来开始构建流水线。
|
||||
|
||||
只有[管理员](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)、[集群所有者或成员](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#集群角色)或[项目所有者](../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/cluster-and-project-roles.md#项目角色)可以配置版本控制提供商和管理全局流水线的执行设置。
|
||||
|
||||
项目成员只能配置仓库和流水线。
|
||||
|
||||
## 设置流水线
|
||||
|
||||
### 先决条件
|
||||
|
||||
:::note 旧版功能开关：
|
||||
|
||||
由于流水线应用已被弃用并替换为 Fleet，因此在使用流水线之前，你需要打开旧版功能的功能开关。请注意，我们不再支持 Kubernetes 1.21+ 中的流水线。
|
||||
|
||||
1. 在左上角，单击 **☰ > 全局设置**。
|
||||
1. 单击**功能开关**。
|
||||
1. 转到`旧版应用 `功能开关并单击 **⋮ > 激活**。
|
||||
|
||||
:::
|
||||
|
||||
1. [配置版本控制提供商](#1-配置版本控制提供商)
|
||||
2. [配置仓库](#2-配置仓库)
|
||||
3. [配置流水线](#3-配置流水线)
|
||||
|
||||
### 1. 配置版本控制提供商
|
||||
|
||||
在为仓库配置流水线之前，你必须配置和授权版本控制提供商：
|
||||
|
||||
- GitHub
|
||||
- GitLab
|
||||
- Bitbucket
|
||||
|
||||
在下方选择你的提供商对应的选项卡，然后按照说明进行操作。
|
||||
|
||||
<Tabs>
|
||||
<TabItem value="GitHub">
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 单击**配置**选项卡。
|
||||
1. 按照说明**设置 Github 应用**。Rancher 会将你重定向到 GitHub 以在 GitHub 中设置 OAuth 应用。
|
||||
1. 从 GitHub 复制 **Client ID** 和 **Client Secret**。将它们粘贴到 Rancher 中。
|
||||
1. 如果你使用的是企业版 GitHub，请选择**使用私有 GitHub 企业版安装**。输入 GitHub 安装的主机地址。
|
||||
1. 单击**验证**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="GitLab">
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 单击**配置**选项卡。
|
||||
1. 单击 **GitLab**。
|
||||
1. 按照说明**设置 GitLab 应用**。Rancher 会将你重定向到 GitLab。
|
||||
1. 从 GitLab 复制 **Application ID** 和 **Secret**。将它们粘贴到 Rancher 中。
|
||||
1. 如果你使用的是企业版 GitLab，请选择**使用私有 GitLab 企业版安装**。输入 GitLab 安装的主机地址。
|
||||
1. 单击**验证**。
|
||||
|
||||
:::note 注意事项：
|
||||
|
||||
1. 流水线使用 GitLab [v4 API](https://docs.gitlab.com/ee/api/v3_to_v4.html)，支持的 GitLab 版本为 9.0+。
|
||||
2. 如果你使用 GitLab 10.7+ 并且你的 Rancher 设置位于本地网络中，请在 GitLab 管理设置中启用 **Allow requests to the local network from hooks and services** 选项。
|
||||
|
||||
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Bitbucket Cloud">
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 单击**配置**选项卡。
|
||||
1. 单击 **Bitbucket** 并保留默认选中的**使用 Bitbucket Cloud**。
|
||||
1. 按照说明**设置 Bitbucket Cloud 应用**。Rancher 会将你重定向到 Bitbucket 以在 Bitbucket 中设置 OAuth 使用者。
|
||||
1. 从 Bitbucket 复制使用者 **Key** 和 **Secret**。将它们粘贴到 Rancher 中。
|
||||
1. 单击**验证**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="Bitbucket Server">
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 单击**配置**选项卡。
|
||||
1. 点击 **Bitbucket** 并选择**使用私有 Bitbucket Server 设置**选项。
|
||||
1. 按照说明**设置 Bitbucket Server 应用**。
|
||||
1. 输入 Bitbucket Server 安装的主机地址。
|
||||
1. 单击**验证**。
|
||||
|
||||
:::note
|
||||
|
||||
Bitbucket server 在向 Rancher 发送 webhook 时需要进行 SSL 验证。请确保 Rancher server 的证书被 Bitbucket server 信任。有两种选择：
|
||||
|
||||
1. 使用受信任的 CA 签发的证书来设置 Rancher server。
|
||||
1. 如果你使用的是自签名证书，请将 Rancher server 的证书导入 Bitbucket server。有关说明，请参阅 Bitbucket sever 文档以了解如何[配置自签名证书](https://confluence.atlassian.com/bitbucketserver/if-you-use-self-signed-certificates-938028692.html)。
|
||||
|
||||
:::
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
**结果**：版本控制提供商通过身份验证后，你将被自动重定向以配置你希望使用流水线的仓库。
|
||||
|
||||
### 2. 配置仓库
|
||||
|
||||
授权版本控制提供商后，你将被自动重定向以配置你希望使用流水线的仓库。即使其他人设置了版本控制提供商，你也能看到他们的仓库并构建流水线：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 单击**配置仓库**。
|
||||
|
||||
1. 此处会显示仓库列表。如果你是第一次配置仓库，请单击 **Authorize & Fetch Your Own Repositories** 来获取你的仓库列表。
|
||||
|
||||
1. 在要设置流水线的仓库处单击**启用**。
|
||||
|
||||
1. 启用所有仓库后，单击**完成**。
|
||||
|
||||
**结果**：你有了一个可以配置流水线的仓库列表。
|
||||
|
||||
### 3. 配置流水线
|
||||
|
||||
现在仓库已添加到你的项目中。你可以通过添加自动化阶段和步骤来配置流水线。为方便起见，我们提供了多种用于特有任务的内置步骤类型。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 找到要设置流水线的仓库。
|
||||
1. 通过 UI 或使用仓库中的 YAML 文件（即 `.rancher-pipeline.yml` 或 `.rancher-pipeline.yaml`）配置流水线。流水线配置分为阶段和步骤。必须完全完成阶段后才能进入下一个阶段，但一个阶段中的步骤可以同时运行。你可以在每个阶段中添加不同的步骤类型。请注意，在构建步骤时，会根据步骤类型提供不同的高级选项。高级选项包括触发规则、环境变量和密文。有关通过 UI 或 YAML 文件配置流水线的更多信息，请参阅[流水线配置参考](../reference-guides/pipelines/pipeline-configuration.md)。
|
||||
|
||||
* 如果要使用 UI，请选择 **⋮ > 编辑配置**以使用 UI 配置流水线。配置流水线后，你必须查看 YAML 文件并将其推送到仓库。
|
||||
* 如果你要使用 YAML 文件，请选择 **⋮ > 查看/编辑 YAML** 来配置流水线。如果你使用 YAML 文件，你需要在更改文件后将更新的文件推送到仓库，以便更新仓库中的内容。在编辑流水线配置时，Rancher 需要花一些时间检查现有的流水线配置。
|
||||
|
||||
1. 从分支列表中选择要使用的`分支`。
|
||||
|
||||
1. 可选：设置通知。
|
||||
|
||||
1. 设置流水线的触发规则。
|
||||
|
||||
1. 为流水线输入**超时**。
|
||||
|
||||
1. 配置完所有阶段和步骤后，单击**完成**。
|
||||
|
||||
**结果** ：你的流水线已配置好并可以运行了。
|
||||
|
||||
|
||||
## 流水线配置参考
|
||||
|
||||
参见[此页面](../reference-guides/pipelines/pipeline-configuration.md)以了解如何通过配置流水线实现以下目的：
|
||||
|
||||
- 运行脚本
|
||||
- 构建和发布镜像
|
||||
- 发布应用商店模板
|
||||
- 部署 YAML
|
||||
- 部署商店应用
|
||||
|
||||
配置参考还包括如何配置：
|
||||
|
||||
- 通知
|
||||
- 超时
|
||||
- 触发流水线的规则
|
||||
- 环境变量
|
||||
- 密文
|
||||
|
||||
|
||||
## 运行流水线
|
||||
|
||||
首次运行你的流水线。找到你的流水线并选择 **⋮ > 运行**。
|
||||
|
||||
在此初始运行期间将测试你的流水线。以下流水线组件将作为工作负载部署到你的项目专用于该流水线的命名空间：
|
||||
|
||||
- `docker-registry`
|
||||
- `jenkins`
|
||||
- `minio`
|
||||
|
||||
这个过程需要几分钟。完成后，你可以从项目的**工作负载**选项卡中查看每个流水线组件。
|
||||
|
||||
## 触发流水线
|
||||
|
||||
启用仓库后，会在版本控制提供商中自动设置 webhook。默认情况下，流水线会由 **push** 事件触发到仓库，但你也可以修改触发运行流水线的事件。
|
||||
|
||||
可用事件：
|
||||
|
||||
* **Push**：当提交被推送到仓库中的分支时，触发流水线。
|
||||
* **Pull Request**：对仓库发起 PR 时，触发流水线。
|
||||
* **Tag**：在仓库中创建标签时，触发流水线。
|
||||
|
||||
:::note
|
||||
|
||||
Rancher 的[示例仓库](../reference-guides/pipelines/example-repositories.md)不存在此选项。
|
||||
|
||||
:::
|
||||
|
||||
### 修改仓库的事件触发器
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 找到要修改事件触发器的仓库。选择 **⋮ > 设置**。
|
||||
1. 为仓库选择所需的事件触发器（**Push**、**Pull Request** 或 **Tag**）。
|
||||
1. 单击**保存**。
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: 概念
|
||||
---
|
||||
|
||||
本文解释与流水线相关的常见概念和术语。
|
||||
|
||||
- **流水线**：
|
||||
|
||||
_流水线_ 是一个软件交付过程，它被分成不同的阶段和步骤。设置流水线可以帮助开发者快速高效地上线新软件。Rancher 支持给每个项目单独设置流水线。流水线基于特定的仓库。它定义了构建、测试和部署代码的过程。Rancher 使用的是[流水线即代码](https://jenkins.io/doc/book/pipeline-as-code/)模型。在源代码仓库中，流水线配置以流水线文件表示，文件名为 `.rancher-pipeline.yml` 或 `.rancher-pipeline.yaml`。
|
||||
|
||||
- **阶段**：
|
||||
|
||||
一个流水线阶段由多个步骤组成。阶段按照流水线文件中定义的顺序执行。一个阶段中的步骤是同时执行的。只有上一个阶段中的所有步骤都完成且没有失败时，下一个阶段才会开始。
|
||||
|
||||
- **步骤**：
|
||||
|
||||
流水线步骤在指定阶段内执行。如果一个步骤以 `0` 以外的代码退出，则该步骤失败了。如果某个步骤以此失败代码退出，则整个流水线将失败并终止。
|
||||
|
||||
- **工作空间**：
|
||||
|
||||
工作空间是所有流水线步骤共享的工作目录。在流水线开始时，源代码会被检出到工作空间。每个步骤的命令都会在工作空间中启动。在流水线执行期间，上一步骤的工件将在后续步骤中使用。工作目录是一个临时卷，将在流水线执行完成时使用 executor pod 进行清理。
|
||||
|
||||
通常，流水线阶段包括：
|
||||
|
||||
- **Build**：
|
||||
|
||||
每次将代码签入仓库时，流水线都会自动克隆仓库并构建软件的新迭代。在整个过程中，软件通常通过自动化测试进行审查。
|
||||
|
||||
- **Publish**：
|
||||
|
||||
构建完成后，将构建 Docker 镜像并将其发布到 Docker 镜像仓库，或发布商店应用模板。
|
||||
|
||||
- **Deploy**：
|
||||
|
||||
发布工件后，你将发布你的应用，以便用户开始使用更新后的产品。
|
||||
-95
@@ -1,95 +0,0 @@
|
||||
---
|
||||
title: 为流水线组件配置持久数据
|
||||
---
|
||||
|
||||
import Tabs from '@theme/Tabs';
|
||||
import TabItem from '@theme/TabItem';
|
||||
|
||||
默认情况下，流水线内部的 Docker 镜像仓库和 Minio 工作负载都使用临时卷。这是开箱即用的默认存储方式，能让测试变得更加便利。但如果运行 Docker 镜像仓库或 Minio 的节点出现故障，你将丢失构建镜像和构建日志。在大多数情况下，这不是太大的问题。如果你希望构建镜像和日志能够在节点故障中幸免于难，你可以让 Docker 镜像仓库和 Minio 使用持久卷。
|
||||
|
||||
本节假设你了解持久存储在 Kubernetes 中的工作原理。如需更多信息，请参阅[存储的工作原理](../../how-to-guides/new-user-guides/manage-clusters/create-kubernetes-persistent-storage/manage-persistent-storage/about-persistent-storage.md)。
|
||||
|
||||
:::note 先决条件（适用于 A 和 B）：
|
||||
|
||||
[持久卷](../../pages-for-subheaders/create-kubernetes-persistent-storage.md)必须在集群中可用。
|
||||
|
||||
:::
|
||||
|
||||
### A. 为 Docker 镜像仓库配置持久数据
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
|
||||
1. 找到 `docker-registry` 工作负载并选择 **⋮ > 编辑**。
|
||||
|
||||
1. 滚动到**卷**部分并展开它。从底部的**添加卷**菜单中选择以下选项之一：
|
||||
|
||||
- **添加卷 > 添加新的持久卷（声明）**
|
||||
- **添加卷 > 使用已有的持久卷（声明）**
|
||||
|
||||
1. 完成为内部 Docker 镜像仓库选择持久卷的表单。
|
||||
<Tabs>
|
||||
<TabItem value="添加新的持久卷">
|
||||
|
||||
1. 输入卷声明的**名称**。
|
||||
1. 选择一个卷声明**源**：
|
||||
- 如果你选择**使用存储类来配置新持久卷**，请选择存储类并输入**容量**。
|
||||
- 如果你选择**使用已有的持久卷**，请从下拉列表中选择**持久卷**。
|
||||
1. 从**自定义**中，选择卷的读/写访问权限。
|
||||
1. 单击**定义**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="使用已有的持久卷">
|
||||
|
||||
1. 输入卷声明的**名称**。
|
||||
1. 从下拉列表中选择**持久卷声明**。
|
||||
1. 从**自定义**中，选择卷的读/写访问权限。
|
||||
1. 单击**定义**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
1. 在**挂载点**字段中，输入 `/var/lib/registry`，这是 Docker 镜像仓库容器内的数据存储路径。
|
||||
|
||||
1. 点击**升级**。
|
||||
|
||||
### B. 为 Minio 配置持久数据
|
||||
|
||||
1. 点击 **☰ > 集群管理**。
|
||||
1. 选择你创建的集群，并点击 **Explore**。
|
||||
1. 点击**工作负载**。
|
||||
1. 转到 `minio` 工作负载并选择 **⋮ > 编辑**。
|
||||
|
||||
1. 滚动到**卷**部分并展开它。从底部的**添加卷**菜单中选择以下选项之一：
|
||||
|
||||
- **添加卷 > 添加新的持久卷（声明）**
|
||||
- **添加卷 > 使用已有的持久卷（声明）**
|
||||
|
||||
1. 完成为内部 Docker 镜像仓库选择持久卷的表单。
|
||||
<Tabs>
|
||||
<TabItem value="添加新的持久卷">
|
||||
|
||||
1. 输入卷声明的**名称**。
|
||||
1. 选择一个卷声明**源**：
|
||||
- 如果你选择**使用存储类来配置新持久卷**，请选择存储类并输入**容量**。
|
||||
- 如果你选择**使用已有的持久卷**，请从下拉列表中选择**持久卷**。
|
||||
1. 从**自定义**中，选择卷的读/写访问权限。
|
||||
1. 单击**定义**。
|
||||
|
||||
</TabItem>
|
||||
<TabItem value="使用已有的持久卷">
|
||||
|
||||
1. 输入卷声明的**名称**。
|
||||
1. 从下拉列表中选择**持久卷声明**。
|
||||
1. 从**自定义**中，选择卷的读/写访问权限。
|
||||
1. 单击**定义**。
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
1. 在**挂载点**字段中，输入 `/data`，这是 Minio 容器内的数据存储路径。
|
||||
|
||||
1. 点击**升级**。
|
||||
|
||||
**结果**：已为你的流水线组件配置了持久存储。
|
||||
-89
@@ -1,89 +0,0 @@
|
||||
---
|
||||
title: 示例仓库
|
||||
---
|
||||
|
||||
Rancher 附带了几个示例仓库，你可以通过这些仓库来熟悉流水线（pipeline）。在生产环境中为你的仓库使用流水线之前，我们建议你先配置和测试与你的环境最相似的示例仓库。你可以把这个示例仓库用作沙盒来配置仓库和构建演示等。Rancher 包含以下示例仓库：
|
||||
|
||||
- Go
|
||||
- Maven
|
||||
- php
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
- 示例仓库仅在你没有[配置版本控制提供商](../../how-to-guides/advanced-user-guides/manage-projects/ci-cd-pipelines.md)时可用。
|
||||
- 由于流水线应用已被弃用并替换为 Fleet，因此在使用流水线之前，你需要打开旧版功能的功能开关。
|
||||
- 请注意，我们不再支持 Kubernetes 1.21+ 中的流水线。
|
||||
|
||||
1. 在左上角，单击 **☰ > 全局设置**。
|
||||
1. 单击**功能开关**。
|
||||
1. 转到`旧版应用 `功能开关并单击 **⋮ > 激活**。
|
||||
|
||||
:::
|
||||
|
||||
要开始使用这些示例仓库：
|
||||
|
||||
1. [启用示例仓库](#1-启用示例仓库)
|
||||
2. [查看示例流水线](#2-查看示例流水线)
|
||||
3. [运行示例流水线](#3-运行示例流水线)
|
||||
|
||||
### 1. 启用示例仓库
|
||||
|
||||
默认情况下，示例流水线仓库是禁用的。你可以启用一个（或多个）示例仓库来测试流水线功能，并查看流水线的工作原理。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 在**流水线**选项卡中，单击**配置仓库**。
|
||||
|
||||
:::note
|
||||
|
||||
示例仓库仅在你尚未 fetch 你自己的仓库时显示。
|
||||
|
||||
:::
|
||||
|
||||
1. 单击某个示例仓库（例如 `https://github.com/rancher/pipeline-example-go.git`）的**启用**按钮。然后单击**完成**。
|
||||
|
||||
**结果**：
|
||||
|
||||
- **流水线**选项卡中启用了示例仓库以使用流水线。
|
||||
|
||||
- 以下工作负载被部署到新命名空间：
|
||||
|
||||
- `docker-registry`
|
||||
- `jenkins`
|
||||
- `minio`
|
||||
|
||||
### 2. 查看示例流水线
|
||||
|
||||
启用示例仓库后，查看流水线的配置：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 在**流水线**选项卡中，单击**配置仓库**。
|
||||
1. 找到示例仓库，然后选择 **⋮ > 编辑配置**。查看流水线有两种方式：
|
||||
* **Rancher UI**：点击**编辑配置**或**查看/编辑 YAML** 以查看流水线的阶段和步骤。YAML 视图会显示 `./rancher-pipeline.yml` 文件。
|
||||
|
||||
### 3. 运行示例流水线
|
||||
|
||||
启用示例仓库后，运行流水线以查看其工作原理。
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 在**流水线**选项卡中，转到流水线并选择 **⋮ > 运行**。
|
||||
|
||||
:::note
|
||||
|
||||
第一次运行流水线时，需要几分钟来拉取相关镜像并预置必要的流水线组件。
|
||||
|
||||
:::
|
||||
|
||||
**结果**：流水线已运行。你可以在日志中查看结果。
|
||||
|
||||
### 后续操作
|
||||
|
||||
有关为仓库设置流水线的详细信息，请[配置版本控制提供商](../../how-to-guides/advanced-user-guides/manage-projects/ci-cd-pipelines.md)、启用仓库并配置流水线。
|
||||
-71
@@ -1,71 +0,0 @@
|
||||
---
|
||||
title: 示例 YAML 文件
|
||||
---
|
||||
|
||||
你可以通过 UI 或使用仓库中的 YAML 文件（即 `.rancher-pipeline.yml` 或 `.rancher-pipeline.yaml`）配置流水线。
|
||||
|
||||
在[流水线配置参考](pipeline-configuration.md)中，我们提供了使用 Rancher UI 或 YAML 来配置每个功能的示例。
|
||||
|
||||
以下是一个完整的 `rancher-pipeline.yml` 示例，供想要直接使用的用户使用：
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Build something
|
||||
# 阶段的条件
|
||||
when:
|
||||
branch: master
|
||||
event: [ push, pull_request ]
|
||||
# 多个步骤并发运行
|
||||
steps:
|
||||
- runScriptConfig:
|
||||
image: busybox
|
||||
shellScript: echo ${FIRST_KEY} && echo ${ALIAS_ENV}
|
||||
# 在容器中为步骤设置环境变量
|
||||
env:
|
||||
FIRST_KEY: VALUE
|
||||
SECOND_KEY: VALUE2
|
||||
# 从项目密文中设置环境变量
|
||||
envFrom:
|
||||
- sourceName: my-secret
|
||||
sourceKey: secret-key
|
||||
targetKey: ALIAS_ENV
|
||||
- runScriptConfig:
|
||||
image: busybox
|
||||
shellScript: date -R
|
||||
# 步骤条件
|
||||
when:
|
||||
branch: [ master, dev ]
|
||||
event: push
|
||||
- name: Publish my image
|
||||
steps:
|
||||
- publishImageConfig:
|
||||
dockerfilePath: ./Dockerfile
|
||||
buildContext: .
|
||||
tag: rancher/rancher:v2.0.0
|
||||
# 可选择推送到远端镜像仓库
|
||||
pushRemote: true
|
||||
registry: reg.example.com
|
||||
- name: Deploy some workloads
|
||||
steps:
|
||||
- applyYamlConfig:
|
||||
path: ./deployment.yaml
|
||||
# 流水线的分支条件
|
||||
branch:
|
||||
include: [ master, feature/*]
|
||||
exclude: [ dev ]
|
||||
# 以分钟为单位的超时
|
||||
timeout: 30
|
||||
notification:
|
||||
recipients:
|
||||
- # Recipient
|
||||
recipient: "#mychannel"
|
||||
# Notifier 的 ID
|
||||
notifier: "c-wdcsr:n-c9pg7"
|
||||
- recipient: "test@example.com"
|
||||
notifier: "c-wdcsr:n-lkrhd"
|
||||
# 选择发送通知的条件
|
||||
condition: ["Failed", "Success", "Changed"]
|
||||
# 覆盖默认消息（可选）
|
||||
message: "my-message"
|
||||
```
|
||||
-633
@@ -1,633 +0,0 @@
|
||||
---
|
||||
title: 流水线配置参考
|
||||
---
|
||||
|
||||
在本文中，你将学习如何配置流水线。
|
||||
|
||||
|
||||
## 步骤类型
|
||||
|
||||
在每个阶段中，你都可以添加任意数量的步骤。一个阶段中的多个步骤会并发运行。
|
||||
|
||||
步骤类型包括：
|
||||
|
||||
- [运行脚本](#步骤类型：运行脚本)
|
||||
- [构建和发布镜像](#步骤类型：构建和发布镜像)
|
||||
- [发布商店应用模板](#步骤类型：发布商店应用模板)
|
||||
- [部署 YAML](#步骤类型：部署-yaml)
|
||||
- [部署商店应用](#步骤类型：部署商店应用)
|
||||
|
||||
<!--
|
||||
### Clone
|
||||
|
||||
The first stage is preserved to be a cloning step that checks out source code from your repo. Rancher handles the cloning of the git repository. This action is equivalent to `git clone <repository_link> <workspace_dir>`.
|
||||
-->
|
||||
|
||||
### 通过 UI 配置步骤
|
||||
|
||||
如果你还没有添加任何阶段，请单击**为此分支配置流水线**以在 UI 中配置流水线。
|
||||
|
||||
1. 通过单击**添加阶段**将阶段添加到流水线执行中。
|
||||
|
||||
1. 输入流水线中各个阶段的**名称**。
|
||||
1. 你可以单击**显示高级选项**来配置[触发阶段的规则](#触发器和触发器规则)。注意，你之后还可以更新它们。
|
||||
|
||||
1. 创建阶段后，单击**添加步骤**来开始[添加步骤](#步骤类型)。你可以向每个阶段添加多个步骤。
|
||||
|
||||
### 通过 YAML 配置步骤
|
||||
|
||||
你可以在每个阶段中添加多个步骤。如需了解如何配置 YAML，请阅读每个[步骤类型](#步骤类型)和高级选项的更多信息。以下是一个小示例，说明如何配置多个阶段，其中各个阶段中都只有一个步骤：
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Build something
|
||||
# 阶段的条件
|
||||
when:
|
||||
branch: master
|
||||
event: [ push, pull_request ]
|
||||
# 多个步骤并发运行
|
||||
steps:
|
||||
- runScriptConfig:
|
||||
image: busybox
|
||||
shellScript: date -R
|
||||
- name: Publish my image
|
||||
steps:
|
||||
- publishImageConfig:
|
||||
dockerfilePath: ./Dockerfile
|
||||
buildContext: .
|
||||
tag: rancher/rancher:v2.0.0
|
||||
# 可选择推送到远端镜像仓库
|
||||
pushRemote: true
|
||||
registry: reg.example.com
|
||||
```
|
||||
# 步骤类型：运行脚本
|
||||
|
||||
**运行脚本**步骤用于在指定容器内的工作空间中执行命令。你可以根据基础镜像提供的实用程序，使用这个步骤来构建、测试，以及执行更多其他操作。为方便起见，你可以使用变量来引用流水线执行的元数据。有关可用变量的列表，请参阅[流水线变量替换参考](#流水线变量替换参考)。
|
||||
|
||||
### 通过 UI 配置脚本
|
||||
|
||||
1. 从**步骤类型**下拉列表中，选择**运行脚本**并填写表单。
|
||||
|
||||
1. 单击**添加**。
|
||||
|
||||
### 通过 YAML 配置脚本
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Build something
|
||||
steps:
|
||||
- runScriptConfig:
|
||||
image: golang
|
||||
shellScript: go build
|
||||
```
|
||||
## 步骤类型：构建和发布镜像
|
||||
|
||||
**构建和发布镜像**步骤用于构建并发布 Docker 镜像。此步骤需要源代码仓库中的 Dockerfile。
|
||||
|
||||
UI 中不提供将镜像发布到不安全镜像仓库的选项。但你可以在 YAML 中指定一个环境变量，从而将镜像发布到不安全的镜像仓库。
|
||||
|
||||
### 通过 UI 配置镜像的构建和发布
|
||||
1. 从**步骤类型**下拉菜单中，选择**构建和发布**。
|
||||
|
||||
1. 完成表单的剩余部分。下面列出了每个字段的说明。完成后，请单击**添加**。
|
||||
|
||||
| 字段 | 描述 |
|
||||
---------|----------|
|
||||
| Dockerfile 路径 | 源代码仓库中 Dockerfile 的相对路径。如果 Dockerfile 位于根目录，则默认路径为 `./Dockerfile`。你可以在不同用例中将其设置为其他路径（例如 `./path/to/myDockerfile`）。 |
|
||||
| 镜像名称 | `name:tag` 格式的镜像名称。不需要填写镜像仓库地址。例如，如果要构建 `example.com/repo/my-image:dev`，请输入 `repo/my-image:dev`。 |
|
||||
| 将镜像推送到远端仓库 | 设置用于发布已构建的镜像的镜像仓库。要使用此选项，请启用它并从下拉列表中选择一个镜像仓库。如果禁用此选项，则将镜像推送到内部镜像仓库。 |
|
||||
| 构建上下文 <br/><br/>（**显示高级选项**） | 默认是源代码的根目录 (`.`)。有关更多详细信息，请参阅 Docker [构建命令文档](https://docs.docker.com/engine/reference/commandline/build/)。 |
|
||||
|
||||
### 通过 YAML 配置镜像的构建和发布
|
||||
|
||||
你可以为 Docker daemon 和构建使用特定参数。UI 中没有开放这些参数，但你能以流水线 YAML 格式配置这些参数，如下例所示。可用的环境变量包括：
|
||||
|
||||
| 变量名称 | 描述 |
|
||||
------------------------|------------------------------------------------------------
|
||||
| PLUGIN_DRY_RUN | 禁用 Docker push |
|
||||
| PLUGIN_DEBUG | Docker daemon 在调试模式下执行 |
|
||||
| PLUGIN_MIRROR | Docker daemon 镜像仓库 mirror |
|
||||
| PLUGIN_INSECURE | Docker daemon 允许不安全的镜像仓库 |
|
||||
| PLUGIN_BUILD_ARGS | Docker 构建参数（逗号分隔的列表） |
|
||||
|
||||
<br/>
|
||||
|
||||
```yaml
|
||||
# 此示例展示了在"推送镜像"步骤中使用的环境变量。
|
||||
# 此变量允许你
|
||||
# 将镜像发布到不安全的镜像仓库：
|
||||
|
||||
stages:
|
||||
- name: Publish Image
|
||||
steps:
|
||||
- publishImageConfig:
|
||||
dockerfilePath: ./Dockerfile
|
||||
buildContext: .
|
||||
tag: repo/app:v1
|
||||
pushRemote: true
|
||||
registry: example.com
|
||||
env:
|
||||
PLUGIN_INSECURE: "true"
|
||||
```
|
||||
|
||||
## 步骤类型：发布商店应用模板
|
||||
|
||||
**发布商店应用模板**步骤将商店应用模板的版本（即 Helm Chart）发布到 Git 托管的镜像仓库。它生成一个 Git commit 并将其推送到你的 chart 仓库。要让这个步骤成功完成，需要源代码仓库中的 Chart 文件夹和专用流水线命名空间中的预配置密文。Chart 文件夹中的任何文件都支持[流水线变量替换参考](#流水线变量替换参考)中的变量。
|
||||
|
||||
### 通过 UI 配置发布商店应用的模板
|
||||
|
||||
1. 从**步骤类型**下拉菜单中，选择**发布商店应用模板**。
|
||||
|
||||
1. 完成表单的剩余部分。下面列出了每个字段的说明。完成后，请单击**添加**。
|
||||
|
||||
| 字段 | 描述 |
|
||||
---------|----------|
|
||||
| Chart 文件夹 | `Chart.yaml` 文件所在的源代码仓库中， chart 文件夹的相对路径。 |
|
||||
| 商店应用模板名称 | 模板的名称。例如，wordpress。 |
|
||||
| 商店应用模板版本 | 你要发布的模板版本，应该和 `Chart.yaml` 文件中定义的版本一致。 |
|
||||
| 协议 | 可以选择使用 HTTP(S) 或 SSH 协议发布。 |
|
||||
| 密文 | 存储 Git 凭证的密文。在添加此步骤之前，你需要在项目的专用流水线命名空间中创建一个密文。如果你使用 HTTP(S) 协议，请将 Git 用户名和密码存储在密文的 `USERNAME` 和 `PASSWORD` 键中。如果你使用 SSH 协议，请将 Git 部署密钥存储在密文的 `DEPLOY_KEY` 中。创建密文后，在此选项中选择它。 |
|
||||
| Git URL | 用于发布模板的 chart 仓库的 Git URL。 |
|
||||
| Git 分支 | 用于发布模板的 chart 仓库的 Git 分支。 |
|
||||
| 提交者姓名 | Commit 消息中使用的提交者姓名。 |
|
||||
| 提交者邮箱 | Commit 消息中使用的提交者邮箱。 |
|
||||
|
||||
|
||||
### 通过 YAML 配置发布商店应用的模板
|
||||
|
||||
你可以直接在 `.rancher-pipeline.yml` 文件中添加**发布商店应用模板**步骤。
|
||||
|
||||
在 `steps` 中，使用 `publishCatalogConfig` 添加一个步骤。你需要提供以下信息：
|
||||
|
||||
* Path：`Chart.yaml` 文件所在的源代码仓库中， chart 文件夹的相对路径。
|
||||
* CatalogTemplate：模板的名称。
|
||||
* Version：你要发布的模板版本，应该和 `Chart.yaml` 文件中定义的版本一致。
|
||||
* GitUrl：用于发布模板的 chart 仓库的 Git URL。
|
||||
* GitBranch：用于发布模板的 chart 仓库的 Git 分支。
|
||||
* GitAuthor：Commit 消息中使用的提交者姓名。
|
||||
* GitEmail：Commit 消息中使用的提交者邮箱。
|
||||
* Credentials：需要通过引用专用流水线命名空间中的密文来提供 Git 凭证。如果你使用 SSH 协议进行发布，请将部署密钥保存在 `DEPLOY_KEY` 环境变量中。如果你使用 HTTP(S) 协议进行发布，请将你的用户名和密码保存在 `USERNAME` 和 `PASSWORD` 环境变量中。
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
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
|
||||
```
|
||||
|
||||
## 步骤类型：部署 YAML
|
||||
|
||||
此步骤将任意 Kubernetes 资源部署到项目中。此部署需要 Kubernetes 清单文件存在于源代码仓库中。清单文件中支持流水线变量替换。你可以在 [GitHub](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml) 中查看示例文件。有关可用变量的列表，请参阅[流水线变量替换参考](#流水线变量替换参考)。
|
||||
|
||||
### 通过 UI 配置 YAML 的部署
|
||||
|
||||
1. 从**步骤类型**下拉列表中，选择**部署 YAML** 并填写表单。
|
||||
|
||||
1. 输入 **YAML 路径**，即源代码中清单文件的路径。
|
||||
|
||||
1. 单击**添加**。
|
||||
|
||||
### 通过 YAML 配置 YAML 的部署
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Deploy
|
||||
steps:
|
||||
- applyYamlConfig:
|
||||
path: ./deployment.yaml
|
||||
```
|
||||
|
||||
## 步骤类型：部署商店应用
|
||||
|
||||
**部署商店应用**步骤用于在项目中部署商店应用。如果应用不存在，则将安装一个新应用，或升级现有应用。
|
||||
|
||||
### 通过 UI 配置商店应用的部署
|
||||
|
||||
1. 从**步骤类型**下拉菜单中，选择**部署商店应用**。
|
||||
|
||||
1. 完成表单的剩余部分。下面列出了每个字段的说明。完成后，请单击**添加**。
|
||||
|
||||
| 字段 | 描述 |
|
||||
---------|----------|
|
||||
| Catalog | 将使用应用模板的商店应用。 |
|
||||
| 模板名称 | 应用模板的名称。例如，wordpress。 |
|
||||
| 模板版本 | 要部署的应用模板的版本。 |
|
||||
| 命名空间 | 要部署应用的目标命名空间。 |
|
||||
| 应用名称 | 要部署的应用的名称。 |
|
||||
| 答案 | 用于部署应用的答案的键值对。 |
|
||||
|
||||
|
||||
### 通过 YAML 配置商店应用的部署
|
||||
|
||||
你可以直接在 `.rancher-pipeline.yml` 文件中添加**部署商店应用**步骤。
|
||||
|
||||
在 `steps` 中，使用 `applyAppConfig` 添加一个步骤。你需要提供以下信息：
|
||||
|
||||
* CatalogTemplate：模板的 ID。你可以单击`启动应用`，并选择该应用的`查看详情`来找到 ID。它是 URL 的最后一部分。
|
||||
* Version：要部署的模板的版本。
|
||||
* Answers：用于部署应用的答案的键值对。
|
||||
* Name：要部署的应用的名称。
|
||||
* TargetNamespace：要部署应用的目标命名空间。
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Deploy App
|
||||
steps:
|
||||
- applyAppConfig:
|
||||
catalogTemplate: cattle-global-data:library-mysql
|
||||
version: 0.3.8
|
||||
answers:
|
||||
persistence.enabled: "false"
|
||||
name: testmysql
|
||||
targetNamespace: test
|
||||
```
|
||||
|
||||
## 超时
|
||||
|
||||
默认情况下，每个流水线执行的超时时间为 60 分钟。如果流水线执行无法在超时期限内完成，则流水线将中止。
|
||||
|
||||
### 通过 UI 配置超时
|
||||
|
||||
在**超时**字段中输入所需的值。
|
||||
|
||||
### 通过 YAML 配置超时
|
||||
|
||||
在 `timeout` 中，输入超时值（以分钟为单位）。
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Build something
|
||||
steps:
|
||||
- runScriptConfig:
|
||||
image: busybox
|
||||
shellScript: ls
|
||||
# 以分钟为单位的超时
|
||||
timeout: 30
|
||||
```
|
||||
|
||||
## 通知
|
||||
|
||||
你可以根据流水线的构建状态，启用对通知器的通知。在启用通知之前，Rancher 建议你先设置通知器，以便立即添加收件人。
|
||||
|
||||
### 通过 UI 配置通知
|
||||
|
||||
1. 在**通知**中，单击**启用**以打开通知。
|
||||
|
||||
1. 选择通知的条件。你可以选择接收以下状态的通知：`失败`、`成功`或`已更改`。例如，如果你想在执行失败时接收通知，请选择**失败**。
|
||||
|
||||
1. 如果你没有现有的通知器，Rancher 会提示未设置通知器的警告，并显示跳转到通知器页面的链接。你可以按照[说明](/versioned_docs/version-2.0-2.4/explanations/integrations-in-rancher/notifiers.md)添加通知器。如果你已经有通知器，你可以单击**添加收件人**按钮，将他们添加到通知中。
|
||||
|
||||
:::note
|
||||
|
||||
通知器是在集群级别配置的，需要不同级别的权限。
|
||||
|
||||
:::
|
||||
|
||||
1. 在下拉列表中为每个收件人选择通知器类型。根据通知器的类型，你可以使用默认收件人或覆盖收件人。例如，如果你有 _Slack_ 通知器，你可以更新通知发送的频道。你可以通过单击**添加收件人**来添加其他通知。
|
||||
|
||||
### 通过 YAML 配置通知
|
||||
|
||||
在 `notification` 中，你需要提供以下信息：
|
||||
|
||||
* **Recipients**：接收通知的通知器/收件人的列表。
|
||||
* **Notifier**：通知器的 ID。你可以先找到通知器，并选择**在 API 中查看**来获取 ID。
|
||||
* **Recipient**：根据通知器的类型，你可以使用“默认收件人”，或使用不同的收件人来覆盖默认收件人。例如，在配置 slack 通知器时，你选择一个频道作为默认收件人，但如果你想将通知发送到不同的频道，你也可以选择不同的收件人。
|
||||
* **Condition**：发送通知的条件。
|
||||
* **Message（可选）**：如果你想更改默认通知消息，你可以在 yaml 中进行编辑。注意：此选项在 UI 中不可用。
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Build something
|
||||
steps:
|
||||
- runScriptConfig:
|
||||
image: busybox
|
||||
shellScript: ls
|
||||
notification:
|
||||
recipients:
|
||||
- # Recipient
|
||||
recipient: "#mychannel"
|
||||
# Notifier 的 ID
|
||||
notifier: "c-wdcsr:n-c9pg7"
|
||||
- recipient: "test@example.com"
|
||||
notifier: "c-wdcsr:n-lkrhd"
|
||||
# 选择发送通知的条件
|
||||
condition: ["Failed", "Success", "Changed"]
|
||||
# 覆盖默认消息（可选）
|
||||
message: "my-message"
|
||||
```
|
||||
|
||||
## 触发器和触发器规则
|
||||
|
||||
配置流水线后，你可以使用不同的方法触发它：
|
||||
|
||||
- **手动**：
|
||||
|
||||
配置流水线后，你可以使用 Rancher UI 中的最新 CI 定义来触发构建。流水线执行被触发后，Rancher 会动态配置一个 Kubernetes pod 来运行你的 CI 任务，然后在完成后将该 Pod 移除。
|
||||
|
||||
- **自动**：
|
||||
|
||||
为流水线启用仓库后，Webhook 会自动添加到版本控制系统中。当项目用户通过推送代码、新建 PR 或创建标签与仓库交互时，版本控制系统会向 Rancher Server 发送一个 webhook，从而触发流水线执行。
|
||||
|
||||
要使用此自动化，仓库需要 webhook 管理权限。因此，当用户进行身份验证并 fetch 仓库时，只会显示他们具有 webhook 管理权限的仓库。
|
||||
|
||||
你可以创建触发规则，从而对流水线配置中的流水线执行进行细粒度控制。触发规则有两种：
|
||||
|
||||
- **Run this when**：在触发器被显式触发时，此类规则将启动流水线、阶段或步骤。
|
||||
|
||||
- **Do Not Run this when**：当触发器被显式触发时，这类规则会跳过流水线、阶段或步骤。
|
||||
|
||||
如果所有条件都评估为 `true`，则执行流水线/阶段/步骤。否则将会跳过。跳过流水线时，不会执行任何流水线。如果一个阶段/步骤被跳过了，它会被认为是成功的，而且后续阶段/步骤会继续运行。
|
||||
|
||||
`branch` 条件支持通配符 (`*`) 扩展。
|
||||
|
||||
### 配置流水线触发器
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 在要管理触发器规则的仓库中，选择 **⋮ > 编辑配置**。
|
||||
1. 点击**显示高级选项**。
|
||||
1. 在**触发器**中，配置规则以运行或跳过流水线。
|
||||
|
||||
1. 单击**添加规则**。在**值**字段中，输入触发流水线的分支名称。
|
||||
|
||||
1. **可选**：添加更多触发构建的分支。
|
||||
|
||||
1. 单击**完成**。
|
||||
|
||||
### 配置阶段触发器
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 在要管理触发器规则的仓库中，选择 **⋮ > 编辑配置**。
|
||||
1. 找到要用于管理触发规则的**阶段**，单击该阶段的**编辑**图标。
|
||||
1. 单击**显示高级选项**。
|
||||
1. 在**触发器**中，配置规则以运行或跳过阶段。
|
||||
|
||||
1. 单击**添加规则**。
|
||||
|
||||
1. 选择触发阶段的**类型**并输入一个值。
|
||||
|
||||
| 类型 | 值 |
|
||||
| ------ | -------------------------------------------------------------------- |
|
||||
| 分支 | 触发阶段的分支名称。 |
|
||||
| 事件 | 触发阶段的事件类型。可选值为 `Push`，`Pull Request` 和 `Tag`。 |
|
||||
|
||||
1. 单击**保存**。
|
||||
|
||||
### 配置步骤触发器
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 在要管理触发器规则的仓库中，选择 **⋮ > 编辑配置**。
|
||||
1. 找到要用于管理触发规则的**步骤**，单击该步骤的**编辑**图标。
|
||||
1. 单击**显示高级选项**。
|
||||
1. 在**触发器**中，配置规则以运行或跳过步骤。
|
||||
|
||||
1. 单击**添加规则**。
|
||||
|
||||
1. 选择触发步骤的**类型**并输入一个值。
|
||||
|
||||
| 类型 | 值 |
|
||||
| ------ | -------------------------------------------------------------------- |
|
||||
| 分支 | 触发步骤的分支名称。 |
|
||||
| 事件 | 触发步骤的事件类型。可选值为 `Push`，`Pull Request` 和 `Tag`。 |
|
||||
|
||||
1. 单击**保存**。
|
||||
|
||||
|
||||
### 通过 YAML 配置触发器
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Build something
|
||||
# 阶段的条件
|
||||
when:
|
||||
branch: master
|
||||
event: [ push, pull_request ]
|
||||
# 多个步骤并发运行
|
||||
steps:
|
||||
- runScriptConfig:
|
||||
image: busybox
|
||||
shellScript: date -R
|
||||
# 步骤条件
|
||||
when:
|
||||
branch: [ master, dev ]
|
||||
event: push
|
||||
# 流水线的分支条件
|
||||
branch:
|
||||
include: [ master, feature/*]
|
||||
exclude: [ dev ]
|
||||
```
|
||||
|
||||
## 环境变量
|
||||
|
||||
配置流水线时，某些[步骤类型](#步骤类型)会允许你使用环境变量来配置步骤的脚本。
|
||||
|
||||
### 通过 UI 配置环境变量
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 找到要编辑构建触发器的流水线，然后选择 **⋮ > 编辑配置**。
|
||||
1. 在其中一个阶段中，找到要为其添加环境变量的**步骤**，然后单击**编辑**图标。
|
||||
1. 单击**显示高级选项**。
|
||||
1. 单击**添加变量**，然后在出现的字段中输入键和值。根据需要添加更多的变量。
|
||||
1. 将你的环境变量添加到脚本或文件中。
|
||||
1. 单击**保存**。
|
||||
|
||||
### 通过 YAML 配置环境变量
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Build something
|
||||
steps:
|
||||
- runScriptConfig:
|
||||
image: busybox
|
||||
shellScript: echo ${FIRST_KEY} && echo ${SECOND_KEY}
|
||||
env:
|
||||
FIRST_KEY: VALUE
|
||||
SECOND_KEY: VALUE2
|
||||
```
|
||||
|
||||
## 密文
|
||||
|
||||
如果你需要在流水线脚本中使用安全敏感信息（如密码），你可以使用 Kubernetes [密文](../../how-to-guides/new-user-guides/kubernetes-resources-setup/secrets.md)来传入这些信息。
|
||||
|
||||
### 先决条件
|
||||
在与流水线相同的项目中创建一个密文，或者在运行流水线构建 pod 的命名空间中显式创建一个密文。
|
||||
<br/>
|
||||
|
||||
:::note
|
||||
|
||||
[PR 事件](#触发器和触发器规则)中的密文传入是禁用的。
|
||||
|
||||
:::
|
||||
|
||||
### 通过 UI 配置密文
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
1. 找到要编辑构建触发器的流水线，然后选择 **⋮ > 编辑配置**。
|
||||
1. 在其中一个阶段中，找到要使用密文的**步骤**，然后单击**编辑**图标。
|
||||
1. 单击**显示高级选项**。
|
||||
1. 单击**使用密文添加**。选择要使用的密文文件。然后选择密钥。或者，你也可以输入密钥的别名。
|
||||
1. 单击**保存**。
|
||||
|
||||
### 通过 YAML 配置密文
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
stages:
|
||||
- name: Build something
|
||||
steps:
|
||||
- runScriptConfig:
|
||||
image: busybox
|
||||
shellScript: echo ${ALIAS_ENV}
|
||||
# 来自项目密文的环境变量
|
||||
envFrom:
|
||||
- sourceName: my-secret
|
||||
sourceKey: secret-key
|
||||
targetKey: ALIAS_ENV
|
||||
```
|
||||
|
||||
## 流水线变量替换参考
|
||||
|
||||
为了方便你的使用，我们提供了以下在流水线配置脚本中可以使用的变量。在流水线执行期间，这些变量会被元数据替换。你可以使用 `${VAR_NAME}` 格式引用这些变量。
|
||||
|
||||
| 变量名称 | 描述 |
|
||||
------------------------|------------------------------------------------------------
|
||||
| `CICD_GIT_REPO_NAME` | 仓库名称（省略 GitHub 组织）。 |
|
||||
| `CICD_GIT_URL` | Git 仓库的 URL。 |
|
||||
| `CICD_GIT_COMMIT` | 正在执行的 Git commit ID。 |
|
||||
| `CICD_GIT_BRANCH` | 此事件的 Git 分支。 |
|
||||
| `CICD_GIT_REF` | 此事件的 Git 参考规范。 |
|
||||
| `CICD_GIT_TAG` | Git 标签名称，在标签事件上设置。 |
|
||||
| `CICD_EVENT` | 触发构建的事件（`push`、`pull_request` 或 `tag`）。 |
|
||||
| `CICD_PIPELINE_ID` | 流水线的 Rancher ID。 |
|
||||
| `CICD_EXECUTION_SEQUENCE` | 流水线的生成号（build number）。 |
|
||||
| `CICD_EXECUTION_ID` | `{CICD_PIPELINE_ID}-{CICD_EXECUTION_SEQUENCE}` 的组合。 |
|
||||
| `CICD_REGISTRY` | 上一个发布镜像步骤的 Docker 镜像仓库地址，可在`部署 YAML` 步骤的 Kubernetes 清单文件中找到。 |
|
||||
| `CICD_IMAGE` | 上一个发布镜像步骤构建的镜像的名称，可在 `Deploy YAML` 步骤的 Kubernetes 清单文件中找到。不包含镜像标签。<br/><br/> [示例](https://github.com/rancher/pipeline-example-go/blob/master/deployment.yaml) |
|
||||
|
||||
## 全局流水线执行设置
|
||||
|
||||
配置版本控制提供商后，你可以在 Rancher 中全局配置流水线的几个执行选项。
|
||||
|
||||
### 更改流水线设置
|
||||
|
||||
:::note 先决条件：
|
||||
|
||||
由于流水线应用已被弃用并替换为 Fleet，因此在使用流水线之前，你需要打开旧版功能的功能开关。请注意，我们不再支持 Kubernetes 1.21+ 中的流水线。
|
||||
|
||||
1. 在左上角，单击 **☰ > 全局设置**。
|
||||
1. 单击**功能开关**。
|
||||
1. 转到`旧版应用 `功能开关并单击 **⋮ > 激活**。
|
||||
|
||||
:::
|
||||
|
||||
要编辑这些设置：
|
||||
|
||||
1. 在左上角，单击 **☰ > 集群管理**。
|
||||
1. 转到要配置流水线的集群，然后单击 **Explore**。
|
||||
1. 在顶部导航栏的下拉菜单中，选择要配置流水线的项目。
|
||||
1. 在左侧导航栏中，单击**旧版应用 > 项目 > 流水线**。
|
||||
|
||||
- [Executor 配额](#executor-配额)
|
||||
- [Executor 的资源配额](#executor-的资源配额)
|
||||
- [自定义 CA](#自定义-ca)
|
||||
|
||||
### Executor 配额
|
||||
|
||||
选择流水线 Executor 的最大数量。_executor 配额_ 决定了项目中可以同时运行多少个构建。如果触发的构建数量超过配额，后续构建将排队并等待空缺。默认情况下，配额为 `2`。如果配置为 `0` 或更小的值，则表示删除配额限制。
|
||||
|
||||
### Executor 的资源配额
|
||||
|
||||
为 Jenkins Agent 容器配置计算资源。当触发流水线执行时，会动态配置构建 pod 以运行你的 CI 任务。在底层，一个构建 pod 由一个 Jenkins Agent 容器和一个用于各个流水线步骤的容器组成。你可以为 pod 中的每个容器[管理计算资源](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/)。
|
||||
|
||||
编辑**内存预留**、**内存限制**、**CPU 预留**或 **CPU 限制**，然后点击**更新限制和预留**。
|
||||
|
||||
要为流水线步骤容器配置计算资源：
|
||||
|
||||
你可以在 `.rancher-pipeline.yml` 文件中为流水线步骤容器配置计算资源。
|
||||
|
||||
在步骤中，你需要提供以下信息：
|
||||
|
||||
* **CPU 预留 (`CpuRequest`)**：对流水线步骤的容器的 CPU 请求。
|
||||
* **CPU 预留 (`CpuRequest`)**：对流水线步骤的容器的 CPU 限制。
|
||||
* **内存预留 (`MemoryRequest`)**：对流水线步骤的容器的内存请求。
|
||||
* **内存限制（`MemoryLimit`）**：对流水线步骤的容器的内存限制。
|
||||
|
||||
```yaml
|
||||
# 示例
|
||||
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 为流水线步骤设置了默认计算资源（`构建和发布镜像`和`运行脚本`步骤除外）。你可以通过指定计算资源来覆盖默认值。
|
||||
|
||||
:::
|
||||
|
||||
### 自定义 CA
|
||||
|
||||
如果你想将版本控制提供商与自定义/内部 CA 根证书一起使用，则需要将 CA 根证书添加到版本控制提供商的配置中，从而让流水线构建 pod 成功运行。
|
||||
|
||||
1. 单击**编辑证书**。
|
||||
|
||||
1. 粘贴 CA 根证书并单击**保存 CA 证书**。
|
||||
|
||||
**结果**：你现在可以使用流水线，而且新的 pod 将能够使用自签名证书。
|
||||
|
||||
# 流水线组件的持久化数据
|
||||
|
||||
默认情况下，内部 Docker 镜像仓库和 Minio 工作负载都使用临时卷。这是开箱即用的默认存储方式，能让测试变得更加便利。但如果运行 Docker 镜像仓库或 Minio 的节点出现故障，你将丢失构建镜像和构建日志。在大多数情况下，这不是太大的问题。如果你希望构建镜像和日志能够在节点故障中幸免于难，你可以让 Docker 镜像仓库和 Minio 使用持久卷。
|
||||
|
||||
有关为流水线设置持久存储的详细信息，请参阅[此页面](configure-persistent-data.md)。
|
||||
|
||||
## 示例 rancher-pipeline.yml
|
||||
|
||||
如果你需要查看示例流水线配置文件，请参见[此页面](example-yaml.md)。
|
||||
Reference in New Issue
Block a user