资源编排最佳实践之入门篇:云服务器如何从 1 到 N?

随着云计算的应用和普及,IaaS层、SaaS层、PaaS层的服务也不断涌现,而国内云端的自动化运维还属于初探阶段。阿里云资源编排Resource Orchestration(ROS)服务即是填补了这部分空缺。 

ROS 的理念是“基础设施即代码”,一方面是用代码思维的版本管理来记录基础设施的变化,另一方面我们都知道计算机世界用代码实现了各种系统、无所不能,ROS 秉承这样的理念,通过代码实现自动化运维,并且简化编写代码的复杂度,只需通过模板描述多个云计算资源的依赖关系、配置等。

通俗地理解,ROS 的资源就像乐高游戏中的小积木,基于每个小资源可以搭建上层的无数种可能。

ROS 目前支持了阿里云12款主要云产品、40多个资源类型,后续还会不断增加。虽然模板简化了编码的复杂度,但通过灵活应用可以满足各种自动化运维的需求。

本系列共分为四篇文章,通过不同的维度介绍几个典型的应用场景,也是希望借助此系列能打开各个运维人员、开发者的脑洞,增强云端自动化运维的能力。 

本文为第一篇“入门篇”。目前云计算领域使用最多的是云服务器,因此本文会围绕云服务器自身的普遍需求展开介绍,其余几篇会介绍和其他服务或工具结合的场景。 

在经过很多的用户回访,我们发现针对于云服务器大家使用最多的场景是基于云服务器“此刻的状态”再创建 1-N 台云服务器,新创建的云服务器系统盘和数据盘都是“此刻的状态”,本文将根据此场景来讲述通过 ROS 如何实现。

我们以一个网站服务为例,一般运维工程师会在系统盘或数据盘中安装一些应用,如:Tomcat、Jenkins、MySql、网站自身的数据/文件等等。如果需要再创建一台云服务器与目前已有云服务器的系统或数据状态保持一致,可以将系统盘做成自定义镜像,数据盘做成快照,然后再新购买云服务器时镜像选择该自定义镜像,数据盘的快照选择该快照,安全组的规则配置与原云服务器一致的规则,就可以创建一台基于原云服务器“此刻状态”的新云服务器。

如果只需创建这一台云服务器,并且不需要记录历史状态,上述方法是比较合适的。但实际情况往往不是这样的,可能会频繁的创建/释放云服务器,或者生成镜像的操作人员与购买云服务器的人员不是同一个人,一但购买选项没有选正确,新购的这台云服务器就不能投入业务中,按量的需要再释放,包年包月的需要等到到期释放,或者做数据迁移,势必会带来一定的损失。

另外如果想记录或跟踪云服务器的历史演变,如安全组配置的变化、基础镜像等信息,需要单独记录。

面对上述问题,运维人员可以使用 ROS 的模板作为交付物,将资源的固定参数在模板资源中定义,将可变的参数在模板参数中定义,方便运行时输入实际参数。这样在频繁创建云服务器时,只需要输入可变参数中的内容即可,如镜像 ID、快照 ID,或者克隆原云服务器,或者没有可变参数,将所有定义都在资源中描述,可以根据实际业务要求灵活变通模板编写。

并且,模板可以存放在 Github 中,可以像管理代码一样跟踪模板历史,也可以基于模板之上创建适合于企业内部的运维工具,实现自动化运维,以“基础设施即代码”的理念代替“重复劳动”。

要了解ROS模板的详细解释,可以深入阅读资源编排模板详解。

下面以“网站服务运维”这个场景为例,讲一下模板定义中的关键要素:

1. 镜像和快照ID可以放在模板参数中定义:


  1. "Parameters": {
  2.     "ImageId": {
  3.       "Description": "镜像文件ID, 表示启动实例时选择的镜像资源",
  4.       "Type": "String"
  5.     },
  6.     "DiskName": {
  7.       "Type": "String"
  8.      },
  9.     "DiskSize": {
  10.       "Default": 40,
  11.       "Type": "Number"
  12.     },
  13.     "SnapshotId": {
  14.       "Type": "String"
  15.     }
  16. }

2. 定义云服务器的镜像和快照资源。

镜像资源定义如下,引用参数中的镜像 ID:


  1. "ImageId": {
  2.   "Ref": "ImageId"
  3. }

快照资源定义如下,引用参数中的磁盘名称、大小、快照 ID:


  1. "DiskMappings": [
  2. {
  3.     "DiskName": {
  4.       "Ref": "DiskName"
  5.     },
  6.     "Size": {
  7.       "Ref": "DiskSize"
  8.     },
  9.     "SnapshotId": {
  10.       "Ref": "SnapshotId"
  11.     }
  12.   }
  13. ]

3. 指定创建的云服务器数量,最大支持100台,可以是按量的也可以是包年包月的,包年包月的资源定义详见一键创建包年包月ECS实例。

4. 其他如IO优化、磁盘大小、安全组等可以根据实际情况定义,此场景的详细例子可以参考官方提供的例子指定镜像、磁盘快照创建ECS。

 

本文是通过一个实例讲解通过自定义镜像和快照生成新云服务器,针对于云服务器的运维远不止于此。 所以接下来,我们将会在[进阶篇]教你“如何利用ROS实现弹性伸缩”,通过ROS能力每个人都能成为运维高手、架构师。

原文发布时间为:2016-06-24

本文来自合作伙伴“Linux中国”

时间: 2024-08-29 08:16:14

资源编排最佳实践之入门篇:云服务器如何从 1 到 N?的相关文章

资源编排最佳实践之入门篇:云服务器如何从1到N?

随着云计算的应用和普及,IaaS层.SaaS层.PaaS层的服务也不断涌现,而国内云端的自动化运维还属于初探阶段.阿里云资源编排(Resource Orchestration,以下简称ROS)服务即是填补了这部分空缺. ROS的理念是"基础设施即代码",一方面是用代码思维的版本管理来记录基础设施的变化,另一方面我们都知道计算机世界用代码实现了各种系统.无所不能,ROS秉承这样的理念,通过代码实现自动化运维,并且简化编写代码的复杂度,只需通过模板描述多个云计算资源的依赖关系.配置等. 通

Web前端优化最佳实践之JavaScript篇

Web 前端优化最佳实践之 JavaScript 篇,这部分有 6 条规则,和 CSS 篇 重复的有几条.前端优化最佳实践,最重要的还是"实践",要理解这东西容易得很,关键是要去"实践",去"执行",去"反馈",去获取受益. 1. 脚本放到 HTML 代码页底部 (Put Scripts at the Bottom) 当一个脚本在下载的时候,浏览器干不了其它的事儿(串行了).所以,把它扔到最后面去处理.对于一些功能性的脚本,可

前端代码标准最佳实践:HTML篇

Web前端代码中,HTML是根本,CSS和JavaScript也是围绕着既有的HTML结构来构建,所以良好的HTML代码结构,除了提高了HTML代码的可读性,可维护性和执行性能之外,也可以让相对应的CSS和JavaScript代码更好的构建.距前面两篇探讨JavaScript(前端代码标准最佳实践:JavaScript篇)和CSS(前端代码标准最佳实践:CSS篇)之后,我们今天来探讨Web前端HTML的一些最佳实践. (1)HTML代码的基本规范 1. HTML的命名和格式 任何代码的混乱都是从

【最佳实践】如何使用云监控+日志服务快速完成故障发现和故障定位

今天分享一篇开发小哥哥如何使用云监控和日志服务快速发现故障定位问题的经历. 事件起因 小哥哥正在Coding,突然收到云监控报警,说他的API调用RT过高,小哥哥的业务主要为线上服务提供数据查询,RT过高可能会导致大量页面数据空白,这还了得,赶紧查. 排查过程 收到报警后查看指标趋势,发现突然RT突然增高. 查看单台机器维度的指标,发现30.239这台机器RT延时非常大. 具体机器的RT走势图: 查看存储在日志服务的原始数据,查看发生问题时的原始日志,发生某一次请求的rt突然变的很大,之后的rt

Web前端优化最佳实践之Server篇

Web 前端优化最佳实践第二部分面向 Server .目前共计有 6 条实践规则.[注,这最多算技术笔记,查看最原始内容,还请访问:Exceptional Performance : Best Practices for Speeding Up Your Web Site ] 1. 使用 CDN (Use a Content Delivery Network) 国内 CDN 的普及还不够.不过我们有独特的电信.网通之间的问题,如果针对这个作优化,基本上也算能收到 CDN 或类似的效果吧(假装如此

Web前端优化最佳实践之Cookie篇

Web 前端优化最佳实践第三部分面向 Cookie .目前只有 2 条实践规则. 1. 缩小 Cookie (Reduce Cookie Size) Cookie 是个很有趣的话题.根据 RFC 2109 的描述,每个客户端最多保持 300 个 Cookie,针对每个域名最多 20 个 Cookie (实际上多数浏览器现在都比这个多,比如 Firefox 是 50 个) ,每个 Cookie 最多 4K,注意这里的 4K 根据不同的浏览器可能不是严格的 4096 .别扯远了,对于 Cookie

前端代码标准最佳实践:javascript篇

前言 最近一直重构项目的前端代码,也参考了各种前端代码的最佳实践,目的是让前端的HTML,CSS,JavaScript代码更符合标准,有更好的性能,更好的可维护性,尝到了重构后的甜头,也萌生了写这个系列博客的念头.前端代码有其固有的灵活性,这就导致了目前前端代码非常混乱的局面,本系列文章希望能起到抛砖引玉的作用,让更多的人重视前端代码的质量,编写更标准的前端代码. 本系列文章共有三篇,分别讨论HTML,CSS,Javascript,本篇将讨论Javascript. 目前,Javascript已广

前端代码标准最佳实践:CSS篇

上一篇<前端代码标准最佳实践:javascript>发表后,大家讨论还是很热烈,从侧面体现了前端工程师对写标准的前端代码的重视程度很高.这些最佳标准实践并不是那个权威组织发布的,而是由大量的前端工程师们在实践过程中的经验总结,目的在于提高代码的可读性,可维护性和性能.那么接着上一篇,我们再来谈谈CSS代码的一些标准实践. 1,命名 和其他语言规范一样,css的命名也讲究命名要有意义,命名要尽可能短但是要足够表达含义:命名的词用连字符连接. 不规范的命名: #navigation{ } .dem

Web前端优化最佳实践之CSS篇

Web 前端优化最佳实践第四部分面向 CSS.目前共计有 6 条实践规则.另请参见 Mozilla 开发者中心的文章:Writing Efficient CSS 1. 把 CSS 放到代码页上端 (Put Stylesheets at the Top) 官方的解释我觉得多少有点语焉不详.这一条其实和用户访问期望有关.CSS 放到最顶部,浏览器能够有针对性的对 HTML 页面从顶到下进行解析和渲染.没有人喜欢等待,而浏览器已经考虑到了这一点. 2. 避免 CSS 表达式 (Avoid CSS Ex