应用程序容器化之前需要考虑的 5 件事

在你奔赴 Docker 化应用程序的道路上，你应该首先放慢脚步，看看这么做是否值得，看看应用程序将如何与容器进行交互。

容器化应用程序，这意味着将它运行在 Docker 容器或其他容器系统内，容器化应用程序提供了许多优势。但在投身容器化前，你应该了解应用程序自身的特性如何影响它在容器中运行的方式。

我将在下面的内容中讨论这些，重点放在应用程序设计、持续集成层和环境配置。这可能听起来像是以前已经讲过的内容，但我保证会有一些变化。

你应该容器化应用吗？

在讨论如何容器化应用之前，我们应该首先考虑是否应该进行容器化。容器化确实提供了很多优势，但在开始之前，应该首先考虑一下你的应用程序是否是无状态的。

如果是的话，这是极好的！容器化肯定很适合你。

如果不是的话，这并不一定意味着你不能容器化，但对有状态的应用程序进行容器化会更加复杂。容器化降低了弹性伸缩的复杂性，但如果你的应用程序有状态的话，这种能力可能会被削减。

深度讨论这个话题（还有 Codefresh( https://codefresh.io/) 如何帮助简化有状态应用的容器化）需要一篇单独的文章来进行。但是我想在进入容器化细节介绍之前简短的说明一下。

现在让我们看看文章的主要内容：应用程序的设计如何影响容器化的能力。

对于新手来说，你需要了解你的应用程序将驻留在某个容器化平台，以及这对你意味着什么。

容器化应用可被设计成与平台无关。有了良好的设计，你不需要担心你的应用程序在哪儿运行以及它的底层系统是什么。这可能有些过度简化，但让我们应该保持简单，不要做无谓的复杂工作。

要容器化的应用不应该包含任何环境配置。如果有的话，这将导致它在不同环境间的部署复杂化，这可能意味着代码中大量的 if else 或 switch case 判断。

有三个备选方案：

1.环境自身进行定义

2.程序中使用环境变量，并在部署时进行设置

3.或两者的组合

原则就是一次构建任意运行。

那么，这项原则给了我们什么呢？我们的应用程序和运行环境的分离，使我们能够构建 /配置并部署每个独立应用。

现在让我们开始思考容器。容器应该运行单一的进程。例如，你不会想在同一个容器中包含你的应用层和 Web 层，因为这意味着你必须同时配置和运行它们两个，这样太混乱了。

以 Apache 和 PHP-FPM 为例说明，这是两个密切联系但不同的进程。 Apache 响应 HTTP 请求及静态文件，也可以将请求转发给容器内的 PHP-FPM 进程。

这种分离值得我们注意，因为在这一点上有另一个问题要考虑。你的开发环境是什么样的？你怎么同时部署到你的各环境： UAT 环境、 stage 环境、预生产环境以及生产环境中？

答案就是你需要根据应用的实际需求来修改代码或配置。因为有太多的持续集成解决方案和编程语言，所以这里没有正确和错误的答案，并且也不止一个答案。

那么，我们需要在持续集成层中做些什么呢？在之前讨论应用设计时，我们简要地讨论了应用中不应该包含配置信息，我们都知道在程序中硬编码配置是很糟糕的方式，那么我们如何能在程序中使用配置呢？

一个简单的解决办法是当程序部署到任意环境时，把配置信息做为参数传入应用程序（注：要在环境部署而不是构建时进行配置信息的设置。应用程序应该做到一次构建任意运行，而不是为每个环境单独进行构建）

接下来我们讲环境配置这一点，理想的程序应该做到一次构建任意运行。

对于应用程序读取环境配置而言，一个优雅的解决方案是把环境相关的配置信息做为可使用的变量暴露给应用程序。

这种方法比硬编码、在程序中使用分支判断和部署时的参数注入要好的多，能够使应用程序轻松迁移到任意的容器化平台。

我们在这里仅仅讨论了与容器化相关的基本内容，除此之外还有很多其他值得思考的内容。

但我在上面列出的内容代表了要进行容器化的主要挑战。

建议你深入阅读 http://12factor.net/，此网站详细列出了做为服务的应用的设计原则。在我以前进行程序设计时从这个网站受益匪浅，并且我确信仍然会有好多人能够从中受益。

最后但同样重要的，如果你在考虑容器化，推荐阅读 https://codefresh.io/ 上的相关文档。这些文件将有助于你熟悉使用自动化工具（如 Codefresh ）进行容器化应用程序的进程。

这些文档解释了哪部分容器化的工作是简单的，还有在进行容器化之前你需要做的准备。它们也许会说服你，容器化未必一定是复杂的，尤其是当你使用像 Codefresh 这样的工具为你做繁杂的工作时。

本文由时速云翻译，如若转载，需注明转载自“时速云”