一、GOCD 一些基础概念
1. Task
任务或构建任务是需要执行的操作。 通常是一个单一的命令
2. Job
- 由多个 Tasks 组成
- 每个任务都是作为一个独立的程序来运行的
- Task 执行方式为顺序执行,Task 之间是相互独立的,即修改的环境变量不会影响到其它 Task
- 一个 Task 失败,则该 Job 失败,除非另有说明,否则其余 Task 将不会运行
3. Stage
- 由多个 Jobs 组成,每个 Job 是独立的
- Job 执行方式为并行,由于 Job 之间是相互独立的,某个 Job 失败后,其它的 Job 会被运行到完成
- 一个 Job 失败,则该 Stage 失败
4. Pipeline
由多个 Stages 组合而成
Stage 执行方式为顺序执行,一个 Stage 失败,将不会执行后续 Stage
一个 Stage 失败,则该 Pipeline 失败
5. Materials and Triggers
使用Git、SVN时,GoCD 可以轮询检测其变更,以触发 Pipeline,也可以手动触发
Pipeline 可以有多个 material(可以简单的理解成代码源),任何一个 material 变更都可以触发 Pipeline
6. Pipeline dependency material
-
Pipeline 和 Pipeline 之间可以产生依赖关系,例如当 Pipeline1 完成之后触发 Pipeline2
-
Pipeline 和Pipeline 之间也可以通过上游 Pipeline 中的某个 Stage 完成后,触发下游 Pipeline 执行
7. Fan-out and fan-in
Fan-out: 一个 material 的完成,触发下游多个 Pipeline ,该 material 不一定是 Pipeline 依赖 material ,可以是任何 material
Fan-in:
- 多个上游 material 触发下游 Pipeline,在触发下游 Pipeline 之前,GoCD 将确保上游 Pipeline 的修订是一致的
如图,git 触发 Pipeline1 和 Pipeline2 ,而 Pipeline1 的 Stage2 的完成和Pipeline2 的 Stage1 的完成是触发 Pipeline3 的条件,如果 Pipeline2 的 Stage1的完成较快而 Pipeline1 的 Stage2 完成较慢,Pipeline 会等待 Pipeline1 的Stage2 的完成后被触发,它不会触发与 Pipeline1 的不一致或旧的修改, 以确保一致性。
8. Value Stream Map (价值流图)
- VSM 是端到端的视图,详细描述了它的上下游依赖关系,在决定哪个 Pipeline
被触发时,GoCD 的 fan-in 和 fan-out 解决方案将始终如一地处理所有依赖项。
如图,当 Repo1(git) 中有新的提交时,GoCD 不会立即触发 Pipeline5,它将等待 Pipeline1 触发并成功完成,然后等待 Pipeline4 触发并成功完成,最后,
它将触发 Pipeline5 与 Pipeline1 使用相同的 Repo1 相同的修订版本。
9. Artifacts
GoCD 中的 Artifacts 是在 Pipeline 运行期间最常生产的文件或目录,每一个Job 都可以选择发布 Artifacts,即文件或目录。在运行 Job 之后,GoCD 将确保已发布指定的 Artifacts,并向用户和其他下游阶段和管道提供。
GoCD 提供了一种特殊的任务,称为“获取 Artifacts”,它允许从任何祖先 pipline 中提取和使用 Artifacts,即当前 pipline 上游的任何 pipline。GoCD 将确保获取 Artifacts 的正确版本,而不考虑系统中可能发生的任何其他事情。
10. Agent
GoCD 的 agent 是 GoCD 生态系统的工人。系统中配置的所有任务都运行在GoCD agent 上。GoCD 服务器轮询 material 的变化(这发生在GoCD服务器本身),然后,当检测到更改并需要触发 pipline 时,相应的 job 被分配给代理,以便他们执行任务。
agent 选择分配给他们的 job ,在 job 中执行task ,并向 GoCD 服务器报告 job 状态。然后,GoCD 服务器整理来自不同 job 的所有信息,然后决定 stage 的状态。
每个部署业务的机器上都必须安装 agent
11. Resources资源是我们打在 Agent 的标签,以表示哪些 Agent 能运行这个Job
如图,我们运行一个需要 Firefox 资源的 Job,那么只有 Agent1 和 Agent3 满足,如何知道 Agent1 和 Agent3 上有 Firefox ?在这两个 Agent 上打上标签"Firefox(or XXX)"
12. Environments
- GOCD 中的 Environments 是对 Pipeline 和 Agent 进行分组和隔离的一种方式
- Pipeline 可以与最大的一个 Environment 相关联。
- Agent 可以与多个Environment 或任何 Environment 相关联。
- Agent 只能在其关联的 Environment 中提取属于 Pipeline 的作业。
- 与 Environment 相关联的 Agent 不能在与任何 Environment 无关的 Agent 中获取 job 。
13. Environment Variables -
环境变量在各层级都可以配置,原则类似于全局变量和局部变量的概念,最底层的变量值会覆盖上层的变量值
注:此环境变量跟上面的 Environment 不要混淆,前者指 a=1 变量赋值,后者为运行环境
上图各变量的最终值为:
ENV_ENV => 1
ENV_PIP => 2
ENV_STG => 3
ENV_JOB => 4
MY_VAR => 4
二、Pipelines Dashboard in GoCD
以我的 dashboard 为例,定义了两个 pipeline group, 在 dashboard 里 pipeline 被列在他们所属的 pipeline group 下面
注:
- “触发” 按钮强制一条 pipeline 开始构建活动。
-
带有[选项按钮的触发器], 允许选择 pipeline 应该构建的 material 的修订,并触发 pipeline。
- “暂停”(Pause)按钮暂停 pipeline 的调度
Dashboard 上的 Personalize 按钮来定制和控制 Dashboard 看到的 Pipeline 。可以选择要查看的 Pipeline ,在这个列表中,并通过单击“Apply”按钮来保存选择。从那时起,Pipeline 指示板将只显示选择的。
如果一个新的 Pipeline 被其他人添加,Pipeline 也会显示在该账户的的Dashboard 上。取消(Show newly created pipelines)复选框,以防止它们出现在我们的 Dashboard 上。
有四种配置 Pipeline 的方法:
通过管理界面来配置 Pipeline。
通过 Pipeline 界面的 “Config XML” 选项卡直接编辑 XML。
还可以通过调用配置API来配置 Pipeline
通过文件系统直接进行 XML 编辑进行配置后。默认情况下,Go服务器每5秒对文件系统进行轮询,以更改 cruise-config.xml。该文件的位置显示在 Admin >配置XML选项卡的右上角。
三、Agent
Agent 页面列出了服务器可用的所有代理和它们当前的状态。当 Agent 首次连接到服务器时,它是 “Pending”(挂起状态)。管理员必须在 GoCD 将工作安排在该Agent 之前启用 Agent。
管理员也可以禁用 Agent 。GoCD不会为一个被 Agent 的代理安排工作。如果在Agent 被禁用时正好有一项工作正在该 Agent 上建立,则该工作将被完成;然后才禁用 Agent。管理员在重新安排工作之前需要启用 Agent。
管理员可以选择删除不再需要的 Agent。在删除 Agent 之前,必须禁用该Agent 。处于(building)状态或者(cancelled)状态的 Agent 不能被删除。
可以将资源与 Agent 关联起来,首先选择您感兴趣的 Agent。然后点击 Resources 按钮。
四、安装
服务器使用的默认端口都是 8153(HTTP端口)和 8154(HTTPS端口),一个或多个 Agent 可以安装在任何节点上,而不一定是安装 GoCD 服务器的节点。唯一的要求是 GoCD 服务器的端口8153和8154可以从安装 Agent 的节点访问。
服务器硬件要求:
- 内存 - 推荐最少 1GB 或者 2GB
- CPU - 最低2核,2GHz 主频
- 硬盘 - 最低要求有1GB的剩余空间
依赖关系:
- Java Runtime Environment (JRE) version 8
- Git or other
运行 GoCD 服务器的主机应该有一个单独的磁盘分区来存储 GoCD Artifacts。Artifacts存储库可以快速填充(特别是在存储大型二进制文件时)。如果不为Artifacts 创建单独的分区,系统磁盘将被填满。可以在页面 Pipeline Management 里或者 config xml 里指定 Artifacts 存储位置。
以我的项目为例,我的 server 是用 docker 启动的,在docker-compose指定了存储卷
cruise-config.xml 和 /godata/artifacts 在 同级目录下 /godata/ 下,指定了 artifacts 的位置:
<cruise>
<server artifactsdir="artifacts">
...
</server>
</cruise>
如果需要更改 artifacts 存储库,那么安全的方法是:
- 暂停所有 Pipeline,等待 agent 网格中的所有活动作业完成(所有 agent 都处于状态 "idle")
- 关闭 GoCD 服务器
- 将 artifacts 存储库复制到新位置
- 按照上面的描述手动编辑 GoCD 的配置文件,告诉 GoCD 在哪里可以找到新的 artifacts
- 重启GoCD服务器
Agent所在机器的硬件要求:
- 内存 - 推荐最少 128MB 或者 256MB
- CPU - 最低2GHz主频
依赖关系: - 需要与 GoCD 服务器的 Java 版本相同
Agent 本身并不需要太多内存或 CPU。 但是,需要确保部署为构建 Agent 的节点具有足够的资源来构建项目 --包括足够的磁盘空间来检查源代码控制之外的源代码。代码控制工具(Git、SVN等)的客户端软件需要安装在所有构建 Agent 上。另外,需要安装任何其他软件来构建应用程序(如不直接从源控制中检出的项目源码),需要安装(例如,Maven或Rake)。
安装 agent 之后需要将 GO_SERVER_URL 配置为 server 的地址
参考:
https://docs.gocd.org/current/
https://www.cnblogs.com/elisun/p/7071536.html
`