首页 / 资讯中心 / 文章详情

用镜像源为 Alas 更新加速:Git、pip 与 Docker 网络卡顿解决方案

用镜像源为 Alas 更新加速:Git、pip 与 Docker 网络卡顿解决方案 ★ FEATURED ARTICLE
玩碧蓝航线的朋友对 Alas 这个名字应该不陌生。这个开源自动化工具能把游戏里那些机械重复的日常操作接管过去让脚本按计划跑图、收菜、做任务省下来的时间可以用来做别的事。Alas 的更新频率在活跃期相当高经常是今天刚适配了新活动过两天又冒出一个小版本修 bug。但问题往往就出在“更新”这两个字上默认从 GitHub 拉代码、从 PyPI 装依赖在国内网络环境下经常会卡到怀疑人生。这篇文章不是官方教程也不是什么高深理论就是我自己长期维护 Alas 时摸索出来的一套镜像源更新方案。我从 Git 同步、Python 依赖、Docker 部署三个层面分别做了处理把踩过的坑和排错心得一并写了进去。无论你是刚接触 Alas 的新手还是已经用了一段时间但每次更新都在跟网络斗智斗勇的老玩家照着这套流程走一遍基本能把更新这件事变得又快又稳。1. 先搞清楚 Alas 更新到底做了什么1.1 更新链条里的三个关键环节Alas 的更新不是一个动作而是一条链。很多人以为更新就是“拉到新代码就完事”其实拉代码只是第一环。第一环是代码本体。Alas 整个项目托管在 GitHub 仓库里更新第一步自然是git pull把最新 commit 拉到本地。这一步如果仓库很旧可能会涉及大量文件变更小文件一多网络传输的压力就上来了。第二环是 Python 依赖。Alas 是用 Python 写的版本升级时经常会新增第三方库这些依赖声明在根目录的requirements.txt里。如果你只拉代码不装依赖启动时大概率会直接报ModuleNotFoundError。反过来说有些版本会把某个依赖去掉这时候如果不及时同步 requirements就可能出现版本冲突。第三环是配置和资源文件。像端口号、模拟器路径、账号信息这些用户配置更新时一般不会动但资源文件会变比如关卡信息、船坞识别模板、脚本流程配置。这些文件虽然不显眼却是最容易在更新后引发“行为异常”的地方。所以完整的更新流程应该是同步代码、更新依赖、检查配置和资源最后才是重启服务。这套链条只要有一环走得慢或者出错整个更新都会卡住。1.2 为什么默认源经常卡住先说明一下我这里说的“卡住”纯粹是网络链路上的客观问题。GitHub、PyPI 官方源这些服务服务器基本都架在海外国内网络直连时 TCP 握手时延高丢包率也偏高。Git 恰恰又是大量小文件并发传输的协议一个包出错就会触发重传重传到一定程度整个传输过程就陷入半死不活的状态。我自己遇到过最典型的情况是git clone跑到 80% 突然卡住进度条不动等了五分钟报fatal: early EOF。这种问题不是 Alas 本身的 bug纯粹是传输链路太脆弱。PyPI 官方源也类似安装依赖时经常是“正在下载”然后长时间没有动静最后超时失败。所以我的思路很直接既然默认源不给力那就把更新链路上能换的源全换成镜像源。镜像源本质上就是官方仓库在国内的同步副本地址在国内访问路径短时延和丢包率都会好很多。1.3 我的镜像源选型方案这里先给出我的整体方案后面章节再细节展开。Git 仓库层面我不建议用网上那些公共加速服务而是自己用 Gitee 导一份镜像。公共加速服务的好与坏完全取决于别人的服务器状态而且有时候会混入奇怪的历史 commit安全性和稳定性都不好把控。自己导一份镜像到 Gitee代码在自己账号下速度稳定出了问题也方便追查。Python 依赖层面我用的是清华 TUNA 的 PyPI 镜像备用源是阿里云。清华镜像同步频率高包比较全适合安装 requirements.txt 里的依赖。阿里云则是备选清华偶尔抽风或者某个包没同步的时候切过去能救急。Docker 部署层面如果 Alas 是通过 Docker 跑的服务我会给 Docker 配置 registry mirror 加速器。这个稍后会在 2.4 节详细说。这套方案的核心逻辑是不要把所有鸡蛋放在一个篮子里每个环节选一个稳定源同时留一个备选源。更新流程跑不通时能快速替换而不是干等。2. 镜像源怎么选深入对比和避坑2.1 常用镜像源速查表先把常用的镜像源整理成一张表方便对照查询。注意镜像源地址是会变的尤其是 Docker 相关的镜像加速器经常有服务调整甚至关停使用前最好去各镜像站官网确认一下当前生效地址。类型推荐镜像源配置地址示例适用场景备注Python / pip清华 TUNAhttps://pypi.tuna.tsinghua.edu.cn/simplerequirements.txt 依赖安装同步频率高包比较全Python / pip阿里云https://mirrors.aliyun.com/pypi/simple清华不可用时的备用速度也很快但偶有同步延迟npmnpmmirrorhttps://registry.npmmirror.com前端工程依赖老 taobao 域名已弃用别再用Docker中科大镜像https://docker.mirrors.ustc.edu.cndocker pull Docker Hub 镜像地址可能有变动Docker网易镜像https://hub-mirror.c.163.comdocker pull Docker Hub 镜像备选APT清华 / 阿里云https://mirrors.tuna.tsinghua.edu.cn/ubuntu/Ubuntu 系统软件源要匹配系统版本如 jammyConda清华https://mirrors.tuna.tsinghua.edu.cn/anaconda/pkgs/main/Conda 创建和管理 Python 环境需要写入 .condarc这张表里的 pip 和 Docker 是 Alas 更新最常涉及的两类。npm 和 APT 属于锦上添花如果你的系统本身就需要频繁装软件顺手配置一下能省很多事。2.2 pip 镜像的配置细节pip 镜像配置有两种方式一种是在命令行里临时指定一种是写在配置文件里全局生效。我强烈建议用配置文件的方式原因很简单命令行临时指定容易忘而且一旦你用了pip install但忘记带-i参数pip 又会跑去官方源网络一卡又是白等。配置文件的位置分系统看。Windows 下是%APPDATA%\pip\pip.ini通常就是C:\Users\你的用户名\AppData\Roaming\pip\pip.ini。Linux 下是~/.pip/pip.conf也可以用系统级路径/etc/pip.conf。如果你不确定当前用的是哪个路径直接执行下面这行命令pip 会把当前生效的配置文件路径打印出来。pip config list -v然后写入如下内容[global] index-url https://pypi.tuna.tsinghua.edu.cn/simple trusted-host pypi.tuna.tsinghua.edu.cntrusted-host这一行是关键。清华镜像的 HTTPS 证书有时不被某些环境的 pip 信任如果报 SSL 相关错误这一行能帮你跳过证书校验环节。但注意trusted-host本质上是在告诉 pip “我信任这个域名”所以千万不要把别人提供的未知镜像源随便加进去安全优先。配置好之后你可以用下面这行命令验证一下pip install --dry-run requests如果很快显示 “Would install requests”说明镜像源配置生效了。2.3 git 仓库的镜像思路用 Gitee 建私人源Git 仓库的镜像我不太推荐用公共代理而是建议在 Gitee 上导一份自己的仓库。Gitee 是国内老牌的 Git 托管平台从 GitHub 导入仓库是它的内置功能不需要你亲自先把仓库下载下来再传上去。具体做法是登录 Gitee点击右上角的“ ”号选择“从 GitHub 导入仓库”。然后粘贴 Alas 的 GitHub 仓库地址仓库名建议起成AzurLaneAutoScript-mirror这样的名字方便自己一眼认出这是镜像。导入过程由 Gitee 服务器完成你只需要等待即可。导入完成后你会得到一个类似https://gitee.com/你的用户名/AzurLaneAutoScript-mirror.git的地址。这就是你后续更新 Alas 时用的镜像源地址。这里要注意一个问题Gitee 导入的仓库默认不是自动同步的。也就是说当你导入完那一刻Gitee 上的代码和 GitHub 官方仓库是一致的但之后官方仓库更新了你的 Gitee 镜像并不知情。你需要每隔一段时间去 Gitee 仓库页面点一次“同步”按钮或者用“强制同步”功能把 GitHub 上的最新 commit 拉过来。这一步是手动操作没见过哪个 Gitee 按钮能完全自动化的除非你自己写脚本调 API。2.4 Docker 镜像加速器配置细节如果 Alas 是用 Docker 部署的那 Docker 镜像加速器就必须配好。Docker 默认从 Docker Hub 拉镜像这个地址对国内网络同样不友好。配置加速器的核心文件是/etc/docker/daemon.json如果文件不存在创建一个即可。{ registry-mirrors: [ https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com ] }修改完成后重启 Docker 服务sudo systemctl restart docker之后执行docker info在输出里找 Registry Mirrors 这一项如果能看到你配置的地址说明加速器已经生效。然后随便拉一个镜像测试一下速度比如docker pull hello-world正常情况几秒钟就能下来。还有一个隐藏坑registry mirror 只对 Docker Hub 官方镜像生效。如果你拉的是ghcr.io、quay.io这类第三方仓库的镜像镜像加速器是不起作用的。所以用 Docker 部署 Alas 之前先确认它的镜像到底发布在哪个仓库再决定要不要配加速器。3. 实操从零开始用镜像源更新 Alas3.1 环境准备与前置检查在动手之前先检查三个东西Git 是否安装、Python 版本是否合规、当前仓库是否干净。Git 检查很简单git --version如果没有安装Windows 用户建议装 Git for Windows安装完记得把 Git 的 bin 目录加到 PATH 里。Python 检查执行python --versionAlas 对 Python 版本有要求一般建议用 3.10 或 3.11具体以仓库 README 的说明为准。如果当前版本太低建议先升级 Python 再继续。第三步是检查本地仓库状态进入 Alas 目录执行git status如果显示工作区有改动一定要先处理否则后面git pull会提示冲突。处理方式我建议先把改动 stash 起来git stash save backup before update这样既保留了你的改动又把工作区恢复干净方便拉取更新。3.2 把 GitHub 仓库导入 Gitee这一步提升速度的效果最明显。操作路径是登录 Gitee - 右上角“ ” - “从 GitHub 导入仓库”。在弹出的页面里粘贴 Alas 的 GitHub 仓库地址然后点导入。导入耗时取决于仓库大小和 Gitee 服务器的状态Alas 这个仓库不算小我等过大概一两分钟。导入完成后打开你自己的 Gitee 仓库确认 code 页面能正常看到文件列表然后复制 HTTPS 地址。有一点要提醒Gitee 导入的时候偶尔会把仓库的 issue、PR 这些也给带过来但代码主体一般没问题。如果导入后仓库看起来缺了不少文件别慌多半是 Gitee 缓存问题点一下仓库页面的“刷新”或者重新同步一次。3.3 本地仓库切换镜像源并拉取更新有两种情况。第一种是你之前还没有克隆过 Alas那直接用 Gitee 地址克隆就行git clone https://gitee.com/你的用户名/AzurLaneAutoScript-mirror.git第二种是你本地已经有一个从 GitHub 克隆的老仓库那不用重新克隆直接改 remote 地址git remote set-url origin https://gitee.com/你的用户名/AzurLaneAutoScript-mirror.git改完之后执行git remote -v确认一下输出里显示的 URL 应该已经变成 Gitee 地址。接下来就是拉取更新git fetch --all -p git pullfetch会把远端最新的 commit 信息拉到本地但不会动你的工作区这一步是安全的。pull则是把远程仓库的最新代码合并到当前分支。如果你之前已经 stash 了本地改动此时大概率能顺利合并。拉完以后看一眼版本号可以用git log --oneline -5看最近几条提交确认代码确实更新到了你要的版本。对比 Gitee 仓库页面上显示的 commit hash如果一致说明同步成功。3.4 用清华 PyPI 镜像安装依赖代码同步完成之后依赖这一环不能漏。进入 Alas 根目录执行pip install -r requirements.txt如果你的 pip 已经按 2.2 节配置好了镜像源这行命令就直接走清华镜像了速度会明显快很多。如果你还没配置全局镜像也可以临时指定pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple我见过很多人只拉代码、不装依赖启动时看到ModuleNotFoundError: No module named xxx又花半小时排查。其实只要你每次更新后都跑一遍pip install -r requirements.txt这类问题能少一大半。如果安装过程中提示某些包找不到比如Could not find a version that satisfies the requirement大概率是清华镜像还没同步这个包的最新版本。这时可以临时加一个官方源兜底pip install -r requirements.txt --extra-index-url https://pypi.org/simple--extra-index-url的意思是“在原有源的基础上额外增加一个官方源”。注意它是追加而不是替换所以清华镜像优先官方源补缺这是最稳妥的兜底方案。3.5 Docker 部署场景下的镜像更新流程如果你是用 Docker 跑 Alas代码和依赖的更新逻辑有点不同。镜像本身是打包好的更新通常意味着拉取新的 image 版本并重新创建容器。假设你已经配好了 2.4 节的 Docker registry mirror那么更新流程是docker pull 你的镜像名镜像下载完成后停掉旧容器、删掉旧容器、用新镜像重新创建容器。具体命令以你使用的镜像页面的说明为准但有一个通用规则必须记住容器里的数据是无状态的杀掉就没了所以一定要把配置、日志、数据库等目录通过 volume 挂载到宿主机上。比如docker run -d --name alas \ -v /你的宿主机路径/config:/app/config \ -v /你的宿主机路径/logs:/app/logs \ 你的镜像名这样更新时即使容器被删掉数据也不会丢。我见过有人就是因为没挂载 volume每次更新后重新创建容器账号配置全没了又得从头设置一遍。3.6 更新完成后的启动与验证代码和依赖都更新完之后最后一步是启动验证。Alas 的启动方式根据版本不同略有差异一般根目录会有main.py文件可能是命令行入口也可能有 GUI 窗口。还有的版本提供.bat或.sh启动脚本。以你当前版本 README 的说明为准。启动后先别急着看界面重点看日志输出。如果是正常启动日志里会有一系列初始化信息比如加载配置、连接模拟器、检查游戏进程。如果启动后立刻报错多半是配置文件和代码存在不兼容。这时候去查看 config 目录下的配置文件看是不是缺了新版本要求的字段。很多时候官方在发布新版本时会新增配置项旧配置里没有程序启动时就抛异常。解决方法是打开配置文件对比仓库里的配置文件模板把缺失的字段补上。如果补完配置还是报错那就进入下一节的问题排查环节。4. 常见问题与排错实录4.1 问题速查表这一节整理我在实际更新 Alas 过程中遇到过的典型问题按表格形式列出方便大家直接对照排查。现象可能原因处理方式git pull报 uncommitted changes本地改过配置或代码工作区不干净git stash保存改动pull 后git stash poppip install找不到某个包镜像源同步延迟或者包名/版本号有变加--extra-index-url https://pypi.org/simple兜底SSL 证书校验失败某些镜像源证书不被当前环境信任在 pip 配置中加trusted-hostdocker pull长时间卡住镜像加速器失效或者拉的是第三方仓库镜像确认 registry-mirrors 地址检查docker info更新后启动报ModuleNotFoundError依赖没有同步安装跑一遍pip install -r requirements.txtGitee 镜像仓库代码很旧Gitee 导入的仓库不会自动同步去 Gitee 仓库页面手动点“同步”更新后游戏行为异常资源文件或配置模板没同步检查配置模板删除旧缓存文件本地仓库被改得乱七八糟直接在主线分支改了代码用git reset --hard回到远程版本4.2 两个容易翻车的细节第一个细节是 pip 镜像的“全局配置依赖”。很多人把 pip 镜像写进全局配置后每次安装都成功了就觉得很稳妥。但如果你换了网络环境比如从家里切换到公司内网内网通常访问不了公网镜像源这时候 pip 就会一直连接超时。遇到这种情况临时用命令行参数覆盖全局配置pip install -r requirements.txt --index-url https://pypi.org/simple --trusted-host pypi.org别嫌麻烦这比卡在超时里等十分钟强得多。第二个细节是git pull和配置文件冲突。Alas 的很多配置文件比如config/目录下的文件本身就在 git 仓库里被跟踪。你有两种选择要么把配置文件从 git 跟踪里移除改为用本地副本要么每次更新前都把配置改动 stash 起来更新后再 pop。我个人的习惯是配置文件和源码分开存放把源码目录保持纯净配置文件放到单独目录这样更新时可以直接git reset --hard完全不用怕冲突。4.3 排错思路总结排错时我习惯从底层往上层排查。先看网络层用curl测试一下镜像源地址通不通再看代码层git status确认工作区是否干净然后是依赖层直接import一下报错的模块看是没安装还是安装版本不对最后才是配置层检查配置模板和实际配置的差异。举个例子有一次更新后模拟器一直连接失败我第一反应是模拟器端口设置问题检查半天发现不是。后来用git diff看了一眼更新前后的配置文件发现新版本把 ADB 连接模式从connect改成了pair端口逻辑完全变了。这种问题只有把镜像源和代码版本对比起来看才能发现。5. 一些我踩过坑之后留下的习惯5.1 更新前先做版本快照现在每次更新 Alas我都会先记录当前 commit hash。这一步很简单git rev-parse HEAD version.txt然后把更新前能正常运行的版本号随手存起来。万一新版本出现重大问题想回退就很方便git reset --hard 之前记录的那个hash有了这个快照心里就有底了更新后就算翻车也能快速恢复不用在那干瞪眼。5.2 让镜像源“活”起来Gitee 镜像不是导一次就完事的。官方仓库每次发新版本Gitee 上的镜像不会自动跟着变需要你去手动同步。我习惯在官方仓库 release 出通告之后先去 Gitee 点一下同步按钮等同步完成再在本地拉更新。这样本地拉到的永远是最新的不会被“Gitee 仓库还停留在旧版本”这种问题坑到。如果你嫌手动麻烦可以写个简单的定时任务每天自动去 Gitee 仓库触发同步。操作不难但要注意别触发太频繁Gitee 对同步频次有些限制。5.3 保留一个纯净的本地副本我的开发机上保留了两份 Alas。一份是纯净的源码副本只用来拉更新、看日志、做对比这份目录永远保持干净不跑实际任务。另一份是实际的运行副本配置文件、账号数据都在这里。这样做的好处很明显纯净副本可以随时git reset --hard回退到任意版本脏东西不会影响主运行环境。遇到新版本 bug我在纯净副本里先测一轮确认没问题再同步到运行副本相当于多了一道保险。最后再分享一个小经验更新这件事工具是死的人是活的。镜像源只是帮你把网络这层障碍扫平真正决定更新顺不顺的是你对 Alas 更新机制的理解深度。把这套流程跑顺之后每次大版本更新我从开始到搞定基本五分钟内完成希望这篇也能让你省下那半小时干等更新的时间。
阅读完成 · 觉得有帮助?
咨询建站