精华内容
下载资源
问答
  • 将“AWS CloudFormation 模板”转换为另一个云编排器模板的工具 安装 将此行添加到应用程序的 Gemfile 中: gem 'cfn_converter' 然后执行: $ bundle 或者自己安装: $ gem install cfn_converter 用法 cfn2...
  • ==================== ====== ============
  • 云编排技术:探索您的选择

    千次阅读 2017-01-09 23:38:38
    最近 IT 行业有很多围绕云编排的议论,而且许多人想知道云编排到底是怎么回事。本文将探索云编排的概念,以及它将如何融入云计算的大发展趋势中。我将分析各种编排工具并介绍它们之间的区别,使您能够更好地了解有...


    最近 IT 行业有很多围绕云编排的议论,而且许多人想知道云编排到底是怎么回事。本文将探索云编排的概念,以及它将如何融入云计算的大发展趋势中。我将分析各种编排工具并介绍它们之间的区别,使您能够更好地了解有哪些可用的选择。

    首先,了解一些背景知识很重要。在虚拟化和云计算出现之前,所有流程都是手动执行的。

    众所周知,3 种最常见的云服务模型是软件即服务 (SaaS)、平台即服务 (PaaS) 和基础架构即服务 (IaaS)。图 1 演示了 IaaS 与虚拟化的密切关系(事实上,虚拟化是 IaaS 的一部分)。可以看到,IaaS 为云服务提供了基础架构来准备服务、存储、网络、操作系统等;这类似于硬件虚拟化,后者在数据中心中提供虚拟机。

    图 1. 虚拟化和云计算
    虚拟化和云计算

    设置环境的手动方法包含类似下面的步骤:

    • 等待批准
    • 购买硬件
    • 安装操作系统
    • 连接并配置网络
    • 获取 IP
    • 分配存储
    • 配置安全性
    • 部署数据库
    • 连接后端系统
    • 将应用程序部署在服务器上

    此方法面临的挑战包括管理代理程序,比如备份和监视、连网和配置。

    大约 10 年前,出现了虚拟化技术,并消除了许多手动步骤。使用虚拟机监控程序和虚拟机来部署应用程序,这有助于降低硬件成本。但是,虚拟机监控程序可能很难管理,所以引入了虚拟机监控程序管理程序来帮助消除许多手动步骤,比如购买硬件、安装操作系统和分配存储。

    在这之后不久,云计算出现了,并帮助解决了前一种方法面临的许多问题。几乎手动方法中的所有步骤都能自动化,这大大减轻了负责基础架构的人员的负担。云计算使得企业能够从任何地方以服务形式访问软件。这有助于减少人工费用,这笔费用通常比硬件成本更高。云始终可用,宕机时间为零,而且所有工作都可以很快完成。不需要等待批准 — 这真正是一种 DIY 方法。

    云编排

    云编排是在云环境中部署服务的过程的端到端自动化。更具体地讲,它是复杂计算机系统、中间件和服务的自动化的安排、协调和管理—所有这些都有助于加速 IT 服务的交付,同时减少成本。它用于管理云基础架构,后者向客户提供和分配需要的云资源,比如创建虚拟机、分配存储容量、管理网络资源,以及授予云软件访问权。通过使用合适的编排机制,用户可在服务器上或任何云平台上部署和开始使用服务。

    云编排涉及 3 个方面:

    • 资源编排负责分配资源
    • 工作负载编排负责在资源之间共享工作负载
    • 服务编排负责将服务部署在服务器或云环境中

    图 2 演示了云编排如何自动化所有类型的云中的服务 — 公共、私有和混合云。

    图 2. 云编排
    云编排

    许多人认为编排和自动化是同一回事,实际上编排更复杂。自动化通常专注于一个任务,而编排处理的是端到端流程,包括管理所有相关服务,负责保证高可用性 (HA)、部署后期工作、故障恢复、扩展等。自动化通常在特定任务的上下文中讨论,而编排指的是流程和工作流的自动化。基本上讲,编排是对自动化的自动化,具体地讲,是自动化在特定机器上执行的任务的顺序,尤其是存在各种各样的依赖关系的地方。

    为什么您应选择编排?

    您在上一节中已经看到,设置环境的手动流程涉及多个步骤。使用编排器工具,可以轻松地快速配置、准备、部署和开发环境,集成服务管理、监视、备份和安全服务 — 而且所有这些步骤都是可重复的。

    编排的另一个优势是,它使您的产品能够应用在更广泛的云环境中,使用户能够更轻松地部署它们。最终,您可以让更多的受众知道您的产品,潜在扩大公司的创收机会。

    编排工具

    您将在以下几节中看到,存在各种各样的编排工具和技术,它们分别适合不同的情形。

    Chef 和 Puppet

    Chef 是一个强大的自动化平台,它将复杂的基础架构转换为代码,并给服务器和服务注入了活力。Chef 自动化了整个网络中的应用的配置、部署和管理。

    Chef 使用操作手册 (cookbook) 来确定应如何配置每个节点。操作手册包含多个秘诀;一个秘诀是使用 Ruby 语言编写的特定服务的自动化脚本。Chef 客户端是一个代理,它在节点上运行并执行配置节点的实际任务。Chef 可管理任何可运行 Chef 客户端的实体,比如物理机器、虚拟机、容器或基于云的实例。Chef 服务器是所有配置数据的中央存储库。Chef 客户端和 Chef 服务器组合使用了公钥和私钥,以一种安全的方式进行通信,这可以确保 Chef 服务器仅响应 Chef 客户端发出的请求。您也可以选择安装名为 chef-solo 的独立客户端。

    Puppet 类似于 Chef。它需要在目标节点上安装一个主服务器和客户端代理,并提供一个安装独立客户端(等效于 chef-solo)的选项。您可以使用 Puppet 命令下载并安装部署模块。像 Chef 一样,Puppet 提供了一个付费企业版,该版本提供了报告和编排/推送部署等附加功能。

    但是,尽管 Chef 和 Puppet 都执行相同的基本功能,但它们的方法不同。Chef 似乎更加集成化和整体性,而 Puppet 由多个服务组成。这使 Chef 更容易安装、运行和管理。二者都有自己的优缺点,所以您需要评估哪种选择最适合您的操作团队和基础架构开发工作流。

    以下是这两种平台的特征比较:

    • Puppet 适合需要指定配置(比如依赖关系)的系统管理员,而 Chef 适合实际编写部署代码的开发人员。
    • Puppet 更多地依赖于自己的特定于域的语言 (DSL) 来定义配置规则,而 Chef 的 DSL 只是 Ruby 的补充,所以大部分 Chef 菜谱 (recipe) 都是使用标准 Ruby 代码编写的。
    • Chef 拥有一个综合性的(第三方)安装程序,该程序使得安装比 Puppet 容易得多。
    • Chef 主要用于操作系统级的自动化,比如部署服务器、补丁和修复问题。Puppet 主要用于中等的自动化,比如安装数据库和启动 Apache。
    • Chef 似乎更适合以开发人员为中心的操作团队,而 Puppet 适合拥有更少 Ruby 编程经验的更传统的操作团队。
    • 一旦掌握了它陡峭的初始学习曲线,Chef 就会带来比 Puppet 更强的功能和灵活性。

    OpenStack

    OpenStack 是一个免费的、开源的云计算软件平台,主要用作基础架构即服务 (IaaS) 解决方案。它包含一系列相互关联的项目,这些项目控制着整个数据中心的处理、存储和网络资源池;用户通过基于 Web 的仪表板、命令行工具或 RESTful API 来管理所有这些资源。OpenStack.org 根据 Apache 许可发布了该平台。

    图 3. OpenStack 的组件
    OpenStack 的组件

    OpenStack 是作为 Rackspace Hosting 和 NASA 的一个联合项目于 2010 年启动的。目前,它由 OpenStack Foundation 负责管理,后者是一个推广 OpenStack 软件及其社区的非营利公司实体。200 多家公司加入了该项目,包括 IBM、Canonical、Cisco、Dell、EMC、Ericsson、Hewlett-Packard、Huawei、Intel、Mellanox、Mirantis、Oracle、Red Hat、SUSE Linux、VMware 和 Yahoo,等等!

    OpenStack 的主要组件包括 Nova(计算)、Cinder(块存储)、Glance(映像库)、Swift(对象存储)、Neutron(网络)、Keystone(身份)和 Heat(编排工具)。本文不会详细介绍所有这些组件,我们仅重点介绍一个特别值得注意的组件:Heat。

    Heat

    Heat 是来自 OpenStack 的一种基于模式的编排机制,它被称为 Orchestration for OpenStack on OpenStack (OOO) 项目。Heat 提供了一种基于模板的编排机制来描述云应用程序,它执行合适的 OpenStack API 调用来生成能正常运行的云应用程序。该软件将 OpenStack 的其他核心组件集成到一个单文件模板系统中。模板支持创建大多数 OpenStack 资源类型(比如实例、浮动 IP、卷、安全组和用户),还支持更多高级功能,比如实例高可用性、实例自动扩展和嵌套堆栈。

    Heat 的工作原理

    您可以使用 Heat 来管理 OpenStack 中的所有软件(比如设置服务器,添加卷,管理网络等),而无需编写脚本。为此,您可以创建一个 Heat 模板来指定需要何种基础架构。如果需要在以后对现有服务执行任何进一步更改,您可以仅修改 Heat 模板,Heat 引擎将在您重新运行该模板时执行必要的更改。当它完成更改后,您可以清理并释放资源,这些资源可供其他任何需要它们的人使用。

    图 4. Heat 的工作原理
    Heat 的工作原理

    在图 4 中可以看到,将 Heat 模板传递给 Heat 引擎,会创建一个在 Heat 模板中指定的资源堆栈。

    Heat 在编排层中位于其他所有 OpenStack 服务的上方,能与其他所有组件的 IP 进行通信。Heat 模板生成一个堆栈,堆栈是 Heat 中的基本度量单位。您编写的 Heat 模板包含许多资源,每种资源是 OpenStack 中的一个对象并具有一个对象 ID。Heat 创建这些对象并跟踪记录它们的 ID。

    您还可以使用嵌套堆栈,它是 Heat 堆栈中一个指向另一个 Heat 堆栈的资源。这就像一个堆栈树,其中的对象相互关联,它们的关系可从 Heat 模板推断出来。这种嵌套功能使不同的团队能够独立开发 Heat 堆栈,并在以后合并它们。

    Heat 的主要组件是 Heat 引擎,Heat 引擎提供了编排功能。

    HOT 规范

    Heat 编排模板 (HOT) 是 Heat 自有的,使用 YAML 表达。这些模板包含:

    • 资源(必填字段)是您需要创建的 OpenStack 对象,比如服务器、卷、对象、存储和网络资源。这些字段在 HOT 模板中是必填的。
    • 参数(可选)指示了资源的属性。声明这些参数比硬编码这些值更方便。
    • 输出(可选)指示了在运行 Heat 模板后创建的输出,比如服务器的 IP 地址。

    每个资源包含:

    • 引用 — 用于创建嵌套堆栈
    • 特性 (property) — 资源的输入值
    • 属性 (attribute) — 资源的输出值

    Juju

    Juju 是 Canonical 开发的一个开源自动服务编排管理工具,Canonical 是 Ubuntu 操作系统的开发者。它使您能够在各种各样的云服务和服务器上部署、管理和扩展软件和服务。Juju 可显著减少部署和配置产品的服务的工作负载。

    图 5. 使用 Juju 部署的服务
    使用 Juju 部署的服务

    优势

    Juju 是在所有主要的公共云和容器上建模和部署应用程序或解决方案的最快方式。它有助于将部署时间从几天缩短至几分钟。Juju 适用于现有的配置管理工具,而且可非常轻松地扩展或精减工作负载。要为产品部署 Juju charm,无需提前具备应用程序堆栈方面的知识。Juju 包含所有主要公共云的提供程序,比如 Amazon Web Services、Azure 和 HP,以及 OpenStack、MAAS 和 LXC 容器。还可以使用 Juju 中提供的手动提供程序将 Juju 部署在 IBM SoftLayer 上,所以任何人都可以结合使用 Juju 和 SoftLayer,只需要手动准备机器,然后告诉 Juju 这些机器的位置。LXC 容器上的本地提供程序允许您在自己的笔记本电脑上重新创建类似生产部署的环境。它还提供了一个快速、简单的环境来在本地机器上测试部署。使用软件包,用户只需几秒钟即可部署整个云环境,这可以节省大量时间和精力。

    Charm

    Juju 利用了 charm,charm 是简化特定部署和管理任务的开源工具。charm 是一组可使用任何语言编写的脚本,它根据某些条件来触发挂钩。部署服务后,Juju 可定义服务之间的关系,并向外部世界公开一些服务。Charm 为 Juju 赐予了力量。它们封装应用程序配置,定义服务部署方式、服务与其他服务的连接方式和服务的扩展方式。Charm 定义服务的集成方式,以及它们的服务单元如何对分布式环境中的事件做出反应,这些反应由 Juju 编排。

    Juju charm 通常包含通过向集群添加机器来水平扩展服务所需的所有智能,保留了与依赖于该服务的所有服务的关系。这使您能够打造(并扩展和精减)您想要的服务,特别是在云上。Juju 提供了一个命令行接口和一个直观的 Web 应用程序,用于设计、构建、配置、部署和管理您的基础架构。Juju 自动化了日常任务,使您能够集中精力创建令人惊叹的应用程序。

    Charm 很容易共享,而且 Juju charm 商店 中已评级和审核了数百个 charm。

    关系和其他功能

    Juju 允许通过关系来迅速集成服务。这些关系展示了从用户那里抽象出集成服务的复杂性。Juju 关系是对服务应如何相互交互的松散分类的定义。这些定义可通过接口来处理。Juju 仅基于接口名称来确定可以关联哪些服务。

    Juju 中的一些高级功能包括:

    • Juju Compose 使用分层方法从现有 charm 构建新 charm,以便大大减少常见任务所需的返工。更低层的功能会被新 charm 继承。
    • 从属 charm 是可作为从属或主要 charm 而分组到一起的相关 charm。主要 charm 是最重要的 charm,从属 charm 不能独立使用,所以它与主要 charm 一起部署。
    • 领导挂钩是 Juju 提供的在集群环境中选择领导者/主人的自动化机制。

    Charm 商店

    Juju 包含一组 charm,使您能够在 Juju 中部署任何喜欢的服务。软件包是一个设计为协同运行的 charm 集合。因为 charm 和软件包是开放的,而且由社区负责维护,所以它们代表着一组部署这些服务的最佳实践。charm 和软件包都包含在我们统称的 charm 商店中。

    要让您的 charm 被列为 charm 管理团队推荐的 charm,您需要经历严格的审核流程,该团队会评估该 charm,测试它,并在不同的配置模式下针对所提供的服务来部署和运行测试。

    Docker

    Docker 是一个快速开发、发布、运行和交付应用程序的开放平台。借助 Docker,用户可将您的应用程序与基础架构分离,像对待托管应用程序一样对待您的基础架构。Docker 可帮助您更快发布代码,更快测试,更快部署,并缩短编写代码与运行代码之间的间隔时间。

    为此,Docker 将一个轻量型的容器虚拟化平台与帮助管理和部署应用程序的工作流和工具相结合。在本质上,Docker 提供了一种方法,在隔离的容器中安全地运行几乎任何应用程序。这使您能够在主机上同时运行许多容器。容器的轻量特性(它的运行不会给虚拟机监控程序增加额外的负担)使您能够更充分地利用您的硬件。

    Docker 容器将一个软件包装在一个完整的文件系统中,该文件系统包括运行该软件所需的所有资源:代码、运行时、系统工具、系统库 — 您可安装在服务器上的任何东西。这可保证它将以相同状态运行,无论它在何种环境中运行。

    Docker 是:

    • 轻量型的— 在一个机器上运行的所有容器共享相同的操作系统内核,所以它们会迅速启动并更高效地利用 RAM。映像是在分层文件系统中构建的,所以它们可共享相同的文件,使磁盘的使用和映像的下载变得高效得多。
    • 开放的— Docker 容器基于开放标准。这使它们能够在所有支持每种基础架构的主要 Linux 发行版和 Microsoft 操作系统上运行。
    • 安全的— 容器将应用程序相互隔离且与底层基础架构隔离,同时为应用程序提供了一个附加的保护层。

    对比容器与虚拟机

    每个虚拟机都包含应用程序、必要的二进制程序和库,以及一个完整的来宾操作系统 — 所有这些可能占用数十 GB 的空间。容器包含应用程序和它的所有依赖关系,但与其他容器共享内核。它们作为隔离的进程在主机操作系统上的用户空间中运行。而且它们不依赖于任何特定基础架构:Docker 容器可在任何计算机、任何基础架构和任何云中运行。容器与虚拟机的关键区别仅在于,虚拟机监控程序抽象化了整个设备,而容器仅抽象化了操作系统内核。这意味着有一件事是虚拟机监控程序能做而容器无法做到的,那就是使用不同的操作系统或内核。

    图 6. 对比容器与虚拟机
    对比容器与虚拟机

    优势

    Docker 容器提供了许多优势,包括:

    • 更快地交付应用程序— Docker 对开发生命周期有极大的帮助。它还使您能够在包含应用程序和服务的本地容器上进行开发。
    • 部署和扩展更容易— Docker 的基于容器的平台支持高度可移植的工作负载。它们可在开发人员的本地主机上、在数据中心中的物理机器或虚拟机上,或者在云中运行。您可以使用 Docker 快速扩展或精减应用程序和服务。
    • 实现更高的密度和运行更多工作负载— Docker 是轻量型和快速的。它为基于虚拟机监控程序的虚拟机提供了一种可行、富有成本效益的替代方案。这在高密度环境中特别有用,比如构建您自己的云或平台即服务。但是,它对您希望更充分利用已有资源的中小型部署也很有用。
    • 消除了环境不一致性— 通过将应用程序与它的配置和依赖项包装在一起,并作为容器发布,应用程序始终将按照设计在本地或另一个机器上运行。
    • 增强开发人员的创造力— Docker 容器的隔离能力解放了开发人员,使他们无需仅使用经过批准的语言堆栈和工具。开发人员可使用最适合其应用程序服务的语言和工具,而无需担心会导致冲突。
    • 加速开发人员的入职培训— 停止浪费时间尝试设置开发人员环境,建立新实例,以及复制生产代码,以便在本地运行。借助 Docker,您可以轻松地复制您的实际环境,并在任何运行 Docker 的新端点上运行它们。

    Dockerfile

    Dockerfile 是一个文本文档,包含用户可在命令行上调用来组装映像的所有命令。使用 docker build,您可以创建一个自动化的编译版来连续执行一些命令行指令。Docker 可从 Dockerfile 读取指令来自动构建映像。

    Docker Hub

    Docker Hub 是来自 Docker 的一个云托管服务,它提供了公共和私有内容登记功能。它使您能更轻松地就关键内容与更庞大的 Docker 社区或您自己的团队合作,或者通过构建工作流来自动化您的应用程序。

    比较云编排工具

    表 1 并列比较了本文中介绍的各种工具:

    表 1. 比较云编排工具
    Chef Puppet Heat Juju Docker
    主要用于自动化部署。最初,它主要用在操作系统级别上,用于执行服务器、补丁和修复程序部署等工作。后来,它被用于执行安装中间件等工作。 最初,它被用于在中间件级别上执行安装数据库和启动 Apache 等工作,探索如何使用 API 来执行所有工作。随着时间的推移,它的用法延伸到了操作系统级别的安装。 来自 OpenStack 的编排机制。 (仅)针对 Ubuntu 的基于模式的服务层(自动化)。 同时还被用作虚拟化技术和编排工具。
    更适合以开发人员为中心的操作团队。 适合具有较少 Ruby 编程经验的更传统操作团队。 编排 OpenStack 上的所有工作。主要针对基础架构,Heat 使用 Chef/Puppet 来实现安装。 可在所有流行的云平台上运行 — Ubuntu 本地机器、裸机等 一个开放平台,使开发人员和系统管理员能够构建、发布和运行分布式应用程序。
    使用 Ruby 代码编写菜谱的过程,开发人员非常熟悉 Ruby。Chef 陡峭的学习曲线在大型企业中通常被认为存在风险,可能很难在大型团队中积累和保留技能。 学习曲线没有那么陡峭,因为 Puppet 主要由模型驱动。      
    一旦掌握了陡峭的初始学习曲线,Chef 就会带来比其他工具更强大的功能和更高的灵活性。 Puppet 是一款比 Chef 更成熟的产品,拥有更大的用户群。      

    结束语

    本文笼统地概述了最流行的云编排机制,以帮助您比较和对比各种选择,确定哪种选择最能满足您的需要。我利用了我自己在学习这些技术时获得的经验,您可以根据相应情况来更深入地探索它们。下面的相关主题链接可帮助您开展探索。

    # 转自:http://www.ibm.com/developerworks/cn/cloud/library/cl-cloud-orchestration-technologies-trs/index.html

    展开全文
  • DAOIC 在云中编排的分布式应用程序
  • 【摘要】 本文介绍了为什么在一个好的公有或私有中必须要有一个编排系统来支持上自动化,以及实现这个编排系统的困难和各家的努力。同时提供了一套实现编排系统的原型,它包括了理论分析及主体插件框架,还给...

    【摘要】 本文介绍了为什么在一个好的公有云或私有云中必须要有一个编排系统来支持云上自动化,以及实现这个编排系统的困难和各家的努力。同时提供了一套实现编排系统的原型,它包括了理论分析及主体插件框架,还给出一些细节控制的建议。希望有助于大家对“资源编排&应用编排”概念有更深的了解,也希望以开放的心态与大家一起努力,使得云真的像水电一样自然和普及。

    1      摘要

    本文介绍了为什么在一个好的公有云或私有云中必须要有一个编排系统来支持云上自动化,以及实现这个编排系统的困难和各家的努力。同时提供了一套实现编排系统的原型,它包括了理论分析及主体插件框架,还给出一些细节控制的建议。希望有助于大家对“资源编排&应用编排”概念有更深的了解,也希望以开放的心态与大家一起努力,使得云真的像水电一样自然和普及。

    2      为什么需要云上自动化

    IT领域的自动化要求无需多言,每个程序员都知道这是必须品。自动化脚本,自动化测试,自动化部署等等,都是为了程序及围绕此程序的各类程序员跑的更加欢快。那么在云上我们是否还需要自动化?简单而言,初次使用无需考虑;深度用户需要云上自动化。具体体现在:

    2.1      重复性的执行动作

    在云上验证应用上线的工作中,有很多的事情是需要重复操作的。比如环境的销毁和重建;或者扩容的场景下,重复地完成多个新实例的配置动作。一旦此类操作的频率变高,比如一天一次或者一天多次的时候,你一定会觉得繁琐,并且开始尝试如何使得整个流程变的自动化,从而保证每一次执行是可重复的。也许你会写些Shell或者Python脚本,或者你主动调用云提供商的API,甚至借助某些工具如Chef,Puppet来完成这个目的。

        重复是催生自动化的首要条件。

    2.2      节约时间

    在云上使用服务,有些操作是非常耗时的,比如创建数据库,创建VM,都需等待分钟级别的时间。一旦需要串行的创建多个耗时任务,就需要用户持续等待一段时间。而此时如果可以将整个流程自动化,则可以释放人为的等待过程,使程序员去完成其他更有价值的任务。

    云上的流程自动化后,执行动作的总体耗时并不会减少,只是这段等待时间可以被转移,比如放在深夜执行。也正是这个原因(耗时没有减少,只是转移了),所以自动化后时间的节省,还是要以重复性为前途的。假如只是一次性的操作,那么“自动化节约的时间” vs “完成自动化的时间”一般都是不划算的。

    2.3      基础环境的复制

    这里的基础环境是指Infrastructure,是指应用跑在云上所需要的所有云服务的集合。例如一个典型Web网站的3层架构,前端+后台+数据库。在云上的某个区(例如华北区)域搭建好一套完整的系统后,遇到需要在华南区甚至另一个云提供商的云上,重新搭建一样的环境的时候,就会有系统复制的需求。是靠程序员手动一个一个组件的安装?还是自动化的一键重复部署?在有后者能力的情况下,当然后者是首选。

    现在很多云厂商都推行一个叫做 Infrastructure As Code 的概念,使用机器可以理解的配置文件,来代替人工交互式的配置动作。并且这种配置文件可以通过版本管理系统像代码一样进行版本管理。这样对于企业的好处主要体现有3个:减小成本、提高效率、降低风险。

    减小成本很好理解,如上提到的,自动化可以将人力转移到其他任务上,提高程序员的产出。而效率的提升主要体现在通过自动化的配置可以将环境安装的实施过程缩短,如果有多个组件或者团队交互的话,提升效率就更明显了。同时自动化可以消除人为的错误,可重复的执行特性也提升实施过程的可靠性。

    2.4      自助式服务

    云上服务,如果做得好,应该是自助式的,就像自来水和电一样,即开即用,按需付费。只有这样子才可以支持任意的自动化按需供给、按需扩容,也才是云本身所具备的含义。

    所以这一条理由其实是对云提供商提出的要求,你的云平台要能够支持用户自助式的按需使用各种云服务,并提供相应的使用计量信息(账单)和使用报告。只有当平台的后端实现流程是全自动化的,才能做到给用户的体验是完全自助式的。这跟淘宝商家的“有货随便拍”一个道理,否则没到下单前都得跟店家沟通,无法做到按需自助式使用。

    2.5      小结:自动化的成本

    任何需要自动化的东西,前提就是你需要重复的执行,只有当自动化的收益大于重复的成本,才会有自动化的需求出现。假如任务只是一次性的,那就不存在自动化的需求。相反我们相信从收益方面考虑,精心人工操作一遍会比将流程自动化更为划算。

    好比有时候路上遇到口渴并不会想安装一套自来水,还不如直接买一瓶矿泉水来的实在,而在家里,则需要安装一套自来水系统,因为你每天都需要使用水。

    云上的自动化提供了一种可靠性,它使得云资源,云服务的每一次创建的行为都是一致的,任何用户,任何组织的执行都是可重复的;同时也消除了由于人为操作可能的失误所带来的问题,是云上深度用户的必需品。

    3      云上自动化演进

    3.1      自动化面临的困难

    (1)云服务的种类丰富多样,导致想要完成全面的自动化并非易事。一个典型的云平台会提供了ECS(虚机),EVS(硬盘),VPC(网络),RDS(数据库),ELB(负载均衡)等等一系列数都数不清的服务。有一个新的术语叫做 AWS fatigued,就是说AWS每年都会上线各种新服务&新特性,使得用户对新上线的服务&特性都感到了“AWS疲乏”,疲于使用。

    (2)云服务间的创建存在复杂的依赖关系。最典型的例子就是,当创建EIP的时候,需绑定VM,而创建CM的时候,又需要先创建Subnet,建Subnet的前提就是需要先有VPC。层层的依赖,以及交叉依赖,都为开发者在企图自动化的道路设置了拦路虎,使得完成自动化的成本大大提高。根据前面提到的成本大于重复性收益的时候,自动化就会被放弃。

    (3)云上资源的使用方式与传统方式不同。用户从资源的完全拥有者变成资源的使用者,后台权限的降低,导致你无法掌控一切,使得不那么方便的定位资源初始化失败原因(也许云平台本身的Bug导致)。有时候不得不联系云提供商求助了解失败原因。另外在使用流程上也会稍有改变,原来你的软件包一次拷贝就到了验证环境,而在云上,也许你需要中转跳板才能达到目的。这些都加剧了自动化的实施困难。

    3.2      自动化的尝试

     探索.PNG

    这里直接给一个图来总结了云上自动化的尝试历程,可以更加直观的了解这一领域的发展情况。不过在资源供给自动化和资源编排上其实边界也没有那么的明显,可以看到主要的差异是在灵活的语法上。在已有的自动化模板里面逐步增加一些灵活的语法,基本可以达到灵活编排的目的。

    4      终极的自动化体系-编排

    自动化是指一个任务流程中不需要人为的干预,而编排则是指多个任务流程可以提前规划,任务间可以互相配合,并行或者串行的执行。可以从最直接的定义上看到,只有做到任意的自动化流程控制才能称之为编排,是一个自动化的升级版。由此可见,如果某云厂商的一个编排系统,连一些基础的自动化流程都无法满足,那么它就不是一个好的编排系统。

    4.1      云上的编排标杆

    提到云上的编排系统,就不得不提老大哥AWS的Cloudformation了,基本上它已经是AWS云生态的一个标准,支撑应用市场以及服务目录完成任意IT软件和IT基础设施的初始化流程。

    它的主要原理就是用户提供创建对象的各种属性,然后CFN协助完成对象的创建。例如初始化EC2,就是相当于创建VM虚拟机。那么用户就得提供属性:主机名,用什么镜像,硬盘多大,用什么网络,主机规格,安全组等。有了这些属性,CFN就可以确定如何调用EC2的API来创建VM了。

    它之所以能力很强是因为它除了提供执行顺序的控制能力以外,在语法层面还提供了很多的内置函数,用户可以通过函数来引用变量,拼接变量值,控制执行细节。超丰富的编排对象,使得使用CFN基本可以满足任意AWS资源的自动化创建。

    4.2      云上编排系统对比

    这里分析三家典型的提供编排能力的云厂商能力分析表,不对之处也请联系纠正。(亚马逊CFN阿里ROS华为AOS

    √表示“强/做得好”,O表示“一般/待增强”,X表示“没有此特性”。

    注:OpenStack的Heat编排能力类似AWS,但是无图形化设计器,这里就不列举了。

    4.3      编排系统的不足

    当前的编排系统都需要一个描述文件,来描述用户希望的执行流程。一般都会把这个描述文件称之为“模板”。通过模板来控制执行逻辑,这并不是一个问题,因为你能看到的业界编排系统都有自己的“模板”语法规则。问题在于,从无到有的写作一个新的模板,会比较困难,需要使用者学习一定的门槛,大家的第一感觉总是像在学习一门新的编程语言。

    这个是由编排的目标对象的复杂度决定的:创建一个RDS数据库,就是会比单独创建一台VM,需要有更多的控制参数。于是一种新的模板语法,相当于一种新的编程语言。写过代码的你肯定知道,想要快速的编码,当然需要合适的IDE支撑。也正因此,一些有实力的编排系统就会推出相应的图形化设计器,其定位就是配套的模板写作IDE。

    比如AWS,阿里和华为都提供了在线的模板编辑IDE。设计器好坏的评价标准就是能否支撑方便的写作模板。

    5      如何实现云上编排系统

    一个编排系统的核心就是一个工作流引擎,负责分析各个步骤间的依赖关系,并按照DAG(有向无环图)模型来控制这些流程的执行顺序。而云上的编排,更加的具化,就是按依赖顺序创建各个云服务。

    算法层面,我们可以称每个云服务为元素。创建各种云服务的过程,就是按顺序创建各个元素的过程。

    5.1      有向无环图DAG

    有向无环图(Directed Acyclic Graph, DAG), 是有向图的一种,字面意思的理解就是图中没有环。常常被用来表示事件之间的依赖关系,用于管理任务之间的调度。

    image.png

    图:一个有向无环图的例子

    其中所有节点的拓扑排序是有向无环图中经常需要使用到的算法,我们的系统原型也是按照此理论基础进行实现的。就是把所有元素按照DAG依赖关系确定好谁先谁后的顺序,具体算法大家可以在网上或者资料中搜索获得,这里就不细介绍了。排好序后,接下里的实现就是先完成底层的元素,再完成上层元素,直到所有元素都初始化完毕。以上就是我们的编排系统模型的理论参照。

    5.2      编排系统原型

    在这里我们假设有一个系统的初始化流程如下:

    image.png

    要实现所有元素按照设定好的顺序创建,我们遵从两个要点:(1)默认并行执行。(2)无依赖的先执行。具体算法实现上,我们首先将元素启动顺序分解为有向图,并遍历计算得到每个节点的依赖数。如下:

    image.png

    注:依赖只需要计算临近的节点就可以。

    遵循之前的两个原则:那么元素B和元素D的依赖数是0,所以这两个元素可以先执行初始化。同时B和D之间无关,可以并行执行。

    在任意一个元素执行完之后,所有依赖这些节点的依赖数减一,重新得到所有节点的依赖数:

    image.png

    本次可以执行的元素就是C和F,因为它们的依赖数为0。在这两个元素执行完后,将依赖他们的元素的依赖数减一,重新得到所有节点依赖数:

    image.png

    按照上述的逻辑递归执行,直到所有的元素都被执行完,整个工作流就完成了。它保证整个流程是按顺序用时最短的。从工作流实现原理可知,编排的能力强弱并不强调流程控制,而是编排元素,及编排语法的丰富程度。好的编排系统,可以快速的完成新元素的驱动开发,从而提供新服务的编排能力。

    5.3      元素间信息传递

    如果每个元素初始化,都得记录着其他元素的信息,这种在实现上元素间就很耦合。为了保持每个元素在执行时候的独立性(即当前元素在初始化时,不用去了解其他元素的信息)。主体框架需要保持一个全局信息,然后在初始化一个元素的时候,把这个元素需要的信息告诉它就行。它自己完全不知道还有哪些其他元素,反正它自己需要的信息都有了。

    image.png

        这里举例说明,调度框架维护一个全局信息,记录每个元素需要哪些参数才能初始化。上图绿色的需要用户提供,红色的则在被依赖对象创建后自动获得。比如创建VM需要VPC的ID,那么在VPC创建后,VPC的ID就知道了,这个字段不用用户提供。

    所以在元素D初始化完成后,元素C就可以开始初始化了。这个时候,所有创建C的参数,都应该是确认的值。在调用C服务的初始化API的时候,不缺任何信息。这样在实现C的创建API和销毁API,就非常独立,只与C服务本身打交道。

    image.png

     如上图,在开发新服务的时候,只需要了解新服务自身就可以了,所有想要的信息(可以直接要求用户提供,或者通过依赖获得),都会通过框架管理和传递。

    image.png

    这就是我们的插件化框架,这个框架使得新增一种服务非常容易。因为服务的驱动开发是完全独立的。

    5.4      插件设计

    5.4.1        元素的生命周期

    每一种云服务对象,在编排系统看来都是一个元素。新增一种元素的编排,就需要该元素提供增删改查等基础执行能力。编排系统的插件管理框架会根据用户执行动作,比如创建or销毁,来调用元素对应的API。

    有了上一节的元素执行流程框架后,新增一个编排对象,只需要完成该元素的各种行为驱动就可以。例如:只要有创建和销毁VM的方法(API),那么就可以在编排元素里面增加一个EC2服务,就可以在模板里面增加这种元素的编排了。调度框架只是把它当做一个普通元素来对待。

    5.4.2        用户自定义插件

        基于插件框架每个元素驱动独立的优势,同时考虑到Kubernetes中的Resource对象也有自定义扩展特性(custom resource definition),可以设计一种元素插件支持用户定义自己的K8S编排对象的能力。即把用户提供的“信息”原封不动的传递给底层API。由底层系统去解释用户的“信息”。编排系统退化为只负责流程控制+信息传递通道。

    5.4.3        操作的等待&进度

    之前提过,有些云服务的操作非常耗时,如果不能提供整体进度的直观反馈,用户体验就会非常的差,以为整个执行流程挂死。所以在元素驱动的编写时,必须考虑进度和等待反馈,让编排框架能感知执行进度。使得用户可以知道当前在执行哪个元素,该元素的执行进度如何。从而确保整体的编排流程能够给用户最直接和友好的反映。

    5.5      TOSCA模型

    有了调度框架&插件框架,剩下的就是配置文件的语法了,目前主要的可借鉴语法就是AWS的Cloudformation和TOSCA语法。其中AWS-CFN是以资源初始化为中心的,而TOSCA的定义为TOSCA is a specification that aims to standardize how we describe software applications and everything that is required for them to run in the “cloud”,可见TOSCA是更加偏向于面向App的。鉴于容器技术的流行,越来越多的应用以独立容器出现,不再强调需要传统的VM。我们觉得模板语法使用TOSCA是个不错的选择。

    实际上,在自动化的过程中,你会发现:模板的语法并不是关键点。只要能自动化,模板写出来都不会相差太大,所以关键还是看自动化能力。这个就好比编程语言的选择,JavaGo,写二叉树遍历不会在意是用for还是用while。各种编程语言的主要区别在内置函数/库上,所以在模板的语法上提供丰富的自动化便利性才是目的。这一点需要向AWS学习,它提供了很多的内置函数

    6      总结

    在云上,自动化其实是刚需,只有完成了自动化这个基座,才能构建出完整的云生态。而编排作为一种高级自动化能力,需要负起推动云生态走向完整的重任。是检验一个云厂商实力的硬通货。

    华为PaaS团队在云上,特别是PaaS云上的自动化&编排领域,有多年的探索和积累。在此希望能与业界一起分享并推动云上编排领域的发展,使得在云的使用过程中能带来更好的用户体验,让云上自动化能真正如云这个趋势一样无处不在。

    如果有好的想法&建议,也可以跟我们交流。

    来源:华为云社区  作者:tsjsdbd

    展开全文
  • 通常,当讨论混合时,这样的讨论的自然选择通常围绕OpenStack加上VMware,或AWS与OpenStack, 甚至不同的云和容器选项 - 但Azure与OpenStack相结合是一个不太常见的讨论。 通常,当讨论混合时,这样的讨论的...
    • 通常,当讨论混合云时,这样的讨论的自然选择通常围绕OpenStack加上VMware,或AWS与OpenStack, 甚至不同的云和容器选项 - 但Azure与OpenStack相结合是一个不太常见的讨论。
      这里写图片描述

    通常,当讨论混合云时,这样的讨论的自然选择通常围绕OpenStack加上VMware,或AWS与OpenStack, 甚至不同的云和容器选项 - 但Azure与OpenStack相结合是一个不太常见的讨论。

    这实际上是一个独特的结合,你认为它是Azure的公共云和OpenStack的私有云高度企业目标.
    随着Azure拥有企业级安全和加密,甚至提供他们最近宣布的Azure堆栈,旨在帮助企业弥合他们的数据中心和云之间的差距,和OpenStack的固有开放性的API,使企业能够构建自己的云,这些应该自然适合在云端景观。然而,这种组合令人惊讶地经常被忽视。

    Nati Shalom最近在他的文章中讨论 前提下实现混合云的最小公分母 这些天,一项调查表明,企业往往同时利用多达6种云,而且该列表只是随着新技术的兴起而不断增长。

    这就是为什么像Azure Stack这样的解决方案,也适用于云应用程序从传统数据中心迁移到云中的多云scenerios,特别是在考虑到这种转换涉及的所有企业级考虑时,危急。

    在历史上,为了实现云可移植性,您需要通过将您的应用程序从以下基础设施的所有基础逻辑抽象化来满足最小公分母,但是这种类型的模型价格昂贵。特定云提供的所有实际优势。如果有更好的方法怎么办?实现互操作性和云之间的可扩展性的方法,同时充分利用底层云功能和服务组合。

    但是即使如此,这些天的许多解决方案并不总是提供可扩展性和互操作性企业,这些日子需要用于面向未来,应用程序部署可移植性以及跨云的其他流行使用情况。混合云本身也已经证明,它不会免疫未来证明与破坏性技术每天出现 - 没有不同,最新和最大的容器(阅读更多的破坏周期)。这意味着新方法需要实际构建用于混合堆栈,而不仅仅是云,同时提供底层基础结构提供的全部功能。

    输入TOSCA(Oasis Foundation for the cloud applications的标准)。 TOSCA是为这个确切的场景编写的,并提供固有的云互操作性和不可知论。 TOSCA方法旨在标准化应用程序在云环境中编排的方式。和企业爱标准。构建一种语法和词汇使组织能够以大大简化的方式适应快节奏的云世界。

    基于TOSCA的Cloudify作为一个集成平台构建起来,利用标准化的模板,工作流和云插件提供跨越不会本机或直观地插入到彼此的技术的单一窗格,例如OpenStack和Azure,甚至Kubernetes或Docker,以及非虚拟化环境(如传统数据中心)。 Cloudify使得有可能选择一种适应您组织工作或希望工作的技术,而不需要您根据所采用的技术调整您的技术,堆栈或实践。

    模板化语言(如TOSCA)比API提取具有更大的灵活性,提供企业所需的可扩展性和定制级别,而不需要开发或更改底层实现代码,这就是为什么重要项目,如ARIA,Tacker,和OpenStack Heat正在构建基于此标准的解决方案。

    通过这种方式,Azure用户现在拥有一套构建块,用于跨云,堆栈和技术管理整个应用程序堆栈及其生命周期。随着微软现在自豪地拥有最开源的开发人员在GitHub,yup - 在Facebook,Angular,甚至谷歌

    这也将最终提供更高程度的灵活性,允许用户针对每个用例或应用程序定义自己的抽象级别。以这种方式,可以实现云可移植性,而不需要改变底层代码,实现真正的混合云。

    展开全文
  • 软件定义的云编排:集成的体系结构和部署过程这是xSDN项目的扩展,xSDN是动态网络流的高效仿真。 如果您使用了该项目或在工作中引用了此项目,请引用以下论文。 卡蒂拉维鲁(Kathiravelu),普拉德班(Pradeeban)...
  • 合成管弦乐队/合成管弦乐队 尝试为计算机音乐合成启用云计算机的编排。 当前在云端处理实时音频可能面临的问题是配置问题。 我们想要制作音乐和声音,而不是成为 DevOps/系统管理员。 当前目标: 使用厨师将...
  • 罗马竞技场 安装(开发) 依存关系: 播放框架2.3.9 一个与hibernate兼容的数据库(以下部分将使用mysql) JDK 8 按照安装播放框架。 安装mysql并设置数据库和该应用程序的用户。 git-clone仓库。...
  • 阿里资源编排ROS使用教程

    千次阅读 2019-04-26 14:58:35
    详细课程链接:阿里资源编排ROS使用教程——阿里大学 什么是资源编排服务? 阿里资源编排服务(Resource Orchestration Service 简称 ROS)是一款帮助阿里用户简化云计算资源管理和自动化运维的服务。用户...

    详细课程链接:阿里云资源编排ROS使用教程——阿里云大学

    什么是资源编排服务?

    阿里云资源编排服务(Resource Orchestration Service 简称 ROS)是一款帮助阿里云用户简化云计算资源管理和自动化运维的服务。用户遵循 资源编排定义的模板规范,编写资源栈模板。您只需要创建一个描述自己所需的所有阿里云资源(如 ECS 实例、 RDS 数据库实例等)的模板,然后资源编排将根据模板,创建和配置这些资源。在模板中,您定义所需的云计算资源、资源间的依赖关系、资源配置等。资源编排通过编排引擎自动完成所有资源的创建和配置,以达到自动化部署、运维的目的。资源编排模板是一种用户可读、易于编写的文本文件。您可以直接编辑 JSON 格式文本,也可以使用资源编排控制台提供的可视化编辑器,更为直观地编辑模板。您可以随时编辑修改模板。通过 SVN、Git 等版本控制工具可以控制模板的版本,以达到控制基础设施版本的目的。也可以通过 API、SDK 等方式把资源编排的编排能力与自己的应用整合,做到基础设施即代码(Infrastructure as Code)。

    资源编排模板也是一种标准化的资源和应用交付方式。如果您是独立软件供应商 (ISV),您可以通过资源编排模板交付包含云资源和应用的整体系统和解决方案。ISV 可以通过这种交付方式,整合阿里云的资源和 ISV 的软件系统,达到统一交付的目的。

    资源编排服务是通过资源栈 (Stack) 这种逻辑集合来统一管理一组云资源(一个资源栈即为一组阿里云资源),所以,对于云资源的创建、删除、克隆等操作,都可以以资源栈为单位来完成。在 DevOps 实践中,可以轻松地克隆开发、测试、线上环境。同时,也可以更容易实现应用的整体迁移和扩容。

    ROS

    “基础设施即代码”(Infrastructure as Code)不止是概念,相比于传统方式,资源编排 (ROS)能够便于您:

    • 通过模板描述云资源编排过程,轻松创建并管理云计算资源的生命周期,自动化部署和配置,简化云应用交付;动态调整云计算资源栈以满足业务发展需要;快速复制整套资源栈;标准化的版本控制和资源变化跟踪,通过API和SDK集成自动化运维能力。
    • 专业指导手把手教您编写,扫描下方二维码加入VIP用户群。
    • 使用资源编排 ,不需要支付额外的费用。
    • 支持云服务器ECS、云数据库RDS、Memcache、负载均衡、对象存储、日志服务、访问控制等核心云产品和服务。

    ROS支持通过模板灵活组装多种云产品或服务:
    您可以根据业务场景灵活组装云服务,以满足自动化运维的要求。 

    典型应用场景:

    • ECS克隆

    瞬间克隆相同配置(包括实例规格、网络配置、磁盘配置、安全组设置、UserData)上限100台的云服务器ECS。

    • 创建子账号

    轻松实现创建子帐号、授权,并开启控制台登录,实现企业权限管理。

    • 云服务器ECS、云数据库RDS组合

    云服务器 + 云数据库的经典组合,不再需要多个步骤,一个模板一键搞定。

    更多精品课程:

    阿里云大学官网(阿里云大学 - 官方网站,云生态下的创新人才工场

    展开全文
  • 本文介绍了为什么在一个好的公有或私有中必须要有一个编排系统来支持上自动化,以及实现这个编排系统的困难和各厂商的努力。
  • 感谢您更深入的了解、学习并使用华为AOS应用编排服务。 通过华为AOS部署应用上云流程非常简单,您只需要编写好模板,并基于该模板创建堆 栈,同时,AOS还提供了应用生命周期管理能力,如升级、伸缩、回滚等。
  • 华为云,服务,架构。2018华为技术私享会演示文档。从“容”不迫,揭开容器神秘面纱。
  • 该项目旨在实现一个云编排层,我们将在其中借助 Docker 远程 API 创建删除虚拟机(VM)容器。 我们还将创建一个 Web 界面来与 docker 远程 API 进行交互。目标是提供一个纯客户端实现,以便轻松连接和管理 docker...
  • 阿里资源编排ROS产品优势

    千次阅读 2019-04-26 15:25:31
    详细课程链接:阿里资源编排ROS使用教程——阿里大学 资源编排(Resource Orchestration)是一种简单易用的云计算资源管理和自动化运维服务。用户通过模板描述多个云计算资源的依赖关系、配置等,并自动完成...
  • 文章目录编排网络结构典型扁平网络架构典型大二层技术NovlanVlan典型编排网络组网规划扁平三层网络公有网络系统网络私有网络扁平网络服务DHCPEIP安全组扁平网络配置场景实践 编排网络结构 典型扁平网络架构 典型...
  • 前端应用、后端应用、数据库,每次创建管理应用系统同样的流程都得走一遍;华南地区已经部署好的环境,复制到华北地区,本以为一键就能实现,结果是同样的环境再部署一次……时代来了,这样重复性...
  • 基础设施编排介绍

    2020-03-04 08:02:37
    编排功能支持跨计算、存储和网络基础设施的智能分配资源,从而降低成本。通过使用软件动态自动化供应、管理和协调服务,您将可以加快服务部署速度,减少人工干预环节。
  • 平台资源编排方案对比.pptx
  • Circuit是一个可编程的平台即服务(PaaS)和/或基础架构即服务(IaaS),用于管理,发现,同步和编排包含应用程序的服务和主机。 Circuit旨在在技术企业的人类工程角色之间实现清晰,负责和安全的接口,从而最终...
  • theme: condensed-night-purple 小知识,大挑战!本文正在参与“程序员必备小知识”创作活动。...这篇文章着重分析市面上八大主云编排工具,提供它们的主要功能,以及使用场景。 一、云编排的优点 以...
  • 新浪公有Docker编排实践

    千次阅读 2016-07-14 10:39:54
    【编者的话】本文是@Container容器技术大会·北京站上新浪带来的分享——新浪公有Docker编排实践。文章围绕微博DCP系统——基于Docker容器混合架构的应用实践,介绍了新浪在Docker编排上的经验以及遇到的问题。 ...
  • Terrasalt(Terraform + Salt)将云编排与配置管理集成。 这使用户可以使用Terraform创建基础架构(例如虚拟机),然后使用Salt来配置和管理基础架构。 该项目的灵感来自于我们从使用切换到Terraform。 我们错过了...
  • 基于服务编排制造服务协同.pdf
  • 一、领域澄清 首先明确我们在讲什么,也就是本文描述的应用编排,资源编排是什么东西。 在云上编排的含义一般有两种: 1.云平台上自动化创建云服务,并部署应用。...二、公有云编排服务介绍 AWSCloudformation...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 32,418
精华内容 12,967
关键字:

云编排器