万字长文|基础架构即代码
目 录
基础架构即代码简介
基础架构资源生命周期
资源配置
配置管理
监控与性能
治理与合规
资源优化
下一步
结论
贡献者
摘 要
基础设施即代码已成为自动化基础设施服务供应的最佳实践。本文描述了将基础架构作为代码的好处，以及如何在此领域利用Amazon Web Services的功能来支持DevOps。
DevOps是文化理念，实践和工具的结合，可以提高组织快速交付应用程序和服务的能力。这使您的组织可以更好地响应客户的需求。将基础架构作为准则的实践可以成为催化剂，使达到这样的速度成为可能。
基础架构即代码简介
基础架构管理是与软件工程相关的过程。组织传统上是“堆放”硬件，然后安装和配置操作系统和应用程序来满足其技术需求。云计算利用虚拟化的优势，可以按需供应构成技术基础架构的计算，网络和存储资源。
基础架构管理人员通常手动执行这种配置。手动过程具有某些缺点，包括：
较高的成本，因为它们需要人力资本，否则这些人力资本会用于更重要的业务需求。
由于人为错误而导致的不一致，导致与配置标准的差异。
通过限制组织发布新版本服务以响应客户需求和市场驱动力的速度，缺乏敏捷性。
由于缺乏可重复的流程，很难达到并保持对公司或行业标准的合规性。
基础架构即代码通过将自动化引入供应流程来解决这些缺陷。管理员和开发人员都可以使用配置文件实例化基础结构，而不必依靠手动执行的步骤。基础设施即代码将这些配置文件视为软件代码。这些文件可用于产生一组工件，即构成操作环境的计算，存储，网络和应用程序服务。《基础结构即代码》消除了自动化带来的配置漂移，从而提高了基础架构部署的速度和敏捷性。
基础架构资源生命周期
在上一节中，我们将“基础结构即代码”介绍为一种以可重复且一致的方式供应资源的方法。基本概念也与基础架构技术运营的更广泛角色有关。参考下图。
图1：基础架构资源生命周期
图1展示了组织中基础结构资源生命周期的通用视图。生命周期的各个阶段如下：
资源配置，管理员根据他们想要的规范来配置资源。
配置管理，资源成为支持诸如调整和修补之类的活动的配置管理系统的组件。
监控和性能，监视和性能工具通过检查指标，综合事务和日志文件等项目来验证资源的运行状态。
合规与治理，法规遵从和治理框架推动了附加验证，以确保与公司和行业标准以及法规要求保持一致。
资源优化，管理员查看性能数据并确定围绕性能和成本管理等标准优化环境所需的更改。
每个阶段都涉及可以利用代码的过程。这将基础架构即代码的优势从其在供应中的传统角色扩展到整个资源生命周期。这样，每个生命周期都将受益于基础架构即代码提供的一致性和可重复性。基础架构即代码的这种扩展视图导致整个信息技术（IT）组织的成熟度更高。
在以下各节中，我们将探索生命周期的每个阶段-供应，配置管理，监视和性能，治理和合规性以及优化。我们将考虑与每个阶段相关的各种任务，并讨论如何使用Amazon Web Services（AWS）的功能来完成这些任务。
资源配置
信息资源生命周期始于资源供应。管理员可以使用“基础架构即代码”原理来简化配置过程。请考虑以下情况：
发布管理器需要构建基于云的生产环境的副本以用于灾难恢复。管理员设计了一个模板，该模板可以对生产环境进行建模，并在灾难恢复位置配置相同的基础架构。
一位大学教授希望每学期为课程提供资源。班上的学生需要一个环境，其中应包含适合其学习的工具。教授使用适当的基础结构组件创建模板，然后根据需要为每个学生实例化模板资源。
每次安装服务时，必须满足某些行业保护标准的服务都需要具有一组安全控件的基础结构。安全管理员将安全控件集成到配置模板中，以便使用基础结构实例化安全控件。
软件项目团队的经理需要为程序员提供开发环境，其中包括必要的工具以及与持续集成平台交互的能力。管理器创建资源模板，并将模板发布在资源目录中。这使团队成员可以根据需要配置自己的环境。
这些情况有一个共同点：需要可重复的过程以一致地实例化资源。基础架构即代码为此类过程提供了框架。了满足此需求，AWS提供了AWS CloudFormation。
AWS CloudFormation
AWS CloudFormation为开发人员和系统管理员提供了一种以有序且可预测的方式轻松创建，管理，供应和更新相关AWS资源集合的简便方法。AWS CloudFormation使用以JSON或YAML格式编写的模板来描述AWS资源（称为堆栈）的集合，它们的相关依赖关系以及任何必需的运行时参数。您可以重复使用模板，以在AWS区域中一致地创建同一堆栈的相同副本。部署资源后，可以以可控且可预测的方式修改和更新它们。实际上，您正在以与应用程序代码相同的方式将版本控制应用于AWS基础架构。
模板解析
图2显示了基本的AWS CloudFormation YAML格式的模板片段。模板包含参数，资源声明和输出。模板可以引用其他模板的输出，从而可以实现模块化。
---
AWSTemplateFormatVersion: "version date"
Description:
String
Parameters:
set of parameters
Mappings:
set of mappings
Conditions:
set of conditions
Transform:
set of transforms
Resources:
set of resources
Outputs:
set of outputs
图2：AWS CloudFormation YAML模板的结构
图3是一个AWS CloudFormation模板的示例。该模板在参数部分中向用户请求Amazon Elastic Compute Cloud（EC2）密钥对的名称。然后，模板的资源部分使用该密钥对创建一个EC2实例，并使用启用HTTP（ TCP端口80）访问。
Parameters:
KeyName:
Description: The EC2 key pair to allow SSH access to the instance
Type: AWS::EC2::KeyPair::KeyName Resources:
Ec2Instance:
Type: AWS::EC2::Instance Properties:
SecurityGroups: !Ref InstanceSecurityGroup KeyName: !Ref KeyName
ImageId: ami-70065467 InstanceSecurityGroup:
Type: AWS::EC2::SecurityGroup Properties:
GroupDescription: Enable HTTP access via port 80 SecurityGroupIngress:
- IpProtocol: tcp FromPort: '80'
ToPort: '80' CidrIp: 0.0.0.0/0
图3：AWS CloudFormation YAML模板的示例
变更集
您可以使用应用程序源代码更新AWS CloudFormation模板，以添加，修改或删除堆栈资源。变更集功能使您可以预览对堆栈的建议变更，而无需执行相关更新。您可以使用AWS Identity and Access Management（IAM）控制创建和查看变更集的能力。您可以允许某些开发人员创建和查看变更集。预览更改集，同时保留更新堆栈或执行更改集到少数选择的功能。例如，您可以允许开发人员在将模板更改推广到测试阶段之前先查看其影响。
与变更集的使用相关的三个主要阶段。
1.创建变更集。
要为堆栈创建更改集，请将对模板的更改或参数提交给AWS CloudFormation。AWS CloudFormation通过将当前堆栈与您的更改进行比较来生成更改集。
2.查看更改集。
您可以使用AWS CloudFormation控制台，AWS CLI或AWS CloudFormation API来查看更改集。AWS CloudFormation控制台以JSON格式提供更改的摘要和更改的详细列表。AWS CLI和AWS CloudFormation API以JSON格式返回详细的更改列表。
3.执行更改集。
您可以在AWS CloudFormation控制台中选择并执行更改集，使用AWS CLI中的aws cloudformation execute-change-set命令或ExecuteChangeSet API。
更改集功能使您能够跟踪从一个版本到下一个版本实际发生的更改，从而超越了AWS CloudFormation中的版本控制。开发人员和管理员可以在促进变更之前获得对变更影响的更多见解，并最大程度地降低引入错误的风险。
可重用模板
许多编程语言提供了使用功能和子例程等结构对代码进行模块化的方法。同样，AWS CloudFormation提供了多种管理和组织堆栈的方式。尽管您可以将所有资源维护在一个堆栈中，但是大型的单堆栈模板可能变得难以管理。遇到许多AWS CloudFormation限制的可能性也更大。
在设计AWS CloudFormation堆栈的架构时，您可以按功能对堆栈进行逻辑分组。您可以使用嵌套堆栈或跨堆栈引用，而不是创建包含所需的所有资源（例如虚拟私有云（VPC），子网和安全组）的模板，而是使用嵌套堆栈或跨堆栈引用。嵌套堆栈功能使您可以在AWS CloudFormation模板内创建新的AWS CloudFormation堆栈资源，并在两个堆栈之间建立父子关系。每次创建AWS时通过父模板的CloudFormation堆栈，AWS CloudFormation还会创建一个新的子堆栈。这种方法允许您在项目之间共享基础结构代码，同时为每个项目维护完全独立的堆栈。
跨堆栈引用使AWS CloudFormation堆栈能够导出其他AWS CloudFormation堆栈随后可以导入的值。跨堆栈引用通过松散耦合来促进面向服务的模型，该模型允许您在多个项目之间共享一组资源。
模板整理
与应用程序代码一样，AWS CloudFormation模板应进行某种形式的静态分析，也称为linting。整理的目的是确定代码在语法上是否正确，识别潜在的错误并评估对特定样式准则的遵守情况。在AWS CloudFormation中，linting验证模板是否正确以JSON或YAML编写。.
AWS CloudFormation提供了ValidateTemplate API，用于检查正确的JSON或YAML语法。如果检查失败，则AWS CloudFormation返回模板验证错误。例如，您可以运行以下命令来验证存储在Amazon Simple Storage Service（Amazon S3）中的模板：
aws cloudformation validate-template --template-url s3://examplebucket/example_template.template
您也可以使用第三方验证工具。例如，cfn-nag对模板执行其他评估，以寻找潜在的安全隐患。
另一个工具cfn-check可对资源规范进行更深入的检查，以在堆栈创建期间发现潜在错误之前将其识别出来。
最佳实践
《 AWS CloudFormation用户指南》提供了用于设计和实施AWS CloudFormation模板的最佳实践列表。我们在下面提供了这些实践的链接。
规划与组织
Organize Your Stacks By Lifecycle and Ownership
Use IAM to Control Access
Reuse Templates to Replicate Stacks in Multiple Environments
Use Nested Stacks to Reuse Common Template Patterns
Use Cross-Stack References to Export Shared Resources
创建模板
Do Not Embed Credentials in Your Templates
Use AWS-Specific Parameter Types
Use Parameter Constraints
Use AWS::CloudFormation::Init to Deploy Software Applications on Amazon EC2 Instances
Use the Latest Helper Scripts
Validate Templates Before Using Them
Use Parameter Store to Centrally Manage Parameters in Your Templates
管理堆栈
Manage All Stack Resources Through AWS CloudFormation
Create Change Sets Before Updating Your Stacks
Use Stack Policies
Use AWS CloudTrail to Log AWS CloudFormation Calls
Use Code Reviews and Revision Controls to Manage Your Templates
Update Your Amazon EC2 Linux Instances Regularly
小 结
信息资源生命周期始于资源供应。AWS CloudFormation提供了一种基于模板的方式来创建基础架构并在创建过程中管理资源之间的依赖关系。借助AWS CloudFormation，您可以像应用程序源代码一样维护基础架构。
配置管理
一旦配置了基础架构资源并且该基础架构已启动并正在运行，就必须满足环境中持续的配置管理需求。请考虑以下情况：
版本管理器希望跨一组服务器部署应用程序的版本，并在出现问题时执行回滚。
系统管理员收到在开发人员环境中安装新操作系统软件包的请求，但其他环境保持不变。
应用程序管理员需要在容纳应用程序的所有服务器上定期更新配置文件。
解决这些情况的一种方法是返回到供应阶段，以所需的更改供应新资源，并处置旧资源。这种方法也称为基础结构不变性，可确保每次进行更改时都根据代码基准重新构建预配置的资源。这消除了配置漂移。
但是，有时候您可能想采用其他方法。在具有高度耐用性的环境中，最好是有办法对当前资源进行增量更改，而不是重新配置它们。为了满足此需求，AWS提供了适用于Chef Automate的Amazon EC2 Systems Manager和AWS OpsWorks。
EC2系统管理员
Amazon EC2 Systems Manager是一组功能，可简化本地环境中EC2实例和服务器或虚拟机（VM）上的操作任务的常见维护，管理，部署和执行。Systems Manager可以帮助您轻松理解和控制EC2实例和OS配置的当前状态。您可以跟踪和远程管理系统配置，OS补丁程序级别，应用程序配置以及有关随时间推移进行的部署的其他详细信息。
这些功能可帮助自动执行复杂且重复的任务，定义系统配置，防止漂移以及维持Amazon EC2和本地配置的软件合规性。
表1列出了Systems Manager简化的任务。
任务 |
详细 |
Run Command |
通过在整个舰队中分发命令来大规模管理托管实例的配置。 |
Inventory |
自动从托管实例收集软件清单。 |
State Manager |
使托管实例保持定义和一致的状态。 |
Maintenance Window |
定义用于运行管理任务的维护窗口。 |
Patch Manager |
跨实例组自动部署软件补丁。 |
Automation |
执行常见的维护和部署任务，例如更新Amazon Machine Images（AMI）。 |
Parameter Store |
通过AWS密钥管理系统（KMS）加密的存储，控制，访问和检索配置数据，无论是纯文本数据（例如数据库字符串）还是机密（例如密码）。 |
表1：Amazon EC2 Systems Manager任务
文件结构
Systems Manager文档定义了Systems Manager对您的托管实例执行的操作。Systems Manager包括十几个预先配置的文档，以支持表1中列出的功能。您还可以创建自定义版本控制的文档，以增强Systems Manager的功能。您可以设置默认版本并在AWS账户之间共享。文档中的步骤指定了执行顺序。所有文档均以JSON格式编写，并且包含参数和操作。与适用于Chef Automate的AWS OpsWorks一样，Systems Manager的文档也成为基础架构代码库的一部分，从而将基础架构即代码引入配置管理。
以下是基于Windows的主机的自定义文档的示例。该文档使用ipconfig命令收集节点的网络配置，然后安装MySQL。
{
"schemaVersion": "2.0",
"description": "Sample version 2.0 document v2", "parameters": {},
"mainSteps": [
{
"action": "aws:runPowerShellScript", "name": "runShellScript",
"inputs": {
"runCommand": ["ipconfig"]
}
},
{
"action": "aws:applications", "name": "installapp", "inputs": {
"action": "Install", "source":
"http://dev.mysql.com/get/Downloads/MySQLInstaller/mysql- installer-community-5.6.22.0.msi"
}
}
]
}
图4：Systems Manager文档的示例
最佳实践
下面是每种Systems Manager功能的最佳做法。
运行命令
Improve your security posture by leveraging Run Command to access your EC2 instances, instead of SSH/RDP.
Audit all API calls made by or on behalf of Run Command using AWS CloudTrail.
Use the rate control feature in Run Command to perform a staged command execution.
Use fine-grained access permissions for Run Command (and all Systems Manager capabilities) by using AWS Identity and Access Management (IAM) policies.
清单
结合使用清单和AWS Config来审核您的应用程序配置超时。
状态管理
Update the SSM agent periodically (at least once a month) using the preconfigured AWS-UpdateSSMAgent document.
Bootstrap EC2 instances on launch using EC2Config for Windows.
(Specific to Windows) Upload the PowerShell or Desired State Configuration (DSC) module to Amazon S3, and use AWS- InstallPowerShellModule.
Use tags to create application groups. Then target instances using the Targets parameter, instead of specifying individual instance IDs.
Automatically remediate findings generated by Amazon Inspector by using Systems Manager.
Use a centralized configuration repository for all of your Systems Manager documents, and share documents across your organization.
维护窗口
定义一个时间表，以在您的实例上执行破坏性操作，例如操作系统修补，驱动程序更新或软件安装。
补丁管理器
使用Patch Manager可以大规模推出补丁程序，并在整个EC2实例中提高机队合规性可见性。
自动化
为基础结构创建自助式运行手册，作为自动化文档。
使用自动化可以简化从AWS Marketplace或自定义AMI创建AMI，使用公共文档或编写自己的工作流的过程。
使用文档AWS-Update Linux Ami for AWS-UpdateWindowsAmi或创建自定义的Automation文档来构建和维护映像。
参数存储
使用参数存储以集中方式管理全局配置设置。
使用参数存储进行机密管理，并通过AWS KMS对其进行加密。
将参数存储与Amazon EC2容器服务（ECS）任务定义一起使用以存储机密。
适用于Chef自动的AWS OpsWorks
适用于Chef Automate的AWS OpsWorks将配置管理平台Chef的功能引入了AWS。适用于Chef Automate的OpsWorks通过提供支持大规模DevOps功能的其他功能，进一步构建了Chef的功能。Chef基于食谱的概念，食谱是用Ruby语言编写的，执行诸如安装服务之类的任务的配置脚本。Chef食谱（如AWS CloudFormation模板）是一种源代码，可以进行版本控制，从而将“基础架构即代码”原理扩展到资源生命周期的配置管理阶段。
适用于Chef Automate的OpsWorks扩展了Chef的功能，使您的组织能够大规模实施DevOps。用于Chef Automate的OpsWorks提供了三个可配置为支持DevOps实践的关键功能：工作流，合规性和可见性。
工作流程
您可以在OpsWorks中使用Chef Chefate的工作流程来协调开发，测试和部署。工作流包括质量门，质量门使具有适当特权的用户能够在发布管理过程的各个阶段之间升级代码。此功能对于支持团队之间的协作非常有用。每个团队可以实施自己的闸门，以确保每个团队的项目之间的兼容性。
承 诺
OpsWorks for Chef Automate提供的功能可以帮助您实现组织合规性，这是配置管理的一部分。Chef Automate可以提供突出显示与合规性和风险相关的事项的报告。您还可以利用来自知名组（例如Internet安全中心（CIS））的配置文件。
可见性
适用于Chef Automate的OpsWorks可提供对工作流状态和项目内合规性的可见性。Chef用户可以创建和查看提供有关相关事件的信息的仪表板，并通过用户界面查询事件。
Recipe Anatomy
厨师食谱由一组资源定义组成。定义描述了资源的期望状态以及Chef如何将其带入该状态。Chef支持60多种资源类型。常见资源类型的列表显示在下面。
资源名称 |
目标 |
Bash |
使用bash解释器执行脚本 |
Directory |
管理目录 |
Execute |
执行一个命令 |
File |
管理档案 |
Git |
管理Git存储库中的源资源 |
Group |
管理群组 |
Package |
管理包裹 |
Route |
管理Linux路由表条目 |
Service |
管理服务 |
User |
管理使用者 |
表2：Chef常用资源
以下是厨师食谱的示例。本示例根据Apache Web服务器的安装定义资源。资源定义包括对底层操作系统的检查。它使用case运算符检查node [：platform]的值以检查基础。
操作系统。action：install指令将资源带到所需的状态（即，它将安装软件包）。
package 'apache2' do case node[:platform]
when 'centos','redhat','fedora','amazon' package_name 'httpd'
when 'debian','ubuntu' package_name 'apache2'
end
action :install
end
图5：厨师食谱示例
配方整理和测试
Chef和Chef用户社区可以使用多种工具来支持linting（语法检查）以及单元和集成测试。在以下各节中，我们重点介绍一些最常见的平台。
与Rubocop和Foodcritic合作
可以使用Rubocop和Foodcritic等工具对基础结构代码（例如Chef食谱）进行整理。Rubocop根据Ruby样式指南对Chef食谱执行静态分析。（Ruby是用于创建Chef食谱的语言。）此工具是Chef Development Kit的一部分，可以集成到软件开发工作流程中。Foodcritic根据一组内置规则检查Chef食谱中是否存在常见语法错误，可以通过社区贡献来扩展这些规则。
ChefSpec进行单元测试
ChefSpec可以在Chef食谱上提供单元测试。这些测试可以确定是否要求Chef执行适当的任务以实现期望的目标。ChefSpec需要配置测试规范，然后根据配方对其进行评估。
例如，ChefSpec不会实际检查Chef是否安装了Apache软件包，而是检查Chef配方是否要求安装Apache。测试的目的是验证配方是否反映了程序员的意图。
Integration Testing with Test Kitchen
Test Kitchen是一个测试平台，它创建测试环境，然后使用busser（这是测试框架）来验证Chef配方中指定的资源的创建。
通过将先前的测试工具与OpsWorks结合使用以实现Chef Automate工作流程功能，开发人员可以在开发生命周期中自动化对其基础结构的测试。这些测试本身就是一种代码形式，并且是基础结构即代码部署方法的另一个关键部分。
最佳实践
此处介绍的策略，技术和建议将帮助您从AWS OpsWorks for Chef Automate获得最大收益和最佳结果：
考虑将厨师食谱存储在Amazon S3档案中。Amazon S3具有高度的可靠性和耐用性。通过使用命名约定来明确版本化每个存档文件。或使用Amazon S3版本控制，该版本提供了审计跟踪以及一种还原为早期版本的简便方法。
建立符合您的组织治理要求的备份计划。
使用IAM限制对OpsWorks的Chef Automate API调用的访问。
小 结
Amazon EC2 Systems Manager允许您将EC2实例以及本地环境中的服务器或VM部署，定制，实施和审核预期状态配置。适用于Chef Automate的AWS OpsWorks可让您使用Chef配方来支持环境的配置。您可以单独或在AWS CloudFormation设置的环境之上使用OpsWorks for Chef Automate。与Systems Manager相关联的运行文档和策略以及与用于Chef Automate的OpsWorks相关联的配方可以成为基础结构代码库的一部分，并且可以像应用程序源代码一样受到控制。
监控与性能
在回顾了基础架构作为代码在基础架构资源和配置管理中的作用之后，我们现在来看一下基础架构的运行状况。考虑以下事件在需求高峰期如何影响网站的运行：
Web应用程序的用户由于负载平衡器的延迟而超时，这使得浏览产品目录变得困难。
由于CPU容量不足，应用服务器性能会下降，并且无法再处理新订单。
跟踪会话状态的数据库吞吐量不足。随着用户过渡到应用程序的各个阶段，这会导致延迟。
这些情况描述了由于基础架构资源无法达到其性能预期而引起的运营问题。重要的是要捕获关键指标以评估环境的健康状况，并在出现问题时采取纠正措施。指标提供可见性。借助指标，您的组织可以自动响应事件。如果没有指标，您的组织将无法了解其基础架构中正在发生的事情，因此需要人工干预来解决所有问题。使用以多种语言和框架编写的可伸缩且松散耦合的系统，可能难以捕获相关的指标和日志并做出相应的响应。为了满足此需求，AWS提供了Amazon CloudWatch服务。
Amazon CloudWatch
Amazon CloudWatch是一组服务，用于摄取，解释和响应运行时指标，日志和事件。CloudWatch会自动从许多AWS服务中收集指标，例如Amazon EC2，Elastic Load Balancing（ELB）和Amazon DynamoDB。响应可以包括内置操作，例如发送通知或由AWS Lambda处理的自定义操作。无服务器事件驱动的计算平台。
Lambda函数的代码成为基础结构代码库的一部分，从而将基础结构即代码扩展到了操作级别。CloudWatch由三个服务组成：主要CloudWatch服务，Amazon CloudWatch Logs和Amazon CloudWatch Events。现在，我们将更详细地考虑每一个。
Amazon CloudWatch
主要的Amazon CloudWatch服务收集并跟踪许多AWS服务的指标，例如Amazon EC2，ELB，DynamoDB和Amazon Relational Database Service（RDS）。您还可以为开发的服务（例如应用程序）创建自定义指标。当指标在一段时间内达到给定阈值时，CloudWatch会发出警报。
以下是一些指标和可能适用于本节开头提到的情况的示例：
如果ELB的等待时间超过两分钟（超过5秒），请向系统管理员发送电子邮件通知。
当EC2实例的平均CPU使用率在三分钟内超过60％时，请启动另一个EC2实例。
发生过多限制时，请增加DynamoDB表的容量单位。
您可以使用内置通知或通过在Python，Node.js，Java或C＃中编写自定义Lambda函数来实现对基于指标的警报的响应。图6显示了CloudWatch警报如何使用Amazon Simple Notification Service（Amazon SNS）触发DynamoDB容量更新的示例。
图6：CloudWatch警报流示例
Amazon CloudWatch日志
Amazon CloudWatch Logs监视和存储来自Amazon EC2，AWS CloudTrail和其他来源的日志。EC2实例可以使用CloudWatch Logs代理和Logstash，Graylog和Fluentd等日志工具来发送日志信息。通过将Amazon S3事件配置为触发Lambda函数，可以将60个存储在Amazon S3中的日志发送到CloudWatch Logs。
摄取的日志数据可以成为新的CloudWatch指标的基础，这些指标又可以触发CloudWatch警报。您可以使用此功能来监视生成日志的任何资源，而无需编写任何代码。如果您需要更高级的响应过程，则可以创建Lambda函数以采取适当的措施。例如，当生产日志中出现NullPointerException错误时，Lambda函数可以使用SES.SendEmail或SNS.Publish API将信息发布到Slack通道。日志处理和关联允许对应用程序行为进行更深入的分析，并可以公开难以从指标中找出的内部细节。CloudWatch Logs提供日志的存储和分析以及处理，以实现对操作问题的数据驱动响应。
Amazon CloudWatch事件
Amazon CloudWatch Events会生成从AWS环境更改产生的事件流，应用规则引擎，并将匹配的事件传递到指定目标。可以流式传输的事件的示例包括EC2实例状态更改，Auto Scaling操作，CloudTrail发布的API调用，AWS控制台登录，AWS Trusted Advisor优化通知，自定义应用程序级事件和时间表操作。目标可以包括内置动作，例如SNS通知或使用Lambda函数的自定义响应。
基础架构响应选定事件的能力在操作和安全性方面均带来了好处。从操作的角度来看，事件可以自动执行维护活动，而不必管理单独的调度系统。关于信息安全，事件可以提供有关CloudTrail记录的控制台登录，身份验证失败和有风险的API调用的通知。在这两个领域中，将事件响应合并到基础结构代码中可促进更大程度的自我修复和更高水平的操作成熟度。
最佳实践
以下是与监视有关的最佳实践的一些建议：
确保所有AWS资源都在发布指标。
为指标创建CloudWatch警报，以在与指标相关的事件发生时提供适当的响应。
将包括Amazon S3和Amazon EC2在内的AWS资源的日志发送到CloudWatch Logs，以使用日志流触发器和Lambda函数进行分析。
使用CloudWatch和Lambda安排正在进行的维护任务。
使用CloudWatch自定义事件来响应应用程序级问题。
小 结
监视对于了解系统行为并自动执行数据驱动的反应至关重要。CloudWatch以指标和日志的形式收集来自运行时环境的观察结果，并使这些结果可通过警报，流和事件进行操作。用Python，Node.js，Java或C＃编写的Lambda函数可以响应事件，从而将基础结构即代码的角色扩展到了操作领域，并提高了操作环境的弹性。
治理与合规
考虑了如何使用“基础结构即代码”来监视组织环境的健康状况之后，我们现在将重点放在技术治理和合规性上。许多组织要求对其基础结构具有可见性，以解决行业或法规要求。云的动态配置功能带来了特殊的挑战，因为在添加，删除或更新资源时必须保持可见性和治理。请考虑以下情况：
将用户添加到特权管理组，并且IT组织无法解释何时发生这种情况。
修改了将远程管理限制为一组有限的IP地址的网络访问规则，以允许从其他位置进行访问。
几台服务器的RAM和CPU配置出乎意料地翻了一番，这导致费用比前几个月大得多。
尽管您可以使用AWS CLI和API调用来查看AWS资源配置的当前状态，但要解决这些情况，就需要能够查看这些资源随时间的变化情况。为了满足此需求，AWS提供了AWS Config服务。
AWS配置
AWS Config使您能够评估，审核和评估AWS资源的配置。AWS Config自动建立您的资源清单并跟踪对其所做的更改。图7显示了EC2实例的AWS Config清单的示例。
图7：AWS Config资源清单示例
AWS Config还提供了资源更改时间表的清晰视图，包括资源配置的更改以及这些资源与其他AWS资源的关联。图8显示了AWS Config为VPC资源维护的信息。
图8：AWS Config资源时间轴示例
当许多不同的资源频繁且自动地更改时，自动化合规性与自动化交付管道一样重要。要响应环境中的更改，您可以使用AWS Config规则。
AWS 配置规则
使用AWS Config规则，每次更改都会触发与资源关联的规则的评估。AWS提供了一组托管规则来满足常见要求，例如具有良好密码，组和策略的IAM用户，或者用于确定EC2实例是否在正确的VPC和安全组上。AWS Config规则可以快速识别不合规的资源，并帮助进行报告和补救。对于超出托管规则提供的验证范围的验证，AWS Config规则还支持使用Lambda函数创建自定义规则。这些规则成为基础架构代码库的一部分，从而将“基础架构即代码”的概念带入了治理和合规性阶段。信息资源生命周期。
规则结构
通过AWS Config规则调用自定义规则时，关联的Lambda函数将接收配置事件，对其进行处理并返回结果。以下功能确定是否在给定的Amazon VPC上启用了Amazon Virtual Private Cloud（Amazon VPC）流日志。
import boto3 import json
def evaluate_compliance(config_item, vpc_id):
if (config_item['resourceType'] != 'AWS::EC2::VPC'): return 'NOT_APPLICABLE'
elif is_flow_logs_enabled(vpc_id): return 'COMPLIANT'
else:
return 'NON_COMPLIANT'
def is_flow_logs_enabled(vpc_id): ec2 = boto3.client('ec2')
response = ec2.describe_flow_logs(
Filter=[{'Name': 'resource-id','Values': [vpc_id]},],
)
if len(response[u'FlowLogs']) != 0: return True
def lambda_handler(event, context):
invoking_event = json.loads(event['invokingEvent']) compliance_value = 'NOT_APPLICABLE'
vpc_id = invoking_event['configurationItem']['resourceId'] compliance_value = evaluate_compliance(
invoking_event['configurationItem'], vpc_id)
config = boto3.client('config') response = config.put_evaluations(
Evaluations=[
{
'ComplianceResourceType': invoking_event['configurationItem']['resourceType'],
'ComplianceResourceId': vpc_id, 'ComplianceType': compliance_value, 'OrderingTimestamp':
invoking_event['configurationItem']['configurationItemCaptureTim e']
},
],
ResultToken=event['resultToken'])
图9：支持AWS Config规则的Lambda函数示例
在此示例中，当Amazon VPC上发生配置事件时，该事件将传递给函数lambda_handler。此代码提取Amazon VPC的ID，并使用describe_flow_logs API调用来确定是否启用了流日志。如果启用了流日志，则Lambda函数将返回COMPLIANT的值，否则返回NON_COMPLIANT。
最佳实践
以下是在您的环境中实施AWS Config的一些建议：
为所有区域启用AWS Config以记录配置项目历史记录，以促进审核和合规性跟踪。
实施流程以响应AWS Config检测到的更改。这可能包括电子邮件通知和使用AWS Config规则以编程方式响应更改。
小 结
AWS Config将基础结构代码的概念扩展到治理和合规领域。AWS Config可以连续记录资源的配置，而AWS Config规则允许事件驱动的响应来跟踪资源的配置变化。您可以使用此功能来帮助您的组织监视合规性控制。
资源优化
现在，我们将重点放在信息资源生命周期的最后阶段，即资源优化。在此阶段，管理员将检查性能数据，并根据安全性，性能和成本管理等标准确定优化环境所需的更改。对于所有应用程序涉众而言，定期评估基础架构以确定是否最佳使用基础架构至关重要。
请考虑以下问题：
是否存在未充分利用的预配资源？
有什么方法可以减少与操作环境相关的费用？
对于提高预配置资源的性能有什么建议吗？
是否有适用于环境中使用的资源的服务限制？如果是，当前资源使用量是否接近这些限制？
为了回答这些问题，我们需要一种查询操作环境，检索与优化相关的数据并使用该数据做出有意义的决策的方法。为了满足此需求，AWS提供了AWS Trusted Advisor。
AWS可信顾问
AWS Trusted Advisor通过扫描AWS资源并将其使用与AWS最佳实践的四个类别进行比较来帮助您观察最佳实践：成本优化，性能，安全性和容错能力。作为对基础架构和应用程序的持续改进的一部分，利用Trusted Advisor可以帮助您最佳地配置资源。图10显示了Trusted Advisor仪表板的示例。
图10：AWS Trusted Advisor仪表板示例
校 验
Trusted Advisor提供了各种检查来确定基础结构是否遵循最佳实践。检查包括以下内容的详细
说 明：
建议的最佳做法，警报条件，操作准则以及有关该主题的有用资源列表。Trusted Advisor提供检查结果，还可以提供每周一次的状态更新和节省成本的每周通知。
所有客户都可以访问一组核心的Trusted Advisor检查。获得AWS Business或Enterprise支持的客户可以访问所有Trusted Advisor检查和Trusted Advisor API。使用这些API，您可以从Trusted Advisor获得信息并采取纠正措施。例如，一个程序可以利用Trusted Advisor检查当前帐户服务限制。如果当前资源使用率接近限制，则可以自动创建支持案例以增加限制。
此外，Trusted Advisor现在与Amazon CloudWatch Events集成。您可以设计Lambda函数以在Trusted Advisor的状态检查更改时通知Slack通道。这些示例说明了如何将“基础结构即代码”的概念扩展到信息资源生命周期的资源优化级别。
最佳实践
AWS Trusted Advisor的最佳做法如下所示。
通过电子邮件或其他传递系统订阅Trusted Advisor通知。
使用通讯组列表，并确保所有适当的收件人包括在所有此类通知中。
如果您有AWS Business或Enterprise支持，请结合使用AWS Support API和Trusted Advisor通知，使用AWS Support创建案例以执行补救。
小 结
您必须不断监视基础结构，以在性能，安全性和成本方面优化基础结构资源。AWS Trusted Advisor提供了使用API询问您的AWS基础架构以获取建议的功能，从而将基础架构即代码扩展到信息资源生命周期的优化阶段。
下一步
通过以查看产品代码的相同方式查看基础结构规范，可以开始在组织中采用“基础结构作为代码”。AWS提供了广泛的工具，可让您更好地控制和灵活地调配，管理和操作云基础架构。
在组织中将基础结构实现为代码时，可以采取以下关键措施：
首先使用基础架构代码的托管源代码控制服务（例如AWS CodeCommit）。
在部署之前，通过单元测试和静态代码分析来整合质量控制过程。
删除人为因素并自动化基础结构设置，包括基础结构许可策略。
创建可以轻松重新部署的幂等基础结构代码。
通过更新幂等堆栈，通过代码将每个新更新发布到您的基础结构。避免手动进行一次性更改。
拥抱端到端的自动化。
将基础设施自动化工作包括在常规产品冲刺中。
使您的更改可审核，并使日志记录为强制性。
定义整个组织的通用标准并不断进行优化。
通过遵循这些原则，您的基础架构可以随着不断变化的业务需求而动态地发展和加速。
结 论
基础结构即代码使您可以将基础结构资源的定义编码为配置文件和控制版本，就像应用程序一样软件。现在，我们可以更新生命周期图，并显示AWS如何通过代码支持每个阶段。
图11：AWS的信息资源生命周期
借助AWS CloudFormation，适用于Chef Automate的AWS OpsWorks，Amazon EC2系统管理器，Amazon CloudWatch，AWS Config和AWS Trusted Advisor，您可以将基础架构即代码的概念集成到项目生命周期的所有阶段。通过将基础结构用作代码，您的组织可以自动部署一致构建的环境，从而可以帮助您的组织提高整体成熟度。
贡献者
以下个人和组织对此文档做出了贡献：
Amazon Web Services解决方案架构师Hubert Cheung
Julio Faerman，Amazon Web Services技术推广员
亚马逊网络服务专业服务顾问Balaji Iyer
亚马逊网络服务解决方案架构师杰弗里·莱文（Jeffrey S.Levine）
2020年4月2日 20:00 刘亚丹
虎牙直播 基础运维负责人
与各位深度交流下一代算力网络基础设施思考和实践
虎牙基础设施发展历程
下一代算力网络基础设施架构
如何构建确定性算力网络
关注新钛云服公众号，回复“虎牙”，获取直播报名入口。
报名进入直播间，并分享专属邀请卡，当晚榜单前三可获得新钛云服出版干货书籍一本。
