document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2024-12-26 21:30:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #8956 from pinewall/submit-tech20180404

Browse Source 
submit tech/20180404 Containerization, Atomic Distributions, and the Future of Linux.md
This commit is contained in:
MjSeven 2018-05-29 23:23:41 +08:00 committed by GitHub
commit c7a020618c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 88 additions and 90 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

90
sources/tech/20180404 Containerization, Atomic Distributions, and the Future of Linux.md
View File

@ -1,90 +0,0 @@
pinewall translating
Containerization, Atomic Distributions, and the Future of Linux
======
![](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/atomic-distro.jpg?itok=SjBeCDtq)
Linux has come a long way since Linus Torvalds announced it in 1991. It has become the dominant operating system in the enterprise space. And, although we’ve seen improvements and tweaks in the desktop environment space, the model of a typical Linux distribution has largely remained the same over the past 25+ years. The traditional package management based model has dominated both the desktop and server space.
However, things took an interesting turn when Google launched Linux-based Chrome OS, which deployed an image-based model. Core OS (now owned by Red Hat) came out with an operating system (Container Linux) that was inspired by Google but targeted at enterprise customers.
Container Linux changed the way operating systems update. It changed the way applications were delivered and updated. Is this the future of Linux distributions? Will it replace the traditional package-based distribution model?
### Three models
Matthias Eckermann, Director of Product Management for SUSE Linux Enterprise, thinks there are not two but three models. “Outside of the traditional (RHEL/SLE) and the image-based model (RH Atomic Host), there is a third model: transactional. This is where [SUSE CaaS Platform][1] and its SUSE MicroOS lives,” said Eckermann.
### What’s the difference?
Those who live in Linux land are very well aware of the traditional model. It’s made up of single packages and shared libraries. This model has its own benefit as application developers don’t have to worry about bundling libraries with their apps. There is no duplication, which keeps the system lean and thin. It also saves bandwidth as users don’t have to download a lot of packages. Distributions have total control over packages so security issues can be fixed easily by pushing updates at the system level.
“Traditional packaging continues to provide the opportunity to carefully craft and tune an operating system to support mission-critical workloads that need to stand the test of time,” said Ron Pacheco, Director of Product Management at Red Hat Enterprise Linux.
But the traditional model has some disadvantages, too. App developers must restrict themselves to the libraries shipped with the distro, which means they can’t take advantage of new packages for their apps if the distro doesn’t support them. It could also lead to conflict between two different versions. As a result, it creates administration challenges as they are often difficult to keep updated and in sync.
### Image-based Model
That’s where the image based model comes to the rescue. “The image-based model solves the problems of the traditional model as it replaces the operating system at every reiteration and doesn't work with single packages,” said Eckermann.
“When we talk about the operating system as an image, what we’re really talking about is developing and deploying in a programmatic way and with better integrated life cycle management,” said Pacheco, giving the example of OpenShift, which is built on top of Red Hat Enterprise Linux.
Pacheco sees the image-based OS as a continuum, from hand-tooling a deployed image to a heavily automated infrastructure that can be managed at a large scale; regardless of where a customer is on this range, the same applications have to run. “You don't want to create a silo by using a wholly different deployment model,” he said.
The image-based model replaces the entire OS with new libraries and packages, which introduces its own set of problems. The image-based model has to be reconstructed to meet the needs of specific environments. For example, if the user has a specific need for installing a specific hardware driver or low-level monitoring option, the image model fails, or options to have finer granularity have to be re-invented.
### Transactional model
The third model is transactional updates, which follows the traditional package-based updates, but instead handles all packages as if they were images, updating all the packages that belong together in one shot like an image.
“The difference is because they are single packages that are grouped together as well as on descending and the installation, the customer has the option to influence this if necessary. This gives the user extra flexibility by combining the benefits of both and avoiding the disadvantages associated with the traditional or image model,” said Eckermann.
Pacheco said that it’s becoming increasingly common for carefully crafted workloads to be deployed as images in order to deploy consistently, reliably, and to do so with elasticity. “This is what we see our customers do today when they create and deploy virtual machines on premises or on public/private clouds as well as on traditional bare metal deployments,” he said.
Pacheco suggests that we should not look at these models as strictly a “compare and contrast scenario,” but rather as an evolution and expansion of the operating system’s role.
### Arrival of Atomic Updates
Google’s Chrome OS and the Core OS popularized the concept of transactional updates, a model followed by both Red Hat and SUSE.
“The real problem is the operating system underlining the container host operating system is not in focus anymore -- at least not in a way the administrator should care about. Both RH Atomic Host and SUSE CaaS Platform solve this problem similarly from a user experience perspective,” said Eckermann.
[Immutable infrastructure][2], such as that provided by SUSE CaaS Platform, Red Hat Atomic Host, and Container Linux (formerly Core OS), encourages the use of transactional updates. “Having a model where the host always moves to a ‘known good’ state enables better confidence with updates, which in turn enables a faster flow of features, security benefits, and an easier-to-adopt operational model,” said Ben Breard, senior technology product manager, Red Hat.
These newer OSes isolate the applications from the underlying host with Linux containers thereby removing many of the traditional limitations associated with infrastructure updates.
“The real power and benefits are realized when the orchestration layer is intelligently handling the updates, deployments, and, ultimately, seamless operations,” added Breard.
### The Future
What does the future hold for Linux? The answer really depends on who you ask. Container players will say the future belongs to containerized OS, but Linux vendors who still have a huge market may disagree.
When asked if, in the long run, atomic distros will replace traditional distributions, Eckermann said, “If I say yes, then I am following the trend; if I say no, I will be considered old-fashioned. Nevertheless, I say no: atomic distros will not replace traditional distros in the long run -- but traditional workloads and containerized workloads will live together in data centers as well as private and public cloud environments.”
Pacheco maintained that the growth in Linux deployments, in general, makes it difficult to imagine one model replacing the other. He said that instead of looking at them as competing models, we should look at atomic distributions as part of the evolution and deployment of the operating system.
Additionally, there are many use-cases that may need a mix of both species of Linux distributions. “Imagine the large number of PL/1 and Cobol systems in banks and insurance companies. Think about in-memory databases and core data bus systems,” said Eckermann.
Most of these applications can’t be containerized. As much as we would like to think, containerization is not a silver bullet that solves every problem. There will always be a mix of different technologies.
Eckermann believes that over time, a huge number of new developments and deployments will go into containerization, but there is still good reason to keep traditional deployment methods and applications in the enterprise.
“Customers need to undergo business, design, and cultural transformations in order to maximize the advantages that container-based deployments are delivering. The good news is that the industry understands this, as a similar transformation at scale occurred with the historical moves from mainframes to UNIX to x86 to virtualization,” said Pacheco.
### Conclusion
It’s apparent that the volume of containerized workloads will increase in the future, which translates into more demand for atomic distros. In the meantime, a substantial percentage of workloads may remain on traditional distros that will keep them running. What really matters is that both players have invested heavily in new models and are ready to tweak their strategy as the market evolves. An external observer can clearly see that the future belongs to transactional/atomic models. We have seen the evolution of datacenter; we have come a long way from one application per server to function-as-a-service model. It is not far fetched to see Linux distros entering the atomic phase.
--------------------------------------------------------------------------------
via: https://www.linux.com/blog/2018/4/containerization-atomic-distributions-and-future-linux
作者：[SWAPNIL BHARTIYA][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
选题：[lujun9972](https://github.com/lujun9972)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.linux.com/users/arnieswap
[1]:https://www.suse.com/products/caas-platform/
[2]:https://www.digitalocean.com/community/tutorials/what-is-immutable-infrastructure

88
translated/tech/20180404 Containerization, Atomic Distributions, and the Future of Linux.md Normal file
View File

@ -0,0 +1,88 @@
容器化，原子化发行版以及 Linux 的未来
======
![](https://www.linux.com/sites/lcom/files/styles/rendered_file/public/atomic-distro.jpg?itok=SjBeCDtq)
自从 Linus Torvalds 在 1991 年发布 Linux 以来，Linux 已历经漫长的岁月。它已经成为企业级领域的主流操作系统。同时，我们看到桌面级领域出现了很多改进和调整，但在过去的 25+ 年，主流 Linux 发行版的模式很大程度上保持不变。基于软件包管理的传统模式依然统治着桌面级和服务器级市场。
但随着 Google 发布了基于 Linux 的 Chrome-OS，情况出现了微妙的转变，Chrome-OS 采用镜像模式。Core OS (目前归属于 Red Hat) 受 Google 启发推出了一款操作系统 Container Linux，主要面向企业级用户。
Container Linux 改变了操作系统更新的方式，也改变了应用分发和更新的方式。这会是 Linux 发行版的未来吗？这是否会取代基于软件包的传统发行版模式呢？
### 三种模式
SLE (SUSE Linux Enterprise) 的产品管理总监 Matthias Eckermann 认为目前存在 3 种模式，而不是 2 种。Eckermann 提到：“除了传统模式 (RHEL/SLE) 和镜像模式 (RH Atomic Host)，还存在第三种模型：事务模式。[SUSE CaaS 平台][1] 及 SUSE MicroOS 就采用这种模型。”
### 差异有哪些
Linux 用户对传统模式非常熟悉，它由独立的软件包和共享库组成。这种模式有独特的优势，让应用开发者无需将共享库捆绑在应用中。由于库不会多次引入，使得系统简洁和轻便。这也让用户无需下载很多软件包，节省了带宽。发行版对软件包全权负责，通过推送系统级别的更新，可以轻松地解决安全隐患。
RHEL (Red Hat Enterprise Linux) 的产品管理总监 Ron Pacheco 表示，“传统的打包方式继续为我们提供精心构建和优化操作系统的机会，以便支持需要经过时间考验的任务关键型工作负载。”
但传统模式也有一些弊端。应用开发者受限使用发行版包含的库，使其无法从发行版不支持的新软件中获益。这也可能导致不同版本之间相互冲突。最终，传统模式给管理员增加了挑战，使其难以让软件包一直处于最新版本状态。
### 镜像模式
镜像模式应运而生。Eckermann 表示，“镜像模式解决了传统模式遇到的问题，它在每次迭代更新时替换整个操作系统，其中也不包含独立的软件包”。
Pacheco 表示，“当我们用镜像作为操作系统的代名词进行讨论时，我们真正关心的是可编程式的开发部署以及更好的集成式生命周期管理”，基于 RHEL 搭建的 OpenShift 被他用作示例。
Pacheco 认为基于镜像的操作系统是一种延续，从手工打造并部署镜像，到可大规模管理的高度自动化基础设施；无论客户使用哪种类型，都需要运行同样的应用。他说，“你肯定不希望使用一个完全不同的部署模式，这需要重做很多工作”。
镜像模式替代了使用新库和软件包的完整操作系统，但也面临一系列问题。在镜像模式中，需要重建镜像才能适应特殊环境的需求。例如，用户有特殊需求，需要安装特定硬件的驱动或安装底层监控功能，镜像模式无法满足，需要重新设计功能以实现细粒度操作。
### 事务模式
第三种模式采用事务更新，基于传统的软件包更新，但将全部的软件包视为一个镜像，就像镜像那样在一次操作中更新全部软件包。
Eckermann 表示，“由于安装或回滚时操作对象是打包在一起的独立软件包，用户在需要时能够做相应的调整，这就是差别所在。结合传统模式和镜像模式的优点，避免两种模式的缺点，事务模式给用户提供了额外的灵活性。”
Pacheco 表示，将精心构造的工作负载部署成镜像的做法越来越成为主流，因为这种部署方式具有一致性和可靠性，而且可以弹性部署。“这正是我们用户目前的做法，部署环境包括在预置设备或公有/私有云上创建并部署的虚拟机，或在传统的裸机上”
Pacheco 建议我们将这几种模式视为操作系统角色的进化和扩展，而不是仅仅“使用场景的比较和对比“。
### 原子化更新的问世
Google 的 Chrome OS 和 Core OS 为我们普及了事务更新的概念，该模型也被 Red Hat 和 SUSE 采用。
Eckermann 表示，”我们必须认识到，用于容器主机的操作系统已经不再是关注点 —— 至少不是管理员的关注点。RH Atomic 主机和 SUSE CaaS 平台都解决了该问题，实现方式在用户看来很相似。“
SUSE CaaS 平台、Red Hat Atomic Host和 Container Linux （前身是 Core OS）提供的[<ruby>不可变基础设施<rt>Immutable infrastructure</rt></ruby>][2] 推广了事务更新的使用。Red Hat 高级技术产品经理 Ben Breard 表示，”在事务模式中，主机总是会变更到已确认正确的新状态，这让我们更有信心执行更新，进而实现更快速的功能流、安全优势以及易于采用的操作模式“。
这些新型操作系统使用 Linux 容器将应用与底层系统隔离，解除了传统模式中基础设施更新的诸多限制。
Breard 补充道，“当编排层可以智能处理更新、部署，甚至最终实现无缝操作时，我们才会真正意识到该模式的威力和好处”。
### 展望未来
Linux 的未来会是什么样子？不同的人会给出不同的回答。容器支持者认为未来属于容器化的操作系统，但依然拥有庞大市场的 Linux 供应商显然不这么认为。
当被问到原子化发行版是否在很久以后将替换传统发行版时，Eckermann 表示，“如果我回答肯定的，那么表示我顺应潮流；如果回答是否的的，意味着我还是站在传统阵营。然而，我的回答是否定的，即 atomic 发行版在很久以后也不会替换传统发行版，传统负载和容器化负载将在数据中心、私有云以及公有云环境中共存。”
Pacheco 认为，从 Linux 的部署增长情况来看，一般情况下很难想象一种模式替换另一种模式。与其将多种模式视为相互竞争的关系，不如将原子化发行版视为操作系统进化和部署的一部分。
此外，在一些使用案例中，我们需要同时使用多种 Linux 发行版。Eckermann 表示，“想一想银行和保险公司中大量的 PL/1 和 Cobol 系统。再想一想内存数据库和核心数据总线系统”。
这些应用大多数无法进行容器化。就我们目前来看，容器化不是解决所有问题的万金油。总是会同时存在多种不同的技术。
Eckermann 相信，随着时间的推移，大量新的开发和部署将采用容器化，但仍然有不错的理由，促使我们在企业级环境中保留传统的部署方式和应用。
Pacheco 认为，“用户需要经历业务、设计和文化的转型，才能最大化基于容器的部署带来的优势。好消息是业界已经认识到并开始大规模转变，就像历史上大型机转变成 UNIX，UNIX 转变成 x86，x86 转变成虚拟化那样”。
### 结论
很明显，未来容器化负载的使用量会持续增长，也就意味着原子化发行版的需求量持续增长。与此同时，仍会有不少工作负载运行在传统发行版中。重要的是，这两类用户都在新模式上大规模投入，以便市场改变时可以做相应的策略改变。从外部观察者的视角来看，未来属于事务/原子化模式。我们已经见证了数据中心的发展，我们花了很长时间完成了从每个服务器一个应用到函数即服务模型的转变。Linux 发行版进入原子化时代的日子也不会太远了。
--------------------------------------------------------------------------------
via: https://www.linux.com/blog/2018/4/containerization-atomic-distributions-and-future-linux
作者：[SWAPNIL BHARTIYA][a]
译者：[pinewall](https://github.com/pinewall)
校对：[校对者ID](https://github.com/校对者ID)
选题：[lujun9972](https://github.com/lujun9972)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]:https://www.linux.com/users/arnieswap
[1]:https://www.suse.com/products/caas-platform/
[2]:https://www.digitalocean.com/community/tutorials/what-is-immutable-infrastructure