将RSS抓取应用容器化，本质是把运行脚本所需的解释器、第三方库和配置全部封装为不可变镜像，从而屏蔽不同主机之间的差异。对于Python编写的RSS抓取程序来说，feedparser等解析库是常见依赖，而输出目录、订阅地址、运行频率等参数又经常随环境变化。借助Docker，这些变量可以通过环境变量和挂载卷统一管理，使同一套代码在本地开发机、测试服务器和生产节点上表现一致。下文以一个简单的RSS抓取脚本为例，梳理从编写脚本到自动化部署的完整路径。
一、准备RSS抓取脚本
先创建一个RSS抓取脚本，使用feedparser库读取订阅源，并将标题和链接写入本地JSON文件。脚本只依赖RSS_URL和OUT_DIR两个环境变量，不硬编码绝对路径，这样容器在不同目录结构和存储位置下都能稳定运行。程序会检查输出目录是否存在，不存在则自动创建，然后以UTF-8编码写入news.json，确保中文标题不会出现乱码。
在真实项目中，RSS抓取通常还需要去重、异常捕获和多源合并等逻辑。但容器化的核心不在于脚本复杂度，而在于让脚本对运行环境的假设尽可能少。避免在代码中写死文件路径，改用环境变量注入目录和订阅地址；把网络请求的失败处理放在合理位置，保证一次源站不可用不会导致容器异常退出。下面的示例保持轻量，便于后续验证容器化流程。
代码使用feedparser.parse获取Feed对象，遍历entries列表构造字典数组，最后通过json.dump落盘。程序入口使用if __name__ == '__main__'保证模块被导入时不会意外执行。
import os
import json
import feedparser
RSS_URL = os.getenv('RSS_URL', 'https://ipipp.com/feed.xml')
OUT_DIR = os.getenv('OUT_DIR', '/data')
def fetch():
feed = feedparser.parse(RSS_URL)
items = []
for entry in feed.entries:
items.append({'title': entry.title, 'link': entry.link})
if not os.path.exists(OUT_DIR):
os.makedirs(OUT_DIR)
with open(os.path.join(OUT_DIR, 'news.json'), 'w', encoding='utf-8') as f:
json.dump(items, f, ensure_ascii=False, indent=2)
if __name__ == '__main__':
fetch()
二、编写Dockerfile
Dockerfile决定镜像里包含什么内容。为了控制最终体积，可以采用多阶段构建：第一阶段安装依赖并生成虚拟环境或直接安装到系统路径，第二阶段只复制运行时需要的文件。基础镜像选用python:3.11-slim，它包含包管理工具和必要的C运行库，又比完整镜像小得多。依赖锁定为feedparser==6.0.10，避免上游版本变化导致不可预期的构建失败。
容器默认以root运行会带来安全隐患。通过RUN useradd -m appuser创建普通用户，再使用USER appuser切换到该用户执行后续命令。同时用ENV指令设置默认环境变量，使镜像在未显式传参时也能工作。挂载目录/data需要在构建阶段创建并赋予appuser用户写入权限。
下面是一个完整的多阶段Dockerfile示例。第二阶段通过COPY --from=builder复制依赖目录，避免在最终镜像中保留pip缓存和构建工具。需要注意，CMD使用JSON数组形式指定启动命令，可以防止shell解析导致的意外行为。
FROM python:3.11-slim AS builder WORKDIR /app RUN pip install --no-cache-dir feedparser==6.0.10 FROM python:3.11-slim WORKDIR /app COPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages COPY rss_fetch.py . ENV RSS_URL=https://ipipp.com/feed.xml ENV OUT_DIR=/data RUN useradd -m appuser && mkdir /data && chown appuser:appuser /data USER appuser CMD ["python", "rss_fetch.py"]
三、配置定时抓取
许多RSS应用不是常驻服务，而需要按固定间隔执行抓取。常见做法有两种：在容器内部用shell循环配合sleep实现简易定时，或者由宿主机cron周期性地销毁并重建容器。前者把所有逻辑封装在镜像内，迁移方便；后者更适合集中管理大量任务，但需要宿主机的调度配置。
如果选择镜像内定时，可以将启动命令替换为包装脚本。下面的入口脚本通过环境变量INTERVAL控制间隔，默认1800秒，修改频率时无需重新构建镜像。脚本以前台进程运行，保持容器存活，并且能接收SIGTERM信号；实际使用时如果需要更细腻的信号管理，还可以在循环体内加入trap或使用exec直接替换当前shell来执行任务。
这种方式适合单容器单任务场景。当有多个抓取源且频率差异较大时，建议拆分为多个服务，或者在compose层用不同INTERVAL启动多个实例，避免一个容器内出现复杂的并发放大逻辑。
#!/bin/sh
INTERVAL=${INTERVAL:-1800}
while true; do
python /app/rss_fetch.py
sleep $INTERVAL
done
四、使用docker compose编排
当抓取源变多，或需要同时挂载输出目录、设置环境变量和重启策略时，单纯使用docker run命令行会变得冗长。docker compose用YAML文件声明服务，适合版本控制和团队复用。下面配置定义了一个rss服务，使用当前目录构建镜像，通过environment覆盖默认订阅地址和抓取间隔，并用卷映射把容器内/data落到宿主机./output目录。
重启策略选择on-failure，意味着只有异常退出时才自动拉起容器，抓取脚本正常结束不会触发不必要的重启。由于镜像内已经设置了默认环境变量，compose文件只在需要覆盖时列出变量，保持配置简洁。整个服务的启动和停止只需docker compose up -d和docker compose down。
这种结构化方式让任务恢复成本大幅降低。换一台机器后，只要安装Docker和compose插件，克隆仓库并执行一条命令，就能重建完整采集环境。如果需要在多台节点上并行抓取不同源，也可以通过compose的--scale参数或定义多个服务来实现。
version: '3.8'
services:
rss:
build: .
environment:
- RSS_URL=https://ipipp.com/tech/feed.xml
- OUT_DIR=/data
- INTERVAL=900
volumes:
- ./output:/data
restart: on-failure
五、镜像构建与首次运行
完成 compose 文件后，在项目根目录执行以下命令构建镜像并启动服务：
docker compose build docker compose up -d
构建阶段会执行 pip install，如果网络较慢，可以在 Dockerfile 中提前配置 pip 镜像源。启动后容器会立即执行一次抓取，然后进入 sleep 等待下一次循环。查看抓取日志可以执行：
docker compose logs -f rss
如果启动后没有立即看到日志输出，可以先确认容器状态是否正常：
docker compose ps
容器启动后，宿主机的 ./output 目录会出现 RSS 解析后的结果文件。具体文件格式取决于 rss_fetch.py 的实现，可能是 JSONL、XML 或 Markdown。如果输出目录长时间为空，应优先查看容器日志中是否出现 Python 异常、网络超时或文件权限错误。
六、数据卷权限与用户隔离
默认情况下，容器以 root 用户运行，写入挂载卷的文件在宿主机上也会显示为 root 所有。如果宿主环境不允许 root 权限文件，或者需要与其他服务共享输出目录，可以在 Dockerfile 中创建非 root 用户：
RUN useradd -m -u 1000 rssuser USER rssuser
如果使用非 root 用户，同时配合 docker compose 挂载宿主机目录，需要确保宿主机目录的 uid 与容器内用户 uid 一致。否则仍可能遇到 Permission denied。可以在宿主机执行 chown -R 1000:1000 ./output 解决。对于大多数个人自建服务，继续使用 root 运行也可以接受，但生产环境中建议采用非 root 方式。
七、定时策略与容器生命周期
当前入口脚本使用 while true 加 sleep 实现固定间隔调度。这种方式足够简单，适合低频抓取场景，容器只需要一个主进程。抓取脚本退出时，如果退出码非零，就可能导致容器退出；配置的 restart: on-failure 会在这种情况下自动重启容器。正常执行后进入 sleep 时容器不会退出。
如果希望抓取时间更精确，或者避免长时间 sleep 带来的漂移，可以将调度逻辑从 shell 脚本替换为 cron 或 Python 调度库。例如在容器内使用轻量级 cron 守护进程，但需要同时管理两个进程，复杂度略高。对于当前需求，sleep 方案已经完全够用。实际使用中可以根据源站更新频率调整 INTERVAL 值：博客类源可设置为 1800 秒，新闻类源可设置为 900 秒，必要时也可以降低到 300 秒。
八、日志与错误处理
为了让容器运行过程更容易观测，建议在 rss_fetch.py 中增加结构化日志，记录每次抓取的开始时间、条目数量和耗时。对于单条 RSS 源，网络波动可能导致一次抓取失败，可以在脚本内部增加重试逻辑，而不是直接抛异常退出。若所有重试均失败，可以返回非零退出码，交由容器重启策略处理。
容器内遇到 DNS 解析失败时，可在 compose 文件中显式指定 DNS 服务器：
dns: - 1.1.1.1 - 8.8.8.8
日志输出尽量保持纯文本，避免彩色控制码干扰 docker logs 查看。也可以配置日志轮转，防止长时间运行后容器日志无限增长：
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"九、镜像优化与安全
当前 Dockerfile 使用 python:3.11-slim 作为基础镜像，已经比完整版镜像小很多。如果希望进一步减小体积，可以考虑使用 python:3.11-alpine，但部分依赖在 Alpine 上可能需要额外编译，兼容性不如 slim。对于这个简单的 RSS 抓取任务，slim 镜像的稳定性和体积之间取得了较好的平衡，不建议为了节省几十 MB 而引入 Alpine 的兼容性问题。
安全方面，除了使用非 root 用户外，还应避免在镜像中硬编码敏感信息。如果 RSS 源需要认证，建议通过环境变量注入，而不是写死在脚本或配置文件中。compose 文件中的环境变量可以从宿主机环境或 .env 文件读取，避免将密钥提交到版本库。
十、总结
本方案通过 Docker 将 RSS 抓取脚本、运行环境、调度逻辑和持久化目录封装在一起，使用 docker compose 实现声明式部署。核心流程可以概括为：编写 rss_fetch.py 完成抓取与解析，Dockerfile 固定 Python 依赖和运行用户，入口脚本控制抓取周期，compose 文件统一管理环境变量、卷映射和重启策略。整条链路清晰，移植性强，换一台机器后只需安装 Docker 和 compose 插件，克隆仓库并执行一条启动命令即可恢复采集环境。
后续如果需要扩展，可以考虑将抓取结果写入数据库，例如 SQLite 或 PostgreSQL；在抓取到新内容时接入通知服务，比如 Webhook 或邮件；还可以为容器增加健康检查，监控抓取进程是否正常工作，而不只是检查容器是否存活。当前结构已经为这些扩展预留了足够的可调整空间。