后端前端音视频【免费下载链接】Auto_BangumiAutoBangumi - 全自动追番工具项目地址https://gitcode.com/gh_mirrors/au/Auto_Bangumi点击查看免费下载AutoBangumi 是一套全自动追番工具支持通过 Docker 容器一键部署。本文以官方部署文档 docs/en/deploy/docker-cli.md 为骨架结合仓库内的 Dockerfile、entrypoint.sh 与 healthcheck.py 等源码实现系统讲解使用docker run命令行部署 AutoBangumi 的完整流程包括目录准备、参数逐项解读、权限模型、首次启动行为与环境变量迁移机制。读完本文你将能够独立完成一次可持久化、可自愈的 Docker CLI 部署并理解容器内部实际发生的关键逻辑。版本 2.6 起的新部署模式WebUI 优先配置从 AutoBangumi 2.6 开始项目的配置方式发生了根本性变化所有设置都可以直接在 WebUI 中完成不再依赖容器环境变量。你可以先启动容器再在 WebUI 中配置下载器、RSS 源等全部参数旧版本通过环境变量写入的配置会被自动迁移到新的配置体系环境变量仍然有效但仅在首次启动时生效——它们会被写入config.json之后以 WebUI 中的配置为准。这意味着 Docker CLI 部署的命令可以大幅简化无需预先注入大量环境变量只要保证数据目录持久化即可完成部署并进入 WebUI 完成后续配置。这与 docs/deploy/docker-cli.md中文版文档保持一致。第一步准备数据与配置目录为了让 AutoBangumi 的配置与数据在容器更新后依然保留官方强烈建议使用Docker 卷volume或绑定挂载bind mount两种持久化方式。方式 A绑定挂载推荐便于直接查看文件# 使用绑定挂载 mkdir -p ${HOME}/AutoBangumi/{config,data} cd ${HOME}/AutoBangumiconfig目录对应容器内的/app/config存放config.json与在线更新覆盖层等data目录对应容器内的/app/data存放 SQLite 数据库、海报缓存等运行数据。从 Dockerfile 可以看到镜像声明了VOLUME [/app/config, /app/data]说明这两个目录被设计为必须持久化的数据载体。方式 BDocker 卷# 使用 Docker 卷 docker volume create AutoBangumi_config docker volume create AutoBangumi_data使用命名卷时后续docker run命令中的挂载参数需要替换为卷名见下文部署命令。两种方式二选一即可绑定挂载更适合希望直接访问配置文件例如备份config.json、查看日志的用户。第二步完整的 Docker CLI 部署命令在确保工作目录为${HOME}/AutoBangumi之后复制并运行以下命令即可完成部署docker run -d \ --nameAutoBangumi \ -v ${HOME}/AutoBangumi/config:/app/config \ -v ${HOME}/AutoBangumi/data:/app/data \ -p 7892:7892 \ -e TZAsia/Shanghai \ -e PUID$(id -u) \ -e PGID$(id -g) \ -e UMASK022 \ --networkbridge \ --dns8.8.8.8 \ --restart unless-stopped \ --log-opt max-size10m \ --log-opt max-file3 \ ghcr.io/estrellaxd/auto_bangumi:latest如果选择了 Docker 卷只需将两个绑定挂载参数替换为卷名-v AutoBangumi_config:/app/config \ -v AutoBangumi_data:/app/data \参数逐项解读参数作用说明-d后台运行容器容器在前台启动后转入守护模式--nameAutoBangumi指定容器名称便于后续docker logs AutoBangumi、docker restart AutoBangumi等管理操作-v ...:/app/config挂载配置目录对应容器内/app/config存放config.json-v ...:/app/data挂载数据目录对应容器内/app/data存放数据库与缓存-p 7892:7892端口映射宿主机7892映射到容器 WebUI 端口 7892从源码 main.py 可知服务实际监听settings.program.webui_port默认即 7892-e TZAsia/Shanghai时区容器内默认TZAsia/Shanghai见 Dockerfile用于 RSS 抓取、下载排程等时间相关逻辑-e PUID$(id -u)容器内运行用户 UID默认 1000$(id -u)取当前宿主机用户 UID保证文件属主一致-e PGID$(id -g)容器内运行用户 GID默认 1000$(id -g)取当前宿主机用户 GID-e UMASK022文件权限掩码默认022新建文件权限为644/755组合--networkbridge网络模式使用默认 bridge 网络便于容器内访问宿主机与外部网络--dns8.8.8.8指定 DNS规避部分环境 DNS 解析异常导致的 RSS 抓取失败--restart unless-stopped自动重启策略容器异常退出时自动拉起手动 stop 后不重启--log-opt max-size10m/--log-opt max-file3日志轮转单个日志文件最大 10MB保留 3 个避免日志无限膨胀占用磁盘提示容器镜像默认用户为abUID/GID 911并通过PUID/PGID环境变量在启动时动态调整为宿主机用户。如果宿主机用户 UID 恰好是 911注意避免与镜像内默认用户混淆——从 entrypoint.sh 可以看到启动脚本会执行groupmod与usermod将ab用户重设为指定 UID/GID。首次启动行为WebUI 先行主程序待命部署命令运行后容器会立即启动但主程序处于暂停状态。这是 AutoBangumi 2.6 的设计WebUI 自动启动访问http://abhost:7892abhost替换为宿主机 IP 或域名即可打开配置界面主程序等待配置首次启动仅完成数据库初始化等准备工作不会立刻开始抓取 RSS 与下载。这与 main.py 中lifespan的逻辑一致——首次启动first_run_boot时不会自动启动后台循环任务等用户在 WebUI 完成设置后由用户触发环境变量落盘如果通过环境变量提供了配置AB 会自动将其写入config.json并开始运行。这一机制对应文档中环境变量仅在首次启动时生效的说明——首次启动写入后后续配置以config.json与 WebUI 为准。容器内部机制entrypoint 与权限模型理解容器内部实际执行的内容有助于排查权限类问题。镜像的入口为tini -g -- /entrypoint.sh见 Dockerfile启动脚本 entrypoint.sh 依次完成以下工作应用UMASKumask ${UMASK}影响容器内所有新建文件的权限旧配置迁移若/config/bangumi.json存在旧版本遗留自动移动到/app/data/bangumi.json并修正属主调整运行用户通过groupmod -o -g ${PGID} ab与usermod -o -u ${PUID} ab将容器内ab用户重映射为宿主机指定的 UID/GID应用在线更新覆盖层以 root 身份执行python /app/boot_overlay.py应用持久卷中的在线更新内容覆盖层失败不会阻断容器启动脚本自带|| true兜底目录属主修复通过/app/config/.ab_owner标记文件判断是否需要递归chown——仅在首次运行或PUID/PGID变更时才遍历挂载卷避免每次启动都对大型海报缓存做 O(文件数) 的全量遍历这是 NAS 场景下每次容器启动的主要耗时来源以应用用户运行su-exec ${PUID}:${PGID} python main.py启动主进程并在收到TERM/INT信号时转发给应用进程、等待其正常退出保证 SQLite WAL 能安全落盘在线更新重启循环若/app/config/updates/.restart标记存在清理标记后自动重新拉起应用。从这段逻辑可以看出修改PUID/PGID后无需手动 chown容器下次启动会自动修复挂载目录属主同时TZ、UMASK、PUID、PGID的默认值Asia/Shanghai、022、1000、1000已在 Dockerfile 中固化即使部署命令不显式传入也能正常运行。健康检查容器自愈的基础镜像内置了 DockerHEALTHCHECK见 Dockerfile每 30 秒执行一次python /app/healthcheck.py超时 5 秒启动宽容期 30 秒连续 3 次失败即标记容器不健康。健康检查的实现位于 healthcheck.py探测无需认证的/health路由该路由在 main.py 中挂载于应用根路径专为容器/编排器健康检查设计端口不是写死的 7892脚本会从config/config.json读取program.webui_port因此即使你在 WebUI 中修改了端口健康检查依然准确依次探测 IPv4 回环127.0.0.1与 IPv6 回环[::1]兼容IPV6环境变量开启时的监听地址::。配合部署命令中的--restart unless-stopped容器在健康检查失败或进程异常退出时能够自动拉起实现基础自愈。环境变量速查与迁移说明尽管 2.6 起推荐 WebUI 配置环境变量在首次启动时依然有效。以下是本次部署涉及的关键环境变量环境变量默认值说明TZAsia/Shanghai容器时区PUID1000容器内运行用户 UIDPGID1000容器内运行用户 GIDUMASK022文件权限掩码HOST0.0.0.0服务监听地址见 main.pyIPV6未设置设为任意非空值则监听::迁移行为旧版本通过环境变量配置的项如下载器地址、凭据等在首次启动时会被自动写入config.json用户在 WebUI 中修改后的值写入同一文件。需要强调环境变量只在首次启动即容器创建并首次运行时写入后续修改环境变量并重启容器不会覆盖已有配置——这正是文档中环境变量仅首次启动生效的实现含义。进阶建议与常见问题使用 Docker 管理面板官方建议在需要高级管理能力时使用Portainer或类似的 Docker 管理界面便于可视化管理容器、卷与日志。这与纯 CLI 方式互补日常查看日志、重启容器用docker logs AutoBangumi/docker restart AutoBangumi即可。其他部署方式参考偏好声明式配置的用户可以参考 docs/en/deploy/docker-compose.md将上述参数映射为docker-compose.yml的environment、volumes、ports、logging、dns字段并使用docker compose up -d一键启动中文用户可直接阅读 docs/deploy/docker-cli.md 获得与本文相同内容的中文版本群晖DSM等 NAS 环境的部署见 docs/deploy/dsm.md。常见问题排查WebUI 无法访问确认端口映射-p 7892:7892未被占用且防火墙放行 7892健康检查脚本从config.json读取端口若你修改过 WebUI 端口需同步更新端口映射挂载目录权限异常检查PUID/PGID是否与宿主机目录属主一致容器启动时会自动修复属主但 NAS 的 root-squash 等场景可能导致修复失败此时建议在宿主机侧调整目录属主RSS 抓取失败但容器健康多为 DNS 问题部署命令中的--dns8.8.8.8正是为此而设可按需替换为可达的 DNS 服务器环境变量修改不生效符合设计预期——环境变量仅首次启动生效后续请在 WebUI 中修改。小结通过 Docker CLI 部署 AutoBangumi 的核心要点可以概括为一对持久化目录config/data 一条docker run命令 WebUI 完成后续配置。2.6 起的 WebUI 优先模式大幅降低了部署门槛而镜像内置的用户权限重映射、在线更新覆盖层、健康检查与日志轮转保证了容器在 NAS、VPS 等场景下的长期稳定运行。按本文步骤执行几分钟内即可得到一个可持久化、可自愈的 AutoBangumi 服务。赞分享后端前端音视频【免费下载链接】Auto_BangumiAutoBangumi - 全自动追番工具项目地址https://gitcode.com/gh_mirrors/au/Auto_Bangumi点击查看免费下载相关推荐Wasp 全栈应用手动部署实战从 wasp build 到 Fly.io / Netlify / Railway / Heroku 的完整指南Wasp 全栈应用手动部署实战从 wasp build 到 Fly.io / Netlify / Railway / Heroku 的完整指南 本篇指南以 W后端前端音视频群晖 NASDSM 7.2部署 AutoBangumi 完整指南Docker Compose 一键搭建全自动追番服务群晖 NASDSM 7.2部署 AutoBangumi 完整指南Docker Compose 一键搭建全自动追番服务 AutoBangumi 是一款全自动后端前端音视频微信聊天记录导出指南用留痕 WeChatMsg 把对话永久存成可搜索网页微信聊天记录导出指南用留痕 WeChatMsg 把对话永久存成可搜索网页 换手机前想给全部微信聊天记录留个底留痕WeChatMsg是个开源工具能把你后端前端音视频上一篇如何将mitm_relay接入Burp代理拦截与修改厚客户端流量的完整指南下一篇Docker Compose网络配置Overleaf微服务间通信与端口映射创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考