Docker 构建报错：绕过 ghcr.io 解析失败问题

Jul 22, 2025

Ollama

Open-LLM-VTuber Ollama Qwen 2.5 Sherpa-Onnx Edge-TTS

在搭建 Open-LLM-VTuber 执行 docker-compose up --build 时，出现 lookup ghcr.io: no such host 报错。

表现

测试宿主机执行 docker pull alpine 正常，说明外部 Docker 引擎连网没问题。报错发生在 Dockerfile 第 19 行，这意味着 Docker 在内部沙盒编译镜像时，虚拟 DNS 无法解析 ghcr.io 的真实 IP。国内网络环境下，GitHub 相关的容器镜像库常遭遇 DNS 阻断。

处理 Docker 虚拟机的 resolv.conf 比较麻烦且容易失效。直接改 Dockerfile 源码绕过 GHCR 源是更稳妥的做法。

问题分析

原项目 Dockerfile 第 19 行左右代码如下：

# Install uv
COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /usr/local/bin/

代码引入了 uv 包管理器来加速安装过程，采用的方式是从 ghcr.io 拉取编译好的二进制文件。既然 Docker 沙盒访问 PyPI 官方库正常，把这步替换成原生的 pip 安装即可。

修改方案

打开源码目录下的 Dockerfile。
找到并注释（或删除）依赖拉取代码：

# COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /usr/local/bin/

替换为标准的 pip 安装命令：

# Bypass GHCR and install uv directly via pip
RUN pip install uv

重新触发编译：

docker-compose up --build

执行后日志会跳过 GHCR 的拉取过程，直接打印 pip 下载依赖的进度条，编译链路打通。

Windows 系统的底层路径解析将 https:// 误认为了本地盘符导致构建崩溃；最彻底的解法是手动 git clone 项目源码到本地，并将 Docker 配置文件指向该本地目录进行构建。

步骤 1：手动将数字人源码克隆到本地

确保你当前在 F:\work_space\python_workspace\AIRI_Project 目录下执行：

# 使用 Git 将源码克隆到名为 "npc_engine" 的子文件夹中
git clone https://github.com/Open-LLM-VTuber/Open-LLM-VTuber.git npc_engine

步骤 2：修改为“纯本地引用”的配置文件

清空你的 docker-compose.yml，替换为以下配置。注意看 build: context: 的变化，它现在指向了刚刚下载的本地文件夹。

services:
  magic-witch-npc:
    build:
      # 【核心更改】直接指向刚刚 git clone 下来的本地源码目录
      context: ./npc_engine
    container_name: magic_witch_container
    ports:
      - "8000:8000"
      - "3000:3000"
    environment:
      - LLM_PROVIDER=openai
      - OPENAI_API_KEY=你的DEEPSEEK_API_KEY_填这里
      - OPENAI_BASE_URL=https://api.deepseek.com/v1
      - LLM_MODEL=deepseek-chat
      - TTS_ENGINE=edge-tts
    volumes:
      # 将 F 盘外部的模型挂载到刚编译好的容器中
      - ./models/witch:/app/live2d_models/witch
    restart: always

步骤 3：最终本地构建与点火

执行以下命令

# 强制基于本地源码进行容器构建并后台运行
docker-compose up -d --build

# 实时查看构建进度与启动日志
docker-compose logs -f