基于Docker和Kubernetes的完美技术架构概述.pdf

基于 Docker 和 Kubernetes 的完美技术架构概述 1 目录 前言 3 一、从现实到开发流程 4 二、从开发工作流到架构 14 三、从架构回归现实 35 2 前言 在 Docker 和 Kubernetes 时代，软件开发的世界发生了怎样的变化？有可能使用这些技 术一劳永逸地构建一个放之四海而皆准的架构吗？当所有东西都 “打包 ”在容器中时，有可能 统一开发和集成的过程吗？这些决策有什么要求？它们会带来什么限制？它们会让开发人员 的生活变得更轻松，还是会增加不必要的复杂性？ 是时候讨论和阐明这些 (以及其它一些)问题了！(在本文和原创插图中) 3 本文将带您踏上从现实到开发过程到架构再回到现实的旅程，在沿途的每一站回答最重要 的问题。我们将尝试确定一些应该成为体系架构一部分的组件和原则 ，并在不过多深入实现细 节的情况下展示一些示例。 这篇文章的结论可能会让你不高兴或高兴。这完全取决于你的个人经验，你对这个分为三 章的故事的看法，甚至可能取决于你阅读时的心情。请在文末发表评论或提出问题，让我知道 你的想法！ 一、从现实到开发流程 在很大程度上，我所见过或有幸参与建立的所有开发过程都服务于一个简单的目标 4 — 降低将一个想法变成现实、并交付生产的时间，同时保持一定程度的代码质量。 这个想法是好是坏并不重要。坏主意来来去去，你可能只是尝试一下，然后拒绝它们，让 它们自生自灭。值得一提的是，从一个坏主意中回退（ rolling back）的责任落在将你的开发 流程自动化的机器人肩上。 持续集成和交付（ CI/CD）似乎是软件开发世界中的一根救命稻草。毕竟，还有什么比这 更简单的呢？你有想法，你有代码，所以去做吧！如果不是存在一个小问题的话，这将会是完 美无缺的 — 如果与贵公司特有的技术和业务流程相分离，集成和交付流程将很难正规化。 然而，尽管这个任务看起来很复杂，生活还是在不断引入优秀的想法，让我们 (当然是我自 己)更接近于建立一个几乎在任何场合都有用的完美机制。对我来说，实现这种机制的最近一步 是 Docker 和 Kubernetes ，它们的抽象层次和意识形态方法让我认为现有问题中的 80%都可 以通过几乎相同的方法来解决。 剩下的 20%我们也无法忽视。但是这正是你可以把你内在的创造性天才集中于其上的有趣 的工作，而不是用于处理重复性的日常任务。专注于 “架构框架 ” （architectural framework ） 可以让你忘记那 80%已经解决掉的问题。 5 所有这些意味着什么， Docker 是如何解决开发流程中的问题的？让我们来看一个简单的 流程，这对于大多数工作环境来说也是足够的： 通过适当的方法，你可以自动化和统一以下序列中的所有内容，并在未来几个月内忘掉它。 建立开发环境 6 一个项目应该包含一个 docker-compose.yml 文件，这样你就不用考虑在本地机器上运 行应用程序/服务需要做