Docker新手入门指南：从零掌握容器化技术与Ubuntu实战

简介这份《Docker 新手入门指南从零开始掌握容器化技术》面向缺乏容器化经验的新手开发者与运维人员帮助读者从概念到实战系统掌握 Docker。内容涵盖容器与虚拟机的差异对比、Ubuntu 环境下的安装与用户组配置、镜像与容器生命周期管理、调试与日志查看并以部署 WordPress 为例讲解 docker-compose.yml 编写与服务启动同时涉及数据卷与绑定挂载两种持久化方式及容器安全最佳实践。资源包为 1 个 PDF 文件约 760KB以图文与命令示例结合的形式呈现便于随时查阅对照。目前已有 1057 人学习适合希望快速上手容器化技术、通过动手实践巩固知识的初学者也可作为日常工作中的速查参考。1. 从一台干净的 Ubuntu 说起这份 Docker 指南到底能帮你省掉哪些弯路如果你手上有一台刚装好的 Ubuntu想跑个 Nginx 或者 WordPress却还在纠结「要不要装虚拟机」「端口怎么映射」「数据放哪不会丢」那这份《Docker 新手入门指南从零开始掌握容器化技术》基本就是冲着你写的。它没有一上来堆概念而是从容器化技术和传统虚拟机的对比切入把启动速度、资源占用、隔离级别、镜像体积这几个新手最容易懵的点用表格摆清楚然后顺着 Ubuntu 安装 Docker Engine、配置用户组、镜像与容器生命周期、docker-compose 部署 WordPress、数据卷与绑定挂载、安全实践一路推下去。适合谁刚接触容器化技术的开发者、运维以及被「docker 安装教程」「docker 常用命令」这类搜索词反复折磨、想一次把环境搭利索的人。它不承诺把你送进 K8s但能让你把单机容器这条线走通。2. 安装与权限Ubuntu 上把 Docker Engine 装干净2.1 为什么不用 apt 里那个 docker.ioUbuntu 官方源里确实有个docker.io包但版本往往落后而且和 Docker 官方维护的docker-ce在插件生态上不一致。常见做法是走 Docker 官方仓库这样docker compose子命令、buildx插件能一起装上后面写docker-compose.yml时不会出现「命令找不到」的尴尬。指南里给的步骤也是这个路子先卸旧包再配 keyring 和软件源最后装docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin。这里有个细节值得说containerd.io是底层运行时docker-ce-cli是命令行客户端三者版本要配套别单独升级某一个。# 卸载可能存在的旧版本避免冲突 sudo apt-get remove docker docker-engine docker.io containerd runc # 准备证书与密钥目录 sudo apt-get update sudo apt-get install ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings # 导入 Docker 官方 GPG 密钥 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \ sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg # 写入软件源VERSION_CODENAME 会自动取当前系统代号 echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] \ https://download.docker.com/linux/ubuntu \ $(. /etc/os-release echo $VERSION_CODENAME) stable | \ sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 安装核心组件与插件 sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io \ docker-buildx-plugin docker-compose-plugin # 验证能跑出 hello-world 就说明守护进程和客户端都通了 sudo docker run hello-world逻辑说明install -m 0755 -d是建目录并给权限gpg --dearmor把 ASCII 密钥转成二进制格式tee写源文件时用 /dev/null只是不想让内容刷屏。参数上$(dpkg --print-architecture)保证在 arm64 机器上也能取对架构$VERSION_CODENAME在 Ubuntu 22.04 上是jammy24.04 上是noble写死会翻车。验证那步如果报Cannot connect to the Docker daemon先看systemctl status docker多半是服务没起来。2.2 把当前用户加进 docker 组别每次都 sudo装完直接docker ps会提示权限不足因为默认只有 root 和 docker 组能访问 socket。指南里给的三行是标准解法建组、加用户、刷新组。这里有个血泪经验——newgrp docker只对当前终端生效你新开的窗口如果还是旧会话照样要 sudo。稳妥做法是加完组后直接退出登录再进或者su - $USER重开一个登录会话。# 创建 docker 组已存在会提示但不影响 sudo groupadd docker # 把当前用户追加进 docker 组-aG 的 a 不能省否则会覆盖原有附加组 sudo usermod -aG docker $USER # 刷新当前 shell 的组身份 newgrp docker # 验证不带 sudo 能列出容器即成功 docker ps参数说明-aG里的a是 append少了它用户的其他附加组会被清掉这在多权限环境里是隐形炸弹。$USER是当前登录名如果你在 root 下执行加进去的就是 root换普通用户登录后还得重来。验证时如果仍报权限错误用id看下输出里有没有docker没有就是组没生效别急着怀疑安装。3. 镜像与容器把生命周期命令用成肌肉记忆3.1 镜像管理pull、images、rmi、build 的边界镜像这层是只读模板容器是它的可写实例。指南里列了docker pull nginx:latest、docker images、docker rmi nginx:latest、docker build -t myapp:v1 .四条看着简单但新手常在这几个地方卡住。第一latest不是「最新稳定版」的保证它只是默认标签生产里建议锁具体版本比如nginx:1.27-alpine。第二docker rmi删镜像时如果还有容器引用它会报image is being used by stopped container得先删容器或加-f但-f是后悔药别养成习惯。第三docker build最后的.是构建上下文路径不是 Dockerfile 路径上下文太大会拖慢构建常见做法是加.dockerignore。# 拉取指定版本比 latest 可控 docker pull nginx:1.27-alpine # 查看本地镜像关注 IMAGE ID 和 SIZE docker images # 删除镜像前先确认没有容器引用 docker rmi nginx:1.27-alpine # 构建自定义镜像-t 指定名称和标签末尾的点是上下文 docker build -t myapp:v1 .逻辑说明docker images输出里的REPOSITORY:TAG是引用名IMAGE ID是短哈希删的时候两者都能用。docker build会先把上下文打包发给守护进程所以别在项目根目录放几个 G 的日志或 node_modules.dockerignore里写上node_modules、.git、*.log是常规操作。如果构建时报no space left on device先docker system df看下镜像和构建缓存占了多少再决定docker system prune清哪些。3.2 容器生命周期run、ps、stop、start、rm 的先后顺序容器生命周期命令是新手最容易「顺序搞反」的地方。docker run是创建加启动docker stop是发 SIGTERM 再等超时后 SIGKILLdocker start只能启动已存在但停止的容器docker rm删的是容器本身。指南里docker run -d -p 80:80 --name my-nginx nginx这行-d是后台-p是端口映射--name给了个固定名字方便后续操作。这里有个玄学现象docker ps看不到容器但docker ps -a能看到说明容器已经退出得用docker logs看它为什么退。# 后台启动 Nginx宿主机 80 映射到容器 80 docker run -d -p 80:80 --name my-nginx nginx # 只看运行中的 docker ps # 包括已停止的排查退出容器必用 docker ps -a # 停止、启动、删除 docker stop my-nginx docker start my-nginx docker rm my-nginx参数说明-p 80:80左边是宿主机端口右边是容器端口写反了就连不上。--name不指定的话 Docker 会随机起名后面exec、logs都得先查名字。docker rm只能删已停止的容器运行中的要加-f但更稳的是先stop再rm。如果docker run报port is already allocated说明宿主机 80 被占了ss -tlnp | grep 80查一下是谁。3.3 调试与日志exec、logs、inspect 三件套容器跑起来不代表服务正常调试三件套得会用。docker exec -it my-nginx bash进容器终端-it是交互加伪终端少了-i命令会立刻退出。docker logs my-nginx看标准输出加-f可以持续跟踪。docker inspect my-nginx输出一大坨 JSON新手容易看晕常见做法是配合--format或grep取关键字段比如查 IP 或挂载点。# 进入容器alpine 镜像可能没有 bash用 sh docker exec -it my-nginx bash # 跟踪日志排查启动失败 docker logs -f my-nginx # 只看容器 IP避免在 JSON 里翻 docker inspect --format {{.NetworkSettings.IPAddress}} my-nginx逻辑说明exec是在运行中的容器里起新进程容器停了就用不了得先start。logs默认显示全部历史加--tail 100只看最后一百行更清爽。inspect的--format用的是 Go 模板语法{{.NetworkSettings.IPAddress}}这种路径可以从docker inspect的完整输出里对照着找。如果exec报container is not running别怀疑命令先docker ps -a看状态。4. 用 docker-compose 部署 WordPress多容器编排的第一课4.1 为什么 WordPress 适合当第一个 compose 项目WordPress 需要 Web 服务和数据库两个容器天然适合演示 compose 的「多服务 依赖 数据卷」三件事。指南里给的docker-compose.yml定义了db和wordpress两个服务db用mysql:8.0挂db_data卷到/var/lib/mysql环境变量设了 root 密码、库名、用户和密码wordpress用wordpress:latest映射8000:80通过WORDPRESS_DB_HOST: db连数据库depends_on声明依赖。这里的关键是服务名db在 compose 网络里就是主机名WordPress 容器里解析db就能找到 MySQL不需要写 IP。version: 3 services: db: image: mysql:8.0 volumes: - db_data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: wordpress MYSQL_USER: wpuser MYSQL_PASSWORD: wppass wordpress: image: wordpress:latest ports: - 8000:80 environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: wpuser WORDPRESS_DB_PASSWORD: wppass depends_on: - db volumes: db_data:参数说明MYSQL_ROOT_PASSWORD是必须的不设 MySQL 容器会拒绝启动。MYSQL_DATABASE会自动建库MYSQL_USER和MYSQL_PASSWORD会创建对应用户并授权。WORDPRESS_DB_HOST写db而不是localhost因为容器之间不走宿主机回环。depends_on只保证启动顺序不保证 MySQL 已经初始化完成这是新手最容易误解的点。4.2 启动、验证与首次访问docker compose up -d会拉镜像、建网络、起容器-d是后台。启动后别急着访问MySQL 首次初始化要几秒到十几秒WordPress 如果在这期间连不上会报错但通常重试几次就好。验证顺序建议是先docker compose ps看两个服务是不是running再docker compose logs db看 MySQL 有没有ready for connections最后浏览器开http://localhost:8000走安装向导。# 后台启动所有服务 docker compose up -d # 查看服务状态 docker compose ps # 跟踪数据库日志确认初始化完成 docker compose logs -f db # 停止并删除容器但保留数据卷 docker compose down逻辑说明docker compose down默认删容器和网络但db_data卷会保留下次up数据还在。如果要连数据一起清加-v但这是后悔药生产里别随手敲。如果up报端口占用改8000:80左边的宿主机端口即可。访问时如果 WordPress 提示「建立数据库连接时出错」先看docker compose logs wordpress多半是数据库还没就绪或密码不匹配。5. 数据持久化与安全别让容器一删数据就没5.1 数据卷与绑定挂载两种持久化怎么选容器删了数据就没这是新手最常踩的坑。指南里给了两种方案数据卷Volume和绑定挂载Bind Mount。数据卷由 Docker 管理存在/var/lib/docker/volumes/下适合数据库这类不需要直接改文件的场景绑定挂载把宿主机目录直接映射进容器适合开发时改代码即时生效。docker volume create my-vol建命名卷-v my-vol:/app挂载绑定挂载则是-v $(pwd)/html:/usr/share/nginx/html路径必须是绝对路径$(pwd)是常见写法。# 创建命名卷 docker volume create my-vol # 挂载命名卷到容器 docker run -d --name devtest -v my-vol:/app nginx:latest # 绑定挂载宿主机当前目录下的 html docker run -d --name devtest2 \ -v $(pwd)/html:/usr/share/nginx/html \ nginx:latest参数说明-v左边是源右边是容器内目标路径。命名卷的源是卷名绑定挂载的源是宿主机绝对路径。如果宿主机目录不存在Docker 会自动建但权限可能不对常见做法是先mkdir -p html并确认属主。docker volume ls看所有卷docker volume inspect my-vol看挂载点。绑定挂载在 macOS 和 Windows 上性能不如 Linux这是平台差异不是配置问题。5.2 非 root 运行与最小化镜像安全这块指南提了三条最小化镜像、非 root 运行、定期扫描。最小化镜像常见做法是用alpine基础镜像体积能小一个数量级。非 root 运行是在 Dockerfile 里用USER指令切换比如node:18-alpine自带node用户USER node就能以非特权身份跑。docker scan可以扫镜像漏洞但需要登录 Docker Hub国内网络下可能慢常见替代是trivy。FROM node:18-alpine WORKDIR /app COPY package*.json ./ RUN npm ci --onlyproduction USER node CMD [node, server.js]逻辑说明WORKDIR建目录并切进去COPY先拷依赖清单再npm ci这样依赖没变时能命中缓存。--onlyproduction不装 devDependencies镜像更小。USER node之后所有命令都以 node 用户跑包括CMD。如果应用要写文件得确保目标目录对 node 用户可写否则会报权限错误。docker scan或trivy image myapp:v1扫出来的高危漏洞优先升级基础镜像版本。6. 避坑与排查新手最容易翻车的五个场景6.1 现象docker ps看不到容器但docker ps -a有原因容器启动后立刻退出常见于命令执行完就结束、配置错误导致进程崩溃、或者前台进程被当成后台。解决先docker logs 容器名看输出如果是「命令找不到」就检查镜像的CMD或ENTRYPOINT如果是配置文件报错进容器或挂载配置目录排查。跑docker run -it 镜像 sh手动起一个 shell能最快定位。6.2 现象docker compose up后 WordPress 连不上数据库原因depends_on只保证启动顺序不保证 MySQL 初始化完成WordPress 在数据库就绪前就连了。解决等十几秒再刷新或者看docker compose logs db出现ready for connections再访问。更稳的做法是在应用侧加重试逻辑但新手阶段手动等一等最省事。6.3 现象docker pull卡住或报TLS handshake timeout原因默认镜像仓库网络不稳定这是国内环境常见问题。解决配置镜像加速器在/etc/docker/daemon.json里加registry-mirrors然后systemctl restart docker。注意加速器地址会变用之前先确认可用性别抄个过期地址又怀疑人生。6.4 现象docker exec报container is not running原因容器已经退出exec只能对运行中的容器用。解决docker ps -a找到容器docker start起来再exec。如果起来又立刻退回到 6.1 看日志。别用docker run重新起一个那样数据卷和网络配置可能对不上。6.5 现象绑定挂载后容器内文件权限报错原因宿主机目录属主和容器内用户 UID 不匹配尤其非 root 运行时。解决ls -ln看宿主机目录 UID和容器内id对比必要时chown调整或者在 Dockerfile 里建对应用户。开发环境图省事可以临时用 root 跑但生产里别这么干。7. 从单机到进阶把这份指南用成长期参考这份指南的定位是入门但它的目录结构其实可以当检查清单用。学完之后我建议按「网络模式 → compose 进阶 → 镜像构建优化 → CI/CD 集成」这条线往下走。网络模式先搞清bridge、host、none的区别bridge是默认容器有独立 IP通过端口映射对外host直接共用宿主机网络栈性能好但端口冲突风险高none只有回环适合完全隔离的场景。验证方法很简单起两个容器一个用默认 bridge一个加--network host在容器里ip addr看网卡差异比看文档直观。compose 进阶可以练profiles、extends、多文件覆盖。比如docker-compose.yml写基础服务docker-compose.override.yml写开发时的端口和挂载docker compose up会自动合并。镜像构建优化重点看多阶段构建把编译环境和运行环境分开最终镜像只留运行时依赖。下面这个 Node 例子是常见写法# 构建阶段 FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # 运行阶段只拷构建产物 FROM node:18-alpine WORKDIR /app COPY --frombuilder /app/dist ./dist COPY --frombuilder /app/node_modules ./node_modules USER node CMD [node, dist/server.js]逻辑说明AS builder给阶段命名COPY --frombuilder从上一阶段取文件最终镜像不含源码和 devDependencies。参数上npm ci比npm install更适合 CI它严格按 lock 文件装。如果构建产物路径不是dist按实际改。验证镜像大小时docker images对比优化前后通常能小一半以上。CI/CD 集成这块常见做法是在流水线里docker build加docker push推之前跑trivy扫一遍。本地验证可以用docker compose -f docker-compose.yml -f docker-compose.ci.yml up模拟。我自己的习惯是每次改完 Dockerfile先docker build --no-cache跑一遍确认没有缓存掩盖问题再docker run起一个做冒烟测试。从那以后我每次动镜像配置都强制走一遍「构建 → 起容器 → 看日志 → 删容器」这个循环省得把问题带到线上。希望帮到你。本文还有配套的精品资源点击获取