多云管理更为复杂原因基础设施即代码

　　欢迎各位阅读本篇文章，通过组合件一键式供应多层应用。策略驱动的扩展、收缩、实时迁移和电源管理。本篇文章讲述了多云管理更为复杂原因基础设施即代码，课课家教育平台提醒各位：本篇文章纯干货~因此大家一定要认真阅读本篇文章哦!

　　对于任何一个力，都存在着一个与其大小相等方向相反的反作用力。这个物理学上的牛顿第三定律也同样适用于IaC：虽然这一服务是有优势的，但它也带来了一些问题。

　　本文是针对混合云和多个云管理使用基础设施即代码系列中的一部分。

　　基础设施即代码是一个强大的工具，它可以帮助简化混合云和多个云的管理工作，因为它能够实现服务器、容器以及虚拟机的部署与配置操作的自动化。但是，它也可能会导致出现低效过程、部署错误以及常见混乱等问题。那么，用户应当如何解决实施能够确定成功与否的基础设施即代码所带来的挑战呢?

　　在实施基础设施即代码过程中，大多数企业所遇到的第一个挑战就是在开发人员和运营团队之间创建一个和谐融洽的平稳关系。在过去，开发人员在为应用程序设置托管平台时几乎很难有所作为。这就会带来问题，尤其是在从应用程序测试到实际生产的过渡过程中更是如此。在大型企业中最常用的开发运营工具能够有助于推动开发团队和运营团队之间的协作。但是，对于那些缺乏开发运营理念与工具以及相关企业文化的公司来说，实施一个混合云或多个云可能是第一次需要这样一种合作。

　　如果企业用户在开发初期就将应用与特定平台相互关联，然后让这些平台需求推动基础设施策略贯穿整个应用程序生命周期管理直至最后生产，那么实施一次基础设施即代码还较为容易完成的。此外，当虚拟平台数量是可管理时，这一目标也是较为容易实现的。这些虚拟平台是应用开发的目标，它们可用于在所有云中或者数据中心资源(应用就是在数据中心资源上运行的)上部署应用。仔细定义这些虚拟平台并让开发团队和运营团队使用它们作为各自工作的重点。

　　不要模糊不同角色之间的界限

　　第二个挑战就是确保基础设施即代码和开发运营团队在混合云和多个云管理策略中各司其职，正常发挥合适的作用。开发运营主要关注应用程序部署，而基础设施即代码则主要负责资源配置管理。亚马逊网络服务(AWS)提供了开发运营工具Chef作为其云服务的部署管理工具，这一事实表明两者之间的界限有可能会发生模糊。事实上，最常见的基础设施即代码工具是开发运营的一部分。这一状况可能会造成开发团队和运营团队之间的持续混乱。

　　除非用户纯粹出于服务器整合的目的来使用云服务，希望还需要开发运营来实现部署自定义和应用程序生命周期管理的简化。对于企业用户来说，如果没有正确好用的工具集，那么部署多层次、多组件应用程序并保持一致地正确协调应用程序响应云计算或数据中心故障将是一项非常困难的任务。即便用户并不立即需要所有的开发运营能力 ，那么也可以选择一个开发运营工具，例如Chef、Puppet、Ansible或Salt等，然后采用其基础设施即代码方法。

　　不要千篇一律地对待所有的云服务供应商

　　当使用基础设施即代码来简化混合云和多个云管理时，第三个挑战就是解决不同云托管环境之间的差异性问题。大多数用户最终将使用一个混合云计算模式或多个云模式，而其中很多人已经这样做了。每一家公共云供应商都有一个不同的管理框架，他们报告问题的方式也不一样，如果发生错误所需要采取的补救措施也不相同。管理这些问题将让开发运营所部属的和基础设施即代码所控制配置的应用程序之间的界限变得模糊起来。

　　按照用户开发运营工具供应商的建议来区分定义，何种情况由基础设施即代码层来处理，何种情况在开发运营层作为“事件”上报。确定用户所计划做出的任何变更是否会影响如何部署虚拟平台，或者如何部署应用程序本身。在第一种情况下，可考虑重新部署资源，例如虚拟机或容器;而在第二种情况下，可考虑重新部署应用组件。例如，如果用户必须扩展应用程序中一个组件，那么相关变更必须发生在开发运营层，但如果用户必须更换故障组件，那么有可能应在基础设施即代码层实施这一操作。

　　云供应商有不同的网络服务，这一事实就带来了下一个挑战。基础设施即服务和基本容器服务在应用镜像外提供了最小的中间件。但是一些供应商(例如AWS和微软Azure)提供的网络服务从本质上说就是云托管的中间件。云供应商提供这些网络服务的形式各有不同，或者在某些情况下，他们甚至都完全不提供这些网络服务。

　　由于不同的托管环境无法提供相同的功能，所以应用无法具备跨不同托管环境的可移植性。如果不可能在多家云计算供应商之间实现网络服务的一致性，那么应当明确命名虚拟平台以表明它们是不可移植的。如果用户所使用的所有平台上必要的网络服务可用，但需要不同的部署配置，那么用户可以使用基础设施即代码脚本程序来为用户虚拟平台定义多个托管选项。

　　不要碎片化实施基础设施即代码

　　实施基础设施即代码的最后一个挑战就是配置外部的小修小补。让基础设施即代码在断开连接的碎片环境中正常运行是非常困难的，同样让企业在缺乏基础设施即代码工具或脚本程序的情况下做出某些配置变更也是非常不容易的。例如，运营团队经常会在不更改基础设施即代码脚本程序或模式的情况下做出一些配置变更以适应新的软件版本。这就意味着这些脚本程序将不再部署托管配置的正确版本。

　　解决这个问题需要执行严格的运行纪律。如果没有通过正式的变更管理系统将这个变更记录在册，那么运营团队就绝不应当对系统或云配置做出这样一个变更操作。当他们确实需要做出变更时，他们应当修改基础设施即代码脚本程序并按要求重新配置，然后将相关变更登记在册。无论何时运营团队修改了基础设施即代码的脚本程序，他们都必须将这个变更反馈给开发团队以便针对应用程序需要验证该变更。

　　基础设施即代码是基于配置管理和开发运营的一种发展，但他也是一个新兴的范例。为基础设施即代码的未来做好规划是非常重要的，否则用户将面临无法发挥混合云和多个云管理部署全部潜力的风险。

　　知识分享：

　　“云管理”，综合协达软件、金蝶、用友等云管理软件主流厂商对云管理的定义，云管理是指运用社交网络、移动互联网、云计算等新兴技术所催生的创新型管理模式。

　　“社交网络”，即社交网络服务，源自英文SNS(Social Network Service)的翻译，中文直译为社会性网络服务或社会化网络服务，意译为社交网络服务。社交网络含义包括硬件、软件、服务及应用。

　　“移动互联网”(Mobile Internet)，是指互联网的技术、平台、商业模式和应用与移动通信技术结合并实践的活动的总称。

　　“云计算”(cloud computing)，是基于互联网的相关服务的增加、使用和交付模式，通常涉及通过互联网来提供动态易扩展且经常是虚拟化的资源。狭义云计算指IT基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源;广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是IT和软件、互联网相关，也可是其他服务。

　　云管理学院

　　MIP云管理学院，简称MIP(Mobile, Interactive, Practive)，中文含义为移动、互动、行动。是一个基于移动互联网的交互平台，为企业内部员工及企业之间提供沟通交流，并集成了培训和管理等功能的IT工具。

　　人们既可以在某个以企业为单位的圈子内互动，也能够在以某个特定主题的圈子内交流;可以通过微博的方式分享知识和想法，也能通过观看视频的方式进行学习。企业家和领导者可以在MIP平台上与下属和员工进行近距离直接交流，普通员工的声音也可以让所有人听到。

　　企业可以通过MIP建立内部和外部的培训体系，积累员工的智慧形成长期的知识积累，通过有形的方式逐步传递企业文化，建立公开透明的管理模式。

　　在MIP云管理学院内，每个参与者都同时是知识的贡献者和受益者，每个人都是云知识的云端，参与的人数越多，积累的知识和经验越多，每个人得到自己想要的知识内容也越多。

　　我们可以通过互联网终端和平板电脑、移动通信终端手机和其他移动设备登陆MIP，随时随地参与学习、互动和分享。

　　小结：相信最后大家阅读完毕本篇文章，肯定学到了不少知识吧?它尽可能提高了对基于 Oracle 的服务的可见性和控制，同时提供全面的监视和报告解决方案，其实大家私下还得多多自学，当然如果大家还想了解更多方面的详细内容的话呢，不妨关注课课家教育平台，在这里你肯定会有意想不到的收获的!