1. 用Docker装软件到底解决了什么问题先说个我自己的经历。前几年在一台服务器上装Redis系统是CentOS 7默认源里只有Redis 3.2但项目要用Redis 6的Stream类型只能自己编译。编译倒是不难难的是编译完发现系统里还装着一个PHP扩展它依赖老版本的libevent我一升级RedisPHP那边直接崩了。折腾了一下午最后老老实实把系统重装了一遍。这个场景你应该不陌生。传统方式安装软件的痛点总结起来就是三个依赖冲突、环境残留、升级困难。你在系统里装的每个软件都在往/usr/lib、/etc、/var下面塞东西软件多了以后谁也说不清哪个文件是谁的哪个库被谁覆盖了。Docker解决这个问题的方式很直接把软件连同它专属的操作系统环境一起打包成一个镜像。镜像就是一个只读模板里面已经装好了运行这个软件所需要的所有依赖、配置、动态链接库甚至包括特定的Linux发行版基础环境。当你运行这个镜像时Docker基于镜像创建一个独立的容器容器里的进程只能看到镜像里给它准备好的那一套环境跟宿主机其他的软件互不干扰。打个比方。传统安装像你往一个合租房里搬家具床、衣柜、书桌都摆在公共区域你搬进来一套沙发可能就得把别人的电视柜挪走。Docker则是每个软件住一间独立的精装公寓家具、电器、水管电线全部标配你想换房升级版本直接换一套公寓住进去就行旧公寓整间退掉干干净净。很多人问那我直接用虚拟机不也一样吗虚拟机是虚拟出一整台计算机里面装完整操作系统开销大、启动慢、资源占用高。容器则共享宿主机内核只隔离用户空间的进程、文件系统、网络和权限启动一个容器往往只要几百毫秒内存占用可能只有几十兆。正因为这个特性Docker特别适合用来装那些本身没有界面、以服务方式运行的后端软件数据库、缓存、消息队列、Web服务器、定时任务平台等等。不过也要说句公道话Docker不是万能的。以下几种情况我仍然建议你老老实实在宿主机装需要直通GPU做深度学习训练的虽然有nvidia-container-toolkit但配置成本不低对IO性能要求极其苛刻的数据库场景容器有存储驱动层的开销虽然现代驱动已经非常接近裸盘但极端场景还是有差距需要长期跑桌面GUI应用的不是不能跑但显示方案绕来绕去体验一般。除此之外用Docker安装部署软件的收益是非常明显的。这篇就围绕我自己折腾Docker装软件的经验从环境准备、单容器实战、编排实战、依赖管理到开发者集成、特殊架构适配完整梳理一遍。2. 环境准备Windows、macOS、Linux下的Docker安装与镜像加速配置2.1 不同系统的正确安装姿势Docker本身是Linux上的原生技术它依赖Linux内核的namespace命名空间和cgroups控制组这两个核心机制来实现隔离和资源限制。你在Windows或macOS上装Docker本质上是装一个轻量级Linux虚拟机然后在虚拟机里跑Docker引擎。Docker Desktop帮你把这一层封装好了所以你几乎感觉不到虚拟机的存在。不同系统下的安装选型我直接给结论操作系统推荐方案说明Windows 10/1164位支持WSL2Docker Desktop for Windows用WSL2作为后端性能和体验都最好Windows Serverdocker-ce containerd原生Windows容器或Linux容器均可生产环境常用macOSIntel/Apple SiliconDocker Desktop for MacApple Silicon上自动用VirtioFS加速文件共享Ubuntu/Debian官方apt源安装docker-ce不要装老旧系统源里的docker.ioCentOS/RHEL/Rockyyum/dnf安装docker-ce需要先配置官方或镜像源龙芯/飞腾等国产平台系统厂商维护的docker-engine包或源码编译见第7章详细讲Windows下安装Docker Desktop我需要强调一个前置条件必须先启用WSL2。很多人装完Docker Desktop提示启动失败十有八九是没装Linux内核更新包或者没有在控制面板→启用或关闭Windows功能里勾选适用于Linux的Windows子系统和虚拟机平台两个选项。装完这两个组件后重启再在管理员PowerShell里执行wsl --set-default-version 2最后再装Docker Desktop一路Next就不会有问题。Linux下用官方脚本安装是最省事的curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh这个脚本会自动检测你的发行版配置官方仓库然后安装docker-ce、docker-ce-cli、containerd.io、docker-compose-plugin这些组件。不想用官方脚本的话Ubuntu可以手动添加Docker的apt源CentOS则添加yum源网上文档很多但核心就两步导入GPG密钥 写入repo文件。2.2 安装完之后必做的三件事不管哪个系统装完Docker先别急着拉镜像做下面三件事第一把当前用户加入docker组仅限Linux/macOS。默认情况下只有root和docker组的用户能操作Docker守护进程不然每条命令都要加sudo麻烦且容易出权限问题sudo usermod -aG docker $USER newgrp docker注意把用户加入docker组相当于授予该用户root级别的宿主机权限因为docker组可以挂载宿主机目录、执行特权容器。个人开发机没问题生产环境服务器要谨慎。第二配置镜像加速器。Docker Hub部署在国外直接拉镜像经常几KB/s甚至超时。国内各大云厂商都提供registry mirror服务它本质上是一个Docker镜像的代理缓存你把Docker守护进程的registry-mirrors指向它拉镜像时优先从国内节点下载。在Docker Desktop里打开Settings → Docker Engine编辑JSON{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com ] }Linux环境下则编辑/etc/docker/daemon.json然后sudo systemctl restart docker。补充加速器地址不是我随便写的云厂商的加速器地址通常是https://xxxx.mirror.aliyuncs.com这种每个人账号对应的地址不同需要登录容器镜像服务控制台获取。上面给的公共加速器我实测过但仍然建议你优先用自己的——公共节点负载高宕机是常事。另外别把加速器地址当成什么见不得光的东西它就是一个常规的镜像源配置。第三验证Docker是否正常工作docker run --rm hello-world这个测试镜像只有几KB运行后会打印一段Docker工作正常的说明然后退出。如果这一步能顺利跑通说明引擎、网络、镜像拉取链路都没问题。2.3 为什么加速器配置要放在环境准备阶段我在帮别人排查Docker问题的时候发现80%的拉镜像失败都和网络有关但很多人第一反应是去改容器配置、换镜像tag结果白折腾。拉镜像是最容易被网络影响的环节而配置加速器是最低成本、最立竿见影的优化手段。关于镜像加速的原理我再多说一句。当你执行docker pull redis:7.2时Docker守护进程并不是直接从Docker Hub下载blob而是先去Hub查索引然后根据索引信息去Registry拉取层数据。配置registry-mirrors后Docker会优先从mirror地址拉取——mirror本身会和源站同步数据你在国内拉取时走的其实是国内节点。这样一来原本可能需要几分钟甚至超时的下载通常能缩短到十几秒。3. 首个容器实战以Redis为例跑通拉取-运行-验证3.1 直接run还是先pull先用好tag制度很多教程上来就让你docker run redis实际Docker会先自动帮你拉取镜像再运行所以很少有人单独执行docker pull。但我建议新手还是先手动pull一次原因很简单你要清楚自己拉的是什么版本。Redis镜像在Docker Hub上的tag规则非常明确redis:latest最新稳定版不推荐生产环境使用因为不可控redis:7.27.2系列的最新补丁版本推荐日常使用redis:7.2-alpine基于Alpine Linux的精简版体积只有几十MBredis:7.2-bookworm基于Debian Bookworm的标准版功能最全redis:7.0.14精确到小版本号锁定不变。我的习惯是本地测试用alpine系列体积小、启动快生产环境用bookworm或官方默认的Debian系列因为Alpine用的是musl libc个别原生模块可能编译不兼容。docker pull redis:7.2-alpine3.2 带持久化和密码的运行参数详解拉完镜像执行下面这条命令这是Docker装软件最核心的一条命令docker run -d \ --name redis-test \ -p 6379:6379 \ -v redis-data:/data \ -e TZAsia/Shanghai \ redis:7.2-alpine \ redis-server --appendonly yes --requirepass MyPassw0rd逐个解释参数这些都是你后面装任何软件都要用到的-d后台运行detach模式不加这个参数容器会占用终端日志直接刷屏--name redis-test给容器起名字后续docker start/stop/logs/exec都用这个名字操作-p 6379:6379端口映射宿主机6379端口转发到容器内6379端口。容器内是一个隔离的网络空间不映射的话宿主机上的程序访问不到它-v redis-data:/data数据卷挂载冒号前是宿主机上的卷名或绝对路径冒号后是容器内的目录。Redis的AOF持久化文件默认存在/data如果不挂载卷容器一旦删除所有数据全部消失-e TZAsia/Shanghai设置容器内时区。容器默认是UTC时区比北京时间慢8小时跑定时任务时会踩坑redis-server --appendonly yes --requirepass MyPassw0rd这后面的参数是传给容器内Redis主进程的命令行参数。镜像默认的启动命令就是redis-server你可以追加参数覆盖默认配置。关于-v我要多说一句。这里我用了卷名redis-data而不是/home/user/data这种绝对路径。两者的区别是具名卷由Docker管理存储在/var/lib/docker/volumes/下迁移、备份用docker volume命令很方便绑定挂载bind mount则直接把宿主机目录映射进容器你可以在宿主机上直接看到和修改文件。数据库类应用我建议用具名卷省心、权限问题少需要直接在宿主机上改配置文件、看日志的用绑定挂载更直观。3.3 验证容器是否真的在干活运行起来之后新手最容易犯的错就是以为容器跑起来了其实它早就退出了。验证方法是一套组合拳# 查看容器状态STATUS显示Up表示正常运行Exited说明已退出 docker ps -a # 查看日志这是排障第一入口 docker logs redis-test # 进入容器内部执行命令 docker exec -it redis-test sh # 在容器内用redis-cli验证 redis-cli -a MyPassw0rd ping # 应该输出PONG如果docker ps -a显示容器Exited不要慌用docker logs redis-test看退出原因。最常见的几种情况端口被占用报错bind: address already in use换宿主机的映射端口即可配置文件参数写错Redis会打印Bad directive or wrong number of arguments权限不足挂载的数据卷目录属主不对容器内redis用户写不进去。还有一个排查利器是docker inspectdocker inspect redis-test它会输出容器完整的配置信息包括挂载的卷、环境变量、网络配置、退出码、重启策略等。JSON很长可以配合grep或jq过滤关键字段docker inspect redis-test | grep -A 5 Mounts docker inspect redis-test | jq .[0].State到这里你已经完成了用Docker安装并运行第一个软件的完整流程。这条路径——拉镜像、起容器、配参数、验证状态——是所有Docker装软件场景的共同母题。4. 进阶编排用Docker Compose搭建Redis主从复制集群4.1 为什么单容器不够用了单个Redis容器解决的是有一个Redis能用的问题。但实际开发中你可能需要一主一从做读写分离或者一主两从加哨兵做高可用。这时候用docker run一条条命令敲也不是不行但有两个问题容器之间要联网通信你得先自己创建自定义网络再在启动时指定--network步骤繁琐整套环境的配置散落在历史命令里换一台机器部署全部重来。Docker Compose就是为了解决多容器环境编排而存在的。它用一个YAML文件描述整套服务的配置docker compose up -d一条命令全部拉起docker compose down一键全部销毁。4.2 先搞懂主从复制的原理再写配置Redis主从复制的基本逻辑从节点启动后向主节点发送SYNC命令新版本是PSYNC主节点生成RDB快照发送给从节点之后主节点把每一次写操作以命令流的方式持续转发给从节点。所以从节点能实时同步主节点的数据。在原生Redis里配置从节点只需要在redis.conf加一行replicaof master-ip master-portDocker环境下主节点容器的IP不是固定的除非指定固定IP所以更优雅的做法是利用Docker内置的DNS解析——在同一个自定义网络里容器可以通过服务名直接访问对方。这就是Compose文件天然适合做多容器架构的原因。4.3 docker-compose.yml完整配置下面是一份我实测过的docker-compose.yml实现一主一从带密码验证services: redis-master: image: redis:7.2-alpine container_name: redis-master restart: unless-stopped ports: - 6379:6379 volumes: - redis-master-data:/data environment: - TZAsia/Shanghai command: redis-server --appendonly yes --requirepass MasterPass --masterauth MasterPass redis-slave: image: redis:7.2-alpine container_name: redis-slave restart: unless-stopped ports: - 6380:6379 volumes: - redis-slave-data:/data environment: - TZAsia/Shanghai depends_on: - redis-master command: redis-server --appendonly yes --requirepass SlavePass --replicaof redis-master 6379 --masterauth MasterPass volumes: redis-master-data: redis-slave-data:这个配置里几个关键点--replicaof redis-master 6379从节点通过服务名redis-master找到主节点Docker内置DNS会解析到主节点容器的IP--requirepass和--masterauth主节点要求客户端认证所以从节点同步时也必须提供密码两个参数要配套设置否则从节点会一直报NOAUTH Authentication requireddepends_on声明启动顺序从节点等主节点先启动。但实际上Redis的replicaof机制有自动重连即使主节点晚启动从节点也会持续重试所以这个字段更像是一种友好声明restart: unless-stopped容器异常退出或宿主机重启时自动拉起生产环境必备。启动方式docker compose up -d4.4 验证主从同步是否正常全部启动后分别验证两个容器状态docker ps # 确认两个容器都是Up状态 # 登录从节点查看复制状态 docker exec -it redis-slave redis-cli -a SlavePass info replication输出里关注几个字段role:slave确认当前节点角色是从节点master_host:redis-master确认主节点地址解析正确master_link_status:up这是最关键的只有up才表示主从连通master_last_io_seconds_ago距离上次和主节点通信的时间数字过大说明同步不健康。然后再验证数据同步# 在主节点写入数据 docker exec -it redis-master redis-cli -a MasterPass set name docker # 在从节点读取 docker exec -it redis-slave redis-cli -a SlavePass get name # 输出 docker 说明同步正常我踩过的一个坑值得提醒如果主节点设置了requirepass而从节点没有正确设置masterauth从节点的日志会每隔几秒打一条错误MASTER - REPLICA sync: Master replied to PING, replication can continue...主节点返回了PING但因为没带认证信息后续的同步请求会被拒绝。此时用docker logs redis-slave能非常清晰地看到NOAUTH字样马上就能定位问题。5. 基础软件的进阶玩法青龙面板的容器依赖管理5.1 为什么容器化部署对这类应用特别友好青龙面板是一个定时任务管理平台在Docker环境下非常流行。这类平台本身就是多语言脚本的执行环境涉及Node.js、Python、JavaScript等运行时的各种依赖库。如果用传统方式部署你得在服务器上手动装Node.js、Python、pip、npm还要处理版本冲突而用Docker镜像里已经把运行时环境全部备好了docker run -d \ --name qinglong \ -p 5700:5700 \ -v ql-data:/ql/data \ -e TZAsia/Shanghai \ whyour/qinglong:latest启动后访问http://宿主机IP:5700就能进入Web界面。一个定时任务平台从下载到运行只需要几分钟这就是容器化的价值。但这里真正值得展开讲的不是启动而是依赖管理——这是我在使用过程中踩坑最多的地方。5.2 容器内依赖管理三个常见误区误区一直接在容器里手动安装依赖然后以为一劳永逸。你会看到很多教程让你执行docker exec -it qinglong bash npm install -g xxx pip install xxx这在当下是生效的但容器一旦重建升级镜像、服务器迁移、异常回滚所有手动安装的依赖全部消失。因为容器本身是临时的数据卷持久化的只是/ql/data目录而npm的全局包安装在容器文件系统里不属于持久化数据。误区二所有依赖都装到全局。有些依赖只在某个特定脚本里用到装成全局包反而容易版本冲突。比如一个脚本要求requests2.28.1另一个脚本要求requests2.31.0全局只能装一个。误区三忽视依赖的时区设置导致的定时任务偏差。青龙镜像虽然可以通过-e TZAsia/Shanghai设置时区但如果你管理的任务脚本内部使用了datetime.now()它读取的是脚本运行时环境的时区不是数据库里的时区。这个问题在容器里表现得尤为隐蔽因为容器基础镜像默认UTC如果你忘了设置环境变量定时任务会准时提前8小时执行。5.3 我推荐的依赖管理方案自定义镜像 启动初始化脚本依赖管理最稳妥的思路是把依赖固化到镜像里而不是临时装进容器里。具体做法是写一个自己的DockerfileFROM whyour/qinglong:latest # 设置时区 ENV TZAsia/Shanghai # 安装系统级依赖 RUN apk add --no-cache tzdata bash curl # 安装Python依赖 RUN pip3 install --no-cache-dir requests apscheduler pycryptodome # 安装Node依赖 RUN npm install -g pnpm ts-node typescript # 声明数据卷沿用官方镜像配置 VOLUME /ql/data然后构建并运行docker build -t qinglong-custom:v1 . docker run -d --name qinglong -p 5700:5700 -v ql-data:/ql/data -e TZAsia/Shanghai qinglong-custom:v1这样每次重建容器镜像里已经包含了声明的依赖不会再丢失。不足是这个方案有个学习成本你需要了解Dockerfile的编写并且更新镜像时要重新构建。如果不想用Dockerfile日常维护也可以把pip和npm的依赖清单存到数据卷里# 在宿主机上建目录挂载为容器的初始化目录 docker run -d \ -v $(pwd)/qinglong-init:/ql/init \ ...然后在Web界面里把依赖管理配置成从文件读取。具体来说青龙面板的依赖管理支持你保存一份依赖清单在依赖缺失时会触发安装。5.4 容器重建后快速恢复依赖的实操清单我自己的服务器上跑着青龙容器一次升级镜像把所有依赖搞丢之后我给自己的恢复流程定了个规矩升级前先导出清单docker exec -it qinglong pip3 freeze requirements.txtNode端用npm list -g --depth0导出升级后不急着配脚本先让容器跑起来然后通过Web界面的依赖管理把上一步导出的清单重新安装装完必须做冒烟验证随便挑一个依赖库执行python3 -c import requests; print(requests.__version__)确认核心依赖锁定了版本。这套流程经历过两次实际验证比之前手动一个个装回去节省了大量时间。6. 开发提效IDEA一键打包Docker镜像6.1 为什么建议直接在IDEA里完成镜像打包Docker不只是运维用来装软件的工具对开发者来说它也是应用交付的重要载体。过去把Spring Boot应用打成镜像流程是本地mvn package打出jar包 → 写Dockerfile → scp到服务器 → ssh登录服务器 → docker build → docker run。链路过长每步都有可能出错。IDEA自带的Docker插件把最后几步集成进了IDE。你在配置里指定Dockerfile路径和构建参数点击执行IDEA自动帮你完成构建、推送、甚至部署到远程服务器。对于频繁迭代开发环境的场景效率提升非常明显。6.2 从零配置连接Docker与Run Configuration第一步让IDEA能连上Docker守护进程。如果Docker和IDEA在同一台机器上Settings → Build, Execution, Deployment → Docker点击加号选择Docker DesktopWindows/macOS或Unix socketLinuxTest Connection显示成功即可。如果是远程服务器上的Docker需要在服务器上开启远程API访问。这一步有安全风险因为默认情况下Docker API没有认证任何人都能连上你的守护进程并执行任意命令。我建议至少配置TLS证书或者用SSH隧道方式连接ssh -L 2375:/var/run/docker.sock userserver然后在IDEA里用tcp://localhost:2375连接走SSH隧道转发比裸奔暴露2375端口安全得多。第二步写好Dockerfile。以常见的Spring Boot应用为例# 多阶段构建 FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /app COPY . . RUN mvn clean package -DskipTests # 运行阶段 FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /app/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]多阶段构建的核心价值是把构建环境和运行环境分开。构建阶段用maven镜像里面有完整的JDK和Maven体积几个GB运行阶段只拷贝最终产出的jar包基于精简的JRE镜像最终镜像可能只有200MB。第三步配置Run Configuration。在IDEA右上角选择 Edit Configurations新增Dockerfile运行配置指定Dockerfile路径镜像tag建议写成${project.name}:v1。点击运行IDEA的底部会实时输出构建日志构建完成后自动注册到本地镜像库。6.3 打包过程中最常见的坑镜像体积过大。如果不做多阶段构建而是用FROM maven:3.9直接在上面打包运行镜像体积会膨胀到几个GB。多阶段构建是必须的不是可选优化项。时区问题。容器默认UTC时区Java应用打印的日志时间会比北京时间慢8小时。打包时在Dockerfile里加上ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone第二句可能因基础镜像缺少tzdata包而报错所以有时要先apt-get install -y tzdata或apk add tzdata。.dockerignore没写。没有.dockerignore的话构建上下文会把整个项目目录包括target/、.git/、logs/都发给Docker守护进程构建速度慢到怀疑人生。在项目根目录放一个target/ .git/ .idea/ *.iml logs/依赖缓存失效。Maven构建最耗时的部分是下载依赖每次构建都重新下意味着白白浪费时间。优化做法是利用Docker层缓存机制把依赖下载单独放一层COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package只要pom.xml没变这一层就可以直接复用缓存后续构建时间从几分钟降到几秒。7. 国产化适配龙芯机器上跑Docker的实践经验7.1 龙芯平台的特殊性龙芯处理器采用的是自主指令集LoongArch不是大家更熟悉的x86Intel/AMD也不是ARM。这意味着市面上绝大多数现成的Docker镜像——不管官方还是第三方——都没有针对龙芯编译过的版本。你执行docker pull mysql:8.0大概率会得到一句no matching manifest for linux/loong64 in the manifest list entries。这不是Docker本身的问题而是镜像的提交者没有构建LoongArch架构的版本。理解这一点是搞定龙芯Docker的第一步。7.2 在龙芯上安装Docker引擎龙芯的新版本统信UOS、麒麟等操作系统通常已经在源里带了docker-engine或docker-ce包优先用系统源安装因为官方已经做了适配# 以统信UOS/麒麟为例 sudo apt update sudo apt install docker.io sudo systemctl enable --now docker或者使用龙芯开源社区维护的安装包覆盖面更广。安装完验证一下架构docker info | grep Architecture # 输出应为 loong64 或 loongarch64注意这里有个容易混淆的点LoongArch的Docker架构标识是loong64还是loongarch64取决于Docker版本的规范写法。较新版本用的是loong64与Go语言对龙芯架构的命名保持一致。7.3 没有现成镜像的三种应对策略既然Docker Hub上几乎没有LoongArch的镜像我们实际用的时候有三个办法办法一寻找龙芯适配过的镜像源。龙芯团队维护了一套适配LoongArch的软件仓库和部分基础镜像包括golang、openjdk、python、nginx、redis等常用软件的LoongArch版本。虽然数量远不如Docker Hub丰富但覆盖了最常见的基础设施。办法二源码/包管理方式构建。这是最通用的兜底方案。以Redis为例龙芯的Linux发行版源里通常带了redis的LoongArch版本直接apt install redis或者从源码编译。编译后和官方包行为一致。虽然这回归了传统安装方式但你可以把它做成自定义镜像以后分发就方便了FROM loong64/debian:bookworm-slim RUN apt update apt install -y redis-server CMD [redis-server, --bind, 0.0.0.0]办法三用qemu-user模拟跨架构镜像。Docker支持在非原生架构上运行其他架构的镜像原理是用qemu-user做用户态指令翻译。你可以启用buildx的cross-platform模拟docker run --privileged --rm tonistiigi/binfmt --install all docker pull --platform linux/arm64 mysql:8.0 docker run --platform linux/arm64 mysql:8.0但我要泼一盆冷水这种方式在开发测试时可以应急生产环境不推荐。性能损耗通常在30%到70%之间有些计算密集的应用甚至可能差一个数量级。而且qemu模拟出来的环境偶尔会有诡异的兼容性问题——文件锁不可靠、glibc版本冲突、内存分配异常——排查起来非常痛苦。7.4 龙芯Docker落地建议在龙芯机器上用过一两个月之后我的个人体会是不要期待镜像拿来就能跑。在龙芯上Docker更像是一个打包分发工具而不是软件超市。你的重点应该放在构建自己的LoongArch镜像而不是到处找现成的第三方镜像。优先选与龙芯合作密切的Linux发行版它们的源里已经适配了大多数常用软件apt或者yum直接装好的二进制包远比自己用qemu模拟x86镜像靠谱。监控内存占用龙芯机器目前常见于信创办公环境服务器内存普遍不大容器数量多了以后swap频繁会导致性能雪崩。docker stats要养成习惯看。留一条传统安装的退路。有些核心数据库、任务调度组件如果实在找不到LoongArch镜像就老老实实装系统原生包。稳定压倒一切别为了必须用Docker而强行折腾。关于LoongArch架构的Docker生态这几年其实在逐步完善官方镜像列表里出现loong64的tag也越来越多。如果你是国产化平台的用户建议多关注龙芯开源社区和厂商适配清单信息更新速度远比Docker Hub的tag页面更快。写在最后给新手的几条操作建议文章写到这该聊的基本都聊了。最后分享几条我实际用下来的经验希望对刚开始接触Docker的你有点帮助。第一不要背命令要学会看帮助。docker run --help、docker compose --help、docker buildx --help这些帮助信息写得比绝大多数教程都清楚。遇到不熟悉的参数先查help比网上搜答案快而且不容易被过时信息误导。第二把常用启动命令固化成文件。不管是用docker-compose.yml还是简单的shell脚本只要是你需要重复部署的环境一定不要依赖上次敲过的命令。我在文章里反复强调Compose的价值实际使用中一份几十行的YAML文件比一长串docker run参数直观得多也方便版本管理。第三养成看日志的习惯。容器起不来、网络不通、数据同步失败90%的问题都能在docker logs里找到线索。而且Docker的日志通常打印得很清楚看到一个关键字配合搜索引擎基本上能解决绝大多数问题。第四注意容器是临时的数据卷才是永久的。这是Docker装软件最容易踩的坑——以为数据在容器里结果容器一删数据全没了。只要涉及数据库、配置文件、脚本都给它挂上数据卷。Docker真正降低了安装和维护软件的门槛但前提是你理解了它的基本逻辑镜像负责打包容器负责运行数据卷负责持久化Compose负责编排。把这四个概念吃透Docker就从一个专门的工具变成了你日常开发和管理服务器的基础能力。希望这篇文章能帮你少走一点弯路。 Docker装软件实战：从环境配置到容器编排的完整指南
1. 用Docker装软件到底解决了什么问题先说个我自己的经历。前几年在一台服务器上装Redis系统是CentOS 7默认源里只有Redis 3.2但项目要用Redis 6的Stream类型只能自己编译。编译倒是不难难的是编译完发现系统里还装着一个PHP扩展它依赖老版本的libevent我一升级RedisPHP那边直接崩了。折腾了一下午最后老老实实把系统重装了一遍。这个场景你应该不陌生。传统方式安装软件的痛点总结起来就是三个依赖冲突、环境残留、升级困难。你在系统里装的每个软件都在往/usr/lib、/etc、/var下面塞东西软件多了以后谁也说不清哪个文件是谁的哪个库被谁覆盖了。Docker解决这个问题的方式很直接把软件连同它专属的操作系统环境一起打包成一个镜像。镜像就是一个只读模板里面已经装好了运行这个软件所需要的所有依赖、配置、动态链接库甚至包括特定的Linux发行版基础环境。当你运行这个镜像时Docker基于镜像创建一个独立的容器容器里的进程只能看到镜像里给它准备好的那一套环境跟宿主机其他的软件互不干扰。打个比方。传统安装像你往一个合租房里搬家具床、衣柜、书桌都摆在公共区域你搬进来一套沙发可能就得把别人的电视柜挪走。Docker则是每个软件住一间独立的精装公寓家具、电器、水管电线全部标配你想换房升级版本直接换一套公寓住进去就行旧公寓整间退掉干干净净。很多人问那我直接用虚拟机不也一样吗虚拟机是虚拟出一整台计算机里面装完整操作系统开销大、启动慢、资源占用高。容器则共享宿主机内核只隔离用户空间的进程、文件系统、网络和权限启动一个容器往往只要几百毫秒内存占用可能只有几十兆。正因为这个特性Docker特别适合用来装那些本身没有界面、以服务方式运行的后端软件数据库、缓存、消息队列、Web服务器、定时任务平台等等。不过也要说句公道话Docker不是万能的。以下几种情况我仍然建议你老老实实在宿主机装需要直通GPU做深度学习训练的虽然有nvidia-container-toolkit但配置成本不低对IO性能要求极其苛刻的数据库场景容器有存储驱动层的开销虽然现代驱动已经非常接近裸盘但极端场景还是有差距需要长期跑桌面GUI应用的不是不能跑但显示方案绕来绕去体验一般。除此之外用Docker安装部署软件的收益是非常明显的。这篇就围绕我自己折腾Docker装软件的经验从环境准备、单容器实战、编排实战、依赖管理到开发者集成、特殊架构适配完整梳理一遍。2. 环境准备Windows、macOS、Linux下的Docker安装与镜像加速配置2.1 不同系统的正确安装姿势Docker本身是Linux上的原生技术它依赖Linux内核的namespace命名空间和cgroups控制组这两个核心机制来实现隔离和资源限制。你在Windows或macOS上装Docker本质上是装一个轻量级Linux虚拟机然后在虚拟机里跑Docker引擎。Docker Desktop帮你把这一层封装好了所以你几乎感觉不到虚拟机的存在。不同系统下的安装选型我直接给结论操作系统推荐方案说明Windows 10/1164位支持WSL2Docker Desktop for Windows用WSL2作为后端性能和体验都最好Windows Serverdocker-ce containerd原生Windows容器或Linux容器均可生产环境常用macOSIntel/Apple SiliconDocker Desktop for MacApple Silicon上自动用VirtioFS加速文件共享Ubuntu/Debian官方apt源安装docker-ce不要装老旧系统源里的docker.ioCentOS/RHEL/Rockyyum/dnf安装docker-ce需要先配置官方或镜像源龙芯/飞腾等国产平台系统厂商维护的docker-engine包或源码编译见第7章详细讲Windows下安装Docker Desktop我需要强调一个前置条件必须先启用WSL2。很多人装完Docker Desktop提示启动失败十有八九是没装Linux内核更新包或者没有在控制面板→启用或关闭Windows功能里勾选适用于Linux的Windows子系统和虚拟机平台两个选项。装完这两个组件后重启再在管理员PowerShell里执行wsl --set-default-version 2最后再装Docker Desktop一路Next就不会有问题。Linux下用官方脚本安装是最省事的curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh这个脚本会自动检测你的发行版配置官方仓库然后安装docker-ce、docker-ce-cli、containerd.io、docker-compose-plugin这些组件。不想用官方脚本的话Ubuntu可以手动添加Docker的apt源CentOS则添加yum源网上文档很多但核心就两步导入GPG密钥 写入repo文件。2.2 安装完之后必做的三件事不管哪个系统装完Docker先别急着拉镜像做下面三件事第一把当前用户加入docker组仅限Linux/macOS。默认情况下只有root和docker组的用户能操作Docker守护进程不然每条命令都要加sudo麻烦且容易出权限问题sudo usermod -aG docker $USER newgrp docker注意把用户加入docker组相当于授予该用户root级别的宿主机权限因为docker组可以挂载宿主机目录、执行特权容器。个人开发机没问题生产环境服务器要谨慎。第二配置镜像加速器。Docker Hub部署在国外直接拉镜像经常几KB/s甚至超时。国内各大云厂商都提供registry mirror服务它本质上是一个Docker镜像的代理缓存你把Docker守护进程的registry-mirrors指向它拉镜像时优先从国内节点下载。在Docker Desktop里打开Settings → Docker Engine编辑JSON{ registry-mirrors: [ https://docker.m.daocloud.io, https://dockerproxy.com ] }Linux环境下则编辑/etc/docker/daemon.json然后sudo systemctl restart docker。补充加速器地址不是我随便写的云厂商的加速器地址通常是https://xxxx.mirror.aliyuncs.com这种每个人账号对应的地址不同需要登录容器镜像服务控制台获取。上面给的公共加速器我实测过但仍然建议你优先用自己的——公共节点负载高宕机是常事。另外别把加速器地址当成什么见不得光的东西它就是一个常规的镜像源配置。第三验证Docker是否正常工作docker run --rm hello-world这个测试镜像只有几KB运行后会打印一段Docker工作正常的说明然后退出。如果这一步能顺利跑通说明引擎、网络、镜像拉取链路都没问题。2.3 为什么加速器配置要放在环境准备阶段我在帮别人排查Docker问题的时候发现80%的拉镜像失败都和网络有关但很多人第一反应是去改容器配置、换镜像tag结果白折腾。拉镜像是最容易被网络影响的环节而配置加速器是最低成本、最立竿见影的优化手段。关于镜像加速的原理我再多说一句。当你执行docker pull redis:7.2时Docker守护进程并不是直接从Docker Hub下载blob而是先去Hub查索引然后根据索引信息去Registry拉取层数据。配置registry-mirrors后Docker会优先从mirror地址拉取——mirror本身会和源站同步数据你在国内拉取时走的其实是国内节点。这样一来原本可能需要几分钟甚至超时的下载通常能缩短到十几秒。3. 首个容器实战以Redis为例跑通拉取-运行-验证3.1 直接run还是先pull先用好tag制度很多教程上来就让你docker run redis实际Docker会先自动帮你拉取镜像再运行所以很少有人单独执行docker pull。但我建议新手还是先手动pull一次原因很简单你要清楚自己拉的是什么版本。Redis镜像在Docker Hub上的tag规则非常明确redis:latest最新稳定版不推荐生产环境使用因为不可控redis:7.27.2系列的最新补丁版本推荐日常使用redis:7.2-alpine基于Alpine Linux的精简版体积只有几十MBredis:7.2-bookworm基于Debian Bookworm的标准版功能最全redis:7.0.14精确到小版本号锁定不变。我的习惯是本地测试用alpine系列体积小、启动快生产环境用bookworm或官方默认的Debian系列因为Alpine用的是musl libc个别原生模块可能编译不兼容。docker pull redis:7.2-alpine3.2 带持久化和密码的运行参数详解拉完镜像执行下面这条命令这是Docker装软件最核心的一条命令docker run -d \ --name redis-test \ -p 6379:6379 \ -v redis-data:/data \ -e TZAsia/Shanghai \ redis:7.2-alpine \ redis-server --appendonly yes --requirepass MyPassw0rd逐个解释参数这些都是你后面装任何软件都要用到的-d后台运行detach模式不加这个参数容器会占用终端日志直接刷屏--name redis-test给容器起名字后续docker start/stop/logs/exec都用这个名字操作-p 6379:6379端口映射宿主机6379端口转发到容器内6379端口。容器内是一个隔离的网络空间不映射的话宿主机上的程序访问不到它-v redis-data:/data数据卷挂载冒号前是宿主机上的卷名或绝对路径冒号后是容器内的目录。Redis的AOF持久化文件默认存在/data如果不挂载卷容器一旦删除所有数据全部消失-e TZAsia/Shanghai设置容器内时区。容器默认是UTC时区比北京时间慢8小时跑定时任务时会踩坑redis-server --appendonly yes --requirepass MyPassw0rd这后面的参数是传给容器内Redis主进程的命令行参数。镜像默认的启动命令就是redis-server你可以追加参数覆盖默认配置。关于-v我要多说一句。这里我用了卷名redis-data而不是/home/user/data这种绝对路径。两者的区别是具名卷由Docker管理存储在/var/lib/docker/volumes/下迁移、备份用docker volume命令很方便绑定挂载bind mount则直接把宿主机目录映射进容器你可以在宿主机上直接看到和修改文件。数据库类应用我建议用具名卷省心、权限问题少需要直接在宿主机上改配置文件、看日志的用绑定挂载更直观。3.3 验证容器是否真的在干活运行起来之后新手最容易犯的错就是以为容器跑起来了其实它早就退出了。验证方法是一套组合拳# 查看容器状态STATUS显示Up表示正常运行Exited说明已退出 docker ps -a # 查看日志这是排障第一入口 docker logs redis-test # 进入容器内部执行命令 docker exec -it redis-test sh # 在容器内用redis-cli验证 redis-cli -a MyPassw0rd ping # 应该输出PONG如果docker ps -a显示容器Exited不要慌用docker logs redis-test看退出原因。最常见的几种情况端口被占用报错bind: address already in use换宿主机的映射端口即可配置文件参数写错Redis会打印Bad directive or wrong number of arguments权限不足挂载的数据卷目录属主不对容器内redis用户写不进去。还有一个排查利器是docker inspectdocker inspect redis-test它会输出容器完整的配置信息包括挂载的卷、环境变量、网络配置、退出码、重启策略等。JSON很长可以配合grep或jq过滤关键字段docker inspect redis-test | grep -A 5 Mounts docker inspect redis-test | jq .[0].State到这里你已经完成了用Docker安装并运行第一个软件的完整流程。这条路径——拉镜像、起容器、配参数、验证状态——是所有Docker装软件场景的共同母题。4. 进阶编排用Docker Compose搭建Redis主从复制集群4.1 为什么单容器不够用了单个Redis容器解决的是有一个Redis能用的问题。但实际开发中你可能需要一主一从做读写分离或者一主两从加哨兵做高可用。这时候用docker run一条条命令敲也不是不行但有两个问题容器之间要联网通信你得先自己创建自定义网络再在启动时指定--network步骤繁琐整套环境的配置散落在历史命令里换一台机器部署全部重来。Docker Compose就是为了解决多容器环境编排而存在的。它用一个YAML文件描述整套服务的配置docker compose up -d一条命令全部拉起docker compose down一键全部销毁。4.2 先搞懂主从复制的原理再写配置Redis主从复制的基本逻辑从节点启动后向主节点发送SYNC命令新版本是PSYNC主节点生成RDB快照发送给从节点之后主节点把每一次写操作以命令流的方式持续转发给从节点。所以从节点能实时同步主节点的数据。在原生Redis里配置从节点只需要在redis.conf加一行replicaof master-ip master-portDocker环境下主节点容器的IP不是固定的除非指定固定IP所以更优雅的做法是利用Docker内置的DNS解析——在同一个自定义网络里容器可以通过服务名直接访问对方。这就是Compose文件天然适合做多容器架构的原因。4.3 docker-compose.yml完整配置下面是一份我实测过的docker-compose.yml实现一主一从带密码验证services: redis-master: image: redis:7.2-alpine container_name: redis-master restart: unless-stopped ports: - 6379:6379 volumes: - redis-master-data:/data environment: - TZAsia/Shanghai command: redis-server --appendonly yes --requirepass MasterPass --masterauth MasterPass redis-slave: image: redis:7.2-alpine container_name: redis-slave restart: unless-stopped ports: - 6380:6379 volumes: - redis-slave-data:/data environment: - TZAsia/Shanghai depends_on: - redis-master command: redis-server --appendonly yes --requirepass SlavePass --replicaof redis-master 6379 --masterauth MasterPass volumes: redis-master-data: redis-slave-data:这个配置里几个关键点--replicaof redis-master 6379从节点通过服务名redis-master找到主节点Docker内置DNS会解析到主节点容器的IP--requirepass和--masterauth主节点要求客户端认证所以从节点同步时也必须提供密码两个参数要配套设置否则从节点会一直报NOAUTH Authentication requireddepends_on声明启动顺序从节点等主节点先启动。但实际上Redis的replicaof机制有自动重连即使主节点晚启动从节点也会持续重试所以这个字段更像是一种友好声明restart: unless-stopped容器异常退出或宿主机重启时自动拉起生产环境必备。启动方式docker compose up -d4.4 验证主从同步是否正常全部启动后分别验证两个容器状态docker ps # 确认两个容器都是Up状态 # 登录从节点查看复制状态 docker exec -it redis-slave redis-cli -a SlavePass info replication输出里关注几个字段role:slave确认当前节点角色是从节点master_host:redis-master确认主节点地址解析正确master_link_status:up这是最关键的只有up才表示主从连通master_last_io_seconds_ago距离上次和主节点通信的时间数字过大说明同步不健康。然后再验证数据同步# 在主节点写入数据 docker exec -it redis-master redis-cli -a MasterPass set name docker # 在从节点读取 docker exec -it redis-slave redis-cli -a SlavePass get name # 输出 docker 说明同步正常我踩过的一个坑值得提醒如果主节点设置了requirepass而从节点没有正确设置masterauth从节点的日志会每隔几秒打一条错误MASTER - REPLICA sync: Master replied to PING, replication can continue...主节点返回了PING但因为没带认证信息后续的同步请求会被拒绝。此时用docker logs redis-slave能非常清晰地看到NOAUTH字样马上就能定位问题。5. 基础软件的进阶玩法青龙面板的容器依赖管理5.1 为什么容器化部署对这类应用特别友好青龙面板是一个定时任务管理平台在Docker环境下非常流行。这类平台本身就是多语言脚本的执行环境涉及Node.js、Python、JavaScript等运行时的各种依赖库。如果用传统方式部署你得在服务器上手动装Node.js、Python、pip、npm还要处理版本冲突而用Docker镜像里已经把运行时环境全部备好了docker run -d \ --name qinglong \ -p 5700:5700 \ -v ql-data:/ql/data \ -e TZAsia/Shanghai \ whyour/qinglong:latest启动后访问http://宿主机IP:5700就能进入Web界面。一个定时任务平台从下载到运行只需要几分钟这就是容器化的价值。但这里真正值得展开讲的不是启动而是依赖管理——这是我在使用过程中踩坑最多的地方。5.2 容器内依赖管理三个常见误区误区一直接在容器里手动安装依赖然后以为一劳永逸。你会看到很多教程让你执行docker exec -it qinglong bash npm install -g xxx pip install xxx这在当下是生效的但容器一旦重建升级镜像、服务器迁移、异常回滚所有手动安装的依赖全部消失。因为容器本身是临时的数据卷持久化的只是/ql/data目录而npm的全局包安装在容器文件系统里不属于持久化数据。误区二所有依赖都装到全局。有些依赖只在某个特定脚本里用到装成全局包反而容易版本冲突。比如一个脚本要求requests2.28.1另一个脚本要求requests2.31.0全局只能装一个。误区三忽视依赖的时区设置导致的定时任务偏差。青龙镜像虽然可以通过-e TZAsia/Shanghai设置时区但如果你管理的任务脚本内部使用了datetime.now()它读取的是脚本运行时环境的时区不是数据库里的时区。这个问题在容器里表现得尤为隐蔽因为容器基础镜像默认UTC如果你忘了设置环境变量定时任务会准时提前8小时执行。5.3 我推荐的依赖管理方案自定义镜像 启动初始化脚本依赖管理最稳妥的思路是把依赖固化到镜像里而不是临时装进容器里。具体做法是写一个自己的DockerfileFROM whyour/qinglong:latest # 设置时区 ENV TZAsia/Shanghai # 安装系统级依赖 RUN apk add --no-cache tzdata bash curl # 安装Python依赖 RUN pip3 install --no-cache-dir requests apscheduler pycryptodome # 安装Node依赖 RUN npm install -g pnpm ts-node typescript # 声明数据卷沿用官方镜像配置 VOLUME /ql/data然后构建并运行docker build -t qinglong-custom:v1 . docker run -d --name qinglong -p 5700:5700 -v ql-data:/ql/data -e TZAsia/Shanghai qinglong-custom:v1这样每次重建容器镜像里已经包含了声明的依赖不会再丢失。不足是这个方案有个学习成本你需要了解Dockerfile的编写并且更新镜像时要重新构建。如果不想用Dockerfile日常维护也可以把pip和npm的依赖清单存到数据卷里# 在宿主机上建目录挂载为容器的初始化目录 docker run -d \ -v $(pwd)/qinglong-init:/ql/init \ ...然后在Web界面里把依赖管理配置成从文件读取。具体来说青龙面板的依赖管理支持你保存一份依赖清单在依赖缺失时会触发安装。5.4 容器重建后快速恢复依赖的实操清单我自己的服务器上跑着青龙容器一次升级镜像把所有依赖搞丢之后我给自己的恢复流程定了个规矩升级前先导出清单docker exec -it qinglong pip3 freeze requirements.txtNode端用npm list -g --depth0导出升级后不急着配脚本先让容器跑起来然后通过Web界面的依赖管理把上一步导出的清单重新安装装完必须做冒烟验证随便挑一个依赖库执行python3 -c import requests; print(requests.__version__)确认核心依赖锁定了版本。这套流程经历过两次实际验证比之前手动一个个装回去节省了大量时间。6. 开发提效IDEA一键打包Docker镜像6.1 为什么建议直接在IDEA里完成镜像打包Docker不只是运维用来装软件的工具对开发者来说它也是应用交付的重要载体。过去把Spring Boot应用打成镜像流程是本地mvn package打出jar包 → 写Dockerfile → scp到服务器 → ssh登录服务器 → docker build → docker run。链路过长每步都有可能出错。IDEA自带的Docker插件把最后几步集成进了IDE。你在配置里指定Dockerfile路径和构建参数点击执行IDEA自动帮你完成构建、推送、甚至部署到远程服务器。对于频繁迭代开发环境的场景效率提升非常明显。6.2 从零配置连接Docker与Run Configuration第一步让IDEA能连上Docker守护进程。如果Docker和IDEA在同一台机器上Settings → Build, Execution, Deployment → Docker点击加号选择Docker DesktopWindows/macOS或Unix socketLinuxTest Connection显示成功即可。如果是远程服务器上的Docker需要在服务器上开启远程API访问。这一步有安全风险因为默认情况下Docker API没有认证任何人都能连上你的守护进程并执行任意命令。我建议至少配置TLS证书或者用SSH隧道方式连接ssh -L 2375:/var/run/docker.sock userserver然后在IDEA里用tcp://localhost:2375连接走SSH隧道转发比裸奔暴露2375端口安全得多。第二步写好Dockerfile。以常见的Spring Boot应用为例# 多阶段构建 FROM maven:3.9-eclipse-temurin-17 AS builder WORKDIR /app COPY . . RUN mvn clean package -DskipTests # 运行阶段 FROM eclipse-temurin:17-jre WORKDIR /app COPY --frombuilder /app/target/*.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, app.jar]多阶段构建的核心价值是把构建环境和运行环境分开。构建阶段用maven镜像里面有完整的JDK和Maven体积几个GB运行阶段只拷贝最终产出的jar包基于精简的JRE镜像最终镜像可能只有200MB。第三步配置Run Configuration。在IDEA右上角选择 Edit Configurations新增Dockerfile运行配置指定Dockerfile路径镜像tag建议写成${project.name}:v1。点击运行IDEA的底部会实时输出构建日志构建完成后自动注册到本地镜像库。6.3 打包过程中最常见的坑镜像体积过大。如果不做多阶段构建而是用FROM maven:3.9直接在上面打包运行镜像体积会膨胀到几个GB。多阶段构建是必须的不是可选优化项。时区问题。容器默认UTC时区Java应用打印的日志时间会比北京时间慢8小时。打包时在Dockerfile里加上ENV TZAsia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime echo $TZ /etc/timezone第二句可能因基础镜像缺少tzdata包而报错所以有时要先apt-get install -y tzdata或apk add tzdata。.dockerignore没写。没有.dockerignore的话构建上下文会把整个项目目录包括target/、.git/、logs/都发给Docker守护进程构建速度慢到怀疑人生。在项目根目录放一个target/ .git/ .idea/ *.iml logs/依赖缓存失效。Maven构建最耗时的部分是下载依赖每次构建都重新下意味着白白浪费时间。优化做法是利用Docker层缓存机制把依赖下载单独放一层COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package只要pom.xml没变这一层就可以直接复用缓存后续构建时间从几分钟降到几秒。7. 国产化适配龙芯机器上跑Docker的实践经验7.1 龙芯平台的特殊性龙芯处理器采用的是自主指令集LoongArch不是大家更熟悉的x86Intel/AMD也不是ARM。这意味着市面上绝大多数现成的Docker镜像——不管官方还是第三方——都没有针对龙芯编译过的版本。你执行docker pull mysql:8.0大概率会得到一句no matching manifest for linux/loong64 in the manifest list entries。这不是Docker本身的问题而是镜像的提交者没有构建LoongArch架构的版本。理解这一点是搞定龙芯Docker的第一步。7.2 在龙芯上安装Docker引擎龙芯的新版本统信UOS、麒麟等操作系统通常已经在源里带了docker-engine或docker-ce包优先用系统源安装因为官方已经做了适配# 以统信UOS/麒麟为例 sudo apt update sudo apt install docker.io sudo systemctl enable --now docker或者使用龙芯开源社区维护的安装包覆盖面更广。安装完验证一下架构docker info | grep Architecture # 输出应为 loong64 或 loongarch64注意这里有个容易混淆的点LoongArch的Docker架构标识是loong64还是loongarch64取决于Docker版本的规范写法。较新版本用的是loong64与Go语言对龙芯架构的命名保持一致。7.3 没有现成镜像的三种应对策略既然Docker Hub上几乎没有LoongArch的镜像我们实际用的时候有三个办法办法一寻找龙芯适配过的镜像源。龙芯团队维护了一套适配LoongArch的软件仓库和部分基础镜像包括golang、openjdk、python、nginx、redis等常用软件的LoongArch版本。虽然数量远不如Docker Hub丰富但覆盖了最常见的基础设施。办法二源码/包管理方式构建。这是最通用的兜底方案。以Redis为例龙芯的Linux发行版源里通常带了redis的LoongArch版本直接apt install redis或者从源码编译。编译后和官方包行为一致。虽然这回归了传统安装方式但你可以把它做成自定义镜像以后分发就方便了FROM loong64/debian:bookworm-slim RUN apt update apt install -y redis-server CMD [redis-server, --bind, 0.0.0.0]办法三用qemu-user模拟跨架构镜像。Docker支持在非原生架构上运行其他架构的镜像原理是用qemu-user做用户态指令翻译。你可以启用buildx的cross-platform模拟docker run --privileged --rm tonistiigi/binfmt --install all docker pull --platform linux/arm64 mysql:8.0 docker run --platform linux/arm64 mysql:8.0但我要泼一盆冷水这种方式在开发测试时可以应急生产环境不推荐。性能损耗通常在30%到70%之间有些计算密集的应用甚至可能差一个数量级。而且qemu模拟出来的环境偶尔会有诡异的兼容性问题——文件锁不可靠、glibc版本冲突、内存分配异常——排查起来非常痛苦。7.4 龙芯Docker落地建议在龙芯机器上用过一两个月之后我的个人体会是不要期待镜像拿来就能跑。在龙芯上Docker更像是一个打包分发工具而不是软件超市。你的重点应该放在构建自己的LoongArch镜像而不是到处找现成的第三方镜像。优先选与龙芯合作密切的Linux发行版它们的源里已经适配了大多数常用软件apt或者yum直接装好的二进制包远比自己用qemu模拟x86镜像靠谱。监控内存占用龙芯机器目前常见于信创办公环境服务器内存普遍不大容器数量多了以后swap频繁会导致性能雪崩。docker stats要养成习惯看。留一条传统安装的退路。有些核心数据库、任务调度组件如果实在找不到LoongArch镜像就老老实实装系统原生包。稳定压倒一切别为了必须用Docker而强行折腾。关于LoongArch架构的Docker生态这几年其实在逐步完善官方镜像列表里出现loong64的tag也越来越多。如果你是国产化平台的用户建议多关注龙芯开源社区和厂商适配清单信息更新速度远比Docker Hub的tag页面更快。写在最后给新手的几条操作建议文章写到这该聊的基本都聊了。最后分享几条我实际用下来的经验希望对刚开始接触Docker的你有点帮助。第一不要背命令要学会看帮助。docker run --help、docker compose --help、docker buildx --help这些帮助信息写得比绝大多数教程都清楚。遇到不熟悉的参数先查help比网上搜答案快而且不容易被过时信息误导。第二把常用启动命令固化成文件。不管是用docker-compose.yml还是简单的shell脚本只要是你需要重复部署的环境一定不要依赖上次敲过的命令。我在文章里反复强调Compose的价值实际使用中一份几十行的YAML文件比一长串docker run参数直观得多也方便版本管理。第三养成看日志的习惯。容器起不来、网络不通、数据同步失败90%的问题都能在docker logs里找到线索。而且Docker的日志通常打印得很清楚看到一个关键字配合搜索引擎基本上能解决绝大多数问题。第四注意容器是临时的数据卷才是永久的。这是Docker装软件最容易踩的坑——以为数据在容器里结果容器一删数据全没了。只要涉及数据库、配置文件、脚本都给它挂上数据卷。Docker真正降低了安装和维护软件的门槛但前提是你理解了它的基本逻辑镜像负责打包容器负责运行数据卷负责持久化Compose负责编排。把这四个概念吃透Docker就从一个专门的工具变成了你日常开发和管理服务器的基础能力。希望这篇文章能帮你少走一点弯路。