云端编曲:这是怎么回事?

  编排是否可以被认为是供应和配置管理的更好的替代方案,特别是在云本地应用程序的情况下?我们可以从不同的角度来看待这个问题;与面向数据中心的解决方案进行比较;区分基础设施(云中和云外)和容器(主要集中在云上)的编排,以及在不同场景下的最佳实践。
 
  这里值得注意的是,这个话题不仅可以涵盖大量的文章,也可以涵盖大量的书籍——正如伟大的理查德·费曼(RichardFeynman)曾经说过的那样,它不仅涉及阅读或解决问题,而且还涉及讨论想法、谈论想法以及与他人交流。
 
  我想从我最喜欢的编曲定义开始,可以在韦氏词典中找到。配器是“和谐组织”。
 
  基础设施还是集装箱?
 
  在讨论编排时,不可避免地,我们问自己的第一个问题是:基础设施编排还是容器编排?
 
  这是两个独立的巨人,但毫无疑问,我们将在当前的IT领域面对他们。这完全取决于我们想要达到的抽象层次,也取决于我们如何组织堆栈,以及我们想要处理哪些层,或者相反。
 
  如果我们决定在基础设施级别进行管理,我们将使用虚拟机和/或裸机服务器—换句话说,可以是多租户服务器,也可以是单租户服务器。假设我们以IaaS的方式租用我们的云,那么我们就获得了资源,比如前面提到的网络资源、存储、负载均衡器、数据库、DNS等等。从那里开始,我们可以随心所欲地建设基础设施。
 
  如果我们决定在CaaS(有时被视为PaaS)级别进行管理,那么我们将管理容器的生命周期,或者正如文献中经常提到的那样,管理工作负载。对于那些不熟悉容器的人来说,这是一种看待工作负载的新方法。其中最受欢迎的是Docker、Rkt和LXC。容器非常适合定义一个不可变的体系结构,也适用于微服务定义——更不用说它们是轻量级的、易于移植的,并且可以打包以备将来使用。
 
  这两种方法各有利弊,但现在,让我们继续讨论这两个端点上的编排方面。基础设施
 
  有几种方法可以协调基础设施:以下两种方法似乎是当今公司中最流行的。
 
  供应和配置管理:实现这一点的一种方法是使用comboPXe/Kickstart文件这一老派的方法,尽管它正在慢慢地被更自动化的解决方案所取代,而且一些公司仍然坚持使用它,或者像Cobbler这样的替代方案。另一方面,我们使用的工具,如福尔曼。Foreman支持跨不同操作系统的BIOS和UEFI,并与Puppet和Chef等配置管理工具集成。Foreman在数据中心资源调配方面大放异彩,为我们提供了一个易于管理的基础设施,可以随时使用,甚至可以对配置进行更多的管理。
 
  一旦配置方面完成,我们将进入配置管理,这将允许在整个生命周期中进行管理。有很多口味:Ansible、Chef、Puppet、Salt,甚至是古老而可靠的CFengine。最后两个是我最喜欢的,甚至是Ansible,一把瑞士军刀,它帮助了我很多次,因为它的工作方式简单且不太熟练。
 
  编排和可选的配置管理:现在,编排在概念上意味着一些不同的东西——如前所述,和谐的组织——现在经常使用的工具是Terraform。另一方面,它允许在数据中心或云中进行编排,与不同的云集成,如AWS、Oracle云、Azure甚至阿里云。Terraform有许多提供者,有时资源管理的灵活性在于底层。除了云提供商,还可以将Terraform与第三方(如PagerDuty)集成,并处理所有类型的资源。从第一手的经验来看,这种整合是平稳和简单的,虽然是理所当然的,但有时还不够成熟。
 
  并非所有的供应商都会产生同样的灵活性。当我开始在Oracle云中使用Terraform时,OCI还没有成熟到可以自动伸缩的程度;因此,提供商不允许Terraform创建自动缩放组,有时因为过去使用Terraform和AWS,我认为这是理所当然的。所以另一个技巧是看一下提供商的能力,不管是云还是其他什么。有时,我们的工具只是不能很好地相互集成,设计一个合适的架构,这是一个不能掉以轻心的方面。
 
  Terraform的另一个优点是,它允许编排任何基础设施,而不仅仅是计算机;它从虚拟机、裸机等,发展到网络资源和存储资源。同样,它将依赖于云、Terraform提供程序和使用的插件。
 
  使Terraform成为新一代工具的不仅仅是编排,还有作为代码的基础设施(IaaC)方面。整个行业都朝着IaaC的方向发展,Terraform也不例外。我们可以将资源定义存储在任何VCS系统、Git、SVN或任何其他系统中的文件中,这是非常庞大的:它允许我们拥有一个版本化的基础设施,团队可以进行交互,每个人都能跟上进度,并且可以管理分支和定义不同的版本,分离基础设施和环境的版本,如生产、登台、UAT等。现在人们认为这是必须的:这不是一厢情愿的想法,而是最好的做法。一旦Terraform的初始步骤完成,就可以用CloudInit之类的东西来完成配置,尽管任何引导都可以。这里一个流行的选择似乎是可行的:我已经用过了,如前所述,它是一把瑞士军刀,用于小而简单的初始任务。如果我们开始在云上工作,cloudInit将符合要求。之后,其他配置管理工具可以接管。
 
  也就是说,我很擅长不可变的基础设施,所以我将配置管理限制在最低限度。我的想法是,在未来,配置管理工具将不再需要。如果某个东西失败了,它应该被销毁并重新实例化。系统管理员必须不知道资源的名称,并且只能作为最后手段(如果有的话)使用SSH访问它们。
 
  容器编排
 
  容器不再是一个新事物;它们已经存在了几年(或者几十年,取决于我们如何看待它),它们足够稳定和有用,我们可以选择它们作为我们的平台。
 
  尽管数据中心中的容器很有趣,但云中的容器是令人惊叹的,尤其是因为现在大多数云为我们提供了容器编排,并且在我们无法得到足够的情况下,存在着大量的解决方案。一些例子包括ECS、Amazon容器服务、ACS、Azure容器服务、CoreOSFleet、DockerSwarm、GCE、Google容器引擎、Kubernetes等。
 
  虽然我最后一次离开了库伯内特斯,但它已经成为了焦点。此工具有未来的原因有三:
 
  它是由Google设计的,由于它所处的巨大环境以及能够茁壮成长的环境,它本身就有其优点
 
  它是从云计算本地计算基金会(CNCF)中挑选出来的,这意味着它有更大的生存机会。CNCF对于云本地应用程序非常重要,它得到许多公司(如Oracle)的支持
 
  该体系结构简单易学,可快速部署,易于扩展
 
  Kubernetes是一个非常有前途的工具,已经在交付结果。如果你考虑的是规模化的容器编排,那么开始钻研Minikube之类的东西,慢慢发展到Rancher之类的易用工具,将大大有助于铺平前进的道路。结论
 
  正如所示,有许多解决方案,这取决于所管理的基础设施的类型;也取决于基础设施的位置、规模和当前的分布方式。
 
  技术也可以联合使用。在OracleCloud拥有OKE(OracleKubernetesEngine)之前,我们在云中实现Kubernetes的方法是通过一个Terraform插件实例化必要的基础设施,然后在上面部署Kubernetes集群,以便我们继续在上面配置、管理和安装ElasticSearch等应用程序。
 
  这个行业正朝着云的方向发展,这个新的范例意味着所有的东西都要以XaaS(一切都是服务)的形式交付。这反过来意味着,以较低的成本构建可靠、性能好、可扩展的分布式体系结构将是一个巨大的竞争优势,而对一些公司来说,这已经是一个巨大的竞争优势。
 
  尽管如此,仍有许多技术可供选择。通常,与行业标准保持一致是一个明智的决定。这意味着它已经被证明,被公司使用,在当前的发展中,并将在未来几年内保持。
相关推荐
新闻聚焦
猜你喜欢
热门推荐
返回列表
 
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。