Showing Posts From
Docker
GPU 租赁平台架构：Agent 节点管理、Docker 容器调度与供给冷启动
核心难点：供给而非技术 GPU 租赁平台最先需要解决的问题不是如何调度，而是为什么别人愿意把 GPU 挂到你的平台。供方需要确认：平台真的有租用需求，不会长期空跑 收益能覆盖电费和硬件损耗 提现流程可靠 机器不会被用于挖矿或违法用途Agent 节点管理（主流方案） Agent 是一个安装在供方机器上的后台进程，负责： 采集信息 ├── GPU 型号 / 显存 / 温度 ├── CPU 利用率 ├── 内存 / 硬盘 ├── 公网 IP / 带宽 ├── 在线状态 └── CUDA 版本 / 驱动版本上报到平台服务器 ↓ 控制台展示节点列表 ↓ 用户下单 → Agent 收到任务 → 启动容器Agent 还需要支持：开机自启、掉线重连、心跳保活、远程执行命令。 容器调度（Docker Worker） 大多数 GPU Marketplace 用 Docker 而非虚拟机： # 接单后自动执行 docker pull nvidia/cuda:12.0-base docker run \ --gpus all \ -p 30000:22 \ -d nvidia/cuda:12.0-base sleep infinity# 租户通过 SSH 接入 ssh user@node-ip -p 30000也可以直接暴露 Jupyter 或 ComfyUI 等界面，省去 SSH 配置。 Docker vs 虚拟机方案 优点 缺点Docker 启动快、开销小 隔离性略弱KVM/QEMU 安全隔离好 GPU 透传（PCI passthrough）配置复杂生产环境主流选 Docker，只有对安全隔离有严格要求的场景才考虑虚拟机。 闲置 GPU 共享（家用机） Agent 可以实现智能避让： def should_accept_task(): gpu_util = get_gpu_utilization() # nvidia-smi cpu_util = get_cpu_utilization() user_active = is_user_active() # 检测鼠标 / 键盘活动 return gpu_util < 10 and cpu_util < 10 and not user_active用户回来玩游戏时 Agent 自动暂停任务、释放 GPU。 计费与分润 用户支付租金 ↓ 平台抽成（通常 10~30%） ↓ 供方获得剩余收益平台抽成比例需要在"吸引供方"和"平台可持续"之间平衡。 冷启动策略 新平台面临先有鸡还是先有蛋的问题，推荐分阶段：先签稳定供方：找渲染农场、AI 创业团队、网吧（高配置机器）合作，保证第一批节点稳定在线 建控制台：展示节点状态、GPU 利用率、收益统计 实现任务调度：支持自动分配节点、启动 Docker 容器 最后开放市场：加入公开租用、计费、支付、评分系统每个阶段独立验证价值，避免同时解决供给、需求、调度、支付四个难题。
开源网盘工具对比：AList / Cloudreve / go-drive
想把 Google Drive 变成自己的网盘前端，有几款成熟的开源工具可以选。 AList（最推荐，个人使用） 定位：单用户多存储聚合，支持在线播放和分享 支持的存储后端：Google Drive、OneDrive、S3、WebDAV、阿里云盘、百度网盘等，几乎覆盖所有主流云存储。 Docker 一键部署： docker run -d \ --name alist \ -p 5244:5244 \ -v /opt/alist:/opt/alist/data \ xhofe/alist:latest初始密码： docker exec -it alist ./alist admin random特点：部署极简，资源占用极低 支持视频在线播放、图片预览 支持目录密码、分享链接 WebDAV 挂载（可接 rclone、Infuse）适合：个人云盘聚合展示，或用 WebDAV 将 Google Drive 挂载到本地工具。 Cloudreve（多用户场景） 定位：完整的网盘系统，支持用户注册和管理 比 AList 功能更重，适合做小型共享网盘站：多用户注册/管理 文件分享链接（有效期、访问次数） WebDAV 支持 离线下载（Aria2 集成） 后台管理面板 存储策略（本地/OneDrive/S3/七牛等）docker run -d \ --name cloudreve \ -p 5212:5212 \ -v /opt/cloudreve:/cloudreve/uploads \ cloudreve/cloudreve:latest适合：需要用户系统、搭建私有云盘分享站的场景。 go-drive（多云聚合） 定位：专注将多个云盘聚合成统一视图 支持：Google Drive、OneDrive、Dropbox、S3、WebDAV、本地存储。 特点：前后端分离，Docker 部署 支持直接上传到各云盘（不经过中转服务器） 断点续传适合：纯聚合需求，不需要用户系统。 功能对比功能 AList Cloudreve go-driveGoogle Drive 支持 ✅ ✅ ✅多用户 ❌ ✅ ❌离线下载 ❌ ✅ ❌视频在线播放 ✅ ✅ ✅部署复杂度 低 中 低资源占用 极低 中 低选择建议个人用：AList，Docker 部署 5 分钟搞定 小团队共享：Cloudreve，有用户管理 多云盘统一入口：AList 或 go-drive 需要离线下载：Cloudreve + Aria2Google Drive 授权配置 以 AList 为例，管理后台 → 存储 → 添加 → Google Drive：在 Google Cloud Console 创建 OAuth 2.0 凭据 填入 Client ID 和 Client Secret 点击授权，完成 OAuth 流程 授权后即可访问 Google Drive 的全部内容注意：Google Drive API 有每日配额限制（默认 100 次/秒、每日 10 亿次查询），个人使用基本不会触及。
Docker 里配代理：容器运行时和 build 阶段的正确写法
一份 docker-compose.yml，改造成让容器 和 构建过程都能走代理，看起来简单，实际上分两层——很多人只加了一层就以为好了。 场景一：容器运行时走代理 只要在 environment 里加 4 个变量（大小写都写一份最保险）： services: web: build: context: . dockerfile: Dockerfile environment: http_proxy: http://host.docker.internal:7890 https_proxy: http://host.docker.internal:7890 HTTP_PROXY: http://host.docker.internal:7890 HTTPS_PROXY: http://host.docker.internal:7890 extra_hosts: - "host.docker.internal:host-gateway"host.docker.internal 是宿主机地址（Mac / Windows 原生支持） Linux 需要显式声明 extra_hosts——不然容器里根本不认这个名字宿主机上代理是 Clash / v2ray，默认端口通常 7890。用之前先在宿主机测： curl -x http://127.0.0.1:7890 https://www.google.com场景二：build 阶段也要走代理 environment 只影响运行时。build 阶段 apt install、git clone、pecl 这些走的还是宿主机网络。要让它们也走代理，得从 args 传进去，再在 Dockerfile 里 ARG + ENV。 docker-compose.yml： services: web: build: context: . dockerfile: Dockerfile args: http_proxy: http://host.docker.internal:7890 https_proxy: http://host.docker.internal:7890 extra_hosts: - "host.docker.internal:host-gateway"Dockerfile 顶部： FROM php:7.4-apacheARG http_proxy ARG https_proxyENV http_proxy=$http_proxy ENV https_proxy=$https_proxy ENV HTTP_PROXY=$http_proxy ENV HTTPS_PROXY=$https_proxy# 之后所有 apt / curl / git / composer 都会走代理写在最前面很重要——ENV 只对后续 RUN 生效。 Linux 老坑：host.docker.internal 不通 Linux 上 host.docker.internal 默认解析不了。有两种解法： 推荐：extra_hosts + host-gateway extra_hosts: - "host.docker.internal:host-gateway"这是 Docker 20.10+ 的标准写法，比手动填 IP 稳。 兜底：用 docker0 网桥 IP environment: http_proxy: http://172.17.0.1:7890前提是宿主机代理监听 0.0.0.0 或者 172.17.0.1——只监听 127.0.0.1 是不行的。 构建后清掉代理（可选） 代理只用于 build 阶段，不希望被镜像继承的话： FROM baseARG http_proxy ARG https_proxyENV http_proxy=$http_proxy https_proxy=$https_proxy RUN apt-get update && apt-get install -y curl git# 用完就抹掉 ENV http_proxy= https_proxy= HTTP_PROXY= HTTPS_PROXY=镜像跑起来后就不会带代理设置了。 一句话总结 environment 只管跑起来之后，build 阶段的代理要靠 args + ARG + ENV。Linux 上别忘 extra_hosts: host-gateway。
Docker Compose 容器内配置 HTTP 代理：environment 变量与 host.docker.internal
Docker 容器不会自动继承宿主机的代理设置，容器内部访问外网需要显式注入代理环境变量。 在 docker-compose.yml 中注入代理 在需要走代理的服务 environment 中添加： services: web: image: nginx:latest environment: http_proxy: http://172.17.0.1:7890 https_proxy: http://172.17.0.1:7890 HTTP_PROXY: http://172.17.0.1:7890 HTTPS_PROXY: http://172.17.0.1:7890 NO_PROXY: localhost,127.0.0.1,172.17.0.0/16同时写大写和小写两种形式，因为不同程序读取的环境变量名不一致（curl/wget 读小写，Java/Python 可能读大写）。 Linux 宿主机代理地址 Linux 下 Docker 默认网桥 IP 是 172.17.0.1，容器内可以用它访问宿主机上运行的代理： # 先在宿主机验证端口可达 curl 172.17.0.1:7890更推荐的写法是用 host-gateway，语义更清晰且不依赖具体网桥 IP： services: web: extra_hosts: - "host.docker.internal:host-gateway" environment: http_proxy: http://host.docker.internal:7890 https_proxy: http://host.docker.internal:7890host.docker.internal 在 macOS/Windows 的 Docker Desktop 中默认可用，Linux 需要通过 extra_hosts 手动映射。 Dockerfile 构建阶段代理 environment 只对运行中的容器生效，docker build 阶段（apt install、pip install、git clone）需要在 Dockerfile 里设置： FROM ubuntu:24.04ENV http_proxy=http://host.docker.internal:7890 ENV https_proxy=http://host.docker.internal:7890RUN apt-get update && apt-get install -y curl或者构建时通过 --build-arg 传入（更灵活，不会写死到镜像层）： ARG http_proxy ARG https_proxy RUN apt-get update && apt-get install -y curldocker build \ --build-arg http_proxy=http://172.17.0.1:7890 \ --build-arg https_proxy=http://172.17.0.1:7890 \ -t myimage .常见问题 容器外能上网，容器内不行 → 忘记设置 environment 代理变量。 代理地址用 127.0.0.1 不通 → 容器的 127.0.0.1 指向容器本身而非宿主机，必须用 172.17.0.1 或 host.docker.internal。 https_proxy 写成 https:// → 代理地址的 scheme 必须用 http://，即使是 HTTPS 流量也一样： HTTPS_PROXY=https://... ← 错误 HTTPS_PROXY=http://... ← 正确
tomcat:7.0-jre7 镜像不存在了？三条替代路
抄一份老教程写 Dockerfile： FROM tomcat:7.0-jre7Error response from daemon: manifest for tomcat:7.0-jre7 not found不是拼错了——Docker Hub 官方镜像库把老 tag 清掉了，尤其 Java 7 / Tomcat 7 / 旧 Debian 基础镜像这些 EOL 很久的组合。 现状 Docker Hub 上现在能拉到的 Tomcat 7： docker pull tomcat:7.0.109-jdk8 # 最后一个 7.x + JDK 8 docker pull tomcat:7.0.109-jdk8-openjdk docker pull tomcat:7.0.103 # 老一点的备选拉不到的：所有 -jre7 tag。Java 7 的 openjdk 基础镜像早就下架，官方 tomcat 镜像自然也不能再基于它构建。 方案一：换用 JDK 8（推荐） 绝大多数 Servlet 2.5 项目 JDK 8 兼容良好： FROM tomcat:7.0.109-jdk8COPY target/myapp.war /usr/local/tomcat/webapps/ROOT.warEXPOSE 8080 CMD ["catalina.sh", "run"]大多数老项目这样跑就好。只有极少数依赖 Java 7 特有行为的（比如 SSL cipher 顺序、某些反射细节），才需要坚持 Java 7。 方案二：自己构建 JRE 7 + Tomcat 7 镜像 必须坚持 Java 7 的情况，自己拼一个。Alpine 有历史包： FROM alpine:3.10# Java 7 需要 32-bit 兼容层 RUN apk add --no-cache openjdk7-jre wget tarENV TOMCAT_VERSION=7.0.109 ENV CATALINA_HOME=/usr/local/tomcat ENV PATH=$CATALINA_HOME/bin:$PATHRUN wget -q https://archive.apache.org/dist/tomcat/tomcat-7/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz \ && tar -xzf apache-tomcat-${TOMCAT_VERSION}.tar.gz -C /usr/local \ && mv /usr/local/apache-tomcat-${TOMCAT_VERSION} $CATALINA_HOME \ && rm apache-tomcat-${TOMCAT_VERSION}.tar.gzEXPOSE 8080 CMD ["catalina.sh", "run"]Alpine 3.10 的 openjdk7-jre 包还能装。更新的 Alpine 都下架了 Java 7。 或者用 Eclipse Temurin 归档（Adoptium 前身）： FROM eclipse-temurin:7-jre-focal但目前 Adoptium 也不再维护 7.x 镜像，能拉到什么看运气。 方案三：第三方社区镜像 Docker Hub 上有些几年没维护的社区镜像还挂着： docker pull consol/tomcat-7.0这个镜像里是 Tomcat 7 + OpenJDK 7。缺点：9 年没更新，安全性堪忧 只适合内网 / 本地测试 生产用必须盯着 CVE我的推荐路线 按业务需求排序：能升 JDK 8 就直接升——tomcat:7.0.109-jdk8，80% 情况没兼容问题 必须 Java 7 且是内网/开发环境——用 Alpine 自建 Dockerfile 老 DSpace / 学术软件之类死绑 Java 7 的项目——尝试 consol/tomcat-7.0 或者自己拼迁移信号 看到这些错误就是要升级 JDK 了： Unsupported major.minor version 52.0 # class 是 JDK 8 编译的，JRE 7 跑不了反过来： Unsupported major.minor version 51.0 # class 是 JDK 7 编译的，JRE 6 跑不了老 JAR 里 class 版本对应表：Java 版本 class versionJava 6 50Java 7 51Java 8 52Java 11 55Java 17 61Java 21 65一句话总结 tomcat:7.0-jre7 已经从官方镜像库消失。首选 tomcat:7.0.109-jdk8，非要 Java 7 就自己拼 Alpine 镜像，社区镜像只做兜底。
Docker 拉镜像报 proxyconnect tcp: EOF 的正确解法
宝塔面板上一键部署一个项目，卡在拉镜像那步： Image mysql:8.2 Error Get "https://registry-1.docker.io/v2/": proxyconnect tcp: EOF Error response from daemon: Get "https://registry-1.docker.io/v2/": proxyconnect tcp: EOF关键词是 proxyconnect tcp: EOF——Docker 通过代理连 Docker Hub 时握手就断了。不是网络挂了，是代理配置有问题。 第一步：看 Docker 是不是走代理 docker info | grep -i proxy如果看到类似： HTTP Proxy: http://127.0.0.1:7890 HTTPS Proxy: http://127.0.0.1:7890说明 Docker daemon 被配了代理。接着验证代理是不是能用： curl -x http://127.0.0.1:7890 https://registry-1.docker.io/v2/返回 {} 或认证提示：代理正常 EOF / timeout：代理进程挂了 Connection refused：代理端口没开三个典型场景系统开了 Clash/v2ray，但 Docker daemon 拿不到——Docker 不会自动继承桌面代理，Mac 上尤其容易踩。 代理协议写错——把 http://127.0.0.1:7890 写成了 https://，直接握手失败。 代理软件本身抽风或被墙——重启一下代理再试。解决办法 方案一：临时不走代理 先确认到底是不是代理的锅： unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY docker pull redis:latest拉得下来就是代理问题，不用再折腾 Docker 本身了。 方案二：配国内镜像源（推荐） 编辑 daemon 配置： sudo mkdir -p /etc/docker sudo nano /etc/docker/daemon.json写入： { "registry-mirrors": [ "https://dockerproxy.com", "https://mirror.ccs.tencentyun.com", "https://registry.docker-cn.com" ] }重启： sudo systemctl daemon-reexec sudo systemctl restart docker再拉镜像基本就通了。注意公开镜像源可用性经常变化，实在拉不下来就换一个。 方案三：正确给 Docker 配代理 如果确实需要走代理，别改环境变量，改 systemd 单元： sudo mkdir -p /etc/systemd/system/docker.service.d sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf写入： [Service] Environment="HTTP_PROXY=http://127.0.0.1:7890" Environment="HTTPS_PROXY=http://127.0.0.1:7890" Environment="NO_PROXY=localhost,127.0.0.1"然后： sudo systemctl daemon-reload sudo systemctl restart docker一句话总结 proxyconnect tcp: EOF = Docker 正在走一个 坏掉的代理。先 unset 代理确认锅在哪儿，然后要么配国内镜像源，要么正确写 systemd 代理配置。
Docker 镜像拉取失败：proxyconnect tcp EOF 与国内镜像源配置
proxyconnect tcp: EOF 这个错误不是 Docker Hub 故障，而是 Docker daemon 正在使用一个不可达的代理。 快速诊断 # 查看 Docker 是否配置了代理 docker info | grep -i proxy# 查看环境变量 env | grep -i proxy如果看到： HTTP Proxy: http://127.0.0.1:7890说明 Docker 正在走代理，需要验证代理是否可用： curl -x http://127.0.0.1:7890 https://registry-1.docker.io/v2/返回 {} 或认证信息 → 代理正常 EOF / timeout → 代理链路断了 Connection refused → 代理未启动方案一：清除代理环境变量（临时） unset http_proxy unset https_proxy unset HTTP_PROXY unset HTTPS_PROXYdocker pull redis:latest如果此时能拉成功，说明就是代理问题。 方案二：配置国内镜像源（推荐） sudo mkdir -p /etc/docker sudo nano /etc/docker/daemon.json写入： { "registry-mirrors": [ "https://mirror.ccs.tencentyun.com", "https://registry.docker-cn.com" ] }然后重启： sudo systemctl daemon-reexec sudo systemctl restart docker验证： docker info | grep -A5 "Registry Mirrors"方案三：正确配置 Docker daemon 使用代理 Docker 不会自动读取系统代理（即使浏览器能上网），需要单独配置： sudo mkdir -p /etc/systemd/system/docker.service.d sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf写入： [Service] Environment="HTTP_PROXY=http://127.0.0.1:7890" Environment="HTTPS_PROXY=http://127.0.0.1:7890" Environment="NO_PROXY=localhost,127.0.0.1"注意：代理地址必须用 http://，不能写 https://： HTTPS_PROXY=https://127.0.0.1:7890 ← 错误 HTTPS_PROXY=http://127.0.0.1:7890 ← 正确重新加载： sudo systemctl daemon-reload sudo systemctl restart docker常见坑 Docker 不继承系统代理：Clash/sing-box 开了，Docker 仍然无法自动使用，必须显式配置 /etc/systemd/system/docker.service.d/http-proxy.conf。 proxyconnect tcp: EOF 和 connection refused 的区别：EOF → 代理在监听但链路断了（软件崩溃、配置错误） refused → 代理根本没有在对应端口监听