飞牛 NAS 实战笔记：高效率 Python 3.11 容器化开发与多脚本管理指南

项目背景与痛点

在 NAS 环境下运行多个 Python 自动化脚本或爬虫时，传统的做法（如直接在宿主机运行、或进入运行中的容器敲 pip install）存在严重隐患：一旦容器重启、系统升级，手动安装的依赖库将彻底灰飞烟灭。

本指南采用 Dockerfile 固化环境 + Docker Compose 多任务编排 的现代标准工程流，实现环境一键迁移、高效复用与依赖防丢，并无缝打通国内网络壁垒。

第一步：构建法律 —— 编写高标准 Dockerfile

在项目的根目录（例如：/vol1/1000/my_scripts）下，新建一个名为 Dockerfile 的文件（注意：D 必须大写，且绝对不能有 .txt 等任何后缀）。

写入以下专为国内网络优化的 Python 3.11 生产级配置：

Dockerfile

# =========================================================
# 1. 基础镜像层 (Base Image)
# =========================================================
# 避坑：利用国内高速镜像站前缀，彻底解决 registry-1.docker.io 联网超时报错
FROM docker.1ms.run/library/python:3.11-slim

# =========================================================
# 2. 容器环境配置 (Environment Settings)
# =========================================================
# 设置容器内部的默认主工作目录
WORKDIR /app

#避坑：强制固化中国标准时区（CST），防止自动化脚本内的定时任务、日志时间错乱
ENV TZ=Asia/Shanghai

#避坑：禁用 Python 内部输出缓存，确保 print() 的日志能秒级无缝同步到飞牛 NAS 界面
ENV PYTHONUNBUFFERED=1

# =========================================================
# 3. 依赖固化层 (Dependencies)
# =========================================================
#避坑：使用 --no-cache-dir 清理 pip 缓存，防止臃肿，瘦身镜像
#避坑：强制指定清华大学国内源，确保依赖库秒级下载
RUN pip install --no-cache-dir -i https://pypi.tuna.tsinghua.edu.cn/simple \    requests \    urllib3 \    beautifulsoup4 \    pycryptodome \    pymysql

# 默认启动命令
CMD ["python3"]

第二步：指挥大局 —— 编写 docker-compose.yml

在 Dockerfile 的同级目录下，新建 docker-compose.yml 文件。它负责统一调度你的多个脚本，并实现极其巧妙的子目录跨层级对齐：

YAML

services:

  # =========================================================
  # 1. 自动化脚本 A 任务
  # =========================================================
  py_script_a:
    #核心大招：让 Compose 自动读取同级目录下的 Dockerfile 现场构建环境
    build:
      context: .
      dockerfile: Dockerfile
    # 构建成功后，为此纯净环境打上标签，方便下方其他脚本直接复用
    image: my-python-env:3.11
    container_name: py_script_a

    #物理传送门：公式 [左边现实(NAS) : 右边虚拟(容器)]
    # 把当前 my_scripts 目录，整体投影到容器内部的 /app 文件夹
    volumes:
      - .:/app

    #行为指挥官：如果 a.py 存放在子目录 scripts 下
    # 开机自动执行 cd /app/scripts，精准进入脚本所在的绝对战场的房间
    working_dir: /app/scripts

    # 因为工作目录已经对齐，直接无脑执行当前目录下的文件，绝不报路径错误
    command: python a.py

    # 异常崩溃安全网：如果代码报错，在后台最多连续重启 5 次，坚决死循环烧 CPU
    deploy:
      restart_policy:
        condition: on-failure
        max_attempts: 5
    networks:
      - fn_nas_net

  # =========================================================
  # 2. 自动化脚本 B 任务 (完美复用环境)
  # =========================================================
  py_script_b:
    image: my-python-env:3.11  #直接复用上面 py_script_a 刚建好的镜像，0秒启动
    container_name: py_script_b
    volumes:
      - .:/app
    working_dir: /app/scripts  # 如果 b.py 也在同一个子目录下
    command: python b.py
    deploy:
      restart_policy:
        condition: on-failure
        max_attempts: 5
    networks:
      - fn_nas_net

# =========================================================
# 3. 外部网络声明（打通宝塔面板/MySQL 的生命线）
# =========================================================
networks:
  fn_nas_net:
    external: true
    name: bridge  # 强行加入飞牛默认的 bridge 网络，使爬虫容器能用容器名直连宝塔的数据库

?‍? 核心概念背书（随时复习复盘）

1. 镜像与容器的关系

  • 镜像（Dockerfile）是法律：任何第三方库（如 requests 等）必须写进这里。今后如果代码需要引入新库，唯一的科学做法是：改 Dockerfile ➡️ 重新构建。
  • 容器是临时的：永远不要试图进入运行中的容器手动修改环境，那是随时可能随重启而蒸发的“空中楼阁”。

2. 传送门公式

在 Docker 的 volumes 与路径配置中，永远遵循：

$$\text{- [左边] 现实的目录（飞牛 NAS 路径）} \quad : \quad \text{[右边] 容器内的目录（虚拟路径）}$$

  • 符号 .（点）在 Linux 中代表“当前 Compose 文件所在的文件夹”。
  • working_dir 的本质是帮你省去了每次手动敲 cd 命令的麻烦，让 command 可以在最正确的文件夹里精准执行。

成果结语

通过今天这套配置的落地，你的飞牛 NAS 已经拥有了一个高并发、高弹性、且完全不惧怕网络封锁和系统重启的 Python 3.11 全自动化运行环境。今后有新的脚本，只需要往 docker-compose.yml 后面继续追加层级即可。把这篇文章存好，它就是你进阶 Docker 架构师的完美起点！

标签: none

评论已关闭