如何完成全自动的部署和 BVT

• Dockerfile 部署 Spring Boot 应用的简单示例
  • 脚本逻辑是：指定一个提供 JDK 的基础镜像（FROM）及创建镜像时用到的变量（ARG），把应用的 jar 包复制到镜像中根目录下（COPY）；ENTRYPOINT 指定容器启动程序及参数。

    

  • 创建 docker 镜像，并启动容器实例的命令示例如下：

    

  • 在第一条命令中，Dockerfile 位于 /tmp/dockerfiles 目录下，逐条执行 Dockerfile 中的指令创建了一个名称和版本号为 my-image:1.0.0 的镜像文件；
  • 第二条命令是用生成的镜像启动一个容器，容器命名为 my-image。
• CI 配置管理工具Ansible
  • Ansible，它是一个基于 Python 开发的自动化运维工具，提供远程系统安装、启动 / 停止、配置管理等服务，并且可以对服务器集群进行批量系统配置、批量部署和批量运行命令
  • Ansible 还可以实现对 Docker 集群的自动化管理工作，比如安装、部署、管理 Docker 容器和 Docker 镜像
  • Ansible 架构示意图

    

  • Ansible 目录结构图

    

  • Ansible执行的脚本文件 playbook.yaml 做为入口文件，指定在哪些服务器集群为哪些 role 执行配置任务，示例如下：

    

  • Inventories 目录下的 hosts 文件存放所有目标服务器的地址。你可以为需要管理的应用创建一个对应的 role，比如 Nginx、Redis 等，把配置信息、需要执行的 shell 脚本存放在每个 role 的目录下
• 微服务在 CI 环境中的自动化部署
  • 目前主流的实践基本都是通过 SSH 协议和远程目标服务器建立连接，然后在目标服务器上执行 shell 命令进行部署，比如 Jenkins、Ansible、GitLab CI 等。
  • Jenkins + Docker 实现持续集成

    

  • 以 Jenkins 为例，一个微服务的构建部署过程如下。
  • 开发 push 代码到代码仓库，触发 Jenkins 拉取代码，通过构建服务器编译、测试、打包，然后执行 shell 脚本使 docker 构建镜像并 push 到镜像仓库。此操作完成后 Jenkins 服务器再执行 SSH 命令登录到部署服务器，执行 shell 脚本使 docker 从镜像仓库拉取镜像，启动容器。
  • Jenkins 运行机器上的 Shell 命令如下：

    

  • 目标服务器上的 Shell 命令如下：

    

  • 以 Jenkins Pipeline + Ansible 为例，Jenkins 内需要安装 Ansible 插件。微服务 Docker 镜像生成后，由 Ansible 上传至目标服务器，执行容器管理对应的 role 所定义的任务进行部署。

    

• BVT 究竟要验证哪些点
  • BVT（Build Verification Test）是持续集成的最后一步，也被称为冒烟测试（Smoke Testing）。“冒烟测试”这个术语来源于电子行业，先对电路板进行通电测试，如果冒烟，电路板存在致命的故障，就没有必要做进一步的测试了，否则需要做进一步的测试
  • BVT 就是用来验证软件的基本功能是否能正常工作，也是用于检验持续集成是否成功
  • 视频会议 App 的 BVT 测试项

    

  • 不稳定的情况 Flaky
    • 在持续集成中，Flaky 是影响自动化测试效率的一个主要因素
    • Flaky Test 的原因有很多，常见的有：
    • 测试用例代码的问题，比如存在异步等待：执行异步调用，并等待对方回复。如果某次运行中得到回复的时间比设定的等待时间长，测试用例就会失败。
    • 测试环境的稳定性问题，比如测试工具不够稳定；测试依赖的远程服务由于网络原因访问不可靠。
    • 正因为造成 Flaky Test 的原因复杂，目前还没有简单有效的办法彻底消除
• Docker 容器的集群管理之 Kubernetes
  • Kubernetes 做为 Docker 容器集群的管理工具主要有下列这些功能：
  • 以集群的方式运行、管理容器，比如复制、扩展容器等，并保证容器之间的通讯；
  • 保证系统服务的计算容量和高可用性，Kubernetes 具有自我修复机制，比如一个宿主机上的某个容器死掉之后，可以在另外一个宿主机上将这个容器迅速拉起来；
  • 对容器集群的自动化、全生命周期的管理，包括伸缩性、负载均衡、资源分配等
  • Kubernetes 的架构

  • 

  • 如图 1 所示，包括一个主节点（Master）和若干个工作节点（Node）。主节点负责对 Kubernetes 集群的控制和管理；工作节点中运行实际的应用系统。Pod 是每个工作节点中可以调度的最小单元，一个 Pod 包含一组容器。Kubernetes 能够管理的集群规模非常强大，单集群就可部署 5000 个工作节点、15 万个 Pods、30 万个容器。
  • Kubernetes 中的每个对象都对应声明式的 API，可以非常方便地通过执行配置文件进行资源的创建和管理。比如，你可以编写 Pod.yaml 文件来定义一个包含两个容器的 Pod，如图 2 所示

    

  • 安装 Kubernetes，可以借助两个工具：Vagrant 和 Ansible。先定义合适的 Vagrantfile（如图 3 所示）来安装虚拟机，包括下载镜像、初始化、配置等工作，并能保证 Kubernetes 的节点配置是一致的。

    

  • 然后再分别创建 Ansible 的 playbook（如 master-playbook.yml 和 node-playbook.yml）自动安装 Kubernetes 主节点和工作节点。这个操作相对比较复杂，比如安装容器及 kubelet、kubeadm、kubectl 等组件，使用 kubeadm 初始化容器集群、配置 kube 文件，以及建立主节点和工作节点的网络连接。可参考 Ansible、Kubernetes 官方网站和网上其他资料来完成具体操作。
  • Kubernetes 集群环境中部署流程图

    

  • 将软件开发、调试和测试部署在同一个 Kubernetes 开发集群中，实施快速迭代。
  • 将代码合并到 GitHub 代码库中，并进行检查，然后运行自动化的构建和 BVT（作为 CD 的一部分）。
  • 验证容器镜像的来源和完整性，在通过扫描之前镜像处在被隔离状态。
  • Kubernetes 使用 Terraform 之类的工具集群，Terraform 安装的 Helm 图表定义了所需的应用程序资源和配置状态。
  • 强制执行策略以管理 Kubernetes 集群的部署。
  • 发布管道会自动执行每个代码的预定义部署策略。
  • 将策略审核和自动修复添加到 CI / CD 管道，比如，只有发布管道有权在 Kubernetes 环境中创建新的 Pod。
  • 启用应用遥测（Telemetry）、容器运行状况监视和实时日志分析。
  • 利用深度分析发现问题，并为下一个迭代制定计划
• 基础架构即代码——Terraform
  • Terraform 具有完成完整的云基础架构创建的能力，并通过 DSL（Domain Specific Language，领域特定语言）以编程方式将各个组件链接在一起，并能将云基础设施的有用部分定义为带有参数化输入的模块，而且可以和其他模块集成，在不同的部署中一次又一次地使用，具有良好的复用性。这里列出 Terraform 其中的两个主要模块：
  • 管理模块，定义 VPC（Virtual Private Cloud，公有云上自定义的逻辑隔离网络空间）、子网、NAT（Network Address Translation，网络地址转换）网关、路由、安全组和 PuppetMaster 等；
  • 服务器模块，在其子网中定义多个消息代理和多个自定义服务器的层，并将它们动态链接到公共 ELB（负载均衡）。
• 管道即代码——Drone.io、ConcourseCI
  • 管道即代码工具。管道即代码，也叫流水线即代码，就是把管道部署流程写进一个脚本文件，然后用一条命令调用文件即可完成复杂的部署过程
• 新一代的部署体验——Serverless 软件系统架构
  • 近几年业界提出了 Serverless 架构，就是去服务器化的软件架构体系。Serverless 架构分为 Backend as a Service（BaaS）和 Functions as a Service（FaaS）两种技术，就是后端即服务和函数即服务。
  • Baas 技术提供软件应用依赖的服务端的服务。对于前后端分离的架构，只需要开发前端应用然后上传到云服务平台，后端应用和服务器端的部署和维护由云平台来提供
  • FaaS 技术通过函数提供应用系统依赖的通用功能，比如视频处理的人脸识别、视频转码等功能。企业开发的微服务主要负责业务逻辑的实现，通用功能由第三方提供的函数实现。这些微服务运行在无状态的临时容器中，容器和计算资源的协调由第三方去管理