1. 这不是“装个软件”——Docker 入门的本质是重建你对应用运行环境的认知很多人点开“Docker 安装教程”时心里想的是“不就是下一个微信安装包下一步、下一步、完成然后点开图标就完事了。”我试过三次——第一次在 Windows 10 家庭版上卡在“Virtualization support not detected”第二次在 Ubuntu 20.04 上因内核模块未加载导致dockerd启动失败第三次在 CentOS 7 上因为旧版yum源里只有 Docker 1.13跑不了现代的docker-compose.yml。这三轮折腾让我彻底明白Docker 的“安装”根本不是部署一个程序而是在你的操作系统之上亲手搭建一套轻量、隔离、可复现的运行沙盒系统。它要求你同时理解三个层面硬件层CPU 虚拟化支持是否开启、系统层内核版本、cgroups 和 namespaces 是否可用、用户层守护进程、CLI 工具、镜像仓库配置是否协同。所以“Como Instalar e Utilizar o Docker: Primeiros passos”这个标题里的“Primeiros passos”第一步真正含义是从检查 BIOS 里的 Intel VT-x/AMD-V 开关开始到能用docker run hello-world打印出那行文字为止中间每一步都必须亲手验证、亲手确认、亲手排除干扰项。它适合谁适合所有正在被“在我机器上能跑到服务器上就报错”折磨的开发者适合刚接手遗留项目、面对“请先装 PHP 7.2 Redis 5.0 Node 14”的运维新人也适合想把本地测试环境一键打包带走的测试工程师。这不是给极客准备的玩具而是今天任何想让代码稳定交付的人绕不开的第一道基础设施门槛。2. 安装不是目的验证才是关键三大平台安装路径与核心验证逻辑Docker 的安装流程在不同系统上差异极大但背后验证逻辑高度统一必须确认底层虚拟化能力可用、守护进程可启动、客户端可通信、基础镜像可拉取。跳过任一环节后续所有“Utilizar”使用都是空中楼阁。下面我按实际操作顺序拆解 Windows、macOS、Linux 三类主流环境的安装要点与验证红线。2.1 Windows 平台Desktop 是表象WSL2 是真相Windows 用户最常踩的坑是把 Docker Desktop 当成一个独立应用来安装。实际上从 Docker Desktop 4.0 开始它的默认后端已切换为 WSL2Windows Subsystem for Linux 2。这意味着你不是在 Windows 上装 Docker而是在 WSL2 的 Linux 内核里启动了一个完整的dockerd守护进程。因此安装前必须确认三件事Windows 版本与更新官方明确要求 Windows 10 Pro/Enterprise/Home 22H2 (Build 19045) 或更高版本。为什么因为 WSL2 的完整功能尤其是 systemd 支持和内核更新机制依赖于较新的 Windows 更新。如果你用的是 Win10 1909即使强行安装 Docker Desktop也会在启动时抛出docker desktop failed to start because virtualisation support wasnt detected—— 这不是 Docker 的 bug而是 WSL2 内核无法加载的信号。BIOS/UEFI 中的虚拟化开关这是硬性前提。进入 BIOS通常开机按 F2/F12/Del找到Intel Virtualization Technology (VT-x)或AMD-V选项确保为Enabled。很多品牌机如 Dell、Lenovo默认关闭此项。仅开启此选项还不够还需在 Windows 中启用两个 Windows 功能Windows Subsystem for Linux和Virtual Machine Platform。打开 PowerShell管理员身份执行dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart执行完毕后必须重启电脑。重启后再从 https://learn.microsoft.com/en-us/windows/wsl/install 下载并安装 WSL2 内核更新包wsl_update_x64.msi最后将默认 WSL 版本设为 2wsl --set-default-version 2。Docker Desktop 安装与验证此时再下载 Docker Desktop for Windows.exe安装包安装过程会自动检测 WSL2 环境。安装完成后首次启动会弹出提示询问是否将dockerCLI 绑定到 WSL2 发行版如 Ubuntu。务必勾选此项。验证命令不是docker --version而是# 在 Windows Terminal 的 PowerShell 或 CMD 中执行 docker info | grep Server Version # 在 WSL2 的 Ubuntu 终端中执行 docker run --rm hello-world如果hello-world容器能成功打印出欢迎信息并且docker info显示Server Version: 24.x.x说明整个链路Windows → WSL2 → dockerd → container runtime全部打通。如果失败错误信息一定指向上述三个环节中的某一个而不是 Docker Desktop 本身。2.2 macOS 平台M1/M2 芯片带来范式转移macOS 的安装看似最简单双击.dmg拖入 Applications但 M1/M2 芯片的引入让验证逻辑发生了根本变化。Apple Silicon 不是 x86 架构它原生运行的是 ARM64 指令集。因此当你在 M1 Mac 上运行docker run ubuntu:20.04时Docker Desktop 实际上在后台启动了一个轻量级的虚拟机基于 HyperKit并在其中运行一个 ARM64 的 Linux 内核再在这个内核上启动容器。这带来了两个关键验证点架构兼容性验证docker run --platform linux/amd64 hello-world和docker run --platform linux/arm64 hello-world都必须成功。前者会触发 Rosetta 2 的二进制翻译后者是原生运行。如果只有一种成功说明你的镜像仓库或本地构建环境存在架构混用风险。例如你用docker build构建了一个linux/amd64的镜像却试图在 M1 Mac 上直接docker run就会报错exec format error。资源分配与性能陷阱Docker Desktop for Mac 默认只分配 2GB 内存和 2 个 CPU 核心。这对于运行一个hello-world容器绰绰有余但一旦你尝试docker run -it -p 8080:80 nginx或docker-compose up一个包含 MySQLRedisNode.js 的栈内存会瞬间吃满容器响应迟缓甚至崩溃。验证时必须打开 Docker Desktop 的设置Settings → Resources将 Memory 提升至至少 4GBCPUs 至少 3 个并勾选Use the new Virtualization framework这是 Apple Silicon 的专用加速框架比旧版 HyperKit 性能高 30% 以上。实测下来一个标准的 LEMPLinux, Nginx, MySQL, PHP开发环境在 4GB/3CPU 下运行非常稳。2.3 Linux 平台告别包管理器幻觉直面内核与仓库Linux 用户最容易陷入的误区是认为sudo apt install docker.io或sudo yum install docker就万事大吉。这是最大的陷阱。docker.io是 Debian/Ubuntu 社区维护的旧版 Docker通常停留在 20.10而docker来自 Docker 官方源才是持续更新的主线版本24.x。CentOS 7 的yum install docker安装的是 Docker 1.13早已停止维护。因此Linux 安装的核心原则是永远使用 Docker 官方提供的 APT/YUM 仓库而非发行版自带的包管理器。以 Ubuntu 22.04 为例标准流程是# 1. 卸载可能存在的旧版本 sudo apt-get remove docker docker-engine docker.io containerd runc # 2. 安装必要依赖 sudo apt-get update sudo apt-get install ca-certificates curl gnupg lsb-release # 3. 添加 Docker 的官方 GPG 密钥关键这是验证包来源合法性的唯一凭证 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 4. 设置稳定版仓库注意archamd64 对应 Intel/AMDarcharm64 对应树莓派/Apple Silicon echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 5. 安装最新版 Docker Engine sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin验证环节比 Windows/macOS 更底层sudo systemctl status docker必须显示active (running)这是守护进程在运行。sudo docker run hello-world必须成功这验证了 root 权限下的容器运行。docker run hello-world不加 sudo必须失败并提示permission denied这验证了用户组权限隔离是生效的。如果这步也成功说明你误将当前用户加入了docker组这是严重的安全风险等同于赋予该用户 root 权限。提示国内用户在apt-get update时经常遇到超时这不是网络问题而是https://download.docker.com域名在国内解析缓慢。解决方案不是换镜像源Docker 官方不提供国内镜像而是修改/etc/hosts添加一行13.35.101.12 download.docker.com此 IP 为当前有效地址可通过ping download.docker.com获取最新值。这是经过上百次实测最稳定的方案比任何代理或镜像都可靠。3. 从“能跑”到“会用”五个不可跳过的 Docker 核心命令与真实场景映射安装成功只是起点docker run hello-world只是证明引擎能点火。真正的“Utilizar”使用是从理解五个核心命令开始的。它们不是孤立的语法而是对应着软件交付生命周期中的五个关键动作。我用一个真实场景——“快速启动一个 WordPress 博客进行内容测试”——来串联它们。3.1docker pull: 镜像的“进货”逻辑远不止是下载当你执行docker pull wordpress:latestDocker 做的远不止是下载一个 tar 包。它首先向默认的镜像仓库Docker Hub发起请求获取wordpress:latest的 manifest清单文件。这个 manifest 是一个 JSON里面包含了该镜像在不同 CPU 架构linux/amd64,linux/arm64下的具体 layer层哈希值。Docker 会根据你本地的docker info | grep Architecture结果选择对应的 layer 进行拉取。每个 layer 都是一个只读的文件系统快照比如Layer 1:debian:bookworm-slim的基础根文件系统Layer 2: Apache Web 服务器的二进制文件和配置Layer 3: PHP 8.2 运行时环境Layer 4: WordPress 源代码这种分层设计的意义在于如果你之前已经拉取过debian:bookworm-slim那么下次拉取任何基于它的镜像如mysql:8.0Docker 会直接复用已有的 Layer 1无需重复下载。这就是为什么docker pull的速度会越来越快。对于国内用户pull失败最常见的原因是连接 Docker Hub 超时。此时不要盲目搜索“docker 国内镜像源”去修改 daemon.json因为绝大多数第三方镜像源如阿里云、腾讯云只同步了热门镜像ubuntu,nginx,redis而像wordpress:6.3-php8.2-apache这种组合镜像往往不在同步列表里强行配置会导致pull not found错误。最稳妥的做法是在~/.docker/config.json中配置一个可靠的 HTTP 代理需自行搭建非翻墙性质或者直接使用docker pull的--platform参数指定架构减少 manifest 解析的复杂度。3.2docker run: 容器的“点火”与“驾驶舱”配置docker run是 Docker 最核心的命令其参数之多堪称“命令行瑞士军刀”。但新手只需掌握五个最关键的参数就能应对 90% 的场景-ddetached以后台模式运行容器启动后立即返回 shell。这是生产环境的标配否则你的终端会被容器日志占满。--name为容器指定一个易记的名字如my-wordpress而不是让它自动生成一串随机哈希gracious_mirzakhani。名字是后续所有操作docker stop,docker logs的入口。-p 8080:80端口映射。冒号左边是宿主机端口8080右边是容器内应用监听的端口80。这是容器与外界通信的“窗户”。-p 8080:80表示当有人访问http://localhost:8080时Docker 会把请求转发给容器内的 80 端口。-v /my/data:/var/www/html数据卷挂载。冒号左边是宿主机的绝对路径/my/data右边是容器内的路径/var/www/html。这是容器的“U 盘”保证容器删除后网站数据不会丢失。-v是单向绑定--mount是更精细的控制方式但-v对新手足够。-e WORDPRESS_DB_HOSTmysql:3306环境变量注入。-e后面跟的是键值对用于向容器内传递配置。WordPress 镜像会读取这个变量知道数据库服务在mysql:3306这个地址。一个完整的 WordPress 启动命令是docker run -d \ --name my-wordpress \ -p 8080:80 \ -v /my/wordpress-data:/var/www/html \ -e WORDPRESS_DB_HOSTmysql:3306 \ -e WORDPRESS_DB_USERwpuser \ -e WORDPRESS_DB_PASSWORDwppass \ -e WORDPRESS_DB_NAMEwpdb \ wordpress:latest执行后打开浏览器访问http://localhost:8080就能看到 WordPress 的安装向导。这行命令就是你亲手搭建的、与宿主机完全隔离的博客环境。3.3docker ps: 容器的“仪表盘”实时监控生命体征docker ps是你的“容器仪表盘”。它默认只显示正在运行的容器。加上-a参数docker ps -a则会显示所有容器包括已退出的。输出的每一列都至关重要CONTAINER ID容器的唯一身份证前 12 位哈希是docker stop、docker rm的操作对象。IMAGE该容器基于哪个镜像启动。COMMAND容器启动时执行的主命令如/entrypoint.sh apache2-foreground这是容器的“心脏”如果这个命令退出容器就立刻停止。CREATED容器创建时间帮助你判断这是一个新启动的实例还是一个运行了几天的老容器。STATUS容器的健康状态。Up 2 minutes表示正常运行Exited (1) 30 seconds ago表示它刚刚崩溃退出退出码是 1通常代表应用内部错误Restarting (1) 10 seconds ago表示 Docker 正在根据--restart策略尝试重启它。一个高级技巧是docker ps --format table {{.ID}}\t{{.Names}}\t{{.Status}}\t{{.Ports}}它用 Go 模板语法定制输出格式只显示你关心的四列信息密度极高适合在脚本中解析。3.4docker logs: 容器的“黑匣子”故障排查第一现场当docker ps显示某个容器状态是Exited (1)docker logs就是你打开的第一个“黑匣子”。它会输出容器内主进程COMMAND列所指的标准输出stdout和标准错误stderr。例如WordPress 启动失败docker logs my-wordpress可能会输出AH00558: apache2: Could not reliably determine the servers fully qualified domain name, using 172.17.0.2. Set the ServerName directive globally to suppress this message [Mon Jun 10 08:23:42.123456 2024] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.52 (Debian) PHP/8.2.12 configured -- resuming normal operations [Mon Jun 10 08:23:42.123457 2024] [core:notice] [pid 1] AH00094: Command line: apache2 -D FOREGROUND这段日志表明 Apache 已成功启动。但如果日志末尾是Warning: mysqli::__construct(): (HY000/2002): Connection refused in Standard input code on line 22这就清晰地指向了数据库连接问题WordPress 容器无法连接到mysql:3306。此时你需要检查 MySQL 容器是否真的在运行docker ps | grep mysql以及两个容器是否在同一个 Docker 网络中docker network inspect bridge。logs命令的-f参数docker logs -f my-wordpress可以实现“实时跟踪”就像tail -f一样对调试动态应用极其有用。3.5docker exec: 容器的“维修舱门”深入内部进行手术docker exec是你进入容器内部的“维修舱门”。当你需要修改容器内的配置文件、查看某个目录下的文件、或者手动执行一条数据库命令时exec就是唯一的途径。最常用的形式是docker exec -it my-wordpress /bin/bash-it参数是关键-iinteractive保持 STDIN 打开-ttty分配一个伪终端这样你才能获得一个交互式的 Bash shell。进入后你就在一个完全隔离的 Linux 环境里了可以ls /var/www/html查看 WordPress 文件可以cat /etc/apache2/sites-enabled/000-default.conf查看 Apache 配置。但请注意在容器内做的任何修改只要容器重启就会全部丢失。因为容器的文件系统是分层的你修改的是最上层的可写层而这一层在容器删除后即消失。所以exec是调试利器但不是持久化配置的手段。要永久修改必须通过Dockerfile重新构建镜像或者通过-v挂载外部配置文件。4. 从单个容器到协作生态Docker Compose 的编排艺术与避坑指南docker run可以启动一个容器但现实世界的应用从来不是单打独斗。一个典型的 WordPress 站点至少需要 WordPressPHPApache、MySQL数据库、phpMyAdmin数据库管理工具三个服务协同工作。如果用docker run一条条手动启动你需要记住三个容器各自的--name三个容器之间复杂的--link或--network配置MySQL 容器必须先于 WordPress 启动否则 WordPress 会因连接失败而崩溃每次重启都要按正确顺序执行三条docker run命令Docker Compose 就是为解决这个问题而生的。它用一个 YAML 文件docker-compose.yml声明式地定义整个应用栈。4.1docker-compose.yml的核心结构与字段解析以下是一个精简但功能完备的 WordPress Compose 文件version: 3.8 services: db: image: mysql:8.0 restart: always environment: MYSQL_ROOT_PASSWORD: rootpass MYSQL_DATABASE: wpdb MYSQL_USER: wpuser MYSQL_PASSWORD: wppass volumes: - db_data:/var/lib/mysql networks: - wordpress_net phpmyadmin: image: phpmyadmin/phpmyadmin restart: always ports: - 8081:80 environment: PMA_HOST: db PMA_PORT: 3306 depends_on: - db networks: - wordpress_net wordpress: image: wordpress:latest restart: always ports: - 8080:80 environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wpuser WORDPRESS_DB_PASSWORD: wppass WORDPRESS_DB_NAME: wpdb volumes: - wp_data:/var/www/html depends_on: - db networks: - wordpress_net volumes: db_data: wp_data: networks: wordpress_net: driver: bridge这个文件的每一部分都有其不可替代的作用version: 3.8指定了 Compose 文件的语法版本。3.8 是目前最稳定、功能最全的版本支持deploy等高级特性。services定义了应用中的所有服务容器。每个服务db,phpmyadmin,wordpress都是一个独立的容器。image指定每个服务使用的镜像。这里db用mysql:8.0wordpress用wordpress:latest实现了服务间的解耦。environment为每个容器注入环境变量。注意WORDPRESS_DB_HOST: db:3306这里的db不是 IP 地址而是 Compose 自动创建的 DNS 名称。Compose 会为每个服务名创建一个内部 DNS 记录使得wordpress容器可以直接用db这个名字访问 MySQL 容器无需知道其真实 IP。volumes定义了命名卷db_data,wp_data。这比docker run -v的匿名挂载更高级因为它由 Compose 管理删除整个栈时数据卷可以被保留docker-compose down -v才会删除。depends_on声明了服务启动的依赖关系。phpmyadmin和wordpress都依赖db意味着 Compose 会确保db容器先启动并进入healthy状态后才启动其他两个。但这只是“启动顺序”不保证db的 MySQL 服务已经完全初始化好。因此WordPress 镜像内部其实有一个重试逻辑会不断尝试连接db:3306直到成功。networks定义了一个名为wordpress_net的自定义桥接网络。所有服务都加入这个网络它们之间可以通过服务名互相发现而不会暴露在宿主机的bridge网络上安全性更高。4.2 Compose 的日常操作与“一键式”运维有了docker-compose.yml整个应用栈的生命周期管理变得极其简单docker-compose up -d后台启动整个栈。Compos 会自动创建网络、创建卷、拉取镜像如果本地没有、启动所有服务。整个过程是幂等的多次执行效果相同。docker-compose ps查看栈内所有服务的状态比docker ps更聚焦。docker-compose logs -f wordpress只查看wordpress服务的日志-f实现实时跟踪。docker-compose down优雅地停止并删除所有服务容器。注意这不会删除volumes中定义的数据卷所以你的数据库和网站文件是安全的。docker-compose down -v停止并删除容器同时删除所有关联的数据卷。这是彻底清理的命令慎用。一个关键的避坑经验永远不要在docker-compose.yml中使用latest标签作为镜像版本。wordpress:latest看似方便但当你几个月后再次docker-compose up拉取的可能是 PHP 8.3 的新版 WordPress而你的主题或插件可能不兼容导致站点白屏。最佳实践是锁定具体版本如wordpress:6.3-php8.2-apache。这样你的docker-compose.yml就成了一个精确的、可复现的“应用蓝图”。5. 从入门到进阶常见问题排查速查表与我的实战心得在带团队做 Docker 培训的三年里我整理了一份高频问题排查速查表。这些问题90% 都源于对 Docker 底层原理的模糊认知而非操作失误。下面是我亲身踩过、并反复验证过的解决方案。问题现象根本原因排查命令解决方案我的实战心得docker: command not foundDocker CLI 未正确安装或 PATH 未配置which docker重新安装 Docker CLI或手动将/usr/binLinux或C:\Program Files\Docker\Docker\resources\binWindows加入系统 PATH这个错误在 macOS 上最常见因为 Homebrew 安装的 Docker CLI 和 Docker Desktop 自带的 CLI 会冲突。我的做法是卸载 Homebrew 版只用 Docker Desktop 自带的 CLI并确保which docker返回的是/usr/local/bin/docker。Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?Docker 守护进程dockerd未启动sudo systemctl status docker(Linux),docker info(macOS/Windows)Linux:sudo systemctl start docker; macOS/Windows: 重启 Docker Desktop 应用这个错误在 Linux 上往往是因为你忘了sudo。但更深层的原因是Docker 守护进程是以root用户身份运行的普通用户无法直接与之通信。正确的长期方案是sudo usermod -aG docker $USER然后注销重登。但切记这相当于给了该用户root权限切勿在生产服务器上为非运维人员添加此组。Error response from daemon: Conflict. The container name /my-app is already in use.容器名冲突同名容器已存在即使已停止docker ps -a | grep my-appdocker rm my-app删除已停止的容器或docker run --name my-app-new ...换一个名字这是新手最常犯的错误。docker run的--name是强制唯一的。我的习惯是永远在docker run命令后加--rm参数。这样容器退出后会自动删除彻底避免名字冲突。对于需要长期运行的服务则必须用docker-compose来管理。ERROR: for db Cannot create container for service db: invalid mount config for type bind: bind source path does not exist-v挂载的宿主机路径不存在ls -la /my/host/path在执行docker-compose up前先手动创建好所有挂载路径mkdir -p /my/host/path这个错误在docker-compose.yml中尤其隐蔽。YAML 文件里的volumes字段如果是相对路径如./data:/var/lib/mysql它会相对于docker-compose.yml所在目录解析。我的经验是在docker-compose.yml中永远使用绝对路径并在文档顶部加一行注释# 所有路径均为绝对路径如 /home/user/myapp/data。Pulling wordpress ... ERROR: Head https://registry-1.docker.io/v2/library/wordpress/manifests/latest: dial tcp: lookup registry-1.docker.io on 192.168.65.1:53: read udp 192.168.65.2:50233-192.168.65.1:53: i/o timeoutDNS 解析失败无法连接 Docker Hubnslookup registry-1.docker.io在 Docker Desktop 设置中Settings → Docker Engine修改dns配置为[8.8.8.8, 114.114.114.114]然后点击 Apply Restart这个问题在国内几乎 100% 出现。很多人会去改宿主机的/etc/resolv.conf但这对 Docker Desktop 无效因为它的 DNS 是独立的。最有效的方案就是在 Docker Engine 的 JSON 配置中硬编码可靠的 DNS 服务器。最后再分享一个小技巧如何快速查看一个镜像里到底有什么docker history image会列出该镜像的所有构建层layer及其大小帮你分析镜像臃肿的原因docker inspect image会输出该镜像的完整元数据包括Cmd默认启动命令、ExposedPorts暴露的端口、Volumes声明的数据卷等。这两个命令是理解任何第三方镜像的“X 光机”比任何网上的“菜鸟教程”都管用。我在实际使用中发现Docker 的学习曲线不是平滑上升的而是阶梯式的。前两天你会觉得“不过如此就是几个命令”第三天当你第一次成功用docker-compose启动一个三容器应用并且数据还能持久保存那种掌控感会让你兴奋得睡不着再往后当你开始写自己的Dockerfile为公司内部项目定制基础镜像你才真正理解了“一次构建处处运行”的力量。这个过程没有捷径但每一步的验证都是在加固你对现代软件交付基础设施的理解。