通常，当人们想要使用你的应用程序时，你认为这是一件好事。但是，当应用程序在服务器上运行时，受欢迎程度是有代价的。随着用户数量的增加，对资源的需求也会增加，在某些时候，你可能会发现你需要扩展你的应用程序。一种选择是在问题上投入更多服务器，建立一个像 Nginx 这样的负载均衡器，让需求自行解决。但是，这种选择可能很昂贵，因为当需求低时，没有节省成本，而你却在没有流量的服务器上运行应用程序实例。容器的优势在于其短暂性，当新的实例可用时启动，并随着需求的减少而消失。如果这听起来像是你需要的功能，那么现在可能是时候将你的应用程序迁移到容器了。
将应用程序迁移到容器可能会很快让人感到迷失方向。虽然容器内的环境可能感觉很熟悉，但许多容器镜像都是最小化的，并且设计为无状态的。但在某种程度上，这是容器的优势之一。就像 Python 虚拟环境一样，它是一个空白的石板，让你可以在没有许多其他环境提供的隐形默认设置的情况下构建（或重建）你的应用程序。
每次迁移都是独一无二的，但是这里有一些重要的原则，你应该在将你的应用程序移植到容器之前解决。
1. 了解你的依赖项
将你的应用程序移植到容器是一个极好的机会，让你了解你的应用程序实际上依赖于什么。由于几乎没有安装除了最基本的系统组件之外的任何默认安装，你的应用程序最初不太可能在容器内运行。
在重构之前，确定你的依赖项。首先通过你的源代码进行 grep 搜索，查找 include 或 import 或 require 或 use 或你的首选语言用来声明依赖项的任何关键字。
$ find ~/Code/myproject -type f \
-iname ".java" \
-exec grep import {} \;仅仅识别你使用的特定于语言的库可能是不够的。审核依赖项，以便你知道是否有运行语言本身所需的底层库，或者特定模块按预期运行所需的底层库。
2. 评估你的数据存储
容器是无状态的，当一个容器崩溃或以其他方式停止运行时，该容器的实例将永远消失。如果你要将数据保存在该容器中，数据也会消失。如果你的应用程序存储用户数据，则所有存储都必须发生在容器外部，在你的应用程序实例可以访问的某个位置。
你可以使用映射到容器内位置的本地存储来存储简单的应用程序配置文件。这对于需要管理员提供简单配置值的 Web 应用程序来说是一种常见的技术，例如管理员电子邮件地址、网站标题等等。例如
$ podman run \
--volume /local/data:/storage:Z \
mycontainer但是，你可以将像 MariaDB 或 PostgreSQL 这样的数据库配置为跨多个容器共享存储，用于存储大量数据。对于私人信息，例如密码，你可以配置一个 secret。
[ 下载我们的 MariaDB 速查表 ]
关于你需要如何重构你的代码，你必须相应地调整存储位置。这可能意味着将路径更改为新的容器存储映射、将端口更改为不同的数据库目标，甚至包含特定于容器的模块。
3. 准备你的 Git 仓库
容器通常在构建时从 Git 仓库拉取源代码。你必须有一个计划来管理你的 Git 仓库，一旦它成为你的应用程序生产就绪代码的规范来源。拥有一个发布或生产分支，并考虑使用 Git 钩子 来拒绝意外的未经批准的提交。
4. 了解你的构建系统
容器化应用程序可能没有传统的发布周期。它们在容器构建时从 Git 中拉取。你可以在容器构建中启动任意数量的构建系统，但这可能意味着调整你的构建系统，使其比以前更加自动化。你应该重构你的构建过程，以便你完全确信它可以在完全无人值守的情况下工作。
5. 构建镜像
构建镜像不必是一项复杂的任务。你可以使用 现有的容器镜像 作为基础，使用简单的 Dockerfile 对其进行适配。或者，你可以使用 Buildah 从头开始构建你自己的镜像。
在某种程度上，构建容器的过程与实际重构你的代码一样是开发的一部分。正是容器构建获取、组装和执行你的应用程序，因此该过程必须是自动化的和健壮的。构建一个好的镜像，你就为你的应用程序构建了一个坚实可靠的基础。
容器化它
如果你是容器新手，请不要被术语吓倒。容器只是另一种环境。容器化开发的感知约束实际上可以帮助你专注于你的应用程序，更好地了解它的运行方式、可靠运行所需的东西以及出现问题时的潜在风险。相反，这为安装和运行你的应用程序的系统管理员带来了更少的约束，因为容器本质上是一个受控环境。仔细审查你的代码，了解你的应用程序需要什么，并相应地重构它。
评论已关闭。