Java 开发人员的 DevOps 工具

第 3 章 容器简介 容器简介

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

Melissa McKay

傻瓜都知道。重点在于理解。

阿尔伯特-爱因斯坦

如果你知道 "为什么"，你就能 "如何活"。

尼采

在撰写本文时，容器 在生产和其他环境中的使用正呈指数级增长，围绕容器化应用程序的最佳实践仍在讨论和定义中。随着我们对效率改进的关注和对特定用例的考虑，博客圈和专业从业人员根据经验强烈推荐的技术和模式也在不断发展。不出所料，也有相当一部分模式和常用方法已经发展起来，同时也出现了一些反模式，我希望本章能帮助大家认识和避免这些反模式。

我自己对容器的尝试和错误介绍感觉就像捅了马蜂窝（哦，刺痛！）。不可否认，我毫无准备。集装箱化表面上看似简单。我现在知道了如何使用容器进行开发和部署，尤其是在 Java 生态系统中，我希望能将这些知识传授给大家，帮助大家避免类似的痛苦。本章概述了成功将应用程序容器化所需的基本概念，并讨论了为什么要这样做。

第 4 章将讨论微服务的全貌， ，但在这里，我们将首先了解微服务部署的基本构件之一：容器，如果你还没有接触过容器的话，毫无疑问你会遇到它。请注意，微服务这一架构概念并不意味着要使用容器；相反，人们关注的是部署这些服务，尤其是在云原生环境中部署这些服务，这通常是围绕容器化展开的话题。

让我们从考虑为什么要使用容器开始。做到这一点的最好办法就是回溯历史，了解一下我们是如何走到今天这一步的。耐心是一种美德。如果坚持下去，通过这堂历史课，你也会自然而然地对容器究竟是什么有一个更清晰的认识。

理解问题

我确信，我并不是唯一一个经历过公司 "房间里有一头大象 "的人。尽管大象的身影若隐若现，声音震耳欲聋，而且一旦被忽视就有可能带来危险的后果，但人们却任由它肆意横行，无人过问。我亲眼目睹了这一切。我对此深感内疚。我甚至有幸成为这头大象。

就容器化而言，我要提出的论点是，我们需要解决房间里的两头大象--两个问题：什么是容器？ 我们为什么要使用容器？这两个问题听起来很简单。怎么会有人错过这些基本出发点呢？

也许是因为微服务运动现在比以往任何时候都更倾向于引出关于部署容器的讨论，而我们又害怕错过。也许是因为容器的实现是人们对 Kubernetes 的默认期待，"我们的 K8s 集群 "是我们谈话中最酷的新词。甚至可能只是因为我们正在遭受 DevOps 生态系统中新技术和新工具的冲击，以至于作为一个开发人员（Java 开发人员也不例外），如果我们停下来问问题，就会担心被抛在后面。不管原因是什么，在我们深入了解如何构建和使用容器的细节之前，必须先解决这些 "是什么 "和"为什么"的问题。

我非常感谢多年来有幸与我共事的同事和导师们。我经常回想起我职业生涯起步阶段的一些箴言，这些箴言已成为我的口头禅。这个建议很简单：在任何项目的开始和接下来的工作中，都要不断重复一个问题：你要解决的问题是什么？衡量你的解决方案成功与否的标准是，它是否满足了这一要求，是否确实解决了最初的问题。

仔细考虑你解决的问题是否正确。尤其要警惕拒绝那些实际上是变相的实现指令的问题陈述，比如这个：通过将应用程序拆分成容器化的微服务来提高其性能。这样的问题陈述会更好：为了缩短客户完成目标所需的时间，将应用程序的性能提高 5%。请注意，后一种陈述包含了衡量成功与否的具体指标，并不局限于微服务实施。

这一原则同样适用于您日常选择使用的工具、选择使用的框架和语言、选择设计系统的方式，甚至是选择打包和部署软件到生产中的方式。您所做的选择是为了解决什么问题？你又如何知道自己是否选择了最佳工具？一种方法是了解所审查的特定工具要解决的问题。而做到这一点的最好方法就是了解它的历史。对于你要使用的每一种工具，都应该采取这种做法。我保证，了解了它的历史，你会做出更好的决定，而且你会从避开已知陷阱中获益，或者，至少有理由接受任何缺点并继续前进。 ...