对动态基础设施平台的要求
发布时间: 2020-09-10 14:34:16文章作者: 网站编辑阅读量: 228
对动态基础设施平台的要求，基础设施即代码的意思是如何把基础设施当作软件系统，这就意味着动态基础设施平台需要具备某些特征。这个平台需要具备如下特征：
可编程；
按需获取；
自服务。
NIST 定义的云的特征
美国国家标准和技术协会（NIST）发布了关于云计算的精彩定义。它列出了云的 5 个基本特征：
按需自服务（置备）；
广泛的网络接入（可以通过“标准的机制”从网络上接入）；
资源池（多租户）；
快速的弹性伸缩（可以快速甚至自动添加和删除元素）；
可度量的服务（可以对资源的使用计费）。
动态基础设施平台的定义要比云宽泛一些。资源池不是基础设施即代码的要求，也就意味着计费不是必需的。
1 可编程
动态基础设施平台必须是可编程的。用户界面是很方便，而且大部分虚拟化产品和云服务商都会提供。但是脚本、软件和工具必须能够与平台交互，这就需要可编程 API。
即便使用开箱即用的工具，大部分团队最终还是至少写了一些自定义脚本和工具。所以基础设施平台的 API 必须能够好好支持团队习惯使用的脚本语言。
大部分基础设施平台通过网络 API 暴露其管理功能，其中 REST API 因其易用性和灵活性而最为流行（见图 2-1）。
图 2-1：基础设施平台的 API 客户端
基于 REST API 编程或者编写脚本相当灵活，但使用封装了 API 细节的特定语言类库也会很有帮助。这些库提供了类（class）和结构（structure）来表示基础设施的元素以及对它们的操作。动态基础设施平台的开发者通常提供至少几种语言的 SDK，还有一些开源的项目为多个平台提供了完备的 API，例如 Ruby 的 Fog 和 Python 的 Boto 库。
脚本示例：使用动态基础设施平台SDK
例 2-1 使用了第 2 版的亚马逊 AWS Ruby SDK 来创建一个 EC2 实例。
例 2-1 使用 AWS SDK 的简单 Ruby 脚本
require 'aws-sdk'
@client = Aws::EC2::Client.new(:region => 'eu-west-1')
@client.run_instances({
image_id: 'ami-903686e7',
instance_type: "t1.micro",
min_count: 1,
max_count: 1
})
@client.describe_instances()[:reservations].each { |reservation|
reservation[:instances].each { |instance|
puts "Instance #{instance.instance_id} is #{instance.state.name}"
}
}
这个脚本首先用 API 创了一个 client 对象，这个对象打开了一个 AWS 认证的会话。它从在脚本运行之前就设定好的环境变量中读取了 AWS API 密钥，然后透明地完成了认证。
run_instances 接口调用指定了用来创建新实例的 AMI、实例的大小，以及启动多少个实例。
这个脚本接着调用 describe_instances 接口，列出这个账户在该区域拥有的所有 EC2 实例。它会打印出所有实例的 ID 以及状态。
2 按需获取
对于基础设施即代码来说，动态基础设施平台支持资源的即时创建和销毁非常关键。
这看起来理所当然，但实际上却不总是这样。一些托管服务提供商和内部 IT 部门声称他们提供的是云服务，但是却需要提出申请，并实际由人来完成这些工作。对使用基础设施即代码的组织来说，其托管平台必须能够在几分钟甚至几秒内满足置备请求。
计费和预算的结构也需要合理设计，以支持按需、累积的收费。传统的计费是基于以月或年计的消费承诺。动态基础设施不应需要长期的承诺，计费周期最多按小时计。
组织可能会做出购买或租借固定硬件池的长期承诺。但是当从这个池中置备虚拟实例时不应该有额外的花费，特别是长期花费。
3 自服务
自服务在按需获取之上对基础设施平台额外增加了一些要求。基础设施用户不仅应该能够快速获得资源，还应该能够依照自己的需求调整和定制这些资源。
这和中央式团队（或者一组团队）为需要基础设施的团队设计方案的传统方式截然不同。在传统方式下，即使是新建 Web 服务器这样的常规需求也会涉及详尽的申请表格、设计、规格文档以及实施计划。
这就像买了一盒子乐高积木，但是却让店员来决定如何组装。这阻碍了需求团队获得所使用基础设施的所有权，也阻碍了他们学习如何按照自己的需求改造并逐步改进基础设施。
随着云的出现，有些中央式基础设施团队提供了自服务资源，但是选项却很少。例如团队可以创建 3 种类型的服务器：Web 服务器、应用服务器和数据库服务器；其中安装的软件都是特定版本，且不能定制这些服务器。
这就像只能买事先组装好的乐高积木玩具，而且是粘在一起的。对于需要定制方案的团队，比如要为应用程序优化 Web 服务器的团队，这于事无补。对于需要全新方案的团队，比如要让软件运行在另一个不同应用服务器上的团队，可能就更不走运了。
基础设施即代码假设并要求团队使用脚本和工具自动化地指定、置备并调整资源。这让使用基础设施的团队能够围绕他们的需求进行调整和演进。
基础设施即代码为被迫扮演守门人的中央式团队提供了其他的选择。基础设施用户拥有能够轻松、常态化地修改其基础设施的能力，意味着他们能够快速地修正错误。此外，使用本书中针对变更的自动化测试和预发布，可以降低中断其他服务的风险。 
