5、容器化与Kubernetes部署全解析

容器化与Kubernetes部署全解析

1. 容器化与本地测试

使用Compose而非仅用Docker进行本地测试的关键原因之一，是它能够通过单个命令搭建并拆除完整的测试环境。在为本地开发和生产配置应用程序时，所有配置更改都应通过环境变量进行。哪怕仅使用一个指示“prod”或“dev”的环境变量来选择配置文件，也足以完成配置。配置不应硬编码在容器中，以免在不同环境间需要修改。这样能让同一容器在所有环境中复用，也意味着你在测试生产环境的产物。

2. 模拟外部依赖

如果你一直以来都是针对远程依赖（如云存储API）进行测试，现在或许是考虑用模拟依赖替代它们的好时机。模拟依赖是外部依赖相同API的轻量级实现，通过提供本地服务来加速开发和测试。

过去，你可能受限于寻找与应用程序使用相同语言编写的模拟依赖（出于实际原因，比如不想为一个项目支持多种不同环境）。容器的好处之一在于，就像你可能并不关心所使用的云服务是用何种语言编写的一样，你也不再需要关心模拟依赖的编写语言，因为它运行在自己的容器中，无需你维护其环境。

这也为高质量模拟依赖的出现带来了机会，这些模拟依赖实际上只是生产环境中所使用的相同API的轻量级实现。就像之前我们在容器中使用真实的MySQL（而非模拟）一样，你也可以使用真实的对象存储提供商进行测试，即便你最终使用的是像Google Cloud Storage或AWS S3这样的云服务提供商。

以对象存储为例，假设你的应用程序使用与S3兼容的API进行云存储（例如使用S3本身，或者众多支持该API的对象存储之一，如Google Cloud Storage）。为了快速迭代而设置本地模拟，你可以使用像Adobe的S3Moc