关于kubernetes:实践分享GitLab-CICD-快速入门

用过 GitLab 的同学必定也对 GitLab CI/CD 不生疏，GitLab CI/CD 是一个内置在 GitLab 中的工具，它能够帮忙咱们在每次代码推送时运行一系列脚本来构建、测试和验证代码的更改以及部署。

Rainbond 自身默认集成了 CI/CD 的整套流程，用户只需提供源代码，后续构建、运行齐全交给 Rainbond 解决，整个过程是由 Rainbond 定义的，无需用户干涉。这样无利也有弊，利就是简化用户的操作和无需学习 CI/CD 相干常识；弊是用户无奈在 CI/CD 过程中自定义，比方想集成代码检测或运行个脚本，这在 Rainbond 的源码构建流程中是不可自定义的。

本文给大家讲述如何应用 GitLab CI/CD 构建、测试、部署 Spring Boot 利用，将产物运行在 Rainbond 上。

应用 GitLab CI 须要在仓库根目录下创立 .gitlab-ci.yml 文件。在这个文件中，你能够定义须要运行的编译、测试、部署脚本。

在增加了 .gitlab-ci.yml 文件后，当推送代码时，GitLab Runner 主动执行你定义的 Pipeline，并在 GitLab CI 页面上展现 CI 过程以及后果。

GitLab CI 的根本流程如下：

开发人员推送代码
触发 GitLab CI 启动
runner 执行预约义脚本

通过开源利用商店一键部署 GitLab 和 Runner，新增 -> 基于利用商店创立组件 -> 在开源利用商店中搜寻 GitLab 顺次装置 GitLab 和 Runner 到指定利用中。

在 Rainbond v5.8 版本之前，Rainbond 对 Runner 类型的组件反对的并不是很好。因为 Runner 若以容器的模式去运行的话，自身它须要去挂载宿主机的 docker.sock 文件，使它能够调度宿主机的 docker 环境，创立容器执行工作。在 Rainbond v5.8 版本中，反对批改组件的 YAML，就能够自定义 Volumes 并挂载本地的 docker.sock。

在通过利用商店装置了 Runner 之后，能够在 Runner 组件内 -> 其余设置中看到 Kubernetes 属性，Rainbond 的利用模型已兼容了 Kubernetes 属性。

注册 Runner 到 GitLab：

进入编排模式，将 runner 连贯到 GitLab 并更新 runner 组件。(如提醒 GitLab 未开启对内端口，则抉择 80 端口)
首先拜访 GitLab，Menu -> Admin -> Overview -> Runners -> Register an instance runner -> 复制 Registration token。
进入 runner 组件内，点击右上角 web 终端进入，执行以下命令进行注册，<token> 换成上一步复制的 Registration token。

gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image alpine:latest \
  --url "http://127.0.0.1" \
  --registration-token "NxNuoRXuzYy3GnFbkhtK" \
  --description "docker-runner" \
  --tag-list "newdocker" \
  --run-untagged="true" \
  --locked="false" \
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock \
  --docker-privileged="true" \
  --access-level="not_protected"

参数阐明

Parameter	Value	Describe
–executor	docker	执行器类型为 docker。
–url	http://127.0.0.1	GitLab addr
–registration-token	<token>	GitLab token
–tag-list	newdocker	定义 runner 的标签 / 名字
–locked	false	runner 为启用状态
–run-untagged	true	运行没有指定标签的 Job
–docker-volumes	file_path	挂载文件到 runner 中
–docker-privileged	true	runner 运行模式：特权模式

注册实现后就能够在 GitLab 页面中看到 online 的 runner

整个流程能够分为：

开发人员提交代码到 GitLab 仓库。
触发 GitLab 流水线创立，Runner 执行 .gitlab-ci.yml 定义的 stages。
将制作好的镜像推送到已有的镜像仓库，供后续的 Deploy 流程应用。
通过 Rainbond 自定义 API 的办法，触发平台组件的主动构建，进入 Deploy 阶段。

前提：

已有 Rainbond 环境
筹备镜像仓库，本文应用的 DockerHub
本文所应用到代码我的项目为 Java-Maven-Demo

1. 在 Rainbond 上有曾经基于镜像部署好的组件

2. 将示例代码导入到 GitLab 中。

3. 编写 .gitlab-ci.yml 文件：

在我的项目根目录下创立 .gitlab-ci.yml 内容如下:

# 定义 job 的执行程序
stages:
  - test
  - package
  - push
# 定义根底镜像
image: maven:3.6.3-jdk-8
job-test:
  stage: test
  tags: 
    - newdocker
  script:
    - echo "=============== 开始执行代码测试工作 ==============="
    - mvn test
job-package:
  stage: package
  tags: 
    - newdocker
  script:
    - echo "=============== 开始执行打包工作 ==============="
    - ls
    - mvn clean package
    - cp Dockerfile target/Dockerfile
  cache:
    key: devops
    paths:
      - target/ 
job-push:
  stage: push
  image: docker:dind
  cache:
    key: devops
    paths:
      - target/
  tags:
    - newdocker
  script:
    - docker login -u ${DOCKER_USERNAME} -p ${DOCKER_PASSWORD}
    - docker build -t ${IMAGE_DOMAIN}/java-maven:latest .
    - docker push ${IMAGE_DOMAIN}/java-maven:latest
  after_script:  
    - curl -d '{"secret_key":"${RAINBOND_SECRET}"}' -H "Content-type:application/json" -X POST http://${RAINBOND_IP}:7070/console/custom/deploy/3321861bcadf0789af71898f23e8e740

after_script 是在推送镜像实现后执行，通过 Rainbond API 构建组件，Rainbond 会获取最新镜像构建运行。<RAINBOND_SECRET> 可在组件 -> 构建源 -> 主动构建中看到。详情可参阅文档配置组件主动构建部署

4. 提交代码测试主动构建 ，

批改代码并提交，提交后可在我的项目的 CI/CD -> Jobs 能够看到正在执行的以及执行实现的工作详情。

5. 查看 Rainbond 组件构建

能够在组件的操作记录中看到主动构建信息。

GitLab CI 扩展性很好，能够集成很多第三方工具，联合 Rainbond 作为 CD，将产物运行到 Rainbond 上，即可造成实用于本身代码我的项目的 Pipeline。

Rainbond 会在将来的 v5.9.x 版本中实现 Pipeline，对 Rainbond 实现 Pipeline 有想法的同学能够在 issue 上提出 Proposal https://github.com/goodrain/r…

关于kubernetes:实践分享GitLab-CICD-快速入门

GitLab CI 介绍

GitLab CI/CD 疾速开始

部署 GitLab 和 Runner

在 Rainbond 上配置 Runner

GitLab CI/CD To Rainbond

实际步骤

写在最初