1. 项目概述这不是一次简单的“上云”而是一场智能体微服务架构的生产级压力测试我带团队做完《智能体微服务架构企业级实战教程》的全部开发后最紧张的环节不是写代码而是把整套系统——包括Dify智能体平台核心服务、多个自研Agent微服务如知识库检索Agent、多模态内容生成Agent、业务流程编排Agent、Redis缓存集群、PostgreSQL主从数据库、Nginx反向代理层还有配套的PrometheusGrafana监控栈——一次性、零故障地部署到阿里云ECS生产环境。很多人以为“部署”就是docker-compose up -d敲完就完事但真实的企业级场景里这一步踩过的坑比整个开发阶段加起来还多。你面对的不是本地MacBook上那个安静的Docker Desktop而是一台裸金属规格的ECS实例它没有图形界面、没有预装IDE、没有自动更新的内核补丁只有SSH终端里一行行命令和随时可能中断的公网连接。更关键的是智能体系统对延迟极其敏感——用户在前端输入一个问题后端要串行调用3个Agent、触发2次大模型推理、查3次向量库整个链路必须控制在1.8秒内完成否则用户体验直接崩盘。这就决定了我们的部署方案不能只求“能跑”而必须满足高可用、低延迟、可观测、可回滚四大硬指标。所以这篇内容不讲Docker基础语法不教怎么拉镜像而是聚焦在当你的智能体微服务架构真正要扛住每天10万请求时如何在阿里云ECS上构建一条稳定、高效、可运维的交付流水线。核心关键词——智能体、微服务架构、阿里云、ECS、Docker——每一个都不是孤立存在而是环环相扣的技术决策点选什么Linux发行版决定Docker兼容性选什么ECS实例规格决定Agent并发能力镜像源配置错误会导致整个部署卡在pulling状态超时Docker守护进程没配好cgroup v2会导致Ollama加载Qwen3.5:9b模型直接OOM崩溃。接下来我会把这趟生产部署的完整路径拆解成可复现、可验证、可抄作业的实操步骤所有命令都经过Rocky Linux 9 ECS g7ne实例实测参数值全部标注计算依据。2. 整体架构设计与技术选型逻辑为什么是这套组合而不是别的2.1 智能体微服务架构的特殊性倒逼部署方案重构传统单体应用部署核心矛盾是“如何把war包丢进Tomcat”。但智能体微服务架构的部署本质是协调多个异构AI服务的生命周期与数据流。以我们教程中的典型场景为例用户通过Web界面提交一个“生成爆款口播视频脚本”的请求背后触发的是一条严格编排的服务链API网关层Nginx接收HTTPS请求做JWT鉴权、限流100 req/s per IP转发到Agent调度中心Agent调度中心Python FastAPI解析用户意图调用LLM Router判断需启动哪些Agent知识库检索AgentLangChain ChromaDB从向量库中召回Top-5相关素材多模态生成AgentOllama Qwen3.5:9b接收召回结果生成符合抖音风格的口播文案音视频合成AgentFFmpeg Piper TTS将文案转为语音并混入BGM结果聚合服务Node.js拼接各Agent返回的JSON生成最终MP4下载链接。这条链路上每个环节都是独立容器且存在强依赖关系——调度中心必须等检索Agent返回才调用生成Agent生成Agent必须等Ollama模型加载完毕才能响应。这意味着部署方案必须解决三个底层问题启动顺序强约束不能让调度中心容器先于Ollama容器启动否则会疯狂重试连接失败资源隔离刚性需求Ollama加载Qwen3.5:9b需要至少12GB显存g7ne实例的A10 GPU而ChromaDB只需2GB内存混部会导致GPU被抢占网络拓扑确定性所有Agent必须通过内部DNS名如ollama:11434互相访问不能依赖IP因为容器重启后IP会变。因此我们放弃纯docker run手动启停也放弃Kubernetes学习成本过高小团队维护不起最终选定Docker Compose V2 systemd服务管理的混合方案。Compose负责定义服务依赖、网络、卷挂载systemd负责将整个Compose栈注册为系统服务实现开机自启、日志统一收集、异常自动重启。这个选择不是拍脑袋而是基于对阿里云ECS特性的深度适配ECS默认使用systemd作为init系统且阿里云官方文档明确推荐用systemd管理长期运行的Docker服务见《云服务器ECS使用指南》第7章。2.2 阿里云ECS实例选型为什么选Rocky Linux 9 g7ne很多教程一上来就写“买一台ECS”但没告诉你买哪一种。我们对比了5种主流配置实例类型CPU/内存比GPU型号适用场景我们的淘汰理由ecs.c7.large(2C4G)1:2无纯Web后端Agent需GPU加速CPU密集型任务如FFmpeg会严重争抢资源ecs.g7.2xlarge(8C32G)1:4NVIDIA A10 (24GB)AI推理✅ 最佳平衡点A10显存足够加载Qwen3.5:9b实测占用11.2GB剩余12GB显存可跑第二个模型CPU核数满足10 Agent并发ecs.r7.4xlarge(16C128G)1:8无大内存数据库无GPUOllama无法启用GPU加速Qwen3.5:9b推理速度下降63%实测从850ms→1380msecs.hfc7.4xlarge(16C32G)1:2NVIDIA A10高频计算CPU核数过多但内存不足ChromaDB向量库在10万条数据下已占满28GB内存OOM风险极高轻量应用服务器固定配置无个人博客带宽限制5Mbps无法支撑视频文件上传/下载且不支持自定义安全组规则最终选定ecs.g7.2xlarge8核32G A10 GPU操作系统选用Rocky Linux 9而非更常见的Ubuntu 22.04。原因有三内核与cgroup v2兼容性Rocky Linux 9默认启用cgroup v2而Ollama 0.3.0强制要求cgroup v2才能正确分配GPU内存。Ubuntu 22.04虽支持cgroup v2但需手动修改GRUB参数且部分驱动存在兼容问题我们实测在Ubuntu上Ollama偶尔报failed to allocate GPU memory阿里云源稳定性Rocky Linux 9的阿里云镜像源http://mirrors.cloud.aliyuncs.com/rocky/9/更新及时且与ECS底层Alibaba Cloud Linux内核高度一致避免dnf update后出现内核模块冲突企业级支持周期Rocky Linux 9提供长达10年的安全更新至2032年远超Ubuntu LTS的5年符合企业级生产环境对长期稳定性的要求。提示不要迷信“最新版”。我们曾用Rocky Linux 10 Beta测试发现其默认的firewalld配置与Docker的iptables规则冲突导致容器间网络不通排查耗时3小时。生产环境永远选LTS版本。2.3 Docker与镜像仓库策略为什么不用Docker Hub而用阿里云ACRDocker Hub是学习神器但绝非生产首选。原因很现实速率限制免费账户每6小时仅限200次拉取pull而我们的微服务架构包含12个独立镜像含基础镜像一次全量部署就触发限流docker-compose pull卡在waiting状态地域延迟Docker Hub主节点在美国从杭州ECS拉取一个1.2GB的ollama/ollama:latest镜像平均耗时4分38秒实测期间所有Agent服务都无法启动安全审计缺失无法对镜像进行漏洞扫描、签名验证不符合金融/政务类客户的安全合规要求。因此我们全线切换至阿里云容器镜像服务ACR并采用三级镜像策略镜像层级存储位置更新频率用途示例基础镜像层ACR 公共仓库每月更新经过阿里云安全扫描的可信OS基础镜像registry.cn-hangzhou.aliyuncs.com/acs/rockylinux:9中间件镜像层ACR 企业版仓库每周更新封装了GPU驱动、CUDA、cuDNN的AI专用镜像registry.cn-hangzhou.aliyuncs.com/myorg/ollama-gpu:0.3.0业务镜像层ACR 企业版仓库每次CI/CD构建包含业务代码、配置、密钥的最终可部署镜像registry.cn-hangzhou.aliyuncs.com/myorg/agent-scheduler:v2.1.3这个策略带来三个直接收益第一拉取速度提升至平均12秒杭州ECS直连杭州ACR第二所有镜像均通过ACR的CVE漏洞扫描报告可导出供甲方审计第三利用ACR的镜像复制功能可一键同步到北京、深圳地域为后续多活架构打下基础。3. 核心细节解析与实操要点从系统初始化到服务就绪的23个关键动作3.1 Rocky Linux 9系统初始化绕过90%的后续故障很多团队部署失败根源不在Docker而在系统初始化没做对。以下是我们在12台ECS上反复验证的23步标准化操作精简版完整版含所有命令输出日志见附件禁用SELinux必须sudo setenforce 0 sudo sed -i s/^SELINUXenforcing$/SELINUXpermissive/ /etc/selinux/config理由SELinux的默认策略会阻止Docker容器访问宿主机GPU设备/dev/nvidia*导致Ollama启动失败。Permissive模式记录但不阻止便于后续审计。配置阿里云YUM源Rocky Linux 9专用# 备份原源 sudo mv /etc/yum.repos.d/rocky.repo /etc/yum.repos.d/rocky.repo.backup # 下载阿里云源 sudo curl -o /etc/yum.repos.d/rocky.repo http://mirrors.cloud.aliyuncs.com/rocky/9/BaseOS/x86_64/os/rocky.repo # 替换URL为阿里云内网地址关键 sudo sed -i s|https://mirrors.aliyun.com|http://mirrors.cloud.aliyuncs.com|g /etc/yum.repos.d/rocky.repo # 清理缓存 sudo dnf clean all sudo dnf makecache注意必须用http://mirrors.cloud.aliyuncs.com而非https因为ECS内网DNS不解析HTTPS证书否则dnf update会超时。安装GPU驱动与CUDAA10实例必需# 安装NVIDIA驱动阿里云已预装但需验证 sudo nvidia-smi # 应显示A10信息 # 安装CUDA Toolkit 12.2与Ollama 0.3.0兼容 sudo dnf install -y cuda-toolkit-12-2 # 验证CUDA nvcc --version # 应输出 release 12.2, V12.2.140配置Docker守护进程关键参数详解创建/etc/docker/daemon.json{ registry-mirrors: [https://your-acr-namespace.mirror.aliyuncs.com], insecure-registries: [registry.cn-hangzhou.aliyuncs.com], default-runtime: nvidia, runtimes: { nvidia: { path: nvidia-container-runtime, runtimeArgs: [] } }, log-driver: journald, log-opts: { tag: {{.Name}}/{{.ImageName}} } }参数解读default-runtime: nvidia让所有容器默认使用NVIDIA运行时无需在docker run中加--gpus alllog-driver: journald将Docker日志接入systemd journal方便用journalctl -u docker统一查看tag为日志添加容器名标签排查时一眼定位问题服务。创建Docker用户组并授权安全实践sudo groupadd docker sudo usermod -aG docker $USER # 重要必须重启sshd或重新登录否则group权限不生效 sudo systemctl restart sshd验证Docker GPU支持必做# 运行NVIDIA测试容器 docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi # 正常输出应包含A10显卡信息且Memory-Usage显示11264MiB / 24576MiB注意以上6步必须在安装Docker前完成。我们曾跳过第1步SELinux导致Ollama容器启动后nvidia-smi命令返回空排查了5小时才发现是SELinux拦截了设备访问。3.2 Docker与Docker Compose安装避开阿里云文档里的3个深坑阿里云帮助文档写的安装命令在Rocky Linux 9上存在3个未明说的坑坑1moby与docker-ce冲突文档推荐sudo yum install -y moby但moby是阿里云定制版不支持--gpus参数。必须卸载moby安装社区版docker-cesudo yum remove -y moby sudo dnf config-manager --add-repo http://mirrors.cloud.aliyuncs.com/docker-ce/linux/centos/docker-ce.repo sudo dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin坑2docker-compose-plugin的二进制路径问题安装后docker compose version能执行但docker-compose命令不存在这是V2的设计。很多旧脚本仍用docker-compose需创建软链接sudo ln -s /usr/libexec/docker/cli-plugins/docker-compose /usr/local/bin/docker-compose坑3containerd.io版本锁死dnf install docker-ce会自动安装最新版containerd.io但Ollama 0.3.0要求containerd.io 1.6.26且 1.7.0。若自动安装了1.7.1Ollama会报failed to start containerd。解决方案# 查看可用版本 dnf list available containerd.io --showduplicates # 强制安装指定版本 sudo dnf install -y containerd.io-1.6.26-3.1.el8.x86_64安装完成后必须执行终极验证# 启动Docker sudo systemctl start docker sudo systemctl enable docker # 验证GPU容器 docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi | head -n 10 # 验证Compose docker compose version # 应输出 Docker Compose version v2.23.03.3 ACR镜像仓库对接让私有镜像拉取快如闪电ACR配置不是简单填个地址而是涉及认证、网络、缓存三层优化登录ACR使用AccessKey非密码# 安装ACR CLI比docker login更稳定 curl -fsSL https://alicloud-images.oss-cn-hangzhou.aliyuncs.com/acr-tool/install.sh | sh # 登录替换region、namespace、access-key-id、access-key-secret acr login --region region --namespace namespace --access-key-id access-key-id --access-key-secret access-key-secret配置Docker Daemon镜像加速关键在/etc/docker/daemon.json中registry-mirrors必须填写ACR命名空间的镜像加速地址格式为https://your-namespace.mirror.aliyuncs.com不是ACR控制台显示的registry.cn-hangzhou.aliyuncs.com后者是推送地址前者才是拉取加速地址。填错会导致拉取速度降回Docker Hub水平。预热核心镜像部署前必做# 并行拉取所有基础镜像减少部署时等待 docker pull registry.cn-hangzhou.aliyuncs.com/myorg/ollama-gpu:0.3.0 docker pull registry.cn-hangzhou.aliyuncs.com/myorg/redis:7.2-alpine docker pull registry.cn-hangzhou.aliyuncs.com/myorg/postgres:15.3 wait # 验证镜像完整性 docker images | grep myorg实操心得我们曾因忘记第2步导致生产部署时docker-compose pull卡在ollama-gpu:0.3.0镜像上超时后自动退出整个上线计划推迟4小时。后来把镜像加速地址写入daemon.json并重启Docker拉取时间从3分20秒降至8秒。4. 生产环境部署全流程从代码到高可用服务的17个精确步骤4.1 项目结构与Docker Compose编排文件设计我们的智能体微服务项目结构如下已脱敏/intelligent-agent-platform/ ├── docker-compose.prod.yml # 生产环境编排文件重点 ├── .env # 环境变量存储ACR密码、数据库密码等 ├── nginx/ │ ├── nginx.conf # 反向代理配置支持WebSocket长连接 │ └── ssl/ # SSL证书由ACM自动续期 ├── agents/ │ ├── scheduler/ # 调度中心FastAPI │ │ ├── Dockerfile │ │ └── requirements.txt │ ├── retrieval/ # 检索AgentLangChainChroma │ │ ├── Dockerfile │ │ └── chroma.db # 向量库数据卷 │ └── generation/ # 生成AgentOllamaQwen │ ├── Dockerfile │ └── models/ # 模型文件Qwen3.5:9b ├── monitoring/ │ ├── prometheus.yml # 监控配置 │ └── grafana/ # Grafana仪表盘 └── scripts/ └── deploy.sh # 一键部署脚本核心docker-compose.prod.yml是整个部署的灵魂我们摒弃了网上常见的“一个services块堆砌所有服务”的写法采用分层编排version: 3.8 # 第一层基础设施服务独立网络高可用 networks: infra: driver: bridge ipam: config: - subnet: 172.20.0.0/16 volumes: postgres_data: driver: local redis_data: driver: local services: # PostgreSQL主从使用Patroni实现自动故障转移 postgres-master: image: registry.cn-hangzhou.aliyuncs.com/myorg/postgres:15.3-patroni networks: [infra] volumes: [postgres_data:/var/lib/postgresql/data] environment: PATRONI_SCOPE: intelligent-agent-cluster PATRONI_POSTGRESQL_DATA_DIR: /var/lib/postgresql/data PATRONI_POSTGRESQL_LISTEN: 0.0.0.0:5432 PATRONI_POSTGRESQL_CONNECT_ADDRESS: postgres-master:5432 deploy: resources: limits: memory: 8G cpus: 2.0 # 第二层AI核心服务GPU专属网络 networks: ai: driver: bridge ipam: config: - subnet: 172.21.0.0/16 ollama: image: registry.cn-hangzhou.aliyuncs.com/myorg/ollama-gpu:0.3.0 networks: [ai] volumes: - ./agents/generation/models:/root/.ollama/models - /dev/shm:/dev/shm # 共享内存加速模型加载 runtime: nvidia deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] healthcheck: test: [CMD, curl, -f, http://localhost:11434/health] interval: 30s timeout: 10s retries: 3 # 第三层业务微服务连接infra和ai网络 networks: app: driver: bridge ipam: config: - subnet: 172.22.0.0/16 scheduler: image: registry.cn-hangzhou.aliyuncs.com/myorg/agent-scheduler:v2.1.3 networks: [app, infra, ai] depends_on: postgres-master: condition: service_healthy ollama: condition: service_healthy environment: DATABASE_URL: postgresql://user:passwordpostgres-master:5432/agentdb OLLAMA_HOST: http://ollama:11434 deploy: replicas: 2 # 双实例负载均衡 resources: limits: memory: 4G cpus: 1.5 restart_policy: condition: on-failure delay: 10s max_attempts: 3设计逻辑三层网络隔离infra数据库/缓存、aiGPU服务、app业务服务物理隔离避免Redis流量挤占GPU带宽健康检查驱动依赖depends_on不再只看容器启动而是等service_healthy即PostgreSQL能响应SELECT 1Ollama能返回HTTP 200GPU资源精准预留reservations.devices确保Ollama独占1块A10 GPU防止其他服务抢占显存。4.2 一键部署脚本deploy.sh把17个步骤压缩成1条命令手工执行docker-compose up有17个易错点环境变量没加载、网络没创建、卷权限不对、ACR没登录……我们编写了健壮的deploy.sh核心逻辑如下#!/bin/bash set -e # 任何命令失败立即退出 echo 步骤1加载环境变量 source .env echo 步骤2验证ACR登录状态 if ! acr login --region cn-hangzhou --namespace myorg --access-key-id $ACR_ACCESS_KEY_ID --access-key-secret $ACR_ACCESS_KEY_SECRET /dev/null 21; then echo ACR登录失败请检查.env文件中的凭证 exit 1 fi echo 步骤3创建专用网络 docker network create intelligent-agent-infra 2/dev/null || true docker network create intelligent-agent-ai 2/dev/null || true docker network create intelligent-agent-app 2/dev/null || true echo 步骤4预拉取核心镜像并行 docker pull registry.cn-hangzhou.aliyuncs.com/myorg/ollama-gpu:0.3.0 docker pull registry.cn-hangzhou.aliyuncs.com/myorg/postgres:15.3-patroni docker pull registry.cn-hangzhou.aliyuncs.com/myorg/agent-scheduler:v2.1.3 wait echo 步骤5设置卷权限关键 sudo chown -R 1001:1001 ./agents/generation/models # Ollama容器用户ID sudo chown -R 999:999 ./agents/retrieval/chroma.db # ChromaDB容器用户ID echo 步骤6启动生产栈 docker compose -f docker-compose.prod.yml up -d --remove-orphans echo 步骤7等待所有服务健康 for i in {1..60}; do if docker compose -f docker-compose.prod.yml ps | grep healthy | wc -l | grep -q 3; then echo ✅ 所有服务已进入healthy状态 break fi sleep 5 if [ $i -eq 60 ]; then echo ❌ 等待超时检查docker compose ps输出 docker compose -f docker-compose.prod.yml ps exit 1 fi done echo 步骤8配置systemd服务实现开机自启 cat /etc/systemd/system/intelligent-agent.service EOF [Unit] DescriptionIntelligent Agent Platform Afterdocker.service Wantsdocker.service [Service] Typeoneshot ExecStart/usr/bin/docker compose -f /opt/intelligent-agent-platform/docker-compose.prod.yml up -d ExecStop/usr/bin/docker compose -f /opt/intelligent-agent-platform/docker-compose.prod.yml down RemainAfterExityes Restarton-failure RestartSec10 [Install] WantedBymulti-user.target EOF systemctl daemon-reload systemctl enable intelligent-agent.service systemctl start intelligent-agent.service echo 部署完成访问 https://$(curl -s http://169.254.169.254/latest/meta-data/public-ipv4) 查看服务关键保障机制set -e任一命令失败立即终止避免半残状态chown -R修复Rocky Linux 9上Docker卷挂载的UID/GID不匹配问题Ollama容器内UID1001宿主机默认是1000systemd服务将整个Compose栈注册为系统服务systemctl restart intelligent-agent即可滚动更新无需手动down再up。4.3 Nginx反向代理与SSL配置让智能体服务暴露在公网智能体服务不能直接暴露Docker端口必须经Nginx反向代理。我们的nginx.conf针对AI场景做了3处深度优化upstream agent_backend { server scheduler:8000; server scheduler2:8000; # 第二个调度实例 keepalive 32; # 保持长连接减少TLS握手开销 } server { listen 443 ssl http2; server_name intelligent-agent.example.com; # SSL证书由阿里云ACM自动管理 ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; # AI服务特殊优化 proxy_http_version 1.1; proxy_set_header Upgrade \$http_upgrade; # 支持WebSocket用于实时Agent日志 proxy_set_header Connection upgrade; proxy_set_header Host \$host; proxy_set_header X-Real-IP \$remote_addr; proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for; # 关键超时时间延长至120秒大模型推理可能耗时 proxy_connect_timeout 120s; proxy_send_timeout 120s; proxy_read_timeout 120s; location / { proxy_pass http://agent_backend; # 添加智能体标识头便于后端识别流量来源 proxy_set_header X-Agent-Platform Dify-Enterprise; } # 健康检查端点供SLB探测 location /healthz { return 200 OK; add_header Content-Type text/plain; } }部署要点使用阿里云SSL证书管理ACM自动申请、续期、部署证书避免手动上传proxy_read_timeout 120s是底线Qwen3.5:9b在复杂提示词下推理峰值可达98秒实测设为60秒会导致大量504 Gateway Timeout/healthz端点必须返回纯文本200阿里云SLB健康检查不支持JSON响应。5. 常见问题与排查技巧实录那些让你凌晨三点还在敲命令的真问题5.1 GPU相关故障Ollama启动失败的5种根因与速查表Ollama是整个智能体架构的“心脏”它挂了所有Agent都瘫痪。我们整理了生产环境中最常遇到的5类GPU故障及排查命令故障现象根本原因排查命令解决方案docker logs ollama显示failed to initialize CUDA: unknown errorNVIDIA驱动未加载或版本不匹配lsmod | grep nvidianvidia-smi重启nvidia-persistenced服务sudo systemctl restart nvidia-persistenceddocker exec -it ollama nvidia-smi返回空容器未正确挂载GPU设备docker inspect ollama | grep -A 10 Devices检查docker-compose.yml中runtime: nvidia和deploy.resources.reservations.devices是否配置curl http://localhost:11434/health返回502Ollama进程崩溃但容器未退出docker top ollamadocker exec ollama ps aux | grep ollama查看/root/.ollama/logs/server.log常见原因是/dev/shm空间不足增大shm-sizeshm_size: 2gollama run qwen3.5:9b卡住无响应模型文件权限错误Rocky Linux 9 UID不匹配ls -l ./agents/generation/models/sudo chown -R 1001:1001 ./agents/generation/modelsdocker-compose up报错no suitable node (insufficient GPUs)Docker Swarm模式误启用docker info | grep -i swarmdocker swarm leave --force实操心得第4种权限问题在Rocky Linux 9上100%发生。因为Ollama容器内用户UID固定为1001而Rocky Linux 9新建用户UID从1000开始chown必须显式指定1001:1001用$USER变量会失败。5.2 网络与DNS故障容器间ping不通的3个隐形杀手微服务架构下ping不通是最高频问题。我们发现90%的“网络不通”其实与Docker网络无关而是以下3个隐形杀手杀手1Rocky Linux 9的firewalld默认拦截firewalld会阻止docker0网桥流量。解决方案sudo firewall-cmd --permanent --zonetrusted --add-interfacedocker0 sudo firewall-cmd --reload杀手2/etc/resolv.conf被覆盖Docker容器默认使用宿主机/etc/resolv.conf但Rocky Linux 9的NetworkManager会动态覆盖它。解决方案# 锁定resolv.conf sudo chattr i /etc/resolv.conf # 或配置Docker使用指定DNS echo {dns:[172.20.0.2]} | sudo tee /etc/docker/daemon.json sudo systemctl restart docker杀手3跨网络通信未启用IP转发当服务分布在infra、ai、app三个网络时需开启IP转发echo