一、前言
通过这些年不断的布道和探索，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: 202、保存模板，可以将创建好的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分别实现用户行为，以及事件日志的分析和监控，确保整个系统的稳定，持续的运行。
附件:
342
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
