K8S-与CICD的融合

K8S与CICD的融合

CICD

CICD的概念

工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”，将最终产品提供给用户的过程称为“持续部署（CD）”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为运维开发DevOps践行者。

“持续”是什么

“持续”用于描述遵循我在此提到的许多不同流程实践。这并不意味着“一直在运行”，而是“随时可运行”。在软件开发领域，它还包括几个核心概念/最佳实践。这些是：

• 频繁发布：持续实践背后的目标是能够频繁地交付高质量的软件。此处的交付频率是可变的，可由开发团队或公司定义。对于某些产品，一季度、一个月、一周或一天交付一次可能已经足够频繁了。对于另一些来说，一天可能需要多次交付也是可行的。所谓持续也有“偶尔、按需”的方面。最终目标是相同的：在可重复、可靠的过程中为最终用户提供高质量的软件更新。通常，这可以通过很少甚至无需用户的交互或掌握的知识来完成（想想设备更新）。

• 自动化流程：实现此频率的关键是用自动化流程来处理软件生产中的方方面面。这包括构建、测试、分析、版本控制，以及在某些情况下的部署。

• 可重复：如果我们使用的自动化流程在给定相同输入的情况下始终具有相同的行为，则这个过程应该是可重复的。也就是说，如果我们把某个历史版本的代码作为输入，我们应该得到对应相同的可交付产出。这也假设我们有相同版本的外部依赖项（即我们不创建该版本代码使用的其它交付物）。理想情况下，这也意味着可以对管道中的流程进行版本控制和重建（请参阅稍后的 DevOps 讨论）。

• 快速迭代：“快速”在这里是个相对术语，但无论软件更新/发布的频率如何，预期的持续过程都会以高效的方式将源代码转换为交付物。自动化负责大部分工作，但自动化处理的过程可能仍然很慢。例如，对于每天需要多次发布候选版更新的产品来说，一轮集成测试integrated testing下来耗时就要大半天可能就太慢了。

持续集成（CI-Continuous Integration）

CI 中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证；

持续集成 CI 是在源代码变更后自动检测、拉取、构建和进行单元测试的过程，持续集成的目标是快速确保开发人员新提交的变更是好的，并且适合在代码库中进一步使用；CI 的流程执行和理论实践让我们可以确定新代码和原有代码能否正确地集成在一起。

[

](https://blog.csdn.net/tojohnonly/article/details/103249881)

持续交付（CD-Continuous Delivery）

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库；为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道，持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化；在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中或发布给最终使用的用户。

1. 代码提交

2. 单元测试

3. 集成代码

4. 测试（Test）：这里不仅仅是单元测试，还可能包含功能测试、集成测试、系统测试等

5. 先部署到预发环境（预生产环境，Staging）：测试人员在预发环境进行产品的主流程验证，验证通过再执行下一步

6. 手动部署到生产环境（Production）：开发手动部署

持续部署（CD-Continuous Deployment）

对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署；作为持续交付（自动将生产就绪型构建版本发布到代码存储库）的延伸，持续部署可以自动将应用发布到生产环境；

持续交付意味着所有的变更都可以被部署到生产环境中，持续部署意味着所有的变更都会被自动部署到生产环境中，但是出于业务考虑可以选择不部署；如果要实施持续部署，必须先实施持续交付；

持续交付并不是指软件每一个改动都要尽快部署到产品环境中，它指的是任何的代码修改都可以在任何时候实施部署；持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段

DvOps

一个软件从零开始到最终交付，大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。

瀑布模型

瀑布模型（Waterfall Model） 是一个项目开发架构，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，每个阶段都会产生循环反馈，因此，如果有信息未被覆盖或者发现了问题，那么最好 “返回”上一个阶段并进行适当的修改，项目开发进程从一个阶段“流动”到下一个阶段。

瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：

（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。

（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。

（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

敏捷开发

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

其实简单来说，就是把大项目变成小项目，把大时间点变成小时间点，然后这样：

虽然敏捷开发大幅提升了软件开发的效率和版本更新的速度，但是它的效果仅限于开发环节。研发们发现，运维那边，依旧是铁板一块，成为了新的瓶颈。

DevOps

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

DevOps对应用程序发布的影响

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：

• 减少变更范围

与传统的瀑布模式模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。

• 加强发布协调

靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议和企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。

• 自动化

强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。

与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）。

基于GitLab实现的cicd自动化

GitLabCI & Runner 介绍

GitLab-CI 是一套 GitLab 提供给用户使用的持续集成系统，GitLab 8.0 版本以后是默认集成并且默认启用。GitLab-Runner 是配合 GitLab-CI 进行使用的，GitLab 里面每个工程都会定义一些该工程的持续集成脚本，该脚本可配置一个或多个 Stage 例如构建、编译、检测、测试、部署等等。当工程有代码更新时，GitLab 会自动触发 GitLab-CI，此时 CitLab-CI 会找到事先注册好的 GitLab-Runner 通知并触发该 Runner 来执行预先定义好的脚本。

传统的 GitLab-Runner 我们一般会选择某个或某几个机器上，可以 Docker 安装启动亦或是直接源码安装启动，都会存在一些痛点问题，比如发生单点故障，那么该机器的所有 Runner 就不可用了；每个 Runner 所在机器环境不一样，以便来完成不同类型的 Stage 操作，但是这种差异化配置导致管理起来很麻烦；资源分配不平衡，有的 Runner 运行工程脚本出现拥塞时，而有的 Runner 缺处于空闲状态；资源有浪费，当 Runner 处于空闲状态时，也没有安全释放掉资源。因此，为了解决这些痛点，我们可以采用在 Kubernetes 集群中运行 GitLab-Runner 来动态执行 GitLab-CI 脚本任务，它整个流程如下图：

这种方式带来的好处有：

• 服务高可用，当某个节点出现故障时，Kubernetes 会自动创建一个新的 GitLab-Runner 容器，并挂载同样的 Runner 配置，使服务达到高可用。

• 动态伸缩，合理使用资源，每次运行脚本任务时，Gitlab-Runner 会自动创建一个或多个新的临时 Runner，当任务执行完毕后，临时 Runner 会自动注销并删除容器，资源自动释放，而且 Kubernetes 会根据每个节点资源的使用情况，动态分配临时 Runner 到空闲的节点上创建，降低出现因某节点资源利用率高，还排队等待在该节点的情况。

• 扩展性好，当 Kubernetes 集群的资源严重不足而导致临时 Runner 排队等待时，可以很容易的添加一个 Kubernetes Node 到集群中，从而实现横向扩展。

1.在Kubernetes集群中安装GitLab Runner

​ 1.获取GitLab Runner的注册信息

1. 获取项目专用Runner的注册信息。

2. 1. 登录Gitlab。
   2. 在顶部导航栏中，选择Projects > Your projects。
3. 1. 在Your projects页签下，选择相应的Project。
   2. 在左侧导航栏中，选择Settings > CI / CD。
4. 1. 单击Runners右侧的Expand。
   2. 获取URL和registration token信息。

5. 获取Group Runners的注册信息。

6. 1. 在顶部导航栏中，选择Groups > Your groups。
   2. 在Your groups页签下，选择相应的group。
7. 1. 在左侧导航栏中，选择Settings > CI / CD。
   2. 单击Runners右侧的Expand。
8. 1. 获取URL和registration token信息。

9. 获取Shared Runners的注册信息。说明 只有管理员有权限执行此步操作。

10. 1. 在顶部导航栏中，单击进入Admin Area页面。
    2. 在左侧导航栏中，选择Overview > Runners。
11. 1. 获取URL和registration token信息。

​ 2.执行以下命令获取并修改GitLab Runner的Helm Chart

git clone https://github.com/haoshuwei/gitlab-runner.git

​ 替换gitlabUrl和runnerRegistrationToken字段，示例如下：

## GitLab Runner Image
##
image: gitlab/gitlab-runner:alpine-v11.4.0

## Specify a imagePullPolicy
##
imagePullPolicy: IfNotPresent

## Default container image to use for initcontainer
init:
  image: busybox
  tag: latest

## The GitLab Server URL (with protocol) that want to register the runner against
##
gitlabUrl: http://xx.xx.xx.xx/

## The Registration Token for adding new Runners to the GitLab Server. This must
## be retreived from your GitLab Instance.
##
runnerRegistrationToken: "AMvEWrBTBu-d8czE****"
## Unregister all runners before termination
##
unregisterRunners: true

## Configure the maximum number of concurrent jobs
##
concurrent: 10

## Defines in seconds how often to check GitLab for a new builds
##
checkInterval: 30

## For RBAC support:
##
rbac:
  create: true
  clusterWideAccess: false

## Configure integrated Prometheus metrics exporter
##
metrics:
  enabled: true

## Configuration for the Pods that that the runner launches for each new job
##
runners:
  ## Default container image to use for builds when none is specified
  ##
  image: ubuntu:16.04

  ## Specify the tags associated with the runner. Comma-separated list of tags.
  ##
  tags: "k8s-runner"

  ## Run all containers with the privileged flag enabled
  ## This will allow the docker:dind image to run if you need to run Docker
  ## commands. Please read the docs before turning this on:
  ##
  privileged: true

  ## Namespace to run Kubernetes jobs in (defaults to the same namespace of this release)
  ##
  namespace: gitlab

  cachePath: "/opt/cache"

  cache: {
     }
  builds: {
     }
  services: {
     }
  helpers: {
     }

resources: {
     }

1. 执行以下命令安装GitLab Runner[

   ](https://blog.csdn.net/aixiaoyang168/article/details/81149264)

• 打包应用

helm package 

.

• 预期输出

Successfully packaged chart and saved it to: /root/gitlab/gitlab-runner/gitlab-runner-0.1.37.tgz

• 安装应用

helm install --namespace gitlab gitlab-runner *.tgz

2.缓存配置

GitLab Runner对缓存方案的支持有限，所以您需要使用挂载Volume的方式做缓存。在上面的示例中，安装GitLab Runner时默认使用/opt/cache目录作为缓存空间。您也可以通过修改values.yaml文件中的runners.cachePath字段修改缓存目录。

例如，如需建立Maven缓存，您可以在variables下添加MAVEN_OPTS变量并指定本地缓存目录：

variables:
  KUBECONFIG: /etc/deploy/config
  MAVEN_OPTS: "-Dmaven.repo.local=/opt/cache/.m2/repository"

修改templates/configmap.yaml文件中的以下字段挂载docker.sock和用于cache的volume。[

](https://blog.csdn.net/aixiaoyang168/article/details/81149264)

cat >>/home/gitlab-runner/.gitlab-runner/config.toml <

3.设置全局变量

1. 在GitLab的顶部导航栏中，选择Projects > Your projects。

2. 在Your projects页签下，选择相应的Project。

3. 在左侧导航栏中，选择Settings > CI / CD。

4. 单击Variables右侧的Expand。添加GitLab Runner可用的环境变量。本示例中，添加以下三个变量。

• • REGISTRY_USERNAME：镜像仓库用户名。
  • REGISTRY_PASSWORD：镜像仓库密码。
• • kube_config：KubeConfig的编码字符串。

• 执行以下命令生成KubeConfig的编码字符串：

echo $(cat ~/.kube/config | base64) | tr -d " "

4.编写.gitlab-ci.yml

编写.gitlab-ci.yml文件，完成Java Demo源码项目的编译构建、镜像推送和应用部署（可参考gitlabci-java-demo源码项目中的.gitlab-ci.yml.example）。

.gitlab-ci.yml示例如下。

image: docker:stable  # Pipeline中各个步骤阶段的构建镜像没有指定时， 默认使用docker:stable镜像
stages:
  - package              # 源码打包阶段
  - docker_build         # 镜像构建和打包推送阶段
  - deploy_k8s           # 应用部署阶段
variables:
  KUBECONFIG: /etc/deploy/config   # 定义全局变量KUBECONFIG
  MAVEN_OPTS: "-Dmaven.repo.local=/opt/cache/.m2/repository"
mvn_build_job:     # job名称
  image: maven:3.6.2-jdk-14  # 本阶段构建使用的构建镜像
  stage: package      # 关联的阶段名称
  tags:                     # GitLab Runner的tag
    - k8s-runner
  script:
    - mvn package -B -DskipTests  # 执行构建脚本
    - cp target/demo.war /opt/cache   # 构建物保存至缓存区
docker_build_job:  # job名称
  image: docker:latest # 本阶段构建使用的构建镜像
  stage: docker_build  # 关联的阶段名称
  tags:                      # GitLab Runner的tag
    - k8s-runner
  script:
    - docker login -u $REGISTRY_USERNAME -p $REGISTRY_PASSWORD registry.cn-beijing.aliyuncs.com   # 登录镜像仓库
    - mkdir target
    - cp /opt/cache/demo.war target/demo.war
    - docker build -t registry.cn-beijing.aliyuncs.com/haoshuwei24/gitlabci-java-demo:$CI_PIPELINE_ID .     # 打包Docker镜像，使用的tag为本次Pipeline的ID
    - docker push registry.cn-beijing.aliyuncs.com/haoshuwei24/gitlabci-java-demo:$CI_PIPELINE_ID      # 推送Docker镜像
deploy_k8s_job:   # job名称
  image: registry.cn-hangzhou.aliyuncs.com/haoshuwei24/kubectl:1.16.6   # 本阶段构建使用的构建镜像
  stage: deploy_k8s   # 关联的阶段名称
  tags:                      # GitLab Runner的tag
    - k8s-runner
  script:
    - mkdir -p /etc/deploy
    - echo $kube_config |base64 -d > $KUBECONFIG   # 配置连接Kubernetes集群的config文件
    - sed -i "s/IMAGE_TAG/$CI_PIPELINE_ID/g" deployment.yaml  # 动态替换部署文件中的镜像tag
    - cat deployment.yaml
    - kubectl apply -f deployment.yaml

https://help.aliyun.com/document_detail/106968.html

其他的CI/CD工具

基于jenkins实现的cicd

https://blog.csdn.net/weixin_41358004/article/details/103725821