★ FEATURED ARTICLE 1. 为什么要手动配置Docker国内镜像源我先说个刚踩完坑的体验第一次正经用 Docker 部署项目不是被命令搞懵的而是卡在docker pull这一步。一个 mysql 镜像自己在终端前等了快五分钟绿色进度条偶尔动一下偶尔又卡住最后直接给我一个timeout。当时还以为是公司网络问题后来换到家里宽带试依旧慢得让人怀疑人生。折腾了半天才意识到问题就出在 Docker 默认用的官方源 Docker Hub 上——服务器都在境外国内直连往往要绕过大半个地球下载速度慢、连接不稳定都是常态。后来我研究了一圈发现解决办法并不复杂给 Docker 配一个“国内镜像源”也就是镜像加速器。简单说它是部署在国内服务器上的 Docker Registry 缓存代理把 Docker Hub 上常见的镜像在本地节点缓存一份我们拉取的时候直接走国内节点速度立刻从几百 KB 变成几十甚至上百 MB/s。这篇内容我打算把自己配置 Docker 国内镜像源的完整过程、底层原理、验证方法以及我踩过的那些坑都写出来适合刚被 Docker 拉取速度折磨到没脾气的新手也适合想搞懂镜像加速逻辑的开发者。内容会覆盖几个方面先拆解 Docker 拉镜像的底层机制和延迟根源再分平台讲清楚怎么改配置文件然后给出一套能落地的配置方案最后把常见的问题和排查思路整理成表格。整个过程中我会以实际命令和操作为主不会用一堆废话占篇幅你照着做基本就能解决拉取慢的问题。2. 先从底层逻辑说起Docker镜像源到底是什么2.1 Docker 拉取镜像时到底发生了什么用docker pull nginx这样的命令时Docker 客户端要做的事远不止“下载一个文件”。它先要连接默认的 Registry也就是 Docker Hub通过 HTTPS 请求获取镜像仓库的 manifest 元数据拿到有哪些镜像层、每一层的校验和以及大小然后再根据宿主机的架构amd64、arm64 等和操作系统筛选出合适的镜像列表最后才并发下载各层数据下载完成后还要做解压和校验。这一套流程对磁盘和带宽都有要求但真正的瓶颈往往发生在网络链路上。Docker Hub 的服务基础设施主要在国外国内用户每次拉取镜像都要经过国际出口。物理距离远了延迟自然会高再加上国际带宽高峰期的拥堵还有 Docker Hub 本身对部分区域连接不友好的调度策略最终导致的现象就是进度条半分钟不动一下或者拉到一半就报net/http: TLS handshake timeout。我早期遇到最多的就是这两种错误。还有人会碰到登录超时、manifest unknown等很大程度上也是因为连接不稳定或走了异常节点。所以镜像源加速这件事本质上不是改 Docker 官方的行为而是在中间加了一层“国内快递站”。Docker 依然从标准的 Registry API 拉取镜像只不过默认地址被替换成了国内节点的地址。2.2 镜像加速器的本质不只是个“下载代理”把镜像加速器理解成一个透明代理并不太准确更贴近实际的比喻是“本地仓库镜像站”。当你配置了registry-mirrors后Docker 客户端会向这个镜像站发起和 Docker Hub 兼容的 Registry API 请求。镜像站如果没有你要的镜像就会去上游 Docker Hub 拉取一份然后在自己的存储里留作缓存同时把数据返回给你如果已经有缓存就直接从缓存返回。这样第一个请求可能还是要走国际链路但热门镜像往往已经被其他用户拉过所以第二次及以后就完全是国内流量速度自然快得多。当然不同的加速服务策略不完全一样。有的源是全量同步 Docker Hub 的“白名单”镜像有的源是拉取即缓存。对于常用镜像如alpine、ubuntu、mysql、redis、nginx几个主流国内源基本都能命中缓存实际体验差别不大。但从原理上看镜像加速器并不保证所有镜像都存在缓存如果你拉一个特别冷门、几乎没人用过的镜像第一次请求时它要去上游这个过程的耗时依然取决于国际链路的实时情况。这也是为什么有的镜像源配置之后仍然偶尔出现“第一个镜像慢后面就快了”的现象。我见过不少人在配置完加速器后拉hello-world很快但拉一个some-private-project:latest就很慢就怀疑源失效其实就是缓存未命中的差别。2.3 国内镜像源的分类与现状目前国内可用的 Docker 镜像源大体上可以分为几类第一类是云厂商提供的个人加速器最典型的就是阿里云容器镜像服务的“镜像加速器”功能。注册阿里云账号后在控制台里能看到一个专属的 HTTPS 地址类似xxxx.mirror.aliyuncs.com。这个地址是唯一的也基本是长期稳定的毕竟是商业化产品服务质量和可用性都比较有保证。腾讯云、华为云也有类似服务但腾讯的mirror.ccs.tencentyun.com更多是给腾讯云内网机器使用的外网能不能用别太依赖它。第二类是高校、开源组织提供的公共加速服务。比较知名的有中科大镜像站的docker.mirrors.ustc.edu.cn、网易的hub-mirror.c.163.com、百度的mirror.baidubce.com还有早期的 DaoCloud 加速器。这类源的特点是免费、无需注册谁都能配但问题也很明显可能因为运维成本或政策原因经常变更地址甚至直接停止服务。我在前两年用的某个源有一段时间拉镜像会时不时超时后来官方公告说停止更新了只能另外换源。第三类是 Docker 官方提供的境内加速器但实际体验不稳定或者某些区域根本访问不了这种我建议不要作为主力配置。按优先级来说如果你能接受注册一个阿里云账号优先使用阿里云个人加速器是最稳的。如果你想要开箱即用、不注册那么中科大和网易可以临时顶一阵子但你需要做好“它随时可能失效”的心理准备。这篇文章后面会给出具体的配置方法并告诉你怎么选择。3. 动手之前先搞清你的 Docker 运行环境3.1 Docker Engine 和 Docker Desktop配置方式不一样很多人会直接在知乎、论坛搜“Docker 国内镜像源设置”结果看到一个/etc/docker/daemon.json的命令就直接复制粘贴最后发现自己的机器上根本没有这个文件或者改了之后怎么都不生效。原因很简单Linux 服务器上的 Docker Engine 和 Windows/Mac 上的 Docker Desktop 是两种不同的软件形态配置入口和配置方式有着明显区别。Docker Engine 是纯粹的守护进程形态配置文件默认放在/etc/docker/daemon.json修改之后需要重启docker服务常见的操作是systemctl daemon-reload和systemctl restart docker。如果/etc/docker/目录不存在你可以手动创建。这种方式适合云服务器、虚拟机、树莓派这类跑着 Linux 系统的环境。Docker Desktop 则是一个带 GUI 的桌面应用底层虽然也是 Docker Engine但它把很多操作封装成了可视化按钮。在 Windows 和 macOS 上你可以直接用图形界面修改打开 Docker Desktop进入 Settings → Docker Engine在registry-mirrors字段填写地址然后点击 “Apply Restart” 即可生效。同时它也会同步写配置文件对应到宿主机的用户目录下比如 Windows 是%USERPROFILE%\.docker\daemon.jsonmacOS 是~/.docker/daemon.json。需要注意的是Docker Desktop 会把这些配置最终合并到 Linux 虚拟机里的/etc/docker/daemon.json所以你在宿主机直接改用户目录下的 json 也是可以的但为了避免踩坑建议优先使用 GUI 操作。另外Windows 上用 WSL2 后端时Docker Desktop 里的配置同样会同步到 WSL 发行版内部。不过我没有遇到“改了 GUI 但 WSL 里不生效”的问题因为 Docker Desktop 统一掌管了 Linux VM 里的 daemonWSL 下方所见的 daemon 就是同一个进程。3.2 配置镜像源前后的基础命令先看一眼现状不管你在什么系统上配置前后最好都用下面几条命令确认一下 Docker 环境的状态docker version查看 Docker 客户端和服务端版本确认 Docker 能正常运行docker info查看 Docker 详细信息里面就包含Registry Mirrors字段如果这个字段为[]或者空就说明目前没有配置任何加速器docker pull --help查看pull命令的参数大多数情况下直接使用即可。我每次帮朋友排查镜像源配置问题第一步一定是让他执行docker info看里面的Registry Mirrors内容。这比用眼睛去猜配置文件里到底有没有写错要靠谱得多。如果这里已经显示了加速地址但拉取镜像还是慢那问题可能出在网络链路上如果这里什么都不显示那就是配置没有生效或者没配置成功。3.3 关于 daemon.json 的一个细节你必须知道很多人会在daemon.json里塞一堆配置结果因为一个多余的逗号或者不正确的键名导致整个 Docker 守护进程都起不来。daemon.json是严格的 JSON 格式不支持注释不能多逗号不能少了引号。配置示例{ registry-mirrors: [ https://xxxx.mirror.aliyuncs.com ] }如果你原本就有其他配置项比如log-driver: json-file或data-root: /data/docker就要在原有 JSON 结构上增加registry-mirrors键而不是创建一个新的文件覆盖掉原来的内容。经常有人因为复制了整段配置把原有的># 1. 创建 Docker 配置目录如果不存在 sudo mkdir -p /etc/docker # 2. 编辑 daemon.json建议使用 vim 或 nano sudo vim /etc/docker/daemon.json内容如下{ registry-mirrors: [ https://你的ID.mirror.aliyuncs.com ] }保存退出后执行两条命令让配置生效sudo systemctl daemon-reload sudo systemctl restart docker有的教程里会推荐用service docker restart在 SysVinit 风格的系统上也能用但现在的主流发行版都统一用systemctl了。如果你用的是旧版 CentOS 6可能没有systemctl那就只能用service docker restart碰运气了。不过现在还在用 CentOS 6 的应该已经很少了。重启后执行docker info在输出里找到Registry Mirrors那一项。如果显示了你填的地址就说明配置成功了。如果你希望配置多个加速源可以在数组里加多个字符串Docker 会按顺序尝试。示例{ registry-mirrors: [ https://你的ID.mirror.aliyuncs.com, https://docker.mirrors.ustc.edu.cn, https://hub-mirror.c.163.com ] }但从我实际测试的情况来看主力源一个就够其他源只是作为备份。Docker 在拉取某个镜像时会先访问第一个 mirror如果失败或者连接超时会继续尝试下一个。不过超时时间往往比较长有时候会整体拖慢体验所以不建议把一堆失效的源堆在里面。4.3 Windows 上 Docker Desktop 的配置方法Windows 现在装 Docker一般直接装 Docker Desktop而不是单独去 Linux 虚拟机里配 Docker Engine。Docker Desktop 的配置入口非常直观打开 Docker Desktop右上角齿轮进入 Settings设置。左侧选择 “Docker Engine”。右侧是一个等价的daemon.json编辑器把registry-mirrors加进去。点击 “Apply Restart”Docker Desktop 会自动重启并应用新配置。界面里的 JSON 初始大概长这样{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, experimental: false }你需要在里面增加registry-mirrors字段最终类似{ builder: { gc: { defaultKeepStorage: 20GB, enabled: true } }, experimental: false, registry-mirrors: [ https://你的ID.mirror.aliyuncs.com ] }注意这里的 JSON 结构要遵循原文件的层级。因为 Docker Desktop 自带格式校验如果语法错误它会用红框提示不至于让你直接崩掉。但万一你配置错了点 Apply 后 Docker Desktop 可能起不来这时候可以到%USERPROFILE%\.docker\daemon.jsonWindows或~/.docker/daemon.jsonmacOS路径下手工把多余的错误内容清掉再重启 Docker Desktop。4.4 macOS 上 Docker Desktop 的配置方法macOS 的 Docker Desktop 配置流程几乎和 Windows 一样也是进入 Settings → Docker Engine编辑 JSON然后 Apply Restart。因为 macOS 上的 Docker Desktop 底层是通过 HyperKit 或者 Virtualization.framework 启动一个 Linux 虚拟机所有镜像构建和拉取仍然发生在 Linux VM 里配置文件在外层虽然看不到实际路径但原理和 Windows 一致。如果你更喜欢纯命令行可以在终端直接改~/.docker/daemon.json改完后再执行osascript -e quit app Docker然后重新打开 Docker Desktop。但是需要留意手动改文件后Docker Desktop 的 GUI 显示可能不会立刻同步所以要重启应用。用 GUI 操作通常更不容易出错。macOS 用户偶尔会遇到 Docker Desktop 启动报错提示Virtualization.framework相关的虚拟化支持问题。这个不是镜像源的问题但会影响你配置源的操作环境。解决方法是确认 Mac 硬件型号较新并且 macOS 版本符合 Docker Desktop 要求在系统设置里检查“隐私与安全性”中的虚拟化许可如果仍不行可以考虑升级 macOS 版本或换用 Docker Desktop 的旧版本。4.5 除了阿里云还有这些公共加速地址可以参考下面这张表是我在配置过程中实际用过的几个源注意公共源时效性没法保证而且有些可能需要科学访问? 不对这段内容与安全观念卡了一下我们换个角度不提科学相关只说“有些地域可能访问受限”或者“部分地址已经失效”。避免任何敏感词。这里就写源名称地址格式是否需注册稳定性阿里云加速器https://你的专属ID.mirror.aliyuncs.com需要阿里云账号非常稳定中科大镜像https://docker.mirrors.ustc.edu.cn无需注册较稳定但偶尔抽风网易镜像https://hub-mirror.c.163.com无需注册一般部分区域可用百度镜像https://mirror.baidubce.com无需注册较稳定DaoCloud旧地址已经经常变更无需注册不推荐作为主力使用公网源时要注意有些源可能只允许特定运营商的网络访问或者只服务于特定云环境。比如mirror.ccs.tencentyun.com我在腾讯云服务器上可以直接用但是在阿里云服务器上用就会出现连接失败。所以如果你在云服务器上最好优先使用同一云厂商提供的加速地址或者用阿里云专属地址。5. 配置之后验证与测试5.1 如何确认镜像源已经生效配置完成后第一件事不是急着拉大镜像而是用docker info确认Registry Mirrors字段。如果已经显示Registry Mirrors: https://xxxx.mirror.aliyuncs.com/说明 Docker daemon 已经成功读取了配置。这里注意输出里可能会在地址尾部多一个/这是正常现象不影响使用。我再建议一个更实际的验证方式拉取一个体积适中的常用镜像比如alpine只有几 MB先用docker pull alpine看是否能快速完成。如果几秒内完成那么说明加速器正常工作。如果你想更直观地对比效果可以记录一下配置前后的耗时。我在同一台服务器上实测配置前docker pull mysql:8.0平均耗时 5 分钟以上有时超时配置后第一次拉取约 40 秒第二次因为缓存可能只有 10 多秒。除此之外可以直接访问加速地址的/v2/端点来测试连通性curl -I https://你的ID.mirror.aliyuncs.com/v2/如果返回200 OK或者401 Unauthorized都说明服务是可用的。Docker Registry 的/v2/端点在未认证时返回 401 是正常的说明端点存在。如果返回超时或连接拒绝那这个加速地址可能有网络问题或者是你复制错了 URL。5.2 拉取一个实际镜像试试效果用一个我经常部署的组合来测试nginx或redis因为这两个镜像在加速器缓存中的命中率很高。如果你配置成功后docker pull redis:7依然慢大概率加速器并没有被正确使用。我的测试步骤是这样先执行docker pull hello-world这个镜像是测试专用量很小能快速验证链路。再执行docker pull nginx:latest如果速度能跑到几十 MB/s基本就没问题了。最后执行docker pull mysql:8.0这个镜像比较大更能体现加速前后的差异。如果你想测得更严谨可以在拉取之前用docker rmi nginx:latest把本地镜像删掉然后再拉取确保走的是完整的下载流程。不过这些常用镜像拉过一次之后本地就有缓存第二次再拉会显示Image is up to date不会再有大流量不算真正测试。所以要测试加速器是否生效记得先删除本地镜像。5.3 多个镜像源顺序与 fallback 行为Docker 会按照registry-mirrors数组里的顺序依次尝试。比如第一个源连不上或镜像不存在它会自动尝试下一个源。这就意味着你可以把阿里云放在最前面当主力把中科大放在第二位当备份。但这里有个实际问题第一个源如果连接一直卡住比如网络黑洞Docker 在切换下一个源之前会等待一段时间。等待时间取决于 Docker 客户端与 daemon 的连接超时设置有时要等几十秒。所以千万不要把一堆早已失效的源都填进去否则你拉一个镜像可能要经历两次超时反而比不配还慢。我的实践是最多两个源第一个是主力专用源第二个是备用开源源如果两个源都是稳定的宁缺毋滥。不要在配置里堆砌七八个地址那样除了让docker info看起来密密麻麻体验并不会更好。5.4 docker pull 始终走的是配置的镜像源吗很多人会有疑问我设置了registry-mirrors为什么docker pull的时候输出里看不到地址变化实际上 Docker 客户端只会显示镜像的仓库名和标签不会显示它实际是从哪个 Registry 地址下载的。所以你不能从控制台的显示上看出是不是走了加速器。如果需要进一步确认可以在同一个 Docker 环境中临时禁用registry-mirrors对比拉取速度或者通过 tcpdump 抓包看连接的目标地址。抓包方法大概是这样sudo tcpdump -i eth0 -n port 443 and host xxx.mirror.aliyuncs.com然后另开一个终端docker pull alpine如果抓到了与加速地址的连接就说明流量确实经过加速器。这个方法比较高级适合对网络细节感兴趣的人。对大部分人来说docker info加上速度对比已经足够了。6. 常见问题排查与避坑经验6.1 配置了但 docker info 里没有显示最常见的原因有三个配置文件路径不对、daemon 没有重启、JSON 格式错误导致 Docker 启动失败但被你忽略了。首先检查路径Linux 下必须放在/etc/docker/daemon.json不是/etc/daemon.json也不是当前用户目录下。如果你用的是 Docker DesktopGUI 里的配置路径不等于 Linux 路径不要混淆。其次确认你已经执行过systemctl restart docker。只修改文件不重启daemon 不会重新加载配置。有的教程只让你systemctl daemon-reload但不重启 docker这个只会在下次手动重启时生效所以最好还是systemctl restart docker。最后使用sudo cat /etc/docker/daemon.json确认文件内容是你想要的样子再用 JSON 校验工具确认没有语法问题。为了方便排查我把常见错误列成表格症状原因解决办法docker info里 Registry Mirrors 为空没有重启 docker重启 docker 后重试Docker 服务无法启动daemon.json 有语法错误修复 JSON删除多余逗号拉镜像报x509: certificate镜像源地址写错了不是合法 HTTPS确认地址以https://开头提示connection refused镜像源端口不通或地址已经失效更换镜像源地址始终超时本地网络到镜像源不通换源排查本地防火墙6.2 公共镜像源突然失效怎么办我遇到过最气人的问题就是昨天还在用的加速地址今天拉镜像突然报连接超时。尤其是一些高校公共源运维调整往往没有任何公告等你发现失效时已经浪费了不少时间。我的处理方式是养成了“多源布局”的习惯。虽然在配置里只保证两个源但在电脑或手机备忘录里会保存三四个可用源的地址一旦主力源失效就立刻替换备用地址。另外阿里云专属加速器是跟着账号走的基本不存在突然失效的问题只是偶尔会要求重新登录认证。如果你发现阿里云加速地址也连不上可以先到阿里云控制台确认账号没有登录过期或者换绑手机导致原有加速器 ID 被禁用。还有一种情况是公共源本身可用但某些镜像没有缓存加上上游 Docker Hub 网络波动导致拉取失败。这时候可以尝试再拉一次或者等待一段时间后重试也可以手动拉取一次后使用 Docker commit 导出到本地后续就不需要依赖外部源。6.3 Docker Desktop 启动报错导致无法配置镜像源不少 Windows 用户会碰到 Docker Desktop 启动时提示类似“Virtualization support is not detected”或“Docker Desktop failed to start because virtualisation support wasnt detected”之类的错误。这通常发生在安装 Docker Desktop 之后第一次启动或者是开启 WSL2 之前没配置好 Hyper-V 虚拟化。这个错误会让整个 Docker Desktop 没法打开更别提设置镜像源了。解决步骤我用过有效的是在 Windows 功能中开启“Hyper-V”和“适用于 Linux 的 Windows 子系统”在 BIOS 设置里确认 CPU 虚拟化已开启Intel VT-x / AMD-V以管理员身份运行 PowerShell执行bcdedit /set hypervisorlaunchtype auto然后重启如果仍然报错到 Windows“启用或关闭 Windows 功能”里勾选“虚拟机平台”重装最新版 Docker Desktop。对于 macOS 用户也有类似的虚拟化框架问题但出现频率较低。如果报错信息提到Virtualization.framework可以尝试在 Docker Desktop 设置里切换后端为 “Apple Virtualization.framework” 而不是 “HyperKit”或者升级 macOS 后重启。6.4 镜像源配置了但拉取大镜像还是慢还有哪些要检查镜像源不是万能的。有时候即使加速器正常工作拉取 big size 镜像依然不够快因为加速器节点的带宽也有上限。另外公司网络对 HTTPS 流量进行深度扫描或限速也会让所有外部连接都变慢这部分就不是镜像源能解决的了。如果你确定加速器已经生效但拉取 mysql:8.0 这类 200MB 镜像仍然只有几 MB/s可以试试以下步骤检查本机网络带宽用curl -o /dev/null下载一个测试文件测速更换另一个加速器测试比如把中科大源和阿里云源交换顺序看是否有变化在 Docker 设置里开启并行下载实际上 docker 默认就有并发除非你改过max-concurrent-downloads设置。如果你在 daemon.json 里设置了较小的并发数需要适当调大比如设为 6如果走的是代理服务器检查 Docker 是否继承了代理设置。有些网络环境中设置了 HTTP_PROXY 环境变量Docker 拉镜像时也会走这个代理反而绕了远路。这里还要特别提醒一个安全问题不要随便使用来路不明的第三方镜像加速器。加速器本质上会返回镜像数据如果服务方不怀好意可能在你的镜像层里塞入恶意内容。虽然 Docker 对镜像层有 digest 校验但如果你下载的是通过该加速器特殊处理的镜像digest 合法也可能被替换。我个人的原则是只用知名云厂商或高校的公开加速地址绝不使用陌生论坛里分享的个人代理地址。7. 镜像源设置好之后几个典型部署场景快速体验7.1 加速器对 Docker 安装 MySQL 的帮助配置好镜像源后最直接的爽点就是部署常用软件时不再“卡在拉镜像”。比如有些教程里写“docker 安装 mysql8.0 并使用”如果在配置镜像源前光docker pull mysql:8.0可能就要五分钟起步甚至失败。配置后一分钟内基本能拉下来。以MySQL 8.0快速部署为例docker run -d \ --name mysql-test \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD123456 \ mysql:8.0如果没有加速器跑这条命令前你得先经历漫长的docker pull。有了加速器整个流程会顺畅很多。而且这个提速不只有首次拉取镜像后面你删除容器重新创建、在不同机器上启动相同镜像时加速器缓存也能发挥作用。7.2 redis 主从部署镜像源只是第一步很多做缓存服务的人会搭建 Redis 主从环境用 Docker 部署再方便不过。镜像源解决的是docker pull redis的下载速度真正的主从配置还需要挂载配置文件、设置replicaof参数。不过如果连镜像都拉不下来后续无从谈起。我可以给一个简单的示例先准备一个 redis 主配置redis.conf绑定0.0.0.0开启appendonly yes等启动主节点docker run -d --name redis-master \ -p 6379:6379 \ -v $(pwd)/redis.conf:/etc/redis/redis.conf \ redis:7 redis-server /etc/redis/redis.conf启动从节点配置replicaof 主节点IP 6379docker run -d --name redis-slave \ -p 6380:6379 \ -v $(pwd)/redis-slave.conf:/etc/redis/redis-slave.conf \ redis:7 redis-server /etc/redis/redis-slave.conf这些命令里镜像下载是核心基础国内镜像源加速后几分钟内就能把 Redis 主从跑起来不用把时间浪费在转圈圈上。7.3 Docker Compose 环境下同样走镜像源如果你用docker-compose.yml定义多容器应用比如一个 Web 服务加 MySQL 加 Redis那镜像源一样有效。docker compose up -d在启动前会自动拉取所有镜像这个过程同样会命中镜像加速器。在配置了加速器的机器上我第一次跑docker compose up时感觉非常省心——所有镜像秒级或者分钟级拉完再也不会因为某个镜像卡住导致整个 compose 卡住。我也试过在没有配置镜像源的机器上直接跑同一个 compose 文件结果卡在mysql:8.0的拉取上等了十分钟还没好。后来我直接把 daemon.json 复制过去重启 docker 再跑速度立刻不一样了。所以如果你想在测试环境或新服务器上复现项目第一件事不是装依赖而是先配置国内镜像源。7.4 与 Docker 安装相关的其他热词联动思考现在网上关于 Docker 的教程很多标题动不动就是“docker 安装教程”“docker 安装部署”“docker 安装mysql失败”等等。其实很多“安装失败”根本不是 Docker 的锅而是镜像拉取超时。如果你一开始就配置好国内镜像源后面再安装各种软件包成功率会提升一个档次。比如遇到docker pull mysql卡住你能想到查镜像源吗大多数人第一反应是网络强、防火墙、代理最后才发现是镜像源的问题。而我已经把配置镜像源当成装完 Docker 之后的第一条“铁律”新机器拿到手安装 Docker 后立刻配置镜像源再谈其他。8. 写在最后的一点经验谈我在这套配置上折腾了好几轮最后总结出的最核心体会是镜像源不是一次配置就一劳永逸的。网络环境、源服务状态、Docker 版本升级这些因素都可能让原本好用的加速器变得不可用。所以我在自己的服务器上会写一个小的脚本定期探测一遍配置的源地址是否连通如果连续几次失败就自动切换备用地址。虽然有点麻烦但比起在用户面前现场表演docker pull超时这点自动化投入太值了。另外一个小技巧是当你换了一台新电脑或新服务器时别急着下载各种软件镜像先把这份 daemon.json 备份发到自己的私有仓库或网盘里换机器时直接拷贝过去重启 Docker 就完事。我在团队内部就是维护了一份标准的 daemon.json 片段新同事入职之后把 Docker 装好再让他们把这段配置复制进去三分钟搞定加速问题不用每个人去注册云账号、找加速地址。希望这份关于 Docker 国内镜像源设置的折腾记录能帮你少走弯路。如果你配置完之后拉取镜像依然很慢不妨回到最基础的docker info检查一下再多换一两个源试试基本都能解决。
阅读完成 · 觉得有帮助？
