华为云devops认证考试课堂笔记3

深碍√TFBOYSˉ_ 2022-11-11 05:54 571阅读 0赞

> 目前在备考华为云的devops认证考试，特把近期的笔记整理好，方便复习

### 文章目录 ###

*   *  目标
     *  持续交付
     *   *  持续交付的概念
         *   *  持续集成和持续交付
             *  持续部署
             *  微服务
             *  微服务设计-DDD领域驱动模型
             *  微服务底座chassis
             *  springcloud微服务框架
             *  serviceComb微服务框架
             *  华为微服务解决方案serviceStage平台
             *   *  场景一、服务应用解决方案
                 *  场景二、微服务的持续交付解决方案
             *  容器技术
             *  容器实现快速交付和部署
             *  容器技术
             *  docker
             *   *  docker三个关键技术
                 *  docker镜像
                 *  dockerfile构建容器镜像
                 *  docker发布系统工作机制
                 *  docker容器的持续部署流水线
                 *  容器让开发和运维协同工作
         *  容器编排
         *   *  概念
             *  k8s的概念
             *  k8s整体架构
             *  k8s关键概念-pod
             *  replicaset
             *  deployment
             *  statefulset
             *  daemonset
             *  service
             *   *  service的类型和解释
             *  ingress
             *  k8s工作原理
             *  应用容器化之CI/CD
             *  华为云容器引擎CCE
             *   *  优势：
                 *  关键特性
             *  基础设施即代码
             *  dockerfile-容器镜像构建文件
             *  kubernetes manifest
             *  编译构建
             *   *  编译构建工具
                 *  maven
             *  编译构建实践-容器镜像构建
             *  软件制品
             *  软件制品库
             *  devcloud中的软件制品库
             *  自动化部署
             *  部署服务的工作原理
             *  部署服务关键特性-批量部署
         *  软件发布
         *   *  发布定义
             *  部署和发布的关系
             *   *  单服务器组发布
                 *  蛮力发布（单服务器组）
                 *  金丝雀发布（单服务器组）
                 *  滚动发布（单服务器组）
             *  双服务器组发布
             *   *  蓝绿发布（双服务器组）
             *  功能开关-toggle/fetureFlag/switch
             *  A/B测试
             *  影子测试
             *  devcloud灰度发布的实践
             *  ILearning
             *   *  背景
                 *  方案
             *  流水线
             *   *  功能实现
                 *  关键特性-工作流编排
                 *  关键特性-流水线参数
                 *  关键特性-自动化质量门禁
                 *  关键特性-自动触发流水线
                 *  关键特性-定时执行流水线

## 目标 ##

*  了解持续交付的理念和特点
 *  了解容器技术与容器化应用在持续交付中的作用
 *  了解自动化技术和理念
 *  掌握编译构建的原理和方法
 *  掌握部署发布的策略和方法

## 持续交付 ##

### 持续交付的概念 ###

持续交付，continuous delivery，CD，是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状况。

目的：让软件的建置、测试和释出变得更快、更频繁。减少软件开发的成本与时间，减少风险。

持续交付以持续集成为基础。将集成后的代码部署到更贴近真实运行环境的类生产环境。给质量团队和用户，以供评审。

devops是三个持续的一个产物，持续交付和持续部署直接汇入devops。

#### 持续集成和持续交付 ####

持续集成 continuous integration，强调开发人员提交了新代码之后，立即进行构建、单元测试，根据测试结果，确定新代码和原有代码能否正确集成在一起。

持续交付 continuous delivery，是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没问题，可继续手动部署到生产环境。

#### 持续部署 ####

持续部署 continuous deployment，是在持续交付的基础上，把部署到生产环境的过程自动化。意味着除了自动化测试之外，还可以自动完成发布过程，并且可以通过单击按钮随时部署应用程序。

持续部署，是持续交付的下一步，代码通过评审后，自动部署到生产环境。持续部署的目标：代码在任何时刻都是可部署的，可进入生产阶段。

持续交付并不意味着每次变化都要尽快部署到生产环境，而是意味着每次变化都是随时可以部署的。

#### 微服务 ####

特征：

*  小，粒度小，专注一件事
 *  独，单独的进程
 *  轻，轻量级通信机制，通常HTTP/REST接口
 *  松，松耦合，可独立部署

#### 微服务设计-DDD领域驱动模型 ####

领域模型是能够精确反映领域中某一知识元素的载体，这种知识的获取需要通过与领域专家（domain expert）进行频繁的沟通才能将专业知识转化为领域模型。领域模型无关技术，具有高度的业务抽象性，能精确地描述领域中的知识体系；同时也是独立的，需要学会如何让它具有表达性，让模型彼此之间建立关系，形成完整的领域架构。

如果领域太复杂，涉及到的领域概念、业务规则、交付流程太多，导致没法直接针对其进行领域建模，需要拆分。

*  会员中心：负责用户账号登录，用户信息的管理
 *  商品中心：负责商品的展示、导航、维护
 *  订单中心：负责订单的生成和生命周期管理
    
     *  历史完成订单
     *  待支付订单
     *  取消订单
 *  交易中心：负责交易相关的业务
 *  库存中心：负责维护商品的库存
 *  促销中心：负责各种促销活动的支持

从本质上作为一种架构设计的方法的DDD和作为一种架构风格的microservices都是为了追求高响应力目标而从业务视角去分离复杂度的手段。

#### 微服务底座chassis ####

chassis，底盘，是一种微服务模式

当开始开发一个微服务应用时，常会花费大量的时间去关注一些横切面问题（cross-cutting concerns），如日志框架（log4x/logback），健康检查，metrics，分布式追踪；此外，还有一些针对特定技术的横切面问题。

在这种模式中，用户不需要自己去处理横切关注点，而是将其交给专门的框架处理，用户更聚焦业务逻辑本身，简单、快速的开发微服务。

#### springcloud微服务框架 ####

是一系列框架的有序集合，利用springboot的开发便利性，简化分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。

*  zuul是Netflix的一个基于JVM路由和服务端的负载均衡器，作用：服务转发，接收并转发所有内外部的客户端调用。
 *  eureka，Netflix的服务注册和发现组件
 *  config为服务端和客户端提供分布式系统的外部化配置支持。server提供配置文件的存储、以借口的形式将配置文件的内容提供出去；client通过接口获取数据，并依据此数据初始化自己的应用
 *  zipkin是分布式实时数据追踪系统，sleuth为服务之间的调用提供链路追踪
 *  feign是一个声明式的web service客户端，整合ribbon和hystrix，让我们不再需要显式的使用这两个组件

#### serviceComb微服务框架 ####

作为功能完善的微服务框架，包括应用框架代码生成，服务注册发现，服务配置管理，服务监控，服务调用追踪，多通信协议支持等功能

具备服务化契约增强，事件驱动等优势，提供分布式事务追踪能力，较好的解决企业应用微服务开发遇到的问题。

#### 华为微服务解决方案serviceStage平台 ####

是个应用托管和微服务管理平台，帮助企业简化部署、监控、运维和治理等应用生命周期管理工作。包含应用开发、持续交付、应用托管、生命周期管理和微服务治理五大功能。

##### 场景一、服务应用解决方案 #####

提供serviceComb、spring cloud和service mesh多种解决方案，帮助用户建设企业级微服务平台

优势：

*  API First：支持基于swagger的API管理
 *  多语言微服务
 *  技术开放

##### 场景二、微服务的持续交付解决方案 #####

基于serviceStage流水线，实现集成环境统一、交付流程标准化，可以实现全流程自助式开发、自验、集成验证与上线。

优势：

*  一键生成持续交付环境：自动生成应用框架代码、构建、部署及测试环境
 *  多语言
 *  多源码仓库：codehub、github、gitee、gitlab、bitbucke

#### 容器技术 ####

背景：高度分散和异构化的部署环境

#### 容器实现快速交付和部署 ####

关键价值

*  快速交付和部署：一站式部署/运维容器应用，一键式滚动升级
 *  提升资源利用率：更细粒度的划分资源，提高资源利用率
 *  保障业务高可用：秒级弹性扩容，快速响应并发高峰
 *  复杂系统管理简单：单一重型应用解耦拆分为多个轻量模块，每个模块升级、伸缩更加灵活、轻松

#### 容器技术 ####

一个是docker为代表的容器引擎技术，另一个是以k8s为标准的容器编排技术

docker代表容器引擎技术是因为docker主导了容器引擎的标准OCI，OCI实际定义了容器的编译方式、技术上的约束，很多其他容器技术都遵循或兼容OCI标准。

k8s是业界公认的容器编排领域的事实标准。完全开源，各厂商做商业性增强。

#### docker ####

最主流的容器运行时技术，提供容器的运行时能力，经过多次容器技术标准的演进和OCI标准的建立，目前的架构：

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eqTHumWT-1616148287704)(img\\01.png)\]

docker技术特点：

*  容器镜像定义了统一的软件交付标准
 *  文件挂载提供了更小资源占用的运行环境
 *  共享OS内核使容器本质上只是一个进程，秒级启停

docker技术优势：

*  统一的交付标准可以屏蔽环境差异，使能devops
 *  更小的资源消耗，提高资源利用率，匹配微服务架构
 *  极速的弹性伸缩、故障恢复，解放运维生产力

docker是最主流的容器运行时，即容器引擎。containerd是容器技术标准化之后的产物，为了能够兼容OCI标准，独立负责容器运行时和生命周期（如创建、启动、停止、中止、信号处理、删除等），从daemon中剥离，向docker engine提供运行容器的API，通过gRPC通信；每创建一个容器，containerd都会创建一个shim进程，每个shim会调用runc(前身是libcontainer)进行实际的容器运行时管理，如创建namespace的隔离。

##### docker三个关键技术 #####

*  namespace，实现容器运行环境的隔离，容器应用进程之间不可见，包括进程隔离、网络隔离、文件隔离
 *  cgroup，实现容器运行的资源隔离，可以为每个容器指定资源数量，避免容器间资源抢占和冲突
 *  union filesystem，一种分层、轻量级且高性能的文件系统，支持对文件系统的修改作为一次提交来叠加，是容器镜像的基础

##### docker镜像 #####

docker镜像文件image，提供一个快速部署的模板，包含已经打包好的应用程序和运行环境，基于image可快速部署多个相同的容器。

docker镜像是个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置文件外，还包含一些为运行时准备的一些配置参数，镜像不包含任何动态数据，内容在构建之后也不会改变。

镜像特点是分层存储，由于镜像包含OS完整的root文件系统，体积庞大，在docker设计时，充分利用union FS技术，将其设计为分层存储的架构，严格意义说，镜像只是虚拟的概念，由多层文件系统联合组成。

实际镜像是一系列分层的只读文件，而当容器镜像运行为容器时，会在镜像的最上层添加一个可写的层，也就是容器层，所有对运行时容器的修改其实都是对这个读写层的修改。所有对容器的变化，如写新的文件，修改已有文件和删除文件，都只会作用在这个容器层之中。

优点：

*  多个容器共享image存储，节省存储空间
 *  部署多个容器时，base image可避免多次拷贝，实现快速部署

##### dockerfile构建容器镜像 #####

镜像是应用发布的标准格式，通过dockerfile描述，可构建为一个tar包。

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hlUygina-1616148287706)(img\\02.png)\]

docker镜像的生命周期：

*  docker pull：从镜像仓库拉取一个镜像
 *  docker push：推送镜像到镜像仓库
 *  docker build：将dockerfile构建为镜像
 *  docker tag：为镜像打上标签

docker容器的生命周期管理：

*  docker run：运行一个容器
 *  docker stop：停止一个容器
 *  docker start：启动一个容器
 *  docker restart：重启一个容器
 *  docker kill：杀死一个运行的容器
 *  docker pause：暂停一个容器

##### docker发布系统工作机制 #####

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ztEOQxzA-1616148287708)(img\\03.png)\]

镜像提供了一种标准化运输或发布方式，发布系统工作机制就是build、ship、run

docker的重要组件：

*  docker引擎
 *  docker客户端
 *  镜像仓库

##### docker容器的持续部署流水线 #####

以容器镜像作为devops流程的标准交付件，将应用程序代码和运行环境（依赖的库文件和系统服务、环境配置等）进行整体打包发布，统一打包格式，实现跨阶段的标准化发布流程。

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-55IcEpJ3-1616148287711)(img\\04.png)\]

jenkins编译构建，jenkins根据代码工程中的dockerfile即可构建为docker容器镜像，然后使用镜像，触发部署，通过k8s集群进行可视化编排和容器集群管理，如弹性伸缩，滚动升级等。统一格式打包的镜像可一致性的部署到开发、测试、生产环境，容器镜像作为devops流程的标准交付件，实现跨阶段的标准化发布流程。

##### 容器让开发和运维协同工作 #####

开发人员关注容器内的：

*  code
 *  libraries
 *  package manager
 *  apps
 *  data

针对任何环境都采用同样方式打包，除了开发时，也要关心运行时

运维人员只需关心容器外的事情

*  远程访问
 *  监控
 *  网络配置

所有的容器采用同样的方式启动，停止，复制，接入和升级

### 容器编排 ###

#### 概念 ####

一组互相连接的操作系统（实体机/虚拟机/容器）形成一个整体的资源池

可扩展到上千个节点，具备自我修复，扩展和收缩能力

作为环境抽象层存在，使得应用可不关心所运行的节点

容器集群的关联及诶DNA会在集群的每个业务节点中部署一个agent，形成一个整体的资源池，且作为环境抽象层存在。

#### k8s的概念 ####

k8s是用于自动部署，扩展和管理容器化应用程序的开源系统

*  生产级别的容器编排系统
 *  数据中心OS
 *  新生代的云平台

k8s：cluster scheduler–>scheduled containers

docker: node container manager–>managed base os

#### k8s整体架构 ####

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xr132DVC-1616148287713)(img\\05.png)\]

master:

*  api server：提供接口供客户端kubectl或者k8s其他组件，管理cluster的各种资源，主要提供k8s API，对pods、services、replicationController等对象的CRUD，处理REST操作，并验证它们
 *  scheduler：负责决定将pod放在哪个node上运行，调度时会充分考虑高可用、性能、数据亲和性的需求
 *  controller manager：负责管理cluster各种资源，由多种controller组成，包括replication controller、namespace controller等
 *  replication controller：管理deployment、replicaset、daemonset等的生命周期

node(worker): 运行工作负载的节点，运行容器应用，node由master统一管理，负责监控并汇报容器的状态，同时根据master的要求管理容器的生命周期

*  kubelet：node上的agent，当scheduler确定在某个node上运行pod后，会将pod的具体配置信息（image、volume等）发送给该节点的kubelet，kubelet会根据这些创建和运行容器，并向master报告运行状态。kubelet管理pods和它们的容器、镜像、卷等。
 *  kubeproxy：提供统一的访问能力，转发service请求到pod，如果有多个副本，kubeproxy会实现负载均衡
 *  kubectl: k8s的命令行工具，kubectl连接APIServer，通过kubectl可部署和管理应用，查看各种资源、创建、删除更新各种组件。

第三方组件

*  etcd：更新相应的对象API，负责保存cluster的配置信息和各类资源的状态信息
 *  docker
 *  监控

#### k8s关键概念-pod ####

在k8s中，pod是能够创建、调度和管理的最小部署单元，是一组容器实例的集合，而不是单独的应用容器。

pod中的容器作为一个整体被master调度到一个node中运行，同一个pod里的容器共享同一个网络命名空间，IP地址及端口空间和卷

从生命周期看，pod是短暂的而不是长久的应用，pod被调度到节点，保持在这个节点直至被销毁。

#### replicaset ####

副本控制器，主要控制deployment应用副本的数量

解决了pod的扩容和缩容问题，通常用于无状态应用。

#### deployment ####

无状态应用，用户会创建一个deployment，deployment自己建replicaset，replicaset建pod，典型应用是nginx和tomcat

#### statefulset ####

有状态的应用，如mysql、redis，每个实例都是唯一的，会区分主从实例，每个实例的重启都是有顺序的

#### daemonset ####

daemonset能够让**所有（或一些特定）的node节点运行同一个pod**。当节点加入到k8s集群中，pod会被daemonset调度到该节点运行。当节点从k8s集群中移除，被daemonset调度的pod会被移除，如果删除daemonset，所有跟这个daemonset相关的pods都会被删除

在使用k8s运行应用时，很多时候需要在一个区域zone或者所有node节点运行同一个守护进程pod，如

*  每个node上运行一个分布式存储的守护进程，如glustered，ceph
 *  运行日志采集器在每个node上，如logstash、fluentd
 *  运行监控的采集端在每个node上，如prometheus node exporter，collectd等

apiVersion:extensions/v1beta1
    kind:DaemonSet
    metadata:
    	name:tomcat-ds
    spec:
    	template:
    		metadata:
    			labels:
    				app: tomcat
    		spec:
    			containers:
    			- name: tomcat
    				image:tomcat:8.0.30-jre8
    				ports:
    				- containerPort: 8080

#### service ####

service定义了pods的逻辑集合和访问这个集合的策略。pods集合是通过定义service时提供的label选择器完成的。

service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service提供代理

service的抽象使得前端客户和后端pods解耦

k8s services支持tcp和udp协议，默认tcp

kind: Service
    apiVersion: v1
    metadata:
     name: my-service
    spec:
     selector:
      app: A
     port:
     - protocol: TCP
      port: 80
      targetPort: 9376
      nodePort: 30061
     type: ClusterIP

##### service的类型和解释 #####

三种类型：clusterIP，NodePort，LoadBalancer，Service定义的是一种四层转发，也可理解为四层负载均衡。是通过iptables（或IPVS）的方式实现，只支持随机转发

*  ClusterIP：使用集群内的私有IP，主要在每个node节点使用iptables，将发向clusterIP对应端口的数据，转发到kube-proxy中，然后kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个service下对应pod的地址和端口，进而把数据转发给对应的pod的地址和端口
 *  nodePort：除了使用cluster ip外，也将service的port映射到每个node的一个指定内部port上，映射的每个node的内部port都一样，原理在于在node上开了个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步导入对应的pod
 *  loadBalancer：使用一个clusterIP&nodePort，但是会向cloud provider申请映射到service本身的负载均衡，loadBalancer和nodePort其实是一种方式，区别在于loadBalancer比nodePort多了一步，就是科研调用cloud provider去创建LB向节点导流

#### ingress ####

service和pod仅可在集群内部网络中通过ip地址访问，所有到达边界路由器的流量或被丢弃或被转发到其他地方

ingress是授权入站连接到达集群服务的规则集合

可给ingress配置提供外部可访问的url、负载均衡、SSL、基于名称的虚拟主机等。用户通过post ingress资源到API server的方式来请求ingress，ingress controller负责实现ingress，通常使用负载均衡器，它还可以配置边界路由和其他前端，有助于以HA方式处理流量。

service提供4层访问，ingress提供7层访问，在集群北向提供7层负载均衡能力，对接创建的service实现7层转发能力，一般通过nginx实现网络转发

七层负载均衡采用增强型弹性负载均衡，在4层的基础上支持了URL配置，通过对应的url将访问流量分发到对应的服务。同时服务根据不同的url实现不同的功能。

通过配置公网类型和私网类型的负载均衡实例，可实现公网的7层路由转发和内网（同一VPC内）的7层路由转发

#### k8s工作原理 ####

\[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KpAebg1P-1616148287715)(img\\06.png)\]

在整个生命周期流程中，controller-manager会持续watch各类set，定期同步，保证最终一致性，而scheduler会持续watch集群的node供调度使用，kubelet会持续watch被调度到本节点的pod，执行生命周期动作。

#### 应用容器化之CI/CD ####

docker和k8s实现了应用容器化，并促进了CI/CD流程，降低应用从构建到部署流程的复杂性，加速业务的快速迭代

#### 华为云容器引擎CCE ####

##### 优势： #####

多样的生态接入

*  支持多语言多框架服务接入
 *  支持第三方模板和镜像快速部署

增强的商用化特性

*  通过自动化配置、构建、部署提升业务上线效率
 *  通过跨可用区高可用和控制面板HA提升业务可靠性
 *  通过物理共享集群提供敏捷可靠的容器适应业务多样化

完全开放的原生平台

*  紧跟k8s和docker社区，迅速同步最新版本
 *  支持原生API调用和命令行操作

高性能基础设施

*  支持多种异构Iaas：虚拟机、物理机、ARM服务器
 *  支持多种存储：云硬盘、对象存储、文件存储
 *  对接公私网络：虚拟私有网络、EIP公网

##### 关键特性 #####

*  一站式部署和运维：一键创建k8s集群，自动化部署、运维容器应用，整个生命周期都在容器服务内一站式完成
 *  可定制化的devops能力：支持多语言代码开发一键式生成镜像能力
 *  灵活的弹性伸缩策略：支持按性能、按时间、按周期的弹性伸缩策略，用户可自由组合策略以应对多变的突发浪涌
 *  IaaS资源的深度整合：直接使用华为云ECS/BMS、网络（VPC/EIP）、存储（EVS/OBS/SFS）能力
 *  高可用业务不中断：集群控制面HA和跨AZ高可用，容器应用优雅伸缩，安全下线，保障业务不掉线
 *  兼容原生k8s和docker

#### 基础设施即代码 ####

也就是自动化。目标是通过可重用的代码实现IT环境变更的自动化。用代码或配置文件来声明应用系统使用的基础设施资源。把环境的创建过程使用代码的形式描述出来，并提交到代码库。任何的环境变更都必须通过修改代码、提交，然后总是使用代码库的最新版本重新构建环境，所有的机器的状态都是可预测的。常见的自动化配置管理工具是ansible、puppet等。

ansible是个开源配置管理工具，使用它来自动化任务部署应用程序，实现IT基础架构。可用来自动化日常任务，如服务器的初始化、配置、安全基线配置、更新和打补丁系统安装软件包等。

#### dockerfile-容器镜像构建文件 ####

docker hub中99%的镜像都是通过在base镜像中安装和配置需要的软件构建出来的。

FROM debian
    RUN apt-get install emacs
    RUN apt-get install apache2
    CMD ["/bin/bash"]

dockerfile: 文件指令集，描述如何自动创建docker镜像，包含若干指令，指令执行后，会创建一个个新的镜像层。

包括4部分：

*  基础镜像信息
 *  维护者信息
 *  镜像操作指令
 *  容器启动指令

docker常见参数：

*  `FROM <image>` 或`FROM <image>:<tag>` ： 基于哪个镜像，`<image>` 首选本地是否存在，如果不存在则会从公共仓库下载
 *  WORKDIR：切换目录用，可多次切换（相当于cd命令），对RUN, CMD, ENTRYPOINT生效
 *  RUN: 执行指令
 *  EXPOSE: EXPOSE指令告诉容器在运行时要监听的端口，但是该端口用于多个容器之间通信用的links，外面的host访问不到，要把端口暴露给外面的主机，在启动容器时使用-p选项
 *  VOLUME: 指定挂载点/data
 *  CMD: 用于容器启动时指定的服务

#### kubernetes manifest ####

通过k8s manifest文件可以用yaml形式描述在k8s中以pod的形式运行的应用容器，以及要运行多少个应用的副本。

#### 编译构建 ####

编译构建是指把软件的源代码编译为目标文件，并把配置文件和资源文件等打包的过程。

输入时源代码文件、库文件、配置文件、资源文件等

输出是软件包：一个可以直接部署的软件，或者是一个可被其他软件使用的lib

编译器完成“ 编译”过程，编译管理工具完成“构建”过程。

依赖管理+编译+打包=编译构建

##### 编译构建工具 #####

*  ant：手动配置，如依赖库、输入输出的位置，甚至在本地安装这些库
 *  maven：约定大于配置，简化用户使用，自动下载依赖的仓库
 *  gradle：配置即代码，更强大和灵活

ant对应ivy依赖，在ant的构建文件中定义ivy任务实现调用ivy的功能，从而实现依赖管理。

##### maven #####

可用groupId、artifactId、version组成的坐标唯一标识一个依赖

pom.xml文件

maven构建：源代码（pom.xml、src）–>maven构建环境（setting.xml、java环境、maven core仓库），需要大量配置和维护

CMake构建：第三方库、依赖文件(lib、dyli…)、代码文件(h、cpp…)–>Cmakelists.txt–>cmake为Makefile–>make为可执行文件(exe、out…)

#### 编译构建实践-容器镜像构建 ####

dockerfile是一个文本格式的配置文件，包含创建镜像所需的全部指令，基于dockerfile的指令，用户可快速创建自定义的镜像

#### 软件制品 ####

软件研发过程中的“源码”和“软件制品包”（俗称二进制包）都是很关键的资产。制品包通常是源码文件的集合或编译后的产物，因此主要有二进制包和压缩包两种形式。

管理方法

包文件通常不在源码库中管理，而是使用专门的**包文件仓库**进行存储并配合包文件依赖管理工具（嘛呢、NPM、ivy）进行使用。

#### 软件制品库 ####

能够统一管理各种类型的二进制制品，同时无缝对接现有的标准化构建和发布工具的软件平台。

软件包及其属性的管理是发布过程管理的基础；软件制品库，用于管理软件包，是连接持续集成和持续交付的重要环节，软件包的发布评审、追溯和安全控制等操作通常在其中进行。

软件制品库的作用：

*  IDE对接
 *  快速获取依赖包
 *  识别开源软件风险
 *  中央仓库对接
 *  开源包镜像，提升下载效率
 *  开源宝策略管理，过滤有害包文件
 *  ‘构建工具对接
 *  复用私有包，提升构建效率
 *  开源依赖包获取，提升构建效率
 *  部署工具对接
 *  利用有序调度不同环境部署，实现持续交付

#### devcloud中的软件制品库 ####

*  私有依赖库：华为云提供的二方组件仓库，目前只支持maven格式的组件管理
 *  软件发布库：面向开发者提供软件发布的云服务，软件仓库、软件发布、发布包下载、发布包元数据管理等功能，通过安全可靠的软件仓库，实现软件包版本管理，提升发布质量和效率，实现产品的持续发布
 *  开源镜像站：三方组件仓库，提供开源组件、开源OS及开源devops工具下载
 *  容器镜像服务：支持容器镜像全生命周期管理的服务

#### 自动化部署 ####

将可交付产品，快速安全的交付用户使用的一套系统和工具，系统会自动构建、测试并准备代码变更，以便将其发布到指定环境的过程，包括dev、test、prod，包含应用管理、环境管理、部署、编排、执行等功能。

华为云CloudDeploy提供自动化部署能力，可实现：

部署应用到物理机、虚机、容器

*  支持将应用部署到物理机、虚机、容器
 *  支持主机有agent或无agent模式提供应用监控数据
 *  支持以代理机的方式进行部署
 *  支持部署到应用管理平台，纳管容器云集群或客户的私有k8s集群

支持多种技术栈应用的部署

*  支持tomcat、springboot、nodejs等
 *  支持springcloud、serviceComb、dubbo等微服务应用部署和治理能力
 *  提供通用模板，且支持自定义模板组装部署任务

支持与流水线、运维管理无缝集成

*  在流水线能关联部署任务
 *  通过流水线关联构建，代码检查，测试等服务，实现端到端devops流程
 *  应用部署后的可运维管理

#### 部署服务的工作原理 ####

云主机部署用户通过手动上传、或者编译构建任务，将软件包保存在软件发布库；部署任务将软件包上传并安装到云主机

容器部署用户通过手动上传、或者编译构建任务，将镜像保存到容器镜像仓中；部署任务将镜像上传到容器镜像集群中

#### 部署服务关键特性-批量部署 ####

多个目标主机执行部署任务

主机组：多态主机的组合，将多个主机添加到某一主机组中，通过主机组在多台主机上并行执行部署任务

环境：是计算、存储、网络等基础设施的集合。环境内部网络互通环境中，通常可包含主机、集群、数据库、ELB、微服务、引擎等资源。用于管理一组网络互通的资源，可预定义生产环境、测试环境等，环境中可添加主机组、数据库、容器集群等资源，作为部署任务的对象。

部署步骤，以tomcat为例：

*  安装tomcat和依赖的jdk，在主机组上安装jdk时指定部署目标主机、jdk版本、jdk安装路径
 *  停止tomcat服务
 *  选择部署来源，**指定软件发布仓的文件**，获取tomcat上部署的应用打包
 *  启动tomcat服务，部署完成后，**url健康测试**，通过访问输入的url，测试服务状态是否OK

### 软件发布 ###

#### 发布定义 ####

将开发好的应用程序正式公布出来的过程

ITIL中定义的发布管理目标包含：

*  规划、协调软件和硬件的实施（或安排实施）
 *  针对分发和安装对系统实施的变更而设计和实施有效的程序
 *  确保和变更相关的硬件和软件时可追溯和安全的（正确的、经过批准和测试的版本才能被安装）
 *  在新发布的规划和试运行期间和用户进行沟通并考虑他们的期望
 *  保障发布软件的原始拷贝被安全的存放在最终软件库，配置信息存储在配置管理数据库

#### 部署和发布的关系 ####

将部署和发布解耦，实现低风险发布

*  部署：在特定的环境上安装指定版本的软件，部署可能与某个特性的发布有关，也可能无关
 *  发布：把一个/组特性提供给（所有或部分）客户

基于环境的发布模式：

*  关注两个或更多环境，但只有一个环境正在接受实时客户流量
 *  新代码部署到非生产环境中
 *  该版本将流量切换到此环境
 *  只需要很少或不需要更改应用程序
 *  包括：blue-green蓝绿发布、canary金丝雀发布、cluster immune systems集群免疫系统

基于应用的发布模式：

*  通过feature toggle来启用特定应用程序功能的发布和展示，启用范围：开发团队、内部员工、1%的客户、整个客户群
 *  实现dark launch黑启动（Facebook聊天功能、baidu关键词联想功能）
 *  缺点：
    
     *  有代码侵入
     *  特性开关也是技术债务，需定期清理
     *  同时增加测试的复杂性，需打开所有特性开关（也许需要排列组合），还要测试特性开关功能本身是否正常

##### 单服务器组发布 #####

传统数据中心，机器资源比较紧张，应用机器基本上是预先静态分配好的（一般由运维负责分配），原来应用A运行在这n台机器上，那么下次升级发布的应用A也运行在这n台机器上，所以称为单服务器组发布方式。

包括蛮力发布、金丝雀发布、滚动发布

##### 蛮力发布（单服务器组） #####

完全靠手工完成软件的升级与发布，在发布过程中会进行人为的终端，进行应用升级

劣势：服务终端用户受影响，出问题回退也慢，影响用户使用体验

##### 金丝雀发布（单服务器组） #####

在金丝雀开始后，先启动一个新版本应用，但不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀

优势：用户体验影响小，发布过程出问题只影响少量用户

劣势：发布自动化程度不够，发布期间可引发服务中断

具体流程：先发布1台，或小比例如2%的服务器，做流量验证用，如果金丝雀测试通过，将剩余的v1版本全部升级v2，如果测试失败，直接回退金丝雀，发布失败

##### 滚动发布（单服务器组） #####

滚动发布：一般取出一个或多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有实例都更新为新版本。

优势：用户体验影响小，体验较为平滑

劣势：发布回退时间较慢；发布工具较复杂，LB需要平滑的流量摘除和拉入能力

滚动发布是自动化程度较高的发布方式，主流发布方式。

#### 双服务器组发布 ####

随着云计算和虚拟化技术的成熟，特别是容器等轻量级虚拟化技术的引入，计算资源受限和申请缓慢问题已经逐步解决，可做到弹性按需分配。为一次发布分配两组服务器，一组运行现有的V1老版本，一组运行待上线的V2新版本，再通过LB切换流量方式完成发布，就是所谓的双服务器组发布方式。

具体的发布策略有蓝绿发布、金丝雀发布、滚动发布功能开关、AB测试、影子测试

##### 蓝绿发布（双服务器组） #####

蓝绿发布，是一种可保证系统在不间断提供服务的情况下，上线的部署方式。蓝绿部署的模型包含两个集群，部署过程，并不停掉老版本，而是直接部署一套新版本，等新版本运行起来，再将流量切换到新版本

#### 功能开关-toggle/fetureFlag/switch ####

利用代码中的功能开关来控制发布逻辑，一般不需要复杂的发布工具和智能LB配合，是一种相对比较低成本和简单的发布方式。

需要一个配置中心或开关中心这样的一个服务支持，通过配置中心运维或研发人员可以在运行期间动态配置功能开关的值。

#### A/B测试 ####

用来测试应用功能表现的方法，例如可用性、受欢迎程度、可见性等。目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获取具有代表性的实验结论，并确信该结论在推广到全部流量可信。

eg,原先的PC端和手机端都访问老版本V1服务（A组或控制组），当V2新版本（也叫B组或实验组）发布后，为验证V2的功能正确性，同时也为了避免V2有问题影响所有用户，先通过LB将手机端的流量切换到V2版本，经过一段时间的A/B测试和观察（主要是用户和监控反馈），确保V2正常，然后通过LB将全部流量切换到V2

AB测试和功能开关类似，但功能开关一般无状态和全量的，无法做到针对某类特定用户进行测试，而AB测试一般有状态，能根据事物和用户级别的状态，实现针对某类特定用户进行测试。

#### 影子测试 ####

对于一些涉及核心业务的遗留系统的升级改造，为确保万无一失，使用影子测试，采用比较复杂的流量复制、回放和比对技术实现。

#### devcloud灰度发布的实践 ####

主要特色：

*  根据用户画像，精准分层用户，灰度逐步递进，全部保证能够检测到所有的用户分群
 *  提供多种灰度策略，如特性开关、AB测试、在线验收测试、友好用户测试等模式
 *  精准把控灰度批次比例，借助SLB服务，严格按照1%、9%、45%、95%，谨慎比例逐步放大灰度群体

#### ILearning ####

##### 背景 #####

敏捷转型，两周一个迭代进行交付，但如果每两周都将产品部署到生产环境交付给用户，非常痛苦，每两周就要周末加班熬夜部署，并赶在用户上班使用之前验证部署结果。

##### 方案 #####

要进一步缩短交付周期，必须做到生产环境部署发布的不停机，既要对用户无感知不影响用户体验，同时也保证部署是成功和安全的。引入“蓝绿部署”的实践，在华为称为“双活”。

使用两套一致的环境，一套在线提供服务，一套闲置准备用于下个版本的部署。有时也将两套都在线提供服务，互为灾备。

步骤：

*  通过路由切换，将流量都切换到C区服务区，G区无流量
 *  对数据库进行变更（保持对应用向下兼容）
 *  对G区4台服务器部署，启动第4台服务器进行验证
 *  若验证不通过，回滚G区的部署
 *  若验证通过，启动G区集群
 *  通过路由切换，将流量都切换到G区，C区无流量
 *  以同样方式对C区进行部署和验证，最后启动集群

#### 流水线 ####

一条流水线就是一个或多个自动化任务或人工任务组合起来的进行交付的工具。

流水线实现devops模式下持续开发、持续测试、持续集成、持续部署和持续监控这些活动的编排并自动化执行、结果反馈，实现商业敏捷。

为什么需要流水线

*  CI/CD无缝结合快速迭代，提升交付效率，适应市场需求频繁变化
 *  每个环节都有反馈，实现完整快速的反馈循环
 *  开发、测试、运维人员协作参与，改善公司组织文化，提升员工的参与感

通过流水线可让部署成为一个日常的低风险的工作来解决开发和运维岗之间的根本的长期的冲突。

流程：用户场景–>需求分析–>架构设计–>代码编写–>本地构建–>提交代码–>代码下载–>云端构建–>静态检查–>α测试–>β测试–>γ测试–>dog food–>发布决策–>变更申请–>灰度发布–>监控运维–>运营反馈

流水线助力持续交付高质量应用

*  分层分级：可通过子流水线-stage-job实现多级灵活串并行调度
 *  快速调度：纳管研发过程中编译构建、代码检查、部署等多种自动化任务
 *  质量管控：设置自动化质量门禁，人工卡点，等待时间等控制任务

##### 功能实现 #####

*  工作流编排：可按需定制自动化工作流程，配置阶段内任务为串行或并行执行，满足用户一键devops持续交付场景
 *  自动触发流水线：通过配置流水线触发器，可支持代码提交自动执行流水线
 *  流水线定时执行：用户可按周或按日指定流水线定时自动执行，并将结果通知给指定的用户，实现人休息而版本级交付不休息
 *  支持多种任务：纳管研发过程中编译构建、代码检查、部署、测试等多种自动化任务，此外，还提供延迟执行、人工审核等流水线内置任务
 *  质量管控：支持多重质量门禁，任务健康度统计等，呈现价值流中耗时长、错误率高的阻塞点，做质量守护的一道大闸
 *  其他：自定义权限配置；准确报错，异常提示联动在线帮助平台；开放对接jenkins任务

##### 关键特性-工作流编排 #####

流水线由各阶段stage组成，阶段内每个块是任务原子task

阶段支持串行/并行、自动/手动等配置

阶段分为自定义阶段、发布仓库两种类型

支持10+种任务类型，根据业务需求自由组装流水线

支持自由拖拽、复制、编辑各阶段任务

流水线上任务支持一键跳转编辑

##### 关键特性-流水线参数 #####

流水线参数传递到各任务，实现产物的价值流动

流水线参数支持文本、主机组、枚举、自增长等4种参数类型

流水线参数分为静态参数和动态参数，静态参数值总等于预设值，动态参数可被传参修改

统一使用`${xxx}` 进行参数化配置