神话还是现实？Docker 和 Kubernetes 架构

在 Docker 和 Kubernetes 时代，软件开发的世界发生了怎样的变化?有可能使用这些技术一劳永逸地构建一个放之四海而皆准的架构吗?当所有东西都“打包”在容器中时，有可能统一开发和集成的过程吗?这些决策有什么要求?它们会带来什么限制?它们会让开发人员的生活变得更轻松，还是会增加不必要的复杂性?

是时候讨论和阐明这些(以及其它一些)问题了!(在本文和原创插图中)

本文将带你踏上从现实到开发过程到架构再回到现实的旅程，在沿途的每一站回答最重要的问题。我们将尝试确定一些应该成为体系架构一部分的组件和原则，并在不过多深入实现细节的情况下展示一些示例。

这篇文章的结论可能会让你不高兴或高兴。这完全取决于你的个人经验，你对这个分为三章的故事的看法，甚至可能取决于你阅读时的心情。请在文末发表评论或提出问题，让我知道你的想法!

一、从现实到开发流程

在很大程度上，我所见过或有幸参与建立的所有开发过程都服务于一个简单的目标 —— 降低将一个想法变成现实、并交付生产的时间，同时保持一定程度的代码质量。

这个想法是好是坏并不重要。坏主意来来去去，你可能只是尝试一下，然后拒绝它们，让它们自生自灭。值得一提的是，从一个坏主意中 回退(rolling back)的责任落在将你的开发流程自动化的机器人肩上。

持续集成和交付(CI/CD)似乎是软件开发世界中的一根救命稻草。毕竟，还有什么比这更简单的呢?你有想法，你有代码，所以去做吧!如果不是存在一个小问题的话，这将会是完美无缺的 —— 如果与贵公司特有的技术和业务流程相分离，集成和交付流程将很难正规化。

然而，尽管这个任务看起来很复杂，生活还是在不断引入优秀的想法，让我们(当然是我自己)更接近于建立一个几乎在任何场合都有用的完美机制。对我来说，实现这种机制的最近一步是 Docker 和 Kubernetes，它们的抽象层次和意识形态方法让我认为现有问题中的 80% 都可以通过几乎相同的方法来解决。

剩下的 20% 我们也无法忽视。但是这正是你可以把你内在的创造性天才集中于其上的有趣的工作，而不是用于处理重复性的日常任务。专注于 “架构框架”(architectural framework)可以让你忘记那 80% 已经解决掉的问题。

所有这些意味着什么，Docker 是如何解决开发流程中的问题的?让我们来看一个简单的流程，这对于大多数工作环境来说也是足够的：

通过适当的方法，你可以自动化和统一以下序列中的所有内容，并在未来几个月内忘掉它。

建立开发环境

一个项目应该包含一个 docker-compose.yml 文件，这样你就不用考虑在本地机器上运行应用程序/服务需要做什么和怎么做了。一个简单的 docker-compose up 命令就能启动你的应用程序及其所有依赖项、用预制数据填充数据库、上传本地代码到容器内、启用代码跟踪以便动态编译，并最终在预期的端口开始接收和响应请求。即使是在设置新服务时，你也不必担心如何启动、向哪里提交代码更改或使用哪些框架。所有这些都应该在标准说明中预先描述，并由不同配置的服务模板决定: frontend、backend 和 worker。

自动化测试

关于“黑盒”你只需要知道，所有该有的东西都已经打包到里面了。是或否，1 或 0。更多关于我为什么将容器称为黑盒的信息，将在本文的后面介绍。有了数量有限的可以在容器内执行的命令，以及描述其所有依赖关系的 docker-compose.yml，你就可以轻松地自动化和统一测试工作，而无需过多关注实现细节。

例如， 像这样 !

在这里，测试不仅意味着单元测试，还意味着功能测试、集成测试、检查代码风格和重复代码、检查过时的依赖关系、可能使用违反许可证的软件包以及许多其他事情。关键是所有这些都应该封装在你的 Docker 镜像中。

系统交付

你想在何时何地安装项目并不重要。结果，就像安装过程一样，应该总是相同的。至于你将安装整个生态系统中的哪个部分，或者从哪个 git 代码库中获取代码，也没有任何区别。这里最重要的组成部分是 幂等性(idempotence)。唯一应该指定的是控制安装的变量。

以下是在我看来解决这个问题非常有效的算法：

从你所有的 Dockerfile 中收集镜像(例如，像 这样 )

使用一个元项目，通过 Kube API 接口将这些镜像传递给 Kubernetes。启动交付过程通常需要如下几个输入参数：

• Kube API 的 访问入口(endpoint)
• 一个 Secret 对象，因不同的上下文而异(local/showroom/staging/production)
• 要显示的系统的名称和这些系统的 Docker 镜像的标签(在前面的步骤中获得)

作为一个包含所有系统和服务的元项目的例子(换句话说，一个描述生态系统是如何安排的以及更新是如何传递给它的项目)，我更喜欢使用 Ansible 剧本与 这个模块 同 Kube API 进行集成。然而，复杂的 自动机(automators)可以引用其他选项，我将在后面详述我自己的选择。但是，你必须考虑一种集中/统一的架构管理方法。拥有一个这样的方法可以让你方便和统一地管理所有服务/系统，中和即将到来的执行类似功能的技术和系统丛林可能带给你的任何复杂性。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!