2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
这是我 HNG 开发运维实习系列文章的一部分。在第一阶段，我在实时服务器上的 Nginx 后面部署了一个个人应用程序接口。第二阶段是事情变得严肃起来的地方。
任务
我们拿到了一个有缺陷的代码库，并被告知要使其达到生产就绪状态。没有关于哪里出错的提示。没有错误列表。只有代码和一条指令：“发现它们也是任务的一部分。”
该应用程序是一个分布式作业处理系统，由四个服务组成：
- 一个前端（Node.js/Express），用户在此提交和跟踪作业
- 一个应用程序接口（Python/FastAPI），用于创建作业并提供状态更新
- 一个工作器（Python），从队列中获取并处理作业
- 一个雷迪斯实例，在应用程序接口和工作器之间共享，作为消息代理
我的工作是找出每一个错误，修复每一个配置错误，用生产质量的 Dockerfile 容器化所有三个服务，用 Docker Compose 将所有内容连接在一起，并构建一个完整的持续集成/持续部署流水线，按严格顺序运行代码检查、测试、安全扫描、集成测试和滚动部署。
在动手之前先阅读代码
我做的第一件事是在编写任何基础设施代码之前仔细阅读每个文件。这是大多数人出错的地方——他们在不了解应用程序实际功能的情况下，直接跳去编写 Dockerfile。
以下是我的发现。
雷迪斯主机名问题
api/main.py 和 frontend/app.js 都将 localhost 硬编码为雷迪斯和应用程序接口的主机名。当所有内容都在一台机器上运行时，这没问题，但在 Docker 容器内，每个服务都有自己的网络命名空间。应用程序接口容器内的 localhost 指向应用程序接口容器本身，而不是雷迪斯。
修复方法很简单——使用环境变量和 Docker 的内置域名系统：
# 修改前
r = redis.Redis(host="localhost", port=6379)
# 修改后
r = redis.Redis(host=os.getenv("REDIS_HOST", "redis"), port=6379)
Docker Compose 会自动使用服务名称为每个服务创建域名系统条目。因此，redis 在网络内部解析为雷迪斯容器的互联网协议地址。
静默的队列不匹配
这一点很微妙。应用程序接口正在将作业标识推送到一个名为 job_queue 的雷迪斯列表中：
r.lpush("job_q
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
