进入应用开发

本章内容概览

像 MySQL、Adminer 和 WordPress 这样的预构建 Docker 镜像非常实用，但最终你可能希望在容器中运行自己的程序。

在本章中，你将创建一个基于 Node.js 的“Hello World”应用程序，将其打包成 Docker 镜像并以容器形式运行。默认情况下，该镜像已准备好部署到生产服务器，但我们将使用 Docker Compose 覆盖部分设置，以搭建开发和调试环境。你可以直接在主机上编辑源代码，而代码将在持续运行的容器中执行。这种方式具有以下优势：

• Docker 会自动管理依赖项——无需安装和维护语言运行时。
• 开发流程与本地开发略有不同。
• 容器是隔离的，你的应用无法导致宿主机崩溃或删除文件。
• 你可以轻松地将应用分发给其他开发者或测试人员，它在任何具备 Docker 环境的设备上都能以完全一致的方式运行，无需额外配置。

基于容器的应用开发

Docker 简化了 Web 开发流程。你所创建的任何 Web 应用都可以运行在一个容器中。

然而，如果你计划将类似的容器部署到生产服务器，应用应设计为无状态（stateless）。这意味着可以启动任意数量的实例，并且任一实例都能响应请求。从实际角度讲，应用不应将关键状态数据存储在本地文件或内存中。

例如，某个应用在用户登录时将凭证信息保存在内存中。开发阶段仅使用单个容器，一切运行正常。
当应用部署到生产环境并由负载均衡器分发至两个容器时，用户首次请求由容器1处理，第二次请求可能由容器2处理。由于容器2没有用户的登录状态，系统会将其重定向回登录页面。

这可能会改变你对应用开发方式的理解。独立的容器应将数据存储在集中式资源中，如数据库。

无状态 Web 应用是理想的设计。它们支持横向扩展，当访问量增加时，只需添加更多机器或容器即可轻松应对。在项目初期做出这一决策很容易，但将原有的有状态遗留应用改造为无状态可能并不现实。

📌 使用 PHP 编写的程序通常更容易容器化，因为 HTTP 请求本身默认就是无状态的。相比之下，原本设计为在单一生产服务器上运行的大型 Node.js 或 Python 应用，转换起来可能更困难。

在开发阶段，这些限制并不重要，因为你通常只会用单个容器运行应用。如果在生产环境中使用容器不切实际，也可以选择不使用。