从Docker Compose迁移到Kubernetes

通过从应用程序中学习企业APM产品，发现更快，更高效的性能监控。 参加AppDynamics APM导览！

AppDynamics演示平台的增长导致基础架构变得更大，并且如果没有真正的编排工具，则很难管理。 我们将研究将Docker Compose之一转换为Kubernetes应用程序所涉及的步骤以及从中获得的收益。

AppDynamics演示平台永不休眠。 它是一个基于云的系统，其中托管了许多应用程序，旨在帮助我们的全球销售团队展示AppDynamics的许多价值主张。

去年秋天，我们在演示平台中添加了几个新的更大的应用程序。 通过这些添加，我们的团队开始看到在单个主机上使用我们的标准Docker Compose应用程序部署模型遇到的一些性能挑战。 具体来说，我们想支持多台主机，而不是局限于像Docker Compose这样的单台主机。 在此之前的几个月中，我们一直在谈论迁移到Kubernetes ，因此我们知道是时候该迈出了一步 。
在此之前，我在Docker化应用程序甚至某些Kubernetes管理的应用程序方面都有丰富的经验。 但是，我从未参与过将应用程序从Docker Compose迁移到Kubernetes的实际工作。 对于我们第一次迁移到Kubernetes的尝试，我们选择了一个相对较小的应用程序，但其中包含各种不同的元素-Java，NodeJS，GoLang，MySQL和MongoDB。 该应用程序使用Docker Compose进行容器部署和“ 编排” 。 我松散地使用编排一词，因为与Kubernetes相比，Docker Compose非常轻巧。

Docker撰写

对于从未使用过Docker Compose的用户，它是一个框架，允许开发人员在单个YAML文件中定义基于容器的应用程序。 此定义包括使用的Docker映像，暴露的端口，依赖项，网络等。查看下面的代码片段，每5到20行的块代表一个单独的服务。 Docker Compose是一个非常有用的工具，它使应用程序部署相当简单。

图1.1 – docker-compose.yaml代码段

为迁移做准备

转换项目的第一个障碍是学习Kubernetes与Docker Compose有何不同。 差异最大的方式之一是容器到容器的通信。

在Docker Compose环境中，所有容器均在一台主机上运行。 Docker Compose创建了一个本地网络，这些容器都是容器的一部分。 以以下代码段为例：

该块将创建一个名为quoteServices的容器，其主机名为quote-services，端口为8080。 本地网络之外的任何内容都必须知道容器的IP地址。
相比之下，Kubernetes通常在称为节点的多个服务器上运行，因此它不能简单地为所有容器创建一个本地网络。 在开始之前，我非常担心这可能导致许多代码更改，但是事实证明这些担心是没有根据的。

创建Kubernetes YAML文件

理解从Docker Compose到Kubernetes的转换的最好方法是查看该转换的真实示例。 让我们采用上述quoteServices的片段并将其转换为Kubernetes可以理解的形式。
首先要了解的是，上述Docker Compose块将转换为两个单独的部分，即Deployment和Service。
顾名思义，该部署告诉Kubernetes关于如何部署容器的大多数知识。 此信息包括诸如为容器命名，从何处提取图像，要创建多少个容器等信息。这里显示了quoteServices的部署：

正如我们前面提到的，联网在Kubernetes中完成的方式与在Docker Compose中进行的方式不同。 该服务使容器之间的通信成为可能。 这是quoteServices的服务定义：

该服务定义告诉Kubernetes接受在选择器下定义的具有名称= quoteServices的容器，并使用quote-services作为主机名和端口8080使它们可访问。因此，再次可以在http：// quote上访问此服务。 Kubernetes应用程序中的-services：8080。 以这种方式定义服务的灵活性使我们能够在应用程序中保持URL完整，因此，由于网络方面的考虑而无需进行任何更改。
到最后，我们获取了一个包含约24个块的Docker Compose文件，并将其转换为约20个不同的文件，其中大多数包含部署和服务。 这种转换是迁移工作的很大一部分。 最初，为了节省时间，我们使用了一个称为Kompose的工具来自动生成部署和服务文件。 但是，一旦知道我们在做什么，我们最终还是重写了所有文件。 使用Kompose有点像使用Word创建网页。 当然，它可以工作，但是一旦您知道自己在做什么，您可能会想要重新执行大部分操作，因为它添加了许多您真正不需要的额外标签。

仪表AppDynamics

这是容易的部分。 我们的大多数应用程序都是docker化的，并且我们始终使用AppDynamics监视这些应用程序和基础Docker基础架构 。 因为我们的Docker映像已经包含了应用程序代理 ，所以我们无需更改任何内容。 如果我们想要的话，我们可以按原样离开他们，他们会做的很好。 但是，我们决定利用Kubernetes世界中相当普遍的东西：sidecar注入。
我们使用了sidecar模型将AppDynamics代理“注入”到了容器中。 这样做的好处是我们现在可以更新代理，而不必重建我们的应用程序映像并重新部署它们。 它也更适合最佳实践。 要更新代理，我们要做的就是更新我们的sidecar映像，然后更改应用程序容器使用的标签。 就像这样，我们的应用程序正在使用新代理运行！

服务器可见性代理

集成服务器可见性 （SVM）代理也非常简单。 需要注意的一个区别是，Docker Compose在单个主机上运行，​​而Kubernetes通常使用多个节点，可以动态添加或删除这些节点。
在我们的Docker Compose模型中，我们的SVM代理被部署到一个容器中，该容器同时监视主机和各个容器。 使用Kubernetes，我们将不得不在集群中的每个节点上运行一个这样的容器。 最好的方法是使用称为DaemonSet的结构。 您可以从下面的代码片段中看到DaemonSet看起来很像Deployment。 实际上，两者实际上是相同的。 主要区别在于它们的行为方式。 部署通常不会说明在群集中的哪个位置运行定义在其中的容器，但是会说明要创建多少个容器。 另一方面，DaemonSet将在集群中的每个节点上运行一个容器。 这很重要，因为群集中的节点数可以随时增加或减少。

图：DaemonSet定义

什么有效

从开发和运营的角度来看，迁移到Kubernetes会涉及一些额外的开销，但是有一定的优势。 我不会在这里列出所有优点，但是我将向您介绍我的两个最爱。
首先，我喜欢Kubernetes仪表板。 它显示有关正在运行的容器，部署，服务等的信息。它还允许您从UI更新/添加/删除任何定义。 因此，当我进行更改并构建新映像时，我要做的就是更新部署定义中的image标签。 然后，Kubernetes将删除旧容器，并使用更新的标签创建新容器。 它还可以轻松访问日志文件或任何容器的外壳。

图：Kubernetes仪表板

对我们而言，另一件行之有效的事情是，我们不再需要保留和维护运行Docker Compose应用程序的主机。 容器化应用程序背后的部分想法是将服务器更像是牛而不是宠物。 尽管在一定程度上是对的，但Docker Compose主机已成为新宠。 我们已经看到主机开始出现问题，需要维护，磁盘空间用尽等问题。有了Kubernetes，不再有主机，集群中的节点可以随时启动和关闭。

结论

在开始Kubernetes之旅之前，我对应用程序内网络，部署过程以及为我们所有流程添加额外的层有些担心。 的确，我们添加了许多额外的配置，从300行的docker-compose.yaml文件扩展到20个文件中的约1,000行。 不过，这主要是一次性费用。 我们还必须重写一些代码，但是无论如何都需要重写它们。

作为回报，我们获得了真正的编排工具的所有优点：可伸缩性，容器可见性增加，服务器管理更轻松等。 当需要迁移我们的下一个应用程序时（该迁移不会太遥远），该过程将变得更加轻松快捷。

通过从应用程序中学习企业APM产品，发现更快，更高效的性能监控。 参加AppDynamics APM导览！

翻译自: https://www.javacodegeeks.com/2018/06/migrating-docker-compose-to-kubernetes.html