mirror of
https://github.com/LCTT/TranslateProject.git
synced 2026-08-23 04:03:29 +08:00
geekpi
GitHub
@@ -1,88 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
Orchestration tools fully exploit Linux container technology
|
||||
============================================================
|
||||
|
||||
### Once companies get past the “let’s see how these container things work” stage, they end up with a lot of containers running in a lot of different places
|
||||
|
||||
|
||||
>Thinkstock
|
||||
|
||||
Companies that need to deliver applications quickly and efficiently—and today, what company doesn’t need to do this?— are turning to Linux containers. What they are also finding is that once they get past the “let’s see how these container things work” stage, they are going to end up with a lot of containers running in a lot of different places.
|
||||
|
||||
Linux container technology is not new, but it has increased in popularity due to factors including the innovative packaging format (now [Open Container Initiative (OCI) format][3]) originally invented by Docker, as well as the competitive requirement for continual development and deployment of new applications. In a May 2016 Forrester study commissioned by Red Hat, 48 percent of respondents said they were already using containers in development, a figure projected to rise to 53 percent this year. Only one-fifth of respondents said that they wouldn’t leverage containers in development processes in 2017.
|
||||
|
||||
Like Lego blocks, container images enable easy reuse of code and services. Each container image is like a separate Lego block, designed to do one part of the job really well. This could be a database, a data store, or even a booking service, or analytics service. By packaging each part separately, they can be used in different applications. But, without some sort of application definition (the instruction booklet), it’s difficult to create copies of the full application in different environments. That’s where container orchestration comes in.
|
||||
|
||||
|
||||
Scott McCarty
|
||||
|
||||
Container orchestration provides an infrastructure like the Lego system – the developer can provide simple instructions for how to build the application. The orchestration engine will know how to run it. This makes it easy to create multiple copies of the same application, spanning developer laptops, CI/CD system, and even production data centers and cloud provider environments.
|
||||
|
||||
Linux container images allow companies to package and isolate the building blocks of applications with their entire runtime environment (operating system pieces). Building on this, container orchestration makes it easy to define and run all of the blocks together as a full applications. Once the work has been invested to define the full application, they can be moved between different environments (dev, test, production, and so on) without breaking them, and without changing how they behave.
|
||||
|
||||
### Kicking the tires on containers
|
||||
|
||||
It’s clear that containers make sense, and more and more companies are figuratively kicking the tires on containers. In the beginning, it might be one developer working with a single container, or a team of developers working with multiple containers. In the latter scenario, the developers are likely writing home-grown code to deal with the complexities that quickly arise once a container deployment grows beyond a single instance.
|
||||
|
||||
This is all well and good: They’re developers, after all – they’ve got this. But it’s going to get messy, even in the developer world, and the home-grown code model is just not going to fly once containers move to QA and [dun, dun, duuuuunnnnn] production.
|
||||
|
||||
Orchestration tools do essentially two things. First, they help developers define what their application looks like – the set of services it takes to build up an instance of their application – the databases, data stores, web servers, etc., for each application instance. Orchestrators help standardize what all the parts of an application look like, running together and communicating to each other, what I would call a standardized application definition. Second, they manage the process of starting, stopping, upgrading and running these multiple containers in a cluster of compute resources, which is especially useful when running multiple copies of any given application, for things like continuous integration (CI) and continuous delivery (CD).
|
||||
|
||||
|
||||
Think about it like an apartment building. Everyone who lives there has the same street address, but each person has a number or letter or combination of both that specifically identifies him or her. This is necessary, for example, for the delivery of the right mail and packages to the right tenants.
|
||||
|
||||
Likewise with containers, as soon as you have two containers or two hosts that you want to run those containers on, you have to keep track of things like where developers go to test a database connect or where users go to connect to a service running in a container. Container orchestration tools essentially help manage the logistics of containers across multiple hosts. They extend life cycle management capabilities to full applications, made of multiple containers, deployed on a cluster of machines, allowing users to treat the entire cluster as a single deployment target.
|
||||
|
||||
It’s really that simple—and that complicated. Orchestration tools provide a number of capabilities, ranging from provisioning containers, to identifying and rescheduling failed containers, to exposing containers to systems and services outside the cluster, to adding and removing containers on demand.
|
||||
|
||||
While container technology has been around for a while, container orchestration tools have been available only for a few years. Orchestrators were developed from lessons learned with high-performance computing (HPC) and application management internally at Google. In essence, to deal with the monstrosity that is, running a bunch of stuff (batch jobs, services, etc.) on a bunch of servers. Since then, orchestrators have evolved to enable companies to strategically leverage containers.
|
||||
|
||||
Once your company determines that it needs container orchestration, the next step is figuring out which platform makes the most sense for the business. When evaluating container orchestrators, look closely at (among other things):
|
||||
|
||||
* Application definition language
|
||||
|
||||
* Existing capability set
|
||||
|
||||
* Rate at which new capabilities are being added
|
||||
|
||||
* Whether it is open source or proprietary
|
||||
|
||||
* Community health (how active/productive members are, the quality/quantity of member submissions, diversity of contributors – individuals and companies)
|
||||
|
||||
* Hardening efforts
|
||||
|
||||
* Reference architectures
|
||||
|
||||
* Certifications
|
||||
|
||||
* Process for productization
|
||||
|
||||
There are three major container orchestration platforms, which seem to be ahead of the others, each with its own history.
|
||||
|
||||
1. **Docker Swarm:** Swarm is an add-on to Docker – arguably, the container poster child. Swarm allows users to establish and manage a cluster of Docker nodes as a single virtual system. The challenge with Swarm is it seems on track to become a single-vendor project.
|
||||
|
||||
2. **Mesos**: Mesos grew up from Apache and high-performance computing, and thus serves as an excellent scheduler. Mesos is also very technically advanced, although it doesn’t seem to have the velocity or investment compared to others.
|
||||
|
||||
3. **Kubernetes:** Developed by Google, with lessons from an internal orchestrator named Borg, Kubernetes is widely used and has a robust community around it. In fact, it’s the No. 1 project on GitHub. Mesos may currently have a slight technical advantage over Kubernetes, but Kubernetes is a fast-moving project, which is also making architectural investments for long-term technical gains. It should catch up and surpass Mesos in terms of technical capabilities in the very near future.
|
||||
|
||||
### The future of orchestration
|
||||
|
||||
Looking ahead, companies can expect to see orchestration tools moving in an application- and service-focused direction. Because, in reality, rapid application development today is really about quickly leveraging a mix of services, code, and data. Whether those services are open source and deployed by your internal team or consumed from a cloud provider, the future looks like a mix of both. Since today’s orchestrators are also tackling the application definition challenge, expect to see them tackle the integration of external services more and more.
|
||||
|
||||
For the here and now, companies that want to take full advantage of containers must take advantage of container orchestration.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.infoworld.com/article/3205304/containers/orchestration-tools-enable-companies-to-fully-exploit-linux-container-technology.html
|
||||
|
||||
作者：[ Scott McCarty][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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
|
||||
@@ -0,0 +1,86 @@
|
||||
编排工具充分利用 Linux 容器技术
|
||||
============================================================
|
||||
|
||||
### 一旦公司过了“让我们看看这些容器如何工作”的阶段，他们最终会在许多不同的地方运行容器
|
||||
|
||||
|
||||
>Thinkstock
|
||||
|
||||
需要快速、高效地交付程序的公司 - 而今天，哪些公司不需要这样做？- 是那些正在转向 Linux 容器的公司。他们还发现，一旦公司过了“让我们看看这些容器如何工作”的阶段，他们最终会在许多不同的地方运行容器。
|
||||
|
||||
Linux 容器技术不是新技术，但它随着最初由 Docker 发明的创新性包装格式（现在的[OCI][3]f格式）以及新程序对持续开发和部署的需求开始变得流行。在 Red Hat 的 2016 年 5 月的 Forrester 研究中，有 48％ 的受访者表示已经在开发中使用容器，今年的数字预计将达到 53％。只有五分之一的受访者表示，他们在 2017 年不会在开发过程中利用容器。
|
||||
|
||||
像乐高积木一样，容器镜像可以轻松重用代码和服务。每个容器镜像就像一个单独的旨在做好一部分工作的乐高积木。它可能是数据库、数据存储、甚至预订服务或分析服务。通过单独包装每个组件，从而可以在不同的应用中使用。但是，如果没有某种程序定义（指令手册），则难以在不同环境中创建完整应用程序的副本。那就是容器编排的来由。
|
||||
|
||||
|
||||
Scott McCarty
|
||||
|
||||
容器编排提供了像乐高系统这样的基础设施 - 开发人员可以提供如何构建应用程序的简单说明。编排引擎将知道如何运行它。这使得可以轻松创建同一应用程序的多个副本、跨越开发人员电脑、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。
|
||||
|
||||
### 编排的未来
|
||||
|
||||
展望未来，企业可以期待看到编排工具在应用程序和服务为中心方向上发展。因为在现实中，如今快速应用程序开发实际上是在快速利用服务、代码和数据的组合。无论这些服务是开源，还是由内部团队部署，还是从云提供商处购买，未来将会是两者的混合。由于今天的编排器也在处理应用程序定义方面的挑战，所以期望看到它们越来越多地应对外部服务的整合。
|
||||
|
||||
此时此刻，想要充分利用容器的公司必须利用容器编排。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
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)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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
|
||||
Reference in New Issue
Block a user