1. 聚能聊>
  2. 话题详情

多云业务需求下如何管理云基础设施的?听说过Terraform和Packer吗?

混合云已经越来越盛行,开源的DevOps工具也玲琅满目,Terraform和Packer是混合云的最佳开源工具:

_1

Terraform是资源编排工具,支持多个云平台Aliyun,AWS,Azure,Openstack等,阿里云官方github地址:https://github.com/alibaba/terraform-provider

Packer是镜像制作工具,支持多个云平台Aliyun,AWS,Azure,VMWare等,阿里云官方github地址:https://github.com/alibaba/packer-provider

让我们来聊聊:

  1. 日常是如何做基础设施管理的,是手工操作还是已经使用了自动化的Ias工具?都有怎样的管理场景?
  2. 是否有自定义镜像的业务场景?现在是如何做的?
  3. 如果还没有使用DevOps工具,原因是什么?觉得难点在哪里?是否愿意尝试?

4月20日在云栖会直播Terraform和Packer的功能(如何利用开源DevOps工具完成云上的自动运维),大家想了解什么,也可以在这里反馈,会选择性纳入直播现场中。 https://yq.aliyun.com/activity/188

参与话题

奖品区域 活动规则 已 结束

  • 奖品一

    聆听专属T恤衫 x 2

  • 奖品二

    定制笔记本 x 1

  • 奖品三

    珍藏版棒球帽 x 1

41个回答

1

低端玩家 已获得聆听专属T恤衫 复制链接去分享

能不能演示一下操作流程,~我是冲着体恤来的

黎山 回复

好的,在直播时会演示操作流程

张维ACE 回复
回复@黎山:

这这这。这也行,大神都是。 😄

评论
1

初码 已获得定制笔记本 复制链接去分享

这个话题的受众应该是云服务公司的开发人员或者架构师,主要是IAAS以下层面的资源聚合管理,而一般面向云服务用户的就是类似cloudbility、yunboard这样的基于公有云API而二次开发的聚合云服务资源管理平台

不知道我这个理解对不对

黎山 回复

一方面是二次开发的聚合云管理平台,另一方面企业的运维开发人员也是受众。

评论
1

sea-line 已获得珍藏版棒球帽 复制链接去分享

想要为DevOps和应用灵活性而重塑团队,需要领导层的勇气和无私奉献。当然,它也需要花费时间和金钱,并且需要在团队成员筛选上做出艰难的决定。
为了促进DevOps战略,调整考核和激励机制是必要的。如果依然只根据敲出代码的生产力来奖励开发人员,或者根据基础设施的可靠性来奖励运维人员,那么,什么都不会改变。相反,应该奖励系统创建和运维的整体团队,并且根据团队工作的全部要素来确定奖励。
围绕业务系统而不是职责来组织工作,这就是DevOps打破IT分组壁垒的寓意。一个团队应该有开发人员创建代码,从用户界面到业务逻辑和数据结构,也应该有运维人员负责操作自动化和部署。
人们需要知道他们需要对什么样的系统负责,而并不仅仅是毫无责任地从一个系统换到另一个系统。唯一的例外是专家。
团队待在一起,共同为他们的应用和系统负责。
不要制造一个团队支持太多应用的局面。在这个预算缩减的年代很难考虑周全,但是经历这种融合转变之后,团队将更加富有成效,并且不需要额外人员就能应对需求的增长。
需要充足的专家参与项目和为团队提供支持 ——这些人都是不同学科的大师和专家。他们为系统提供支持,但是不会长期指派给某一个系统。他们不需要对这些系统负责。
全面自动化 —— 部署、 升级、 扩展、 维护、 数据卫生、 测试、 监测、 安全和策略管理。在自动化方面投入巨资,目标是100%的自动化,不考虑低于90%的可能性。但是,全面自动化也可能会引起自动化泛滥。集中审查和调整可以控制Chef或Puppet脚本库的无序增长。
针对整个团队进行奖励和表彰。成功离不开大家共同的努力,同样,问题需要整个团队自我反省。系统团队应该承认专家们的贡献 ,对表现杰出的专家给予奖励。
围绕建设运营融合的原则制定新的企业体系结构标准。这将确保系统符合运维的需求。
DevOps战略必须获取本组织自顶向下的全面支持。整个行政领导团队 ——不只是首席信息官 ——应知道它为什么重要和怎样使它取得成功。
请记住,这是重大的文化和组织变革,多分配些时间开展培训和组织开发活动。如果变革得太快而忘了和您的所有团队步调一致,将整天陷入失误和冲突——最后满盘皆输。

1

张维ACE 已获得聆听专属T恤衫 复制链接去分享

DevOps。DevOps 就是开发(Development)和运维(Operations)这两个领域的合并。(如果没错的话,DevOps还包括产品管理、QA、winces 甚至销售等领域)

脱节(The Broken)

那么……为什么要合并这两个领域?原因很多,但首要原因是:我们目前的工作流程是脱节的。绝对的脱节。很多公司的开发部门和运维部门之间存在的深刻矛盾,其实就是这个“脱节”造成的。(意译,求斧正)

下面是一个大家都基本熟悉的例子:部署软件产品。

开发部门要开发一款新产品。这款产品要使用最新最炫的技术,来保证客户的所有花俏的需求,从而给公司带来百万美元的利润。这款产品被要求使用最新的技术和运行平台,还得马上交付。于是开发部门没日没夜的加班、赶代码(cuts code like crazy),终于如期完成了任务。然后他们把自己的“杰作”一股脑的甩给了运维部门,后者还没能完全接手,前者已经迫不及待的开始了庆功会。

接到产品后,运维部门每个人的心中都充满了恐惧。

下面就是运维部门的恐惧之源:({A.B.C}表示A或B或C之一)

这款优秀的产品在目前的底层平台上无法运行,因为这个平台{太古老了,空间不足,不支持某某版本}
这款产品的体系结构跟我们的{存储,网络,部署,安全}模型不匹配。
这款产品的{ 报告,安全,监视,备份,服务提供} 我们搞不懂 ,所以没法把它做成实际可用的产品。
尽管伴随着不绝于耳的抱怨和咒骂,运维部门最终还是把这款产品安装好了。不幸的是,由于做了很多蹩脚的修改和不合理的强迫式运行,这款产品的性能最后被归结为:终极失败(Epic Fail)。

于是非常沮丧的运维部门开始记录各种问题,源源不断的给开发部门提Issue。而开发部门的回应基本上都是:

这不是我们的错 —— 我们的代码非常完美——而是(运维部门的)部署做的太差劲了。
运维部门比较笨,他们不懂新技术—— 为什么他们没法实现最新的技术呢?为什么他们这么落伍呢?
在我的机器上运行的没问题啊……
两个部门之间的交流很快变成了一场暴风骤雨。客户(以及股东、投资方和管理层)则成了蒙受损失的失败方。最终公司损失了无数的金钱,大家也都失业了。终极的失败。

DevOps 又有啥不同?它有什么好处?

DevOps 就是想方设法的避免这种“终极失败”,同时让大家用更聪明更有效的方式去工作。它是一种框架,包含了很多优秀想法和原则,它鼓励开发部门和运维部门通力合作。在DevOps环境中,开发人员和系统管理员会构建一些关系、流程和工具,从而更好的与客户互动,最终提供更好的服务。

DevOps 也不仅仅是一种软件的部署方法。它通过一种全新的方式,来思考如何让软件的作者(开发部门)和运营者(运营部门)进行合作与协同。使用了DevOps模型之后,会使两个部门更好的交互,使两者的关系得到改善,从而让很多领域从中受益,例如:自动化、监视、能力规划和性能、备份与恢复、安全、网络以及服务提供(provisioning)等等。

“对于DevOps是什么?” 这个问题,DevOps社区中的每个人的回答都不尽相同。因为我们的工作经验不同,关注的问题也不同。就我个人而言,DevOps分成四大部分:

简单

KISS(Keep it Simple and Stupid,简单就是美)原则是最重要的。所以本段文字也很简单。我们要尽量提供简单、可重用的解决方案。“简单”节约了书写文档、培训和提供支持的时间。“简单”增加了沟通的速度、避免混淆、减少了开发和运维出错时的风险。“简单”让人更快的发布产品。

部门之间关系

早参与,多参与。对于开发人员,要让运维人员常驻到开发部门,全程参与开发流程。邀请运维人员参与你的Scrum或者开发会议,与他们分享项目计划、分享新技术的点子和心得。搜集功能性需求(指开发人员用到的需求)的同时也要搜集运维方面的需求。把对于“发布、备份、监控、安全、配置管理和系统功能”的测试作为一项独立的项目流程。软件产品在开发时解决的问题越多,那么在使用时暴露给用户的问题就越少。给运维人员做培训,让他们弄清楚项目的体系结构和核心代码。如果运维人员在反馈bug时提供的信息越多,那么你花在排查问题(trouble-shooting) 的时间就越少,这个bug也就会更快的被解决掉。

对于运维人员,在遇到问题时需要把开发人员加进来,大家一起解决问题。邀请开发人员参与你们的会议,分享项目进度(roadmaps),并且共同修订工作计划。运维人员一定要了解开发部门下一步的工作方向,从而确保产品运行的底层平台能够良好的支持最新技术。开发人员也会带来相关的技术、知识和工作,帮助你们改善产品的运行环境,使其更加易于维护、简洁有效。

有一些开发领域的概念,例如:“要根据API而非封闭的interface来构建工具”,分布式版本控制,驱动测试开发,以及诸如敏捷开发、看板管理(Kanban)和Scrum等方法论。如果把这些概念应用在运维领域,同样会产生革命性的变革。

不要惧怕新点子和新技术。我们可以随时随地的向他人学习,哪怕是一句“我们再也不要那样做了!”也会让我们从中获益。尽管处于不同的部门,但是我们要共同学习、共同成长,这样才能协同工作的更好!

按照从高到低的顺序,有效的沟通方式应该是:面对面交流 、视频会议、电话、即时通讯软件、Email。

工作中的流程

有自己的流程管理(process engineering)—— 从原始的笔录到 ISO9001。但它们都存在一个关键的缺陷:过于理想化,它要求每个步骤都必须成功执行。例如:为了搭建一台新主机,会有下列一套简单的流程:

步骤一:装机(把各个硬件组装到一起)。
步骤二:接线、通电。
步骤三:安装操作系统。
接下来还有步骤四、五、六。
如果一切顺利的话,第N步结束之后就会有一个功能完整、运行正常的新主机。但万一有个流程没跑通怎么办?比如说在某个步骤断了,走不下去了,或者在这一步得到了异常的输出,有没有另外的步骤来处理这个异常?

所以,流程绝对不会从头到尾一帆风顺,所以我们要把每一步流程都认真对待,找出所有潜在的问题和障碍。跟软件产品一样,在流程的管理中也要有异常处理。我们不必做到精确预见每一个问题,但一定要保证:即使流程出错,它还能往下走。

把不同领域的所有流程串到一起。这些领域包括:部署、监控、能力计划(capacity planning) 等等。从逻辑上讲,“部署”是软件开发周期的最后一环,所以它应该属于“开发流程”,而非“运维流程”。另一个例子是度量和监控。在开发领域,如果不理解底线标准和估算,就什么评估都做不了。把开发部门和运维部门的流程衔接在一起,也会让两个部门更好的配合、相互理解、承担共同的责任。最后还有个优点:文档只需要一份而不是两份(开发一份、运维一份),从而节省了资金。

自动化,自动化,还是自动化。构建或使用简单、可扩展的工具(确保提供API, 机器可读的输入、输出 -- 参考 James White的文章:Infrastructure Manifesto)。使用Puppet一类的工具做配置管理。要扩展这些自动化工具,使其能够支持多个领域(开发领域和运维领域),并且在产品的不同环境(开发环境、测试环境、发布环境和生产环境)中使用相同的工具(也叫end-to-end)。这样不但会在产品支持和管理方面带来经济效益,而且也可以在编写新代码的同时,进行产品的发布和管理。

最后,在构建流程和自动化时,要把KISS原则牢记于心。越复杂就越易错。只有简单的流程和工具才易于实现、易于管理和易于维护。

持续改进

不要停止创新和学习。当今技术发展的很快,客户的需求也往往如此。把“持续改进和持续集成” 加入到你的工具和流程中去,这也是运维人员向(优秀的)开发人员学习的好途径,可以学到诸如测试驱动开发等最佳实践。例如:可以向你的部署流程中加入单元测试。做监控时也应该增加些行为测试,提高交付质量。尝试用开发领域中的工具(例如Hudson)在运维领域中做些工作(例如浏览数据(explore)、测量性能(measure)等等)。

要不断的总结教训。要积极主动的、在不同领域寻找错误的根源。 一旦收到错误报告,就果断把开发小组和运维小组找来,一起解决这个问题。有时候开发人员很简单的几次代码重构,就可以很好的避免底层运行环境的改变,减少运维人员的负担。总之,遇到问题时,开发部门和运维部门要密切配合、共同解决,而不是互相推诿、踢皮球。

对我来说...

最后,对我来说,DevOps 的主要内容是:跟谁共同工作、如何共同工作。它最吸引我的地方就是致力于把不同部门不同分工的人召集到一起,共同努力解决问题。这样的工作环境,是我所憧憬的乐园。

1

keller.zhou 复制链接去分享

世界上没有哪种工具能够像DevOps这么神奇(或敏捷,或精益)。DevOps在开发和运营团队之间建立了完美的合作与沟通,因此与其说这是一种神奇的工具,不如说是一种文化的转变。
然而,团队之间也拥有支持自动化和协作的工具及技术。经常有人问我们在Atlassian时关于支持DevOps工作方式所用到的工具(除了我们自己)。所以,我准备拟定一份购买指南,标明购买DevOps工具时所需要的东西并且告知您我们团队所用到的工具。
尽管许多工具都能以这种或那种的方式在开发周期的各个阶段发挥作用,但没有一种工具能在每个阶段起到主要作用。所以,当我们谈及DevOps工具时,将其分解到各阶段是很有帮助的。我将其分解成:规划、构建、持续集成、部署、运营以及持续反馈。

黎山 回复

请问你们在各个阶段是如何使用各种工具的? 相关经验能分享下吗

评论
1

李四爷 复制链接去分享

我的理解,DevOps其实是包含了自动化运维的。DevOps、微服务、容器等概念已经越来越热了。这让我想到了2年前OpenStack的状态,各大社区、互联网创业公司、生产传统企业,纷纷投入到OpenStack怀抱;而现在,虽然是有一些公司存活下来了,但总的来看谁也没赚到多少钱,也没有哪家公司如预想般把VMware给替代了。过热的后果是反而把市场秩序给弄得一团糟,产品低价竞争,人员漫天要价。这样一来运营我觉得现在的DevOps也到了这个岔路口,有很多公司在热炒DevOps的概念,并纷纷宣布转型成功;而从实际市场、尤其企业市场的反馈来看,客户对此的评价几乎众口一词:“DevOps很好,但我们很难做到”。究其原因,最缺乏的是DevOps方案提供公司真正到深入到企业里面,沉下心来,结合实际情况进行实施实践,从而帮助客户切实地做到横向协作打通、纵向工具链打通。所以我觉得,市场到今年底前还是会充斥着很多概念炒作;但从2017年开始,大家会逐步看到,这个领域中真正的脱颖而出的,将会是那些已经将DevOps实际落地的企业和服务商。小编个人观点,请支持理解,谢谢。我要棒球帽,谢谢。

1

似水的流年 复制链接去分享

可以把DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集。
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法(例如敏捷软件开发),这是一个重要的课题:按照从前的工作方式,开发和部署不需要IT支持或者QA深入的、跨部门的支持,而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。
DevOps的引入能对产品交付、测试、功能开发和维护(包括──曾经罕见但如今已屡见不鲜的──“热补丁”)起到意义深远的影响。在缺乏DevOps能力的组织中,开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性,开发人员则希望基础设施响应更快,而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。
以下几方面因素可能促使一个组织引入DevOps:
使用敏捷或其他软件开发过程与方法
业务负责人要求加快产品交付的速率
虚拟化和云计算基础设施(可能来自内部或外部供应商)日益普遍
数据中心自动化技术和配置管理工具的普及
有一种观点认为,占主导地位的“传统”美国式管理风格(“斯隆模型 vs 丰田模型”)会导致“烟囱式自动化”,从而造成开发与运营之间的鸿沟,因此需要DevOps能力来克服由此引发的问题。
DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善,整个组织的效率因此得到提升,伴随频繁变化而来的生产环境的风险也能得到降低。

1

张维ACE 复制链接去分享

Wikipedia对DevOps的定义是:
DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。 它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。 ...... DevOps并不仅仅关注软件部署,它是部门间沟通协作的一组流程和方法。
持续集成思想
怎样才能达到这样一种状态呢,我们先放一下,看看持续集成(Continuous Integration)体现出来的一些思想。

DevOps是IT交付过程令人兴奋和具有深远意义的转变。承诺很诱人: 从根本上提高生产力,更低的成本和更可靠的系统。
那么,你应该跟随潮流,让你的IT部门去参与开发运营融合(DevOps),对吧?大家都开始干了,所以你也别落后。最大的问题不是干不干,而是怎样干,从哪里入手?
首先,走出去,招聘一些DevOps人才。等等,DevOps可不是一个岗位哦。
好吧,你应该创建一个DevOps工作组或者部门,对吗? 在一个DevOps主管的带领下,你可以训练出一个伟大的DevOps团队——再等等!!——DevOps既不是一个部门,也不是一种职能。

当IT运维人员开始失宠时,来自DevOps运动中的“形象提升”方法应该是最佳的应对方案。
不像DevOps(开发运营组合),IT运营的地位倍受争议, 他们被普遍认为存在公关问题。DevOps的解决方案能否像把运营专家安插在产品开发团队中,让其自吹自擂这么简单呢?一位来自Etsy.com的高级副总裁认为:“这是前进之路的一部分。”
DevOps运动的倡导者John Allspaw,也是Web运营和容量规划相关书籍的作者,曾效力于多个国际著名网站。他目前是Etsy.com(一个类似ebay但专注于手工艺品的网站)的技术运营高级副总裁。我们咨询了Allspaw关于IT运营人员引入DevOps运动之前与之后的对比,然后为他们的IT运营人员如何提升形象提出一些建议。
开发和运维在Etsy是怎么工作的?

Rackspace正在拓展他们的支持解决方案,并将Chef 等DevOps工具纳入其中以帮助企业自动化他们的云管理。
通过全新的DevOps自动化服务,Rackspace将为帮助企业部署和扩展运行在Linux上的应用的DevOps工具提供支持。Rackspace在上周四表示,该服务很快将能够与Windows协同工作。DevOps为一种软件开发概念,旨在让开发与运营部门之间的互动更为顺畅。
尽管任何人都可以使用这一服务,但是该服务最适合那些需要快速扩展基础设施或是希望在今后扩展基础设施的企业。Rackspace在网站上称,如果企业是通过Chef实现自动化或是使用StatsD、Graphite和New Relic进行监控,那么他们可以向Rackspace寻求帮助。Rackspace还将对一些用于工作流自动化、日志聚合和源控制的工具提供支持。
Rackspace能够编写、测试和维护Chef的“烹饪书”。其中“烹饪书”的功能是描述系统如何被配置。Hadoop和MySQL等软件可以通过“烹饪书”被安装、配置和优化。厂商也可以在代码发生变化或出现其它事件时帮助公司分析性能是如何提高或是如何恶化的。

1

张维ACE 复制链接去分享

与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少。根据CA的一项调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作。
DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后。
在开发者圈子中,DevOps专业人士经常是被嘲弄的对象,例如下面这个专门恶搞的Twitter帐号:DevOps Borat.
1
为了让开发、测部署试,以及运维更好的结合在一起,DevOps出现了,至此它便成了加速应用交付过程关注的宠儿。有些人认为DevOps有点姗姗来迟,因为业务的成功很显然是取决于高质量软件服务的快速交付。
无论是哪一项创新技术,最初都会面临着大量的信息和讨论,有些可能是有价值的,有些则没有。但是在你一头扎进DevOps之前,先了解一些常见的误解,避免走进误区。
误解一:DevOps很新很潮
有一个从事开发的人员,他们熟悉的语言有C++、JavaScript和Rails。在虚拟化成为主流之前,他就开始了IT运维工作,从事虚拟化多年,另外还有汇编语言。
虽然一些调查结果突出显示了DevOps的好处,Rebel实验室的负责人Oliver White最近讨论了IT组织采纳DevOps的种种困难。InfoQ有幸采访了Oliver,并回顾了这一主题的相关研究报告。
2
作为开始,Oliver表示就像Rebel实验室2013年度报告所建议的,DevOps能够带来可度量的提升。该报告与2013 Puppet实验室的DevOps状态报告和InformationWeek的问卷调查在此主题上的观点非常吻合。它们都得出结论,认为DevOps帮助IT系统变得更加稳固、也更易于快速和频繁地部署。
另一方面,InformationWeek去年10月份进行了DevOps相关调查,调查结果最近已经发布。结果显示只有75%的受访查者知道DevOps,其中只有21%已经使用它。

1

31745696 复制链接去分享

真心累,不学习跟不上时代啊

0

大拇 复制链接去分享

来学习的呀

0

国历 复制链接去分享

想请一位阿里云技术指导

0

1028975797907195 复制链接去分享

不清楚
6d14413504964db08d1d4f132c862c9e_4b13e5ae8d3b4b4b8e9e98b6015efa8c.jpg

0

隆昌集团 复制链接去分享

二零一七大发财

0

汽车架构 复制链接去分享

相关工具还是要深入学习啊

0

1751290714901701 复制链接去分享

很好的工具

0

1105687868505712 复制链接去分享

看看也不错

0

不死就疯 复制链接去分享

要学的东西越来越多,感觉力不从心!!!
混合云真应该好好的去学习了!
努力吧

0

1625490429745267 复制链接去分享

越来越好

0

aligbay 复制链接去分享

好厉害的样子啊!

2