目前在备考华为云的devops认证考试,特把近期的笔记整理好,方便复习
持续交付,continuous delivery,CD,是一种软件工程手法,让软件产品的产出过程在一个短周期内完成,以保证软件可以稳定、持续的保持在随时可以发布的状况。
目的:让软件的建置、测试和释出变得更快、更频繁。减少软件开发的成本与时间,减少风险。
持续交付以持续集成为基础。将集成后的代码部署到更贴近真实运行环境的类生产环境。给质量团队和用户,以供评审。
devops是三个持续的一个产物,持续交付和持续部署直接汇入devops。
持续集成 continuous integration,强调开发人员提交了新代码之后,立即进行构建、单元测试,根据测试结果,确定新代码和原有代码能否正确集成在一起。
持续交付 continuous delivery,是持续集成的延伸,将集成后的代码部署到类生产环境,确保可以以可持续的方式快速向客户发布新的更改。如果代码没问题,可继续手动部署到生产环境。
持续部署 continuous deployment,是在持续交付的基础上,把部署到生产环境的过程自动化。意味着除了自动化测试之外,还可以自动完成发布过程,并且可以通过单击按钮随时部署应用程序。
持续部署,是持续交付的下一步,代码通过评审后,自动部署到生产环境。持续部署的目标:代码在任何时刻都是可部署的,可进入生产阶段。
持续交付并不意味着每次变化都要尽快部署到生产环境,而是意味着每次变化都是随时可以部署的。
特征:
领域模型是能够精确反映领域中某一知识元素的载体,这种知识的获取需要通过与领域专家(domain expert)进行频繁的沟通才能将专业知识转化为领域模型。领域模型无关技术,具有高度的业务抽象性,能精确地描述领域中的知识体系;同时也是独立的,需要学会如何让它具有表达性,让模型彼此之间建立关系,形成完整的领域架构。
如果领域太复杂,涉及到的领域概念、业务规则、交付流程太多,导致没法直接针对其进行领域建模,需要拆分。
从本质上作为一种架构设计的方法的DDD和作为一种架构风格的microservices都是为了追求高响应力目标而从业务视角去分离复杂度的手段。
chassis,底盘,是一种微服务模式
当开始开发一个微服务应用时,常会花费大量的时间去关注一些横切面问题(cross-cutting concerns),如日志框架(log4x/logback),健康检查,metrics,分布式追踪;此外,还有一些针对特定技术的横切面问题。
在这种模式中,用户不需要自己去处理横切关注点,而是将其交给专门的框架处理,用户更聚焦业务逻辑本身,简单、快速的开发微服务。
是一系列框架的有序集合,利用springboot的开发便利性,简化分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
作为功能完善的微服务框架,包括应用框架代码生成,服务注册发现,服务配置管理,服务监控,服务调用追踪,多通信协议支持等功能
具备服务化契约增强,事件驱动等优势,提供分布式事务追踪能力,较好的解决企业应用微服务开发遇到的问题。
是个应用托管和微服务管理平台,帮助企业简化部署、监控、运维和治理等应用生命周期管理工作。包含应用开发、持续交付、应用托管、生命周期管理和微服务治理五大功能。
提供serviceComb、spring cloud和service mesh多种解决方案,帮助用户建设企业级微服务平台
优势:
基于serviceStage流水线,实现集成环境统一、交付流程标准化,可以实现全流程自助式开发、自验、集成验证与上线。
优势:
背景:高度分散和异构化的部署环境
关键价值
一个是docker为代表的容器引擎技术,另一个是以k8s为标准的容器编排技术
docker代表容器引擎技术是因为docker主导了容器引擎的标准OCI,OCI实际定义了容器的编译方式、技术上的约束,很多其他容器技术都遵循或兼容OCI标准。
k8s是业界公认的容器编排领域的事实标准。完全开源,各厂商做商业性增强。
最主流的容器运行时技术,提供容器的运行时能力,经过多次容器技术标准的演进和OCI标准的建立,目前的架构:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eqTHumWT-1616148287704)(img\01.png)]
docker技术特点:
docker技术优势:
docker是最主流的容器运行时,即容器引擎。containerd是容器技术标准化之后的产物,为了能够兼容OCI标准,独立负责容器运行时和生命周期(如创建、启动、停止、中止、信号处理、删除等),从daemon中剥离,向docker engine提供运行容器的API,通过gRPC通信;每创建一个容器,containerd都会创建一个shim进程,每个shim会调用runc(前身是libcontainer)进行实际的容器运行时管理,如创建namespace的隔离。
docker镜像文件image,提供一个快速部署的模板,包含已经打包好的应用程序和运行环境,基于image可快速部署多个相同的容器。
docker镜像是个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置文件外,还包含一些为运行时准备的一些配置参数,镜像不包含任何动态数据,内容在构建之后也不会改变。
镜像特点是分层存储,由于镜像包含OS完整的root文件系统,体积庞大,在docker设计时,充分利用union FS技术,将其设计为分层存储的架构,严格意义说,镜像只是虚拟的概念,由多层文件系统联合组成。
实际镜像是一系列分层的只读文件,而当容器镜像运行为容器时,会在镜像的最上层添加一个可写的层,也就是容器层,所有对运行时容器的修改其实都是对这个读写层的修改。所有对容器的变化,如写新的文件,修改已有文件和删除文件,都只会作用在这个容器层之中。
优点:
镜像是应用发布的标准格式,通过dockerfile描述,可构建为一个tar包。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hlUygina-1616148287706)(img\02.png)]
docker镜像的生命周期:
docker容器的生命周期管理:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ztEOQxzA-1616148287708)(img\03.png)]
镜像提供了一种标准化运输或发布方式,发布系统工作机制就是build、ship、run
docker的重要组件:
以容器镜像作为devops流程的标准交付件,将应用程序代码和运行环境(依赖的库文件和系统服务、环境配置等)进行整体打包发布,统一打包格式,实现跨阶段的标准化发布流程。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-55IcEpJ3-1616148287711)(img\04.png)]
jenkins编译构建,jenkins根据代码工程中的dockerfile即可构建为docker容器镜像,然后使用镜像,触发部署,通过k8s集群进行可视化编排和容器集群管理,如弹性伸缩,滚动升级等。统一格式打包的镜像可一致性的部署到开发、测试、生产环境,容器镜像作为devops流程的标准交付件,实现跨阶段的标准化发布流程。
开发人员关注容器内的:
针对任何环境都采用同样方式打包,除了开发时,也要关心运行时
运维人员只需关心容器外的事情
所有的容器采用同样的方式启动,停止,复制,接入和升级
一组互相连接的操作系统(实体机/虚拟机/容器)形成一个整体的资源池
可扩展到上千个节点,具备自我修复,扩展和收缩能力
作为环境抽象层存在,使得应用可不关心所运行的节点
容器集群的关联及诶DNA会在集群的每个业务节点中部署一个agent,形成一个整体的资源池,且作为环境抽象层存在。
k8s是用于自动部署,扩展和管理容器化应用程序的开源系统
k8s:cluster scheduler–>scheduled containers
docker: node container manager–>managed base os
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Xr132DVC-1616148287713)(img\05.png)]
master:
node(worker): 运行工作负载的节点,运行容器应用,node由master统一管理,负责监控并汇报容器的状态,同时根据master的要求管理容器的生命周期
第三方组件
在k8s中,pod是能够创建、调度和管理的最小部署单元,是一组容器实例的集合,而不是单独的应用容器。
pod中的容器作为一个整体被master调度到一个node中运行,同一个pod里的容器共享同一个网络命名空间,IP地址及端口空间和卷
从生命周期看,pod是短暂的而不是长久的应用,pod被调度到节点,保持在这个节点直至被销毁。
副本控制器,主要控制deployment应用副本的数量
解决了pod的扩容和缩容问题,通常用于无状态应用。
无状态应用,用户会创建一个deployment,deployment自己建replicaset,replicaset建pod,典型应用是nginx和tomcat
有状态的应用,如mysql、redis,每个实例都是唯一的,会区分主从实例,每个实例的重启都是有顺序的
daemonset能够让所有(或一些特定)的node节点运行同一个pod。当节点加入到k8s集群中,pod会被daemonset调度到该节点运行。当节点从k8s集群中移除,被daemonset调度的pod会被移除,如果删除daemonset,所有跟这个daemonset相关的pods都会被删除
在使用k8s运行应用时,很多时候需要在一个区域zone或者所有node节点运行同一个守护进程pod,如
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定义了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
三种类型:clusterIP,NodePort,LoadBalancer,Service定义的是一种四层转发,也可理解为四层负载均衡。是通过iptables(或IPVS)的方式实现,只支持随机转发
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层路由转发
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KpAebg1P-1616148287715)(img\06.png)]
在整个生命周期流程中,controller-manager会持续watch各类set,定期同步,保证最终一致性,而scheduler会持续watch集群的node供调度使用,kubelet会持续watch被调度到本节点的pod,执行生命周期动作。
docker和k8s实现了应用容器化,并促进了CI/CD流程,降低应用从构建到部署流程的复杂性,加速业务的快速迭代
多样的生态接入
增强的商用化特性
完全开放的原生平台
高性能基础设施
也就是自动化。目标是通过可重用的代码实现IT环境变更的自动化。用代码或配置文件来声明应用系统使用的基础设施资源。把环境的创建过程使用代码的形式描述出来,并提交到代码库。任何的环境变更都必须通过修改代码、提交,然后总是使用代码库的最新版本重新构建环境,所有的机器的状态都是可预测的。常见的自动化配置管理工具是ansible、puppet等。
ansible是个开源配置管理工具,使用它来自动化任务部署应用程序,实现IT基础架构。可用来自动化日常任务,如服务器的初始化、配置、安全基线配置、更新和打补丁系统安装软件包等。
docker hub中99%的镜像都是通过在base镜像中安装和配置需要的软件构建出来的。
FROM debian
RUN apt-get install emacs
RUN apt-get install apache2
CMD ["/bin/bash"]
dockerfile: 文件指令集,描述如何自动创建docker镜像,包含若干指令,指令执行后,会创建一个个新的镜像层。
包括4部分:
docker常见参数:
FROM
或FROM :
: 基于哪个镜像,
首选本地是否存在,如果不存在则会从公共仓库下载通过k8s manifest文件可以用yaml形式描述在k8s中以pod的形式运行的应用容器,以及要运行多少个应用的副本。
编译构建是指把软件的源代码编译为目标文件,并把配置文件和资源文件等打包的过程。
输入时源代码文件、库文件、配置文件、资源文件等
输出是软件包:一个可以直接部署的软件,或者是一个可被其他软件使用的lib
编译器完成“ 编译”过程,编译管理工具完成“构建”过程。
依赖管理+编译+打包=编译构建
ant对应ivy依赖,在ant的构建文件中定义ivy任务实现调用ivy的功能,从而实现依赖管理。
可用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)进行使用。
能够统一管理各种类型的二进制制品,同时无缝对接现有的标准化构建和发布工具的软件平台。
软件包及其属性的管理是发布过程管理的基础;软件制品库,用于管理软件包,是连接持续集成和持续交付的重要环节,软件包的发布评审、追溯和安全控制等操作通常在其中进行。
软件制品库的作用:
将可交付产品,快速安全的交付用户使用的一套系统和工具,系统会自动构建、测试并准备代码变更,以便将其发布到指定环境的过程,包括dev、test、prod,包含应用管理、环境管理、部署、编排、执行等功能。
华为云CloudDeploy提供自动化部署能力,可实现:
部署应用到物理机、虚机、容器
支持多种技术栈应用的部署
支持与流水线、运维管理无缝集成
云主机部署用户通过手动上传、或者编译构建任务,将软件包保存在软件发布库;部署任务将软件包上传并安装到云主机
容器部署用户通过手动上传、或者编译构建任务,将镜像保存到容器镜像仓中;部署任务将镜像上传到容器镜像集群中
多个目标主机执行部署任务
主机组:多态主机的组合,将多个主机添加到某一主机组中,通过主机组在多台主机上并行执行部署任务
环境:是计算、存储、网络等基础设施的集合。环境内部网络互通环境中,通常可包含主机、集群、数据库、ELB、微服务、引擎等资源。用于管理一组网络互通的资源,可预定义生产环境、测试环境等,环境中可添加主机组、数据库、容器集群等资源,作为部署任务的对象。
部署步骤,以tomcat为例:
将开发好的应用程序正式公布出来的过程
ITIL中定义的发布管理目标包含:
将部署和发布解耦,实现低风险发布
基于环境的发布模式:
基于应用的发布模式:
传统数据中心,机器资源比较紧张,应用机器基本上是预先静态分配好的(一般由运维负责分配),原来应用A运行在这n台机器上,那么下次升级发布的应用A也运行在这n台机器上,所以称为单服务器组发布方式。
包括蛮力发布、金丝雀发布、滚动发布
完全靠手工完成软件的升级与发布,在发布过程中会进行人为的终端,进行应用升级
劣势:服务终端用户受影响,出问题回退也慢,影响用户使用体验
在金丝雀开始后,先启动一个新版本应用,但不直接将流量切过来,而是测试人员对新版本进行线上测试,启动的这个新版本应用,就是我们的金丝雀
优势:用户体验影响小,发布过程出问题只影响少量用户
劣势:发布自动化程度不够,发布期间可引发服务中断
具体流程:先发布1台,或小比例如2%的服务器,做流量验证用,如果金丝雀测试通过,将剩余的v1版本全部升级v2,如果测试失败,直接回退金丝雀,发布失败
滚动发布:一般取出一个或多个服务器停止服务,执行更新,并重新将其投入使用。周而复始,直到集群中所有实例都更新为新版本。
优势:用户体验影响小,体验较为平滑
劣势:发布回退时间较慢;发布工具较复杂,LB需要平滑的流量摘除和拉入能力
滚动发布是自动化程度较高的发布方式,主流发布方式。
随着云计算和虚拟化技术的成熟,特别是容器等轻量级虚拟化技术的引入,计算资源受限和申请缓慢问题已经逐步解决,可做到弹性按需分配。为一次发布分配两组服务器,一组运行现有的V1老版本,一组运行待上线的V2新版本,再通过LB切换流量方式完成发布,就是所谓的双服务器组发布方式。
具体的发布策略有蓝绿发布、金丝雀发布、滚动发布功能开关、AB测试、影子测试
蓝绿发布,是一种可保证系统在不间断提供服务的情况下,上线的部署方式。蓝绿部署的模型包含两个集群,部署过程,并不停掉老版本,而是直接部署一套新版本,等新版本运行起来,再将流量切换到新版本
利用代码中的功能开关来控制发布逻辑,一般不需要复杂的发布工具和智能LB配合,是一种相对比较低成本和简单的发布方式。
需要一个配置中心或开关中心这样的一个服务支持,通过配置中心运维或研发人员可以在运行期间动态配置功能开关的值。
用来测试应用功能表现的方法,例如可用性、受欢迎程度、可见性等。目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获取具有代表性的实验结论,并确信该结论在推广到全部流量可信。
eg,原先的PC端和手机端都访问老版本V1服务(A组或控制组),当V2新版本(也叫B组或实验组)发布后,为验证V2的功能正确性,同时也为了避免V2有问题影响所有用户,先通过LB将手机端的流量切换到V2版本,经过一段时间的A/B测试和观察(主要是用户和监控反馈),确保V2正常,然后通过LB将全部流量切换到V2
AB测试和功能开关类似,但功能开关一般无状态和全量的,无法做到针对某类特定用户进行测试,而AB测试一般有状态,能根据事物和用户级别的状态,实现针对某类特定用户进行测试。
对于一些涉及核心业务的遗留系统的升级改造,为确保万无一失,使用影子测试,采用比较复杂的流量复制、回放和比对技术实现。
主要特色:
敏捷转型,两周一个迭代进行交付,但如果每两周都将产品部署到生产环境交付给用户,非常痛苦,每两周就要周末加班熬夜部署,并赶在用户上班使用之前验证部署结果。
要进一步缩短交付周期,必须做到生产环境部署发布的不停机,既要对用户无感知不影响用户体验,同时也保证部署是成功和安全的。引入“蓝绿部署”的实践,在华为称为“双活”。
使用两套一致的环境,一套在线提供服务,一套闲置准备用于下个版本的部署。有时也将两套都在线提供服务,互为灾备。
步骤:
一条流水线就是一个或多个自动化任务或人工任务组合起来的进行交付的工具。
流水线实现devops模式下持续开发、持续测试、持续集成、持续部署和持续监控这些活动的编排并自动化执行、结果反馈,实现商业敏捷。
为什么需要流水线
通过流水线可让部署成为一个日常的低风险的工作来解决开发和运维岗之间的根本的长期的冲突。
流程:用户场景–>需求分析–>架构设计–>代码编写–>本地构建–>提交代码–>代码下载–>云端构建–>静态检查–>α测试–>β测试–>γ测试–>dog food–>发布决策–>变更申请–>灰度发布–>监控运维–>运营反馈
流水线助力持续交付高质量应用
流水线由各阶段stage组成,阶段内每个块是任务原子task
阶段支持串行/并行、自动/手动等配置
阶段分为自定义阶段、发布仓库两种类型
支持10+种任务类型,根据业务需求自由组装流水线
支持自由拖拽、复制、编辑各阶段任务
流水线上任务支持一键跳转编辑
流水线参数传递到各任务,实现产物的价值流动
流水线参数支持文本、主机组、枚举、自增长等4种参数类型
流水线参数分为静态参数和动态参数,静态参数值总等于预设值,动态参数可被传参修改
统一使用${xxx}
进行参数化配置
门禁支持关联代码检查服务,提供专业级的代码检查能力,使缺陷发现前移
门禁支持关联接口测试服务,针对用例成功率进行看护
任务执行成功统计以健康度形式可视化,便于识别价值流动阻塞点
用户可选择软开云代码托管服务中指定仓库的分支作为触发器,当分支有push请求时,会自动触发流水线执行
两步实现触发器配置
计划功能提供流水线定时执行能力,支持每日定时执行、每周定时执行等多种模式
两步实现流水线定时配置