说实话从“docker”、“容器技术”这两个词衍生出来的搜索记录基本能把一个后端开发者这几年的成长轨迹看个七七八八从“docker是干什么的”到“ubuntu 安装docker”再到“docker安装redis主从”、“docker部署微服务项目”最后卡在“permission denied while trying to connect to the docker api”这种报错上。我也经历过这个过程所以这篇东西不打算写什么官方文档翻译就按一个实际用过、也踩过坑的人的口吻把容器技术这条线从头捋一遍。不管是刚准备学docker的小白还是已经在部署mysql、redis但被各种问题卡住的进阶用户这篇文章应该都能给你一点参考。1. 再聊容器这件事你现在学Docker到底在学什么1.1 容器为什么能成为“部署标配”很多新手第一次接触docker是从“装环境”开始的MySQL装不上、Redis老出问题、换了电脑项目跑不起来有人告诉你“用docker装特别方便”于是你开始了docker之旅。但学了一段时间后你会发现docker的价值根本不只是“方便装软件”而是一种彻底改变软件交付方式的思路。过去部署一个应用流程是买服务器、装操作系统、装编译器、装数据库、装中间件、配置环境变量、把代码传上去、启动。问题是环境是“一次性”的换一台机器就得重新折腾一遍。容器技术解决的正是这个“环境一致性”问题你把应用和它的运行环境一起打包成镜像镜像里已经包含了代码、运行时、依赖库、配置文件扔到哪儿都能以同样的方式跑起来。我的理解是容器本质上是把“部署环境”从一个物理概念变成了一个文件概念。以前环境是机器的一部分现在环境是镜像的一部分。这就是为什么docker能成为CI/CD、微服务、云原生这些名词的共同底座——所有自动化流程最终都要落到一个标准化的运行单元上而容器就是这个单元。1.2 镜像、容器、仓库三个概念一次说透这三个概念是理解docker的第一道门槛。我用一个做饭的类比来说明镜像Image就像“菜谱加上所有预处理好的食材”——它是一套完整的、只读的模板里面包含了运行一个应用所需要的全部内容操作系统基础层、依赖库、配置、代码。镜像可以反复使用同一条命令启动多少次生成的都是同质的实例。容器Container是“按菜谱正在做的菜”——它是镜像运行时的实体有一个可写的临时层。对镜像做的修改比如在容器里装个软件、改个文件都在这个临时层里容器删除后这些修改也就没了。仓库Repository是“存放食材和菜谱的菜市场”——镜像从仓库拉取或推送最出名的自然是Docker Hub也有各云厂商的镜像仓库、私有仓库比如Harbor。这三个概念对应着docker日常操作里最基础的三个动作docker pull从仓库拉镜像、docker run用镜像启动容器、docker commit/build把容器改动或Dockerfile构建成新镜像。很多人学docker喜欢死记命令其实只要把这三者的关系理清了后面的命令都是顺着这个逻辑延伸出来的。2. 环境安装不同操作系统下的选型与避坑2.1 Windows下Docker DesktopWSL2后端和授权问题Windows上安装docker绕不开Docker Desktop。但先提醒一句Docker Desktop对个人和小公司员工少于250人且年收入低于1000万美元免费大型企业需要用付费订阅。如果你是在公司电脑上装先确认一下授权问题避免后续法律风险。Docker Desktop现在的默认后端是WSL2Windows Subsystem for Linux 2而不是老版的Hyper-V。这个变化的意义在于WSL2启动快、内存占用相对可控而且和你本机的Linux环境是打通的。安装时需要注意Windows 10 版本要在 2004 以上Windows 11 没问题。安装前最好在“启用或关闭Windows功能”里勾选“适用于Linux的Windows子系统”和“虚拟机平台”。安装完成后如果提示virtualization support not detected请先到BIOS里确定虚拟化技术Intel VT-x / AMD-V已开启。这个报错在网上非常高频90%的情况就是BIOS虚拟化没开或者在“Windows功能”里缺少了相关组件。如果你的电脑没有WSL2或虚拟化受限也可以选用WSL1或Hyper-V但我建议别折腾直接用WSL2最省心。实测下来Docker Desktop在WSL2模式下的磁盘性能比老版Hyper-V模式好很多尤其是构建镜像、读写挂载目录的时候差距体感明显。2.2 Ubuntu与CentOS的命令行安装服务器上安装docker走命令行是常态。Ubuntu和CentOS的安装路径略有不同。Ubuntu这边官方推荐用安装脚本一条命令curl -fsSL https://get.docker.com | sh如果你在云服务器上网络正常情况下这条脚本会自动配置好软件源并安装docker-ce。装完以后顺手下三个命令sudo systemctl enable docker sudo systemctl start docker sudo systemctl status dockerCentOS 7 的情况比较特殊。很多老教程让你yum install docker那个是老版本1.13现在基本不建议这么装。推荐用清华或阿里云镜像仓库里的 docker-ce 源来装。大致流程是sudo yum install -y yum-utils sudo yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo sudo yum install -y docker-ce docker-ce-cli containerd.ioCentOS 7默认内核3.10虽然能跑docker但一些新特性比如overlay2存储驱动、iptables规则行为在老内核上偶尔有兼容问题。如果你在CentOS 7上遇到不明原因的docker网络异常先看看内核版本能升级尽量升级到长期维护版本。装完之后先验证docker version docker infodocker version能看到客户端和服务端两个版本信息如果服务端没起来会出现无法连接到docker daemon的提示。2.3 镜像拉取慢的通用解法镜像下载慢几乎是大陆用户绕不过去的问题。官方Docker Hub在国内访问不稳定几十MB的镜像能拉到人睡着。解决办法是配置镜像加速地址也就是registry mirror。做法很简单编辑/etc/docker/daemon.json没有就新建{ registry-mirrors: [ https://your-id.mirror.aliyuncs.com ] }注意your-id换成你自己的。阿里云容器镜像服务里有专属加速地址登录控制台就能看到。其他云厂商也提供类似服务原理都一样就是让你从就近的镜像缓存下载而不是直接连Docker Hub。改完配置后重启dockersudo systemctl daemon-reload sudo systemctl restart docker说几个实测要注意的点daemon.json改坏了docker可能会启动失败改之前先备份。配置了加速地址不代表所有镜像都能加速某些冷门镜像可能还是慢这是正常的。如果是内网环境最稳妥的办法是自建一个镜像仓库把常用镜像预先拉取后推送到内网各节点统一从内网拉取。公司里大规模使用docker基本都会走这个方案。3. 从docker run开始一个容器完整的一生3.1 一条docker run到底发生了什么新手喜欢把docker run当作“启动命令”来背但它背后其实是一套完整的生命周期。当你运行docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD123456 mysql:8.0docker做的工作包括检查本机有没有mysql:8.0镜像没有就去仓库拉取解压镜像并创建一个可写层分配一个容器ID和文件系统通过网络配置分配容器IP执行镜像里定义的启动命令最后把启动的进程托管给docker daemon。理解了这个过程你就能推测很多问题的原因了为什么容器删了之后改动也没了因为可写层跟着容器走为什么docker pull之后容器启动很快因为镜像已经在本机缓存了为什么docker run里写了端口映射但连不上那就要往网络层排查。3.2 核心参数逐个拆解docker run的参数看着多常用且必须理解的就这几个参数作用备注-d后台运行容器不占用终端不加这个容器在前台运行CtrlC会终止容器-p 宿主机端口:容器端口端口映射宿主机上访问指定端口流量转发到容器内的端口-v 宿主机目录:容器目录目录挂载把宿主机目录映射进容器数据持久化的关键--name指定容器名后续docker exec、docker rm都可以用名字代替ID-e KEYVALUE设置环境变量MySQL的root密码、时区等常用它传入--restartalways容器退出后自动重启服务器重启后容器也能自动拉起--network指定网络容器之间要互相访问时让它们加入同一个自定义网络以我个人的习惯凡是需要持久化数据的容器-v是必须的不然容器一删数据全没。凡是提供服务的容器--restartalways是必须的不然服务器宕机重启你的数据库可能就再也起不来了。凡是需要对外访问的容器-p的宿主机端口尽量选不常见的减少被扫描爆破的概率。3.3 为什么连不上容器里的服务端口映射与网络排查“docker安装mysql失败”这个搜索词背后的真实场景大概率是镜像拉下来了、容器也启动了但宿主机上就是连不上MySQL。我先说结论如果容器已经正常运行宿主机连不上九成原因出在端口映射或者防火墙而不是docker本身。端口映射的原理是docker会在宿主机上创建一个端口转发规则实际通过iptables实现宿主机访问3306端口时流量被NAT转发给容器IP的3306端口。所以先用docker ps确认容器在运行。再确认docker run时确实写了-p 3306:3306。然后在宿主机上telnet 127.0.0.1 3306试试通不通。如果不通查防火墙systemctl status firewalld或ufw status。云服务器还要检查安全组的入站规则默认只开放了22端口其他端口需要在控制台放行。还有一种情况容易被忽略容器里服务监听的IP不对。MySQL空洞默认是监听所有地址但某些应用镜像可能只监听了127.0.0.1那即使端口映射正确外部也访问不了。所以排查的时候最好进容器看一眼服务实际监听在哪个地址上。4. 实战部署MySQL、Redis与Compose编排4.1 MySQL 8.0容器化完整命令与参数含义MySQL是容器化部署最典型的案例。我给一个生产环境常用的启动方式命令里的每个参数都有讲究docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORDYourStrongPass \ -e TZAsia/Shanghai \ -v /data/mysql:/var/lib/mysql \ -v /etc/localtime:/etc/localtime:ro \ --restartalways \ mysql:8.0 \ --character-set-serverutf8mb4 \ --collation-serverutf8mb4_unicode_ci几个容易被忽略的点-v /data/mysql:/var/lib/mysql把MySQL的数据目录挂载到宿主机这样删容器、升级镜像都不会丢数据。-e TZAsia/Shanghai和-v /etc/localtime:/etc/localtime:ro是为了解决容器内外时间不一致的问题。MySQL日志里的时间和系统时间对不上排查问题时会非常痛苦。命令最后跟着的两个参数是MySQL的启动配置项它们会传给mysqld进程。指定utf8mb4字符集是必须的否则默认字符集在插入emoji或部分中文时可能报错。MySQL 8.0默认的认证插件是caching_sha2_password旧版本的客户端驱动比如PHP 5.x、老Navicat连不上会报认证错误。如果遇到可以在创建用户时指定mysql_native_password或者升级客户端驱动。验证部署是否正常docker exec -it mysql8 mysql -uroot -p进入容器执行SQL没问题再在宿主机上用本机安装的mysql客户端或其他工具连一下测试端口。容器内localhost和容器外的localhost要分清楚这是很多新手最容易绕晕的地方。4.2 Redis主从容器部署同网络加配置Redis主从容器化部署核心思路就两条让容器之间能互相通信让从节点知道谁是主节点。先说一条命令部署单机版本docker run -d \ --name redis \ -p 6379:6379 \ -v /data/redis/data:/data \ -v /data/redis/redis.conf:/etc/redis/redis.conf \ --restartalways \ redis:7.0 \ redis-server /etc/redis/redis.conf注意最后的redis-server /etc/redis/redis.conf是容器启动时执行的命令如果没有这个容器会以默认配置启动你自己写的配置文件就形同虚设。这是一个非常经典的坑配置文件挂载了但容器并没有读取它。搭主从的思路先创建一个自定义网络让主从容器在同一个网络里通过容器名互相访问。docker network create redis-net启动主节点docker run -d --name redis-master --network redis-net -p 6379:6379 redis:7.0启动从节点docker run -d --name redis-slave --network redis-net -p 6380:6379 redis:7.0 \ redis-server --replicaof redis-master 6379从节点通过--replicaof redis-master 6379指定主节点这里用的是容器名redis-master而不是IP。容器名在同一个自定义网络里会自动解析为对应的容器IP这比写死IP更灵活——如果容器重建导致IP变化配置也不用改。验证主从同步状态docker exec -it redis-master redis-cli info replication如果看到connected_slaves:1就说明从节点已经连上主节点了。Redis 5.0以后原来的slaveof已经改叫replicaof网上老教程里的命令在新版本上可能不识别。4.3 用Docker Compose把多个服务编排在一起如果你需要同时部署MySQL、Redis、应用服务甚至再加上Nginx一个个docker run写下去会非常繁琐。这时候就应该用Docker Compose。Compose的核心是把容器定义写进一个 YAML 文件目录结构大致这样services: mysql8: image: mysql:8.0 container_name: mysql8 restart: always environment: - MYSQL_ROOT_PASSWORDYourStrongPass - TZAsia/Shanghai ports: - 3306:3306 volumes: - /data/mysql:/var/lib/mysql command: - --character-set-serverutf8mb4 - --collation-serverutf8mb4_unicode_ci redis: image: redis:7.0 container_name: redis restart: always ports: - 6379:6379 volumes: - /data/redis/data:/data app: build: . container_name: myapp restart: always depends_on: - mysql8 - redis ports: - 8080:8080启动的命令就两条docker compose up -d docker compose psCompose的价值不只是少敲几行命令更重要的是“基础设施即代码”——整套环境的定义变成了一个文件提交到代码仓库里任何人拉下来docker compose up -d就能得到一样的运行环境。这对团队协作、环境迁移的体验提升是革命性的。需要注意的是depends_on只能保证mysql8和redis先于app启动并不能保证数据库已经就绪。如果app启动就依赖数据库连接需要在应用代码里做重试逻辑或者使用healthcheck做健康检查。这是新手部署微服务项目时常遇到的坑。5. 常见报错与排查实录5.1 permission deniedDocker权限问题permission denied while trying to connect to the docker api这个报错出现的频率极高本质原因就是当前用户不在docker用户组里。默认情况下docker daemon 的 socket 文件/var/run/docker.sock属于root用户和docker用户组普通用户执行docker命令就会被拒绝。解决办法sudo usermod -aG docker 你的用户名执行完后重新登录或者重启虚拟机/重新连接SSH让用户组生效。然后docker ps测试一下。有个特殊情况有些管理工具或自建脚本用非root用户执行docker也会遇到这个报错。如果你是在CI/CD环境里更推荐的做法是让脚本所在用户加入docker用户组而不是直接把权限放到sudo因为docker用户组权限约等于root权限给谁加都要谨慎。还有一点如果你在容器内部使用docker命令Docker in Docker场景需要挂载docker.sock进去这个涉及权限的玩法更多新手先了解报错原因即可。5.2 virtualization support not detected虚拟化没开virtualization support not detected是Docker Desktop在Windows下启动失败的常见报错。原因基本就三个BIOS里虚拟化功能没开、Windows的虚拟化相关功能没启用、电脑上已经有其他虚拟化平台在占用。排查顺序按这个来重启电脑进BIOS设置找到Intel Virtualization TechnologyIntel或者SVM ModeAMD设为Enabled。不同品牌主板的名称略有差异但基本都是VT-x/AMD-V相关。Windows功能里确保“适用于Linux的Windows子系统”和“虚拟机平台”已勾选。控制面板的“程序和功能”里检查Hyper-V是否被其他软件禁用。某些版本的Android模拟器、老版本VMware会和WSL2冲突。命令行执行systeminfo在输出中查看“Hyper-V要求”的项目如果四条要求后面显示“已检测到虚拟机监控程序”则正常。如果在Windows 10上反复开启失败可以考虑关闭防火墙和杀毒软件后重装Docker Desktop但这种情况较少。多数情况下BIOS开启虚拟化后问题就解决了。5.3 容器起来了但端口不通这种情况前面在端口映射部分提过这里再整理一个完整的排查清单docker ps看容器状态和端口映射栏确认Ex(port)列显示有0.0.0.0:3306-3306/tcp如果没有箭头映射说明启动时根本没加-p参数。在宿主机上curl http://127.0.0.1:3306或者ss -lntp | grep 3306确认端口在监听。检查防火墙和安全组。CentOS用firewall-cmd --list-portsUbuntu用ufw status云服务器去控制台看安全组规则。如果宿主机通但局域网内其他机器不通重点查防火墙如果容器里能连但宿主机不能重点查端口映射和NAT规则。如果上面全没问题但容器内服务本身没起来docker logs 容器名看应用日志。还有一个容易忽略的同一台机器上两个容器都映射了同一个宿主机端口后面起的那个会启动报错或映射失败所以先docker ps -a看看是不是端口被占了。5.4 磁盘被镜像和日志吃满容器用久了磁盘空间莫名其妙就满了这是新手最容易忽略的运维问题。罪魁祸首通常有几个历史镜像和悬空镜像dangling images堆积。容器不删除日志文件不断膨胀。容器内的数据写进了可写层没有挂载到宿主机。清理命令docker system df docker image prune docker system prune -adocker system df能直观看到镜像、容器、数据卷、构建缓存各占多少空间。docker image prune清理悬空镜像没有被容器引用的镜像docker system prune -a更彻底会把所有未被使用的镜像都清理掉。需要注意你正在用的镜像一旦容器被删除且没有其他引用也可能被清掉所以执行前看清楚提示。日志膨胀的解决思路有两个一是限制容器日志大小在daemon.json里加{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }二是对已经膨胀的容器清空或滚动日志文件。注意不要直接删除json.log文件用truncate -s 0 /var/lib/docker/containers/*/*-json.log这类方式置空不然docker会一直持有文件句柄导致磁盘空间无法释放。从我自己踩过的坑来说数据卷和可写层的问题最隐蔽。如果你启动容器时没有用-v挂载目录应用写入的数据都在容器的可写层里容器一删数据全消失而且即使不删日志和临时文件也会把可写层撑爆导致容器整体空间告急。所以再次强调有状态的应用比如数据库一定要把数据目录挂出来。5.5 关于青龙、微服务、IDEA打包这类场景顺带说明热词里出现了一些具体场景简单提两句操作方向帮助有需要的读者少走弯路。青龙面板之类的管理类应用容器部署本身并不复杂docker run -d -p 5700:5700 --name qinglong whyour/qinglong就能起一个服务后续的依赖管理和脚本配置都在Web界面完成。依赖装不上多半是镜像版本和依赖源的问题建议直接换国内可用的软件源再重试。IDEA里打包docker镜像前提是IDEA能连上Docker daemon。Windows下可以通过Docker Desktop的TCP端口暴露给IDEALinux下可以直接连unix socket。配置好之后IDEA里右键Dockerfile选择运行即可构建镜像它会自动读取项目上下文。这种方式对Java开发者做镜像构建测试比较友好但正式CI/CD还是建议用Dockerfile加docker build命令在流水线里做。微服务项目的容器化部署思路是把每个服务做成独立镜像通过Compose编排在一起对外只暴露网关端口内部服务之间走自定义网络。消息队列、配置中心、注册中心这些中间件也全部容器化整个环境的可复制性会非常高。这也是我推荐每一个做后端的人都认真学一遍docker的原因——它不只是一个工具更是一种环境管理思维。6. 写在最后的个人体会折腾了这些年容器技术我最深的体会是docker不难难的是理解它的设计哲学。很多人都急着敲命令、跑镜像但遇到问题时就卡住了。归根结底是因为没理解镜像、容器、数据卷、网络这几对核心概念之间的关系。如果你刚开始学我建议的路子是先装好环境把docker run的几个核心参数摸透然后拿MySQL和Redis练手熟悉数据卷和端口映射再学Dockerfile自己写一个简单的Web服务镜像最后用Compose把一个前后端项目跑起来。这条路径走完你就已经超越了大多数只会拉镜像跑容器的人。最后分享一个小技巧养成看文档和日志的习惯。docker命令记不住没关系docker run --help、docker compose --help都有完整的参数说明容器出问题第一件事永远是docker logs它告诉你应用层面发生了什么。先不管网上那些花哨的运维面板和编排工具从一条命令、一个容器开始把基本功打扎实了后面学Kubernetes、学微服务编排你会觉得整个知识体系都是相通的。