mirror of
https://github.com/kubesphere/website.git
synced 2025-12-26 17:12:51 +00:00
Update Jenkins Terms in DevOps Docs
Signed-off-by: Felixnoo <felixliu@kubesphere.io>
This commit is contained in:
Felixnoo
parent
32e6349983
commit
85ced9bdd3
|
|
@ -12,7 +12,7 @@ The `agent` section specifies where the entire Pipeline, or a specific stage, wi
|
|||
|
||||
A podTemplate is a template of a Pod that is used to create agents. Users can define a podTemplate to use in the Kubernetes plugin.
|
||||
|
||||
As a pipeline runs, every Jenkins agent Pod must have a container named `jnlp` for communications between the Jenkins master and Jenkins agent. In addition, users can add containers in the podTemplate to meet their own needs. They can choose to use their own Pod YAML to flexibly control the runtime, and the container can be switched by the `container` command. Here is an example.
|
||||
As a pipeline runs, every Jenkins agent Pod must have a container named `jnlp` for communications between the Jenkins controller and Jenkins agent. In addition, users can add containers in the podTemplate to meet their own needs. They can choose to use their own Pod YAML to flexibly control the runtime, and the container can be switched by the `container` command. Here is an example.
|
||||
|
||||
```groovy
|
||||
pipeline {
|
||||
|
|
|
|||
|
|
@ -8,9 +8,9 @@ weight: 11110
|
|||
|
||||
DevOps is a set of practices and tools that automate the processes between IT and software development teams. Among other things, as agile software development sees increasing popularity, continuous integration (CI) and continuous delivery (CD) have become an ideal solution in this connection. In a CI/CD workflow, every integration is tested through automatic building, including coding, releasing and testing. This helps developers to identify any integration errors beforehand and teams can deliver internal software to a production environment with speed, security, and reliability.
|
||||
|
||||
Nevertheless, the traditional master-agent architecture of Jenkins (i.e. multiple agents work for a master) has the following shortcomings.
|
||||
Nevertheless, the traditional controller-agent architecture of Jenkins (i.e. multiple agents work for a controller) has the following shortcomings.
|
||||
|
||||
- The entire CI/CD pipeline will crash once the master goes down.
|
||||
- The entire CI/CD pipeline will crash once the controller goes down.
|
||||
- Resources are not allocated equally as some agents see pipeline jobs wait in queue while others remain idle.
|
||||
- Different agents may be configured in different environments and require different coding languages. The disparity can cause inconvenience in management and maintenance.
|
||||
|
||||
|
|
@ -31,9 +31,9 @@ The KubeSphere DevOps system provides you with the following features:
|
|||
|
||||
### KubeSphere CI/CD pipeline workflows
|
||||
|
||||
A KubeSphere CI/CD pipeline runs on the back of the underlying Kubernetes Jenkins agents. These Jenkins agents can be dynamically scaled as they are dynamically provisioned or released based on the job status. The Jenkins master and agents run as Pods on KubeSphere nodes. The master runs on one of the nodes with its configuration data stored in a volume. Agents run across nodes while they may not be active all the time because they are created dynamically and deleted automatically as needed.
|
||||
A KubeSphere CI/CD pipeline runs on the back of the underlying Kubernetes Jenkins agents. These Jenkins agents can be dynamically scaled as they are dynamically provisioned or released based on the job status. The Jenkins controller and agents run as Pods on KubeSphere nodes. The controller runs on one of the nodes with its configuration data stored in a volume. Agents run across nodes while they may not be active all the time because they are created dynamically and deleted automatically as needed.
|
||||
|
||||
When the Jenkins master receives a building request, it dynamically creates Jenkins agents that run in Pods according to labels. At the same time, Jenkins agents will be registered in the master. After agents finish their jobs, they will be released and related Pods will be deleted as well.
|
||||
When the Jenkins controller receives a building request, it dynamically creates Jenkins agents that run in Pods according to labels. At the same time, Jenkins agents will be registered in the controller. After agents finish their jobs, they will be released and related Pods will be deleted as well.
|
||||
|
||||
### Dynamically provision Jenkins agents
|
||||
|
||||
|
|
@ -43,4 +43,4 @@ The advantages of dynamically provisioning Jenkins agents are:
|
|||
|
||||
**High scalability**. When a KubeSphere cluster has insufficient resources which lead to long waiting time of jobs in the queue, you can add new nodes to the cluster.
|
||||
|
||||
**High availability**. When a Jenkins master fails, KubeSphere automatically creates a new Jenkins master container with the volume mounted to the new container. In this way, the data are secured with high availability achieved for the cluster.
|
||||
**High availability**. When a Jenkins controller fails, KubeSphere automatically creates a new Jenkins controller container with the volume mounted to the new container. In this way, the data are secured with high availability achieved for the cluster.
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ weight: 11250
|
|||
|
||||
podTemplate 是一种 Pod 模板，该 Pod 用于创建 Agent。用户可以定义在 Kubernetes 插件中使用的 podTemplate。
|
||||
|
||||
当流水线运行时，每个 Jenkins Agent Pod 必须具有一个名为 `jnlp` 的容器，用于 Jenkins Master 和 Jenkins Agent 之间进行通信。另外，用户可以在 podTemplate 中添加容器以满足自己的需求。用户可以选择使用自己的 Pod YAML 来灵活地控制运行时环境 (Runtime)，并且可以通过 `container` 命令来切换容器。请参见以下示例。
|
||||
当流水线运行时，每个 Jenkins Agent Pod 必须具有一个名为 `jnlp` 的容器，用于 Jenkins Controller 和 Jenkins Agent 之间进行通信。另外，用户可以在 podTemplate 中添加容器以满足自己的需求。用户可以选择使用自己的 Pod YAML 来灵活地控制运行时环境 (Runtime)，并且可以通过 `container` 命令来切换容器。请参见以下示例。
|
||||
|
||||
```groovy
|
||||
pipeline {
|
||||
|
|
|
|||
|
|
@ -8,9 +8,9 @@ weight: 11110
|
|||
|
||||
DevOps 是一系列做法和工具，可以使 IT 和软件开发团队之间的流程实现自动化。其中，随着敏捷软件开发日趋流行，持续集成 (CI) 和持续交付 (CD) 已经成为该领域一个理想的解决方案。在 CI/CD 工作流中，每次集成都通过自动化构建来验证，包括编码、发布和测试，从而帮助开发者提前发现集成错误，团队也可以快速、安全、可靠地将内部软件交付到生产环境。
|
||||
|
||||
不过，传统的 Jenkins Master-Agent 架构（即多个 Agent 为一个 Master 工作）有以下不足。
|
||||
不过，传统的 Jenkins Controller-Agent 架构（即多个 Agent 为一个 Controller 工作）有以下不足。
|
||||
|
||||
- 如果 Master 宕机，整个 CI/CD 流水线会崩溃。
|
||||
- 如果 Controller 宕机，整个 CI/CD 流水线会崩溃。
|
||||
- 资源分配不均衡，一些 Agent 的流水线任务 (Job) 出现排队等待，而其他 Agent 处于空闲状态。
|
||||
- 不同的 Agent 可能配置环境不同，并需要使用不同的编码语言。这种差异会给管理和维护带来不便。
|
||||
|
||||
|
|
@ -31,9 +31,9 @@ KubeSphere DevOps 系统为您提供以下功能：
|
|||
|
||||
### KubeSphere CI/CD 流水线工作流
|
||||
|
||||
KubeSphere CI/CD 流水线基于底层 Kubernetes Jenkins Agent 而运行。这些 Jenkins Agent 可以动态扩缩，即根据任务状态进行动态供应或释放。Jenkins Master 和 Agent 以 Pod 的形式运行在 KubeSphere 节点上。Master 运行在其中一个节点上，其配置数据存储在一个存储卷 (Volume) 中。Agent 运行在各个节点上，但可能不会一直处于运行状态，而是根据需求动态创建并自动删除。
|
||||
KubeSphere CI/CD 流水线基于底层 Kubernetes Jenkins Agent 而运行。这些 Jenkins Agent 可以动态扩缩，即根据任务状态进行动态供应或释放。Jenkins Controller 和 Agent 以 Pod 的形式运行在 KubeSphere 节点上。Controller 运行在其中一个节点上，其配置数据存储在一个存储卷 (Volume) 中。Agent 运行在各个节点上，但可能不会一直处于运行状态，而是根据需求动态创建并自动删除。
|
||||
|
||||
当 Jenkins Master 收到构建请求，会根据标签动态创建运行在 Pod 中的 Jenkins Agent 并注册到 Master 上。当 Agent 运行完任务后，将会被释放，相关的 Pod 也会被删除。
|
||||
当 Jenkins Controller 收到构建请求，会根据标签动态创建运行在 Pod 中的 Jenkins Agent 并注册到 Controller 上。当 Agent 运行完任务后，将会被释放，相关的 Pod 也会被删除。
|
||||
|
||||
### 动态供应 Jenkins Agent
|
||||
|
||||
|
|
@ -43,4 +43,4 @@ KubeSphere CI/CD 流水线基于底层 Kubernetes Jenkins Agent 而运行。这
|
|||
|
||||
**高可扩缩性**：当 KubeSphere 集群因资源不足而导致任务长时间排队等待时，您可以向集群新增节点。
|
||||
|
||||
**高可用性**：当 Jenkins Master 故障时，KubeSphere 会自动创建一个新的 Jenkins Master 容器，并将存储卷挂载至新创建的容器，保证数据不会丢失，从而实现集群高可用。
|
||||
**高可用性**：当 Jenkins Controller 故障时，KubeSphere 会自动创建一个新的 Jenkins Controller 容器，并将存储卷挂载至新创建的容器，保证数据不会丢失，从而实现集群高可用。
|
||||
Loading…
Reference in New Issue