阿里云服务器ECS    
弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新 [咨询更多]
阿里云存储OSS
简单易用、多重冗余、数据备份高可靠、多层次安全防护安全性更强、低成本 [咨询更多]
阿里云数据库RDS
稳定可靠、可弹性伸缩、更拥有容灾、备份、恢复、监控、迁移等方面的全套解决方案 [咨询更多]
阿里云安全产品
DDoS高防IP、web应用防火墙、安骑士、sll证书、态势感知众多阿里云安全产品热销中 [咨询更多]
阿里云折扣优惠    
云服务器ECS、数据库、负载均衡等产品新购、续费、升级联系客服获取更多专属折扣 [咨询更多]
对动态基础设施平台的要求
2020-9-10    点击量:
  对动态基础设施平台的要求,基础设施即代码的意思是如何把基础设施当作软件系统,这就意味着动态基础设施平台需要具备某些特征。这个平台需要具备如下特征:
  
  可编程;
  
  按需获取;
  
  自服务。
  
  NIST 定义的云的特征

  
  美国国家标准和技术协会(NIST)发布了关于云计算的精彩定义。它列出了云的 5 个基本特征:
  
  按需自服务(置备);
  
  广泛的网络接入(可以通过“标准的机制”从网络上接入);
  
  资源池(多租户);
  
  快速的弹性伸缩(可以快速甚至自动添加和删除元素);
  
  可度量的服务(可以对资源的使用计费)。
  
  动态基础设施平台的定义要比云宽泛一些。资源池不是基础设施即代码的要求,也就意味着计费不是必需的。
  
  1 可编程
  
  动态基础设施平台必须是可编程的。用户界面是很方便,而且大部分虚拟化产品和云服务商都会提供。但是脚本、软件和工具必须能够与平台交互,这就需要可编程 API。
  
  即便使用开箱即用的工具,大部分团队最终还是至少写了一些自定义脚本和工具。所以基础设施平台的 API 必须能够好好支持团队习惯使用的脚本语言。
  
  大部分基础设施平台通过网络 API 暴露其管理功能,其中 REST API 因其易用性和灵活性而最为流行(见图 2-1)。
  基础设施平台的 API 客户端
  图 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 服务器的团队,这于事无补。对于需要全新方案的团队,比如要让软件运行在另一个不同应用服务器上的团队,可能就更不走运了。
  
  基础设施即代码假设并要求团队使用脚本和工具自动化地指定、置备并调整资源。这让使用基础设施的团队能够围绕他们的需求进行调整和演进。
  
  基础设施即代码为被迫扮演守门人的中央式团队提供了其他的选择。基础设施用户拥有能够轻松、常态化地修改其基础设施的能力,意味着他们能够快速地修正错误。此外,使用本书中针对变更的自动化测试和预发布,可以降低中断其他服务的风险。
联系客服免费领取更多阿里云产品新购、续费升级折扣,叠加官网活动折上折更优惠