对动态基础设施平台的要求


微信扫码阿里云返佣咨询	微信扫码阿里云折扣咨询	微信扫码技术支持
电话：18580233332 QQ客服：32738651	电话：18581111192 QQ客服：3551327919	电话：18623333330 QQ客服：2194888888

对动态基础设施平台的要求

2020-9-10 点击量：

　　对动态基础设施平台的要求，基础设施即代码的意思是如何把基础设施当作软件系统，这就意味着动态基础设施平台需要具备某些特征。这个平台需要具备如下特征：
　　
　　可编程；
　　
　　按需获取；
　　
　　自服务。
　　
　　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 服务器的团队，这于事无补。对于需要全新方案的团队，比如要让软件运行在另一个不同应用服务器上的团队，可能就更不走运了。
　　
　　基础设施即代码假设并要求团队使用脚本和工具自动化地指定、置备并调整资源。这让使用基础设施的团队能够围绕他们的需求进行调整和演进。
　　
　　基础设施即代码为被迫扮演守门人的中央式团队提供了其他的选择。基础设施用户拥有能够轻松、常态化地修改其基础设施的能力，意味着他们能够快速地修正错误。此外，使用本书中针对变更的自动化测试和预发布，可以降低中断其他服务的风险。

最热文章更多

推荐文章更多

阿里云代理商最高返点多少，阿里云代理商返...

云代理商返点，阿里云代理商优惠购买流程

按量付费转包年包月时下单失败如何处理？包...

预留实例券可以同时抵扣多台实例吗

获取更多阿里云折扣立即咨询