本示例基于开源的 KubeSphere 容器平台 演示如何经过 GitHub 仓库中的 Jenkinsfile 来建立流水线,流水线共包括 8 个阶段,最终将一个 Hello World 页面部署到 Kubernetes 集群中的不一样 namespace。java
下面的流程图简单说明了流水线完整的工做过程:git
流程说明:github
- 阶段一. Checkout SCM: 拉取 GitHub 仓库代码
- 阶段二. Unit test: 单元测试,若是测试经过了才继续下面的任务
- 阶段三. sonarQube analysis:sonarQube 代码质量检测
- 阶段四. Build & push snapshot image: 根据行为策略中所选择分支来构建镜像,并将 tag 为
SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER
推送至 Harbor (其中$BUILD_NUMBER
为 pipeline 活动列表的运行序号)。- 阶段五. Push latest image: 将 master 分支打上 tag 为 latest,并推送至 DockerHub。
- 阶段六. Deploy to dev: 将 master 分支部署到 Dev 环境,此阶段须要审核。
- 阶段七. Push with tag: 生成 tag 并 release 到 GitHub,并推送到 DockerHub。
- 阶段八. Deploy to production: 将发布的 tag 部署到 Production 环境。
使用 project-regular 登陆 KubeSphere,进入已建立的 devops-demo 工程,开始建立凭证。web
一、本示例代码仓库中的 Jenkinsfile 须要用到 DockerHub、GitHub 和 kubeconfig (kubeconfig 用于访问接入正在运行的 Kubernetes 集群) 等一共 3 个凭证 (credentials) 。
二、而后建立一个 Java 的 Token 并复制。docker
三、最后在 KubeSphere 中进入 devops-demo
的 DevOps 工程中,与上面步骤相似,在 凭证 下点击 建立,建立一个类型为 秘密文本
的凭证,凭证 ID 命名为 sonar-token,密钥为上一步复制的 token 信息,完成后点击 肯定。shell
至此,4 个凭证已经建立完成,下一步须要在示例仓库中的 jenkinsfile 修改对应的四个凭证 ID 为用户本身建立的凭证 ID。segmentfault
登陆 GitHub,将本示例用到的 GitHub 仓库 devops-java-sample Fork 至您我的的 GitHub。浏览器
一、Fork 至您我的的 GitHub 后,在 根目录 进入 Jenkinsfile-online。安全
二、在 GitHub UI 点击编辑图标,须要修改以下环境变量 (environment) 的值。网络
修改项 | 值 | 含义 |
---|---|---|
DOCKER_CREDENTIAL_ID | dockerhub-id | 填写建立凭证步骤中的 DockerHub 凭证 ID,用于登陆您的 DockerHub |
GITHUB_CREDENTIAL_ID | github-id | 填写建立凭证步骤中的 GitHub 凭证 ID,用于推送 tag 到 GitHub 仓库 |
KUBECONFIG_CREDENTIAL_ID | demo-kubeconfig | kubeconfig 凭证 ID,用于访问接入正在运行的 Kubernetes 集群 |
REGISTRY | docker.io | 默认为 docker.io 域名,用于镜像的推送 |
DOCKERHUB_NAMESPACE | your-dockerhub-account | 替换为您的 DockerHub 帐号名 (它也能够是帐户下的 Organization 名称) |
GITHUB_ACCOUNT | your-github-account | 替换为您的 GitHub 帐号名,例如 https://github.com/kubesphere/ 则填写 kubesphere (它也能够是帐户下的 Organization 名称) |
APP_NAME | devops-java-sample | 应用名称 |
SONAR_CREDENTIAL_ID | sonar-token | 填写建立凭证步骤中的 SonarQube token凭证 ID,用于代码质量检测 |
注: Jenkinsfile 中 mvn
命令的参数 -o
,表示开启离线模式。本示例为适应某些环境下网络的干扰,以及避免在下载依赖时耗时太长,已事先完成相关依赖的下载,默认开启离线模式。
三、修改以上的环境变量后,点击 Commit changes,将更新提交到当前的 master 分支。
CI/CD 流水线会根据示例项目的 yaml 模板文件,最终将示例分别部署到 Dev 和 Production 这两个项目 (Namespace) 环境中,即 kubesphere-sample-dev
和 kubesphere-sample-prod
,这两个项目须要预先在控制台依次建立,参考以下步骤建立该项目。
一、使用项目管理员 project-admin
帐号登陆 KubeSphere,在以前建立的企业空间 (demo-workspace) 下,点击 项目 → 建立,建立一个 资源型项目,做为本示例的开发环境,填写该项目的基本信息,完成后点击 下一步。
kubesphere-sample-dev
,若须要修改项目名称则需在 yaml 模板文件 中修改 namespace二、本示例暂无资源请求和限制,所以高级设置中无需修改默认值,点击 建立,项目可建立成功。
第一个项目建立完后,还须要项目管理员 project-admin
邀请当前的项目普通用户 project-regular
进入 kubesphere-sample-dev
项目,进入「项目设置」→「项目成员」,点击「邀请成员」选择邀请 project-regular
并授予 operator
角色。
同上,参考以上两步建立一个名称为 kubesphere-sample-prod
的项目做为生产环境,并邀请普通用户 project-regular
进入 kubesphere-sample-prod
项目并授予 operator
角色。
说明:当 CI/CD 流水线后续执行成功后,在kubesphere-sample-dev
和kubesphere-sample-prod
项目中将看到流水线建立的部署 (Deployment) 和服务 (Service)。
一、进入已建立的 DevOps 工程,选择左侧菜单栏的 流水线,而后点击 建立。
二、在弹出的窗口中,输入流水线的基本信息。
一、点击代码仓库,以添加 Github 仓库为例。
二、点击弹窗中的 获取 Token。
三、在 GitHub 的 access token 页面填写 Token description,简单描述该 token,如 DevOps demo,在 Select scopes 中无需任何修改,点击 Generate token
,GitHub 将生成一串字母和数字组成的 token 用于访问当前帐户下的 GitHub repo。
四、复制生成的 token,在 KubeSphere Token 框中输入该 token 而后点击保存。
五、验证经过后,右侧会列出此 Token 关联用户的全部代码库,选择其中一个带有 Jenkinsfile 的仓库。好比此处选择准备好的示例仓库 devops-java-sample,点击 选择此仓库,完成后点击 下一步。
完成代码仓库相关设置后,进入高级设置页面,高级设置支持对流水线的构建记录、行为策略、按期扫描等设置的定制化,如下对用到的相关配置做简单释义。
一、构建设置中,勾选 丢弃旧的构建
,此处的 保留分支的天数 和 保留分支的最大个数 默认为 -1。
说明:
分支设置的保留分支的天数和保持分支的最大个数两个选项能够同时对分支进行做用,只要某个分支的保留天数和个数不知足任何一个设置的条件,则将丢弃该分支。假设设置的保留天数和个数为 2 和 3,则分支的保留天数一旦超过 2 或者保留个数超过 3,则将丢弃该分支。默认两个值为 -1,表示不自动删除分支。
丢弃旧的分支将肯定什么时候应丢弃项目的分支记录。分支记录包括控制台输出,存档工件以及与特定分支相关的其余元数据。保持较少的分支能够节省 Jenkins 所使用的磁盘空间,咱们提供了两个选项来肯定应什么时候丢弃旧的分支:
- 保留分支的天数:若是分支达到必定的天数,则丢弃分支。
- 保留分支的个数:若是已经存在必定数量的分支,则丢弃最旧的分支。
二、行为策略中,KubeSphere 默认添加了三种策略。因为本示例还未用到 从 Fork 仓库中发现 PR 这条策略,此处能够删除该策略,点击右侧删除按钮。
说明:
支持添加三种类型的发现策略。须要说明的是,在 Jenkins 流水线被触发时,开发者提交的 PR (Pull Request) 也被视为一个单独的分支。
发现分支:
- 排除也做为 PR 提交的分支:选择此项表示 CI 将不会扫描源分支 (好比 Origin 的 master branch),也就是须要被 merge 的分支
- 只有被提交为 PR 的分支:仅扫描 PR 分支
- 全部分支:拉取的仓库 (origin) 中全部的分支
从原仓库中发现 PR:
- PR 与目标分支合并后的源代码版本:一次发现操做,基于 PR 与目标分支合并后的源代码版本建立并运行流水线
- PR 自己的源代码版本:一次发现操做,基于 PR 自己的源代码版本建立并运行流水线
- 当 PR 被发现时会建立两个流水线,一个流水线使用 PR 自己的源代码版本,一个流水线使用 PR 与目标分支合并后的源代码版本:两次发现操做,将分别建立两条流水线,第一条流水线使用 PR 自己的源代码版本,第二条流水线使用 PR 与目标分支合并后的源代码版本
三、默认的 脚本路径 为 Jenkinsfile,请将其修改成 Jenkinsfile-online。
注:路径是 Jenkinsfile 在代码仓库的路径,表示它在示例仓库的根目录,若文件位置变更则需修改其脚本路径。
四、在 扫描 Repo Trigger 勾选 若是没有扫描触发,则按期扫描
,扫描时间间隔可根据团队习惯设定,本示例设置为 5 minutes
。
说明:按期扫描是设定一个周期让流水线周期性地扫描远程仓库,根据 行为策略 查看仓库有没有代码更新或新的 PR。Webhook 推送:
Webhook 是一种高效的方式可让流水线发现远程仓库的变化并自动触发新的运行,GitHub 和 Git (如 Gitlab) 触发 Jenkins 自动扫描应该以 Webhook 为主,以上一步在 KubeSphere 设置按期扫描为辅。在本示例中,能够经过手动运行流水线,如需设置自动扫描远端分支并触发运行,详见 设置自动触发扫描 - GitHub SCM。
完成高级设置后点击 建立。
流水线建立后,点击浏览器的 刷新 按钮,可见一条自动触发远程分支后的运行记录。
一、点击右侧 运行,将根据上一步的 行为策略 自动扫描代码仓库中的分支,在弹窗选择须要构建流水线的 master
分支,系统将根据输入的分支加载 Jenkinsfile-online (默认是根目录下的 Jenkinsfile)。
二、因为仓库的 Jenkinsfile-online 中 TAG_NAME: defaultValue
没有设置默认值,所以在这里的 TAG_NAME
能够输入一个 tag 编号,好比输入 v0.0.1。
三、点击 肯定,将新生成一条流水线活动开始运行。
说明: tag 用于在 Github 和DockerHub 中分别生成带有 tag 的 release 和镜像。 注意: 在主动运行流水线以发布 release 时,TAG_NAME
不该与以前代码仓库中所存在的tag
名称重复,若是重复会致使流水线的运行失败。
至此,流水线 已完成建立并开始运行。
注:点击 分支 切换到分支列表,查看流水线具体是基于哪些分支运行,这里的分支则取决于上一步 行为策略 的发现分支策略。
为方便演示,此处默认用当前帐户来审核,当流水线执行至 input
步骤时状态将暂停,须要手动点击 继续,流水线才能继续运行。注意,在 Jenkinsfile-online 中分别定义了三个阶段 (stage) 用来部署至 Dev 环境和 Production 环境以及推送 tag,所以在流水线中依次须要对 deploy to dev, push with tag, deploy to production
这三个阶段审核 3
次,若不审核或点击 终止 则流水线将不会继续运行。
说明:在实际的开发生产场景下,可能须要更高权限的管理员或运维人员来审核流水线和镜像,并决定是否容许将其推送至代码或镜像仓库,以及部署至开发或生产环境。Jenkinsfile 中的
input
步骤支持指定用户审核流水线,好比要指定用户名为 project-admin 的用户来审核,能够在 Jenkinsfile 的 input 函数中追加一个字段,若是是多个用户则经过逗号分隔,以下所示:
··· input(id: 'release-image-with-tag', message: 'release image with tag?', submitter: 'project-admin,project-admin1') ···
一、点击流水线中 活动
列表下当前正在运行的流水线序列号,页面展示了流水线中每一步骤的运行状态,注意,流水线刚建立时处于初始化阶段,可能仅显示日志窗口,待初始化 (约一分钟) 完成后便可看到流水线。黑色框标注了流水线的步骤名称,示例中流水线共 8 个 stage,分别在 Jenkinsfile-online 中被定义。
二、当前页面中点击右上方的 查看日志
,查看流水线运行日志。页面展现了每一步的具体日志、运行状态及时间等信息,点击左侧某个具体的阶段可展开查看其具体的日志。日志可下载至本地,如出现错误,下载至本地更便于分析定位问题。
一、若流水线执行成功,点击该流水线下的 代码质量
,便可看到经过 SonarQube 的代码质量检测结果,以下图(仅供参考)。
二、流水线最终 build 的 Docker 镜像也将被成功地 push 到 DockerHub 中,咱们在 Jenkinsfile-online 中已经配置过 DockerHub,登陆 DockerHub 查看镜像的 push 结果,能够看到 tag 为 snapshot、TAG_NAME(master-1)、latest 的镜像已经被 push 到 DockerHub,而且在 GitHub 中也生成了一个新的 tag 和 release。Hello World 示例页面最终将以 deployment 和 service 分别部署到 KubeSphere 的 kubesphere-sample-dev
和 kubesphere-sample-prod
项目环境中。
环境 | 访问地址 | 所在项目 (Namespace) | 部署 (Deployment) | 服务 (Service) |
---|---|---|---|---|
Dev | http://{$Virtual IP}:{$8080} 或者 http://{$内网/公网 IP}:{$30861} |
kubesphere-sample-dev | ks-sample-dev | ks-sample-dev |
Production | http://{$Virtual IP}:{$8080} 或者 http://{$内网/公网 IP}:{$30961} |
kubesphere-sample-prod | ks-sample | ks-sample |
三、可经过 KubeSphere 回到项目列表,依次查看以前建立的两个项目中的部署和服务的状态。例如,如下查看 kubesphere-sample-prod
项目下的部署。
进入该项目,在左侧的菜单栏点击 工做负载 → 部署,能够看到 ks-sample 已建立成功。正常状况下,部署的状态应该显示 运行中。
四、在菜单栏中选择 网络与服务 → 服务 也能够查看对应建立的服务,能够看到该服务的 Virtual IP 为 10.233.42.3
,对外暴露的节点端口 (NodePort) 是 30961
。
查看服务
五、查看推送到您我的的 DockerHub 中的镜像,能够看到 devops-java-sample
就是 APP_NAME 的值,而 tag 也是在 jenkinsfile-online 中定义的 tag。
六、点击 release
,查看 Fork 到您我的 GitHub repo 中的 v0.0.1
tag 和 release,它是由 jenkinsfile 中的 push with tag
生成的。
若在内网环境访问部署的 HelloWorld 示例服务,可经过 SSH 登录集群节点,或使用集群管理员登录 KubeSphere 在 web kubectl 中输入如下命令验证访问,其中 Cluster IP 和节点端口 (NodePort) 可经过对应项目下的服务中查看:
验证 Dev 环境的示例服务
# curl {$Virtual IP}:{$Port} 或者 curl {$内网 IP}:{$NodePort} curl 10.233.40.5:8080 Hello,World!
验证 Prodcution 环境的示例服务
# curl {$Virtual IP}:{$Port} 或者 curl {$内网 IP}:{$NodePort} curl 10.233.42.3:8080 Hello,World!
KubeSphere (https://github.com/kubesphere... 是一个开源的以应用为中心的容器管理平台,支持部署在任何基础设施之上,并提供简单易用的 UI,极大减轻平常开发、测试、运维的复杂度,旨在解决 Kubernetes 自己存在的存储、网络、安全和易用性等痛点,帮助企业轻松应对敏捷开发与自动化监控运维、端到端应用交付、微服务治理、多租户管理、多集群管理、服务与网络管理、镜像仓库、AI 平台、边缘计算等业务场景。