一、前言
通过这些年不断的布道和探索,DevOps理念已经深入人心,打破了开发和运维天然隔离,大大提升了效率。
AWS通过提供一系列的工具和框架,实现了对DevIOps的全面支持。如下图所示:
下面我们逐一介绍。
二、CodeCommit
CodeCommit是AWS提供了代码托管服务,它其实就是一个GIT的服务,就像Github一样管理我们的代码。CodeCommit与AWS其他的产品结合,实现更强大的功能。
- 可扩展,它会用到AWS S3这样的对象存储服务包括代码,作为一个海量的代码库,它对一些大的分区或者大尺寸文件的储存会有更好的优势;使用Amazon的NoSQL服务(DynamoDB)去作为它的元数据管理。
- 安全,代码可以通过KMS进行加密,也可以用与IAM集成,显示权限的分配。
CodeCommit是将我们的代码保存到代码仓库,是DevOps的第一步,。
三、CodePipeline
CodePipeline就是构建持续集成的过程,将代码的编译,部署,测试,发布通过自动化的方式集成起来。如下图所示:
提交代码后,进行编译(CodeBuild),在不同的Staging里面去做不同的测试,通过人工审核,部署到生产。
四、CodeBuild
参照Jenkins,代码提交后,就可以从代码库下载代码,根据不同的环境和配置进行代码编译和打包。CodeBuild与Jenkins的功能类似,在具有弹性的云端编译工具和环境中,预先构造好一些成熟、常见的编译环境,比如安卓、Java、Golang等各种的编译。其工作流程如下图所示:
编译完成后,通过测试和审核,接下来就部署生产环境了。
五、部署
AWS提供的部署方式和工具非常丰富,满足不同的场景和需求,主要包括CloudFormat,Beanstalk,CodeDeploy,Opsworks。如果我们将运行环境的配置也看做是部署一部分,根据前面章节的介绍,有些工作如User Data,AMI,启动模板配置也算作是部署。这里一并总结下。
1、User Data
初始化一个EC2实例时,可以通过 user data 让 EC2 第一次启动后实现初始化工作,可以放置 shell script 或 cloud-init 指令,比如说安装并启动ngnix。
对user data的脚本有以下要求。
(1)是脚本时必须以 #! 开始, 如 #!/bin/bash
(2)user data是以 root 身份执行,所以不要用 sudo, 当然创建的目录或文件的 owner 也是 root,需要 ec2-user 用户访问的话需要 chmod 修改文件权限,或者直接用 chown ec2-user:ec2-user -R abc 修改文件的所有者
(3)脚本不能交互,有交互时必须想办法跳过用户输入,如 apt install -y xzy, 带个 -y 标记
(4)如果脚本中需访问 AWS 资源,权限由 Instance Profile 所指定的 IAM role 决定
(5)user data 中的脚本会被存储在 /var/lib/cloud/instances/<instance-id>/user-data.txt 文件中,因此也可以从这里验证 user data 是否设置正确。并且在 EC2 实例初始化后不被删除,所以以此实例为基础来创建一个新的 AMI 需把它删除了
(6)cloud-init 的输出日志在 /var/log/cloud-init-output.log, 它会捕获 cloud-init 控制台的输出内容。
User Data实现了启动脚本的部署。
2、AMI
在AWS云计算技术架构探索系列之三-计算章节我们讲到过AMI,EC2实例启动时,需要指定一个AMI。AMI是实例启动的镜像,其内容包括操作系统,应用程序,以及启动账号许可等。
使用同一个AMI启动实例,能够确保实例环境的一致性。当我们需要将运行的EC2实例环境复制到多个实例上,就可以制作此实例的镜像,再使用该镜像启动新的实例。如下图所示:
AMI可以保存在S3中,实现在区域之间复制,也可以再多账户之间共享使用,甚至可以公开AMI,供整个社区使用。
AMI实现了EC2运行所需软件系统环境的部署。
3、启动模板
一个实例启动并真正运行起来,除了AMI软件的环境外,还需要有网络,存储等各种配置。在AWS云计算技术架构探索系列之三-计算的Auto Scaling组的配置中了解中,需要选择一个启动模板,在EC2弹性扩容的时候,会根据启动模板,实现EC2实例自动启动和运行。对于启动模板包括以下信息:实例类型,AMI,密钥对,网络(子网,安全组),存储(EBS卷)等。
启动模板实现了EC2运行所属生态环境的部署。
4、CloudFormat
启动模板是以EC2为中心的配置,但是从整个工程资源配置看,还包括数据库,LB,Auto Scaling组等等。
CloudFormat是以复杂的工程为中心,将所需要的资源进行模板编排,再通过配置堆栈实例化这些模板,创建这些资源。所以模板可以类似接口,堆栈类比实现类,其过程如下图所示:
1、创建模板,模板是JSON或YAML格式的文件,在文件中,可以按照格式描述EC2实例,比如实例类型,AMI,密钥对等。模板一般有以下的元素组成:
- 参数列表(可选),如EC2实例类型,数据库大小和端口号等,这些参数在创建堆栈的时候,才会给出输入值。
- 输出值列表(可选),堆栈创建后,这些值可以作为响应返回输出到控制台,供用户查看,也可以输出给其他的堆栈。比如web应用的url,数据库的访问地址等。
- 数据表列表(可选),用于查询静态配置值,比如AMI名称,区域名等,采用Mapping映射模式。
- AWS 资源及其配置值的列表(必填),声明所需要的资源,如EC2,S3等。
- 模板文件格式版本号。
以下是官网给出的YAML样例:
AWSTemplateFormatVersion: "2010-09-09"
Description: A sample template
Resources:
MyEC2Instance: #An inline comment
Type: "AWS::EC2::Instance"
Properties:
ImageId: "ami-0ff8a91507f77f867" #Another comment -- This is a Linux AMI
InstanceType: t2.micro
KeyName: testkey
BlockDeviceMappings:
-
DeviceName: /dev/sdm
Ebs:
VolumeType: io1
Iops: 200
DeleteOnTermination: false
VolumeSize: 20
2、保存模板,可以将创建好的S3存储桶。
3、创建堆栈,选择模板,并配置模板所属的参数,以及堆栈的策略,就可以创建资源。当创建过程失败,可以通过回滚,释放其他已经创建的资源。
CloudFormat实现了工程所需资源的部署。
5、Beanstalk
以上的部署在实际生产过程中,面向的是系统运维人员,需要对于AWS的产品以及部署架构比较熟悉。但是对于很多小公司来说,可能只有几名开发,而且产品也较简单。那么有没有面向开发人员的部署呢?这就是Beanstalk。
Beanstalk仅需要开发人员选择相应的平台,上传代码即可搞定。诸如实例选择,系统配置,网络环境配置,安全配置,数据库配置等等,统统由Beanstalk帮我们搞定,是不是酷毙了。
Beanstalk 支持 Java、.NET、PHP、Node.js、Python、Ruby、Go 和 Docker Web 应用程序,在这些自动化部署的背后,Beanstalk整合和协调诸多模块,比如CloudFormat。
Beanstalk实现了面向开发人员的端到端傻瓜式部署。
6、CodeDeploy
随着微服务的发展,部署单元也由之前的应用部署发展为微服务的部署,对于部署的独立性,灵活性要求更高,同时需要做到对业务的影响最小。
CodeDeploy可以支持AmazonLambda ,EC2,WCS平台。我们来看下部署EC2典型流程:
创建应用,可以结合CodeCommit,CodeBuild进行应用的打包。对于CodeDeploy来说,最重要的是创建部署组和部署配置。
- 部署组
部署组描述的是部署到什么目标上。可以根据环境设置不同的部署组,比如测试环境,生产环境;设置实例数,EC2实例,或者Auto Scaling组;部署类型,本地部署或者蓝绿部署等。
- 部署配置
部署配置为部署组指定如何进行部署的行为,包括如何处理部署故障,每次部署实例的比例等,如下图所示,可以设置一次一台,一次一半等部署比例,实现波浪形部署。
- 部署
实际的部署可以分为本地部署和蓝绿部署两种类型。
本地部署,更新部署中的实例,在部署过程中,每个实例会短暂的的离线进行更新。
蓝绿部署,云端的资源可以认为是无限的,当发布新版本时,可以扩充资源,短时间内产生一台新机器,并部署新版本,通过域名或者负载,把一部分流量割接到新环境,如下图所示:
CodeDeploy是面向复杂系统微服务的部署。
7、Opsworks
Opsworks大家估计不大熟悉,它是一款配置管理服务,提供 Chef 和 Puppet 的托管EC2虚拟机实例。Chef 和 Puppet 是自动化平台,允许用户使用代码来自动配置服务器。用户借助OpsWorks可以使用 Chef或Puppet 自动完成所有 EC2实例或本地计算环境中的服务器配置、部署和管理。OpsWorks 提供三种产品:AWS OpsWorks for Chef Automate,AWS OpsWorks for Puppet Enterprise,AWS OpsWorks Stacks。
AWS OpsWorks for Chef Automate:一款完全托管的配置管理服务,可托管 Chef Automate,后者是出自 Chef 的一套用于配置管理、确保合规性与安全性以及持续部署的自动化工具。
AWS OpsWorks for Puppet Enterprise:一个完全托管的配置管理服务,它托管 Puppet Enterprise,后者是一套来自 Puppet 的用于基础设施和应用程序管理的自动化工具。
AWS OpsWorks Stacks:一款应用程序和服务器管理服务。利用 OpsWorks Stacks,客户可以将自己的应用程序塑造成一个包含不同层级 (例如负载均衡层、数据库层和应用程序服务器层) 的堆栈。其工作原理如下图所示:
Opsworks是面向托管 Chef 和 Puppet的部署。
六、监控
在监控方案,AWS提供了CloudTrail,CloudWatch 两类产品。
1、CloudTrail
CloudTrail主要针对用户的活动,API的使用,进行审计和监控,包含三类数据。
管理事件数据,对AWS相关资源的操作数据,包括用户登录,设备注册,安全配置等。
数据事件数据,主要是对数据的操作跟踪,如S3,数据库,EBS的读写API的调用。
见解事件数据,主要是对异常的 API 调用率或错误率。
如上图所示,CloudTrail可以将三类数据存储到S3,也可以推送到CloudWatch Log,CloudWatch Events继续处理。
CloudTrail支持多个账户间共享,如下图所示,各账号所属的数据都发送到同一个S3存储桶存储,账号A是管理员用户,可以查看所有账号的数据,其他账号则需要通过授权可以查看。这样即确保了数据的统一管理,又确保了数据安全。
2、CloudWatch
CloudWatch可以近乎实时的监控所属的资源(如EC2)和用户的应用程序,通过日志的采集,指标跟踪和分析,并提供查询收集,也可进行告警阈值设置,实现指标监控。其原理图如下:
CloudWatch提供了CloudWatch Logs以及CloudWatch Events两种组件。
CloudWatch Logs可以监控、存储和访问来自 EC2实例、Amazon CloudTrail、Route 53 和其他来源的日志文件。将这些日志集中到一起,通过检索特定的关键字或筛选字段进行日志。
在实际工程中,经常需要采集应用的日志进行调式和分析。如下图所示:
源EC2安装CloudWatch Logs agent代理,agent通过一定的频率(5s)采集指定的日志目录数据(/var/log/app),发送到CloudWatch保存,用户可以通过Logs Insights进行检索和查询。
CloudWatch Events提供几乎实时的系统事件流。当资源发送更改发送事件,匹配预置的规则,将其路由到多个目标进行处理。
例如,Auto Scaling发生启动或终止实例的事件,通过规则匹配,路由到SNS,发送通知。
七、总结
本章节介绍了AWS在DevOps方面提供的一系列解决方案和工具。
通过CodeCommit进行代码提交,CodePipeline实现持续集成,CodeBuild支持多个语言的代码编译,根据工程的场景和特点,可以选择CloudFormat,Beanstalk,CodeDeploy,Opsworks等多种部署方式。CloudTrail,CloudWatch分别实现用户行为,以及事件日志的分析和监控,确保整个系统的稳定,持续的运行。
附件:
AWS云计算技术架构探索系列之一-开篇
AWS云计算技术架构探索系列之二-身份账户体系(IAM)
AWS云计算技术架构探索系列之三-计算
AWS云计算技术架构探索系列之四-存储
AWS云计算技术架构探索系列之五-网络
AWS云计算技术架构探索系列之六-数据库文章来源:https://www.toymoban.com/news/detail-813394.html
AWS云计算技术架构探索系列之七-DevOps文章来源地址https://www.toymoban.com/news/detail-813394.html
到了这里,关于AWS云计算技术架构探索系列之七-DevOps的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!