mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
76 lines
7.6 KiB
Markdown
76 lines
7.6 KiB
Markdown
编排工具充分发挥了 Linux 容器技术优势
|
||
============================================================
|
||
|
||
> 一旦公司越过了“让我们看看这些容器如何工作”的阶段，他们最终会在许多不同的地方运行容器
|
||
|
||
|
||
|
||
需要快速、高效地交付程序的公司 —— 而今天，哪些公司不需要这样做？—— 是那些正在转向 Linux 容器的公司。他们还发现，一旦公司越过了“让我们看看这些容器如何工作”的阶段，他们最终会在许多不同的地方运行容器。
|
||
|
||
Linux 容器技术不是新技术，但它随着最初由 Docker 发明的创新性打包格式（现在的 [OCI][3] 格式）以及新应用对持续开发和部署的需求开始变得流行。在 Red Hat 的 2016 年 5 月的 Forrester 研究中，有 48％ 的受访者表示已经在开发中使用容器，今年的数字预计将达到 53％。只有五分之一的受访者表示，他们在 2017 年不会在开发过程中利用容器。
|
||
|
||
像乐高积木一样，容器镜像可以轻松地重用代码和服务。每个容器镜像就像一个单独的、旨在做好一部分工作的乐高积木。它可能是数据库、数据存储、甚至预订服务或分析服务。通过单独包装每个组件，从而可以在不同的应用中使用。但是，如果没有某种程序定义（即<ruby>指令手册<rt>instruction booklet</rt></ruby>），则难以在不同环境中创建完整应用程序的副本。那就是容器编排的来由。
|
||
|
||
|
||
|
||
容器编排提供了像乐高系统这样的基础设施 —— 开发人员可以提供如何构建应用程序的简单说明。编排引擎将知道如何运行它。这使得可以轻松创建同一应用程序的多个副本，跨越开发人员电脑、CI/CD 系统，甚至生产数据中心和云提供商环境。
|
||
|
||
Linux 容器镜像允许公司在整个运行时环境（操作系统部件）中打包和隔离应用程序的构建块。在此基础上，通过容器编排，可以很容易地定义并运行所有的块，并一起构成完整的应用程序。一旦定义了完整的应用程序，它们就可以在不同的环境（开发、测试、生产等）之间移动，而不会破坏它们，且不改变它们的行为。
|
||
|
||
### 仔细调查容器
|
||
|
||
很明显，容器是有意义的，越来越多的公司像“对轮胎踹两脚”一样去研究容器。一开始，可能是一个开发人员使用一个容器工作，或是一组开发人员在使用多个容器。在后一种情况下，开发人员可能会随手编写一些代码来处理在容器部署超出单个实例之后快速出现的复杂性。
|
||
|
||
这一切都很好，毕竟他们是开发人员 —— 他们已经做到了。但即使在开发人员世界也会变得混乱，而且随手代码模式也没法跟着容器进入 QA 和生产环境下。
|
||
|
||
编排工具基本上做了两件事。首先，它们帮助开发人员定义他们的应用程序的表现 —— 一组用来构建应用程序实例的服务 —— 数据库、数据存储、Web 服务等。编排器帮助标准化应用程序的所有部分，在一起运行并彼此通信，我将这称之为标准化程序定义。其次，它们管理一个计算资源集群中启动、停止、升级和运行多个容器的过程，这在运行任何给定应用程序的多个副本时特别有用，例如持续集成 （CI） 和连续交付 （CD）。
|
||
|
||
想像一个公寓楼。居住在那里的每个人都有相同的街道地址，但每个人都有一个数字或字母或两者的组合，专门用来识别他或她。这是必要的，就像将正确的邮件和包裹交付给合适的租户一样。
|
||
|
||
同样，在容器中，只要你有两个容器或两个要运行这些容器的主机，你必须跟踪开发人员测试数据库连接或用户连接到正在运行的服务的位置。容器编排工具实质上有助于管理跨多个主机的容器的后勤。它们将生命周期管理功能扩展到由多个容器组成的完整应用程序，部署在一组机器上，从而允许用户将整个集群视为单个部署目标。
|
||
|
||
这真的很简单，又很复杂。编排工具提供了许多功能，从配置容器到识别和重新调度故障容器，将容器暴露给集群外的系统和服务，根据需要添加和删除容器等等。
|
||
|
||
虽然容器技术已经存在了一段时间，但容器编排工具只出现了几年。编排工具是 Google 从内部的高性能计算（HPC）和应用程序管理中吸取的经验教训开发的。在本质上，其要解决的就是在一堆服务器上运行一堆东西（批处理作业、服务等）。从那时起，编排工具已经进化到可以使公司能够战略性地利用容器。
|
||
|
||
一旦你的公司确定需要容器编排，下一步就是确定哪个平台对于业务是最有意义的。在评估容器编排时，请仔细查看（尤其）：
|
||
|
||
* 应用程序定义语言
|
||
* 现有能力集
|
||
* 添加新功能的速度
|
||
* 开源还是专有
|
||
* 社区健康度（成员的积极性/高效，成员提交的质量/数量，贡献者的个人和公司的多样性）
|
||
* 强化努力
|
||
* 参考架构
|
||
* 认证
|
||
* 产品化过程
|
||
|
||
有三个主要的容器编排平台，它们似乎领先于其他，每个都有自己的历史。
|
||
|
||
1. **Docker Swarm：** Swarm 是容器典范 Docker 的附件。Swarm 允许用户建立并管理 Docker 节点的集群为单个虚拟系统。Swarm 似乎正在成为一个单一供应商的项目。
|
||
2. **Mesos：** Mesos 是从 Apache 和高性能计算中成长起来的，因此是一个优秀的调度员。Mesos 的技术也非常先进，虽然与其他相比似乎没有发展速度或投资优势。
|
||
3. **Kubernetes：** 由 Google 开发，由其内部编排工具 Borg 经验而来，Kubernetes 被广泛使用，并拥有强大的社区。其实这是 GitHub 上排名第一的项目。Mesos 目前可能比 Kubernetes 略有技术优势，但是 Kubernetes 是一个快速发展的项目，这也是为了长期技术上的收益而进行的架构投资。在不久的将来，在技术能力上应该能赶超 Mesos。
|
||
|
||
### 编排的未来
|
||
|
||
展望未来，企业们可以期待看到编排工具在应用程序和服务为中心的方向上发展。因为在现实中，如今快速应用程序开发实际上是在快速地利用服务、代码和数据的组合。无论这些服务是开源的，还是由内部团队部署的抑或从云提供商处购买的，未来将会是两者的混合。由于今天的编排器也在处理应用程序定义方面的挑战，所以期望看到它们越来越多地应对外部服务的整合。
|
||
|
||
此时此刻，想要充分利用容器的公司必须利用容器编排。
|
||
|
||
（题图：Thinkstock）
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://www.infoworld.com/article/3205304/containers/orchestration-tools-enable-companies-to-fully-exploit-linux-container-technology.html
|
||
|
||
作者：[Scott McCarty][a]
|
||
译者：[geekpi](https://github.com/geekpi)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://www.infoworld.com/author/Scott-McCarty/
|
||
[1]:https://www.infoworld.com/article/3204171/what-is-docker-linux-containers-explained.html#tk.ifw-infsb
|
||
[2]:https://www.infoworld.com/resources/16373/application-virtualization/the-beginners-guide-to-docker.html#tk.ifw-infsb
|
||
[3]:https://github.com/opencontainers/image-spec
|