企业官网建设流程全解析

上周一个朋友跑来跟我吐槽，说自己看了大半天Docker教程，信心满满地下载了 Docker Desktop，结果双击之后一直报错virtualization support not detected，折腾到半夜也没解决。他的经历其实非常典型：教程并不少，但大部分默认你已经装好了基础环境，一旦界面和报错跟教程不一样，你根本不知道该从哪里下手。Docker 这种工具，安装环节的坑其实比使用环节更值得先花时间搞明白，因为你连环境都跑不起来的话，后面学命令、学编排全都没有意义。这篇我打算把"从入门到安装"这条线完整串一遍：先讲清概念，再讲清不同系统该走哪条安装路线，然后把 Windows 和 Linux 的安装流程、高频报错、镜像加速和网络排查一起过掉。篇幅不短，但每一步你都能对着自己的电脑找到对应位置。

1. 先弄懂Docker是什么，再决定装不装

很多人第一反应是"Docker 不就是个容器工具吗，直接装不就完了"。但装之前如果对它的核心模型没有概念，后面使用的时候会频繁碰壁，连报错都看不懂。所以我建议你先花十分钟把这一章看完，再往下走。

1.1 镜像、容器、仓库：三个词讲清Docker的核心模型

Docker 体系里最常被提起的三个词是镜像（Image）、容器（Container）和仓库（Registry）。这三个词完全可以对应到"安装包、正在运行的程序、软件分发平台"。

镜像就是一个打包好的、只读的环境模板，里面包含程序运行需要的操作系统层、依赖库、配置文件和应用本身。你不需要关心这个软件原来是怎么编译出来的，只要拿到镜像，它就能在任何装有 Docker 的机器上跑起来。容器则是这个模板真正运行起来之后产生的实例，你可以对它做启动、停止、删除、进入执行命令等操作。仓库负责存放镜像，最出名的公共仓库是 Docker Hub，上面你能找到几乎所有主流软件的官方镜像，比如 mysql、redis、nginx、gitlab。这也是 Docker 能大幅降低部署成本的根本原因：大部分软件都已经有人帮你打包好了，不用再从零配置。

这里必须强调一个点：镜像和容器不是一一对应的关系。同一个镜像可以同时启动多个容器，容器之间互相隔离、互不影响，删除容器也不会破坏镜像本身。这也是 Docker 能在一台机器上密集部署多个服务的原因——每个容器共享宿主机内核，却拥有各自独立的文件系统、网络栈和进程空间。理解了这个关系，后面再看docker run、docker stop、docker rm这些命令就不会觉得乱。

1.2 数据卷、网络、Dockerfile：迟早要碰的另外三样

除了镜像和容器，入门阶段还要提前认识三个概念，否则后面实战时会遇到"数据怎么保存""容器之间怎么通信""镜像怎么自己构建"这些问题。

数据卷（Volume）解决的是容器数据持久化的问题。容器是临时性的，一旦删除，容器内产生的数据也会跟着消失，这对数据库这类服务来说是不可接受的。数据卷的本质就是把宿主机上的一个目录挂载到容器内部，让容器读写某条路径时实际读写的是宿主机磁盘。你删容器、重建容器，只要挂载同一个数据卷，数据都还在。实战部分我讲 MySQL 的时候会专门演示。

网络这块，Docker 默认会给每个容器分配一个独立 IP，但容器被删除重建后 IP 会发生改变，不能把 IP 写死到配置里。更合理的做法是创建自定义网络，让容器之间通过服务名互相访问，这一点在 Redis 主从集群里非常关键，后面 6.3 节会展开。

Dockerfile 是用于构建镜像的文本文件，里面按顺序写清楚"从哪个基础镜像开始、拷贝什么文件、安装什么依赖、执行什么命令、暴露哪个端口"，执行docker build就能生成一个自定义镜像。入门阶段不要求你很会写它，但要能看懂，因为很多开源项目的部署文档都会附带 Dockerfile。

1.3 一个常见误区：Docker容器不是轻量虚拟机

对新手来说，最容易产生的误解是把 Docker 容器当成"体积小、启动快的虚拟机"。从应用效果看两者确实很接近：都能隔离环境、都能跑服务、都能快速销毁重建。但底层原理完全不同，这个差异直接影响安装方式。

虚拟机需要模拟完整的硬件设备，然后在虚拟硬件上安装一个完整操作系统，所以每个虚拟机都有自己的内核。而容器直接共享宿主机内核，只是在用户空间做隔离和限制。这也是 Docker 启动那么快、资源占用那么少的根本原因。也正是因为容器共享 Linux 内核的机制，Docker 本身是 Linux 技术，在 Windows 上跑容器时，实际还是要通过 WSL2 或 Hyper-V 提供一个 Linux 环境，再把容器运行在 Linux 内核之上。

如果你误以为 Docker Desktop 在 Windows 上就是个普通桌面软件，装完就能直接用，碰到virtualization support not detected这类报错时就会完全摸不着头脑——其实问题根本不是出在 Docker 本身，而是底层虚拟化环境没有准备好。这个机制理解了，后续排错的思路就清晰了。

2. 安装前的路线选择：你的电脑适合装什么

Docker 不像普通软件那样只有一种安装包。同样叫"Docker"，在 Windows、macOS 和 Linux 上装的东西并不是同一个东西，选错路线会浪费大量时间。

2.1 Windows：Docker Desktop 与 WSL2 的搭配

Windows 上官方推荐的是 Docker Desktop，它带图形界面，能直接管理容器和镜像。Docker Desktop 在 Windows 上有两种后端可选：WSL2 和 Hyper-V，现在主流且官方默认推荐的是 WSL2。原因很实在：WSL2 启动快、占用内存小，而且装好之后你等于同时拥有一个轻量的 Linux 环境，很多 Docker 操作可以直接在同一套环境里完成，排查网络问题也方便。

需要满足的前提是系统为 Win10 21H2 以上或 Win11，并且 CPU 支持并开启了硬件虚拟化。如果你的系统比较老，或者公司电脑被统一限制了虚拟化功能，装 Docker Desktop 之前要先解决这些前置条件，否则装完也会启动失败。另外，网上流传的各种 Docker Desktop 汉化包我是不推荐装的，桌面端本身菜单就那么几个，中文还是英文影响不大，汉化包反而可能引入未知风险。

2.2 Linux：Docker Engine 直接装

如果使用 Ubuntu、CentOS 这类 Linux 系统作为服务器，直接安装 Docker Engine 就可以了，不需要装 Docker Desktop，也没有图形界面可用，一切通过命令行操作。很多刚从 Windows 转过来的同学会下意识去找"Linux 版的 Docker Desktop"，其实没必要，生产环境里几乎没人那么干，命令行管理容器反而更灵活、更省资源。

Linux 下安装 Docker 有两条主流路径：一是用 Docker 官方提供的一键脚本，二是手动添加官方软件源后安装。一键脚本适合第一次快速搭建，手动配源适合需要锁定版本、离线安装或者网络环境受限的场景。我自己一般推荐手动配源，因为后面升级、卸载、排查依赖关系都更可控。需要提醒的是，有些 Linux 发行版的软件源里也直接提供了docker.io包，确实能装，但版本往往比 Docker 官方源滞后不少，生产环境建议还是用官方源或可信镜像源。

2.3 硬件检查和内核要求：忘掉这一步后面全是坑

安装前建议花两分钟做一次环境自检，可以省掉后续大量排错时间。

先看虚拟化是否开启。Windows 上打开任务管理器，切到"性能"页，点 CPU，右下角会显示"虚拟化：已启用或已禁用"。如果显示已禁用，需要进 BIOS 开启 Intel VT-x 或 AMD-V 选项才能正常使用 WSL2 和 Docker Desktop。这一步是 Windows 上最容易忽略的坑，很多人报virtualization support not detected其实根因就在这里。

再看内存和磁盘。Docker 本身占用不算高，但跑通用容器时最好不要少于 4GB 可用内存，如果计划跑数据库、中间件这类服务，建议 8GB 起步。磁盘优先考虑 SSD，镜像和容器快照对随机读写性能比较敏感。还要注意 Docker Desktop 默认会把数据放到 C 盘，C 盘紧张的话请在安装后修改镜像和容器的存储位置。

Linux 上主要看内核版本。较新版 Docker 要求内核版本至少是 3.10，实际跑容器应用建议内核在 4.18 以上，可以用uname -r查看。CentOS 7 默认内核是 3.10，能装 Docker 但部分新特性支持有限，需要你在升级内核和新版 Docker 之间做取舍。如果uname -r显示的内核版本过低，先升级内核，否则 Docker 装完也可能服务起不来或者容器频繁异常。

3. Windows安装Docker Desktop实操记录

Windows 上安装 Docker Desktop 的完整链路，我按"开启 WSL2 -> 安装桌面端 -> 排错"的顺序来写。这一节也是你最容易卡住的地方。

3.1 三步开启WSL2环境

如果你之前完全没碰过 WSL，第一步是先把 Windows 的 Linux 子系统功能打开。以管理员身份打开 PowerShell，依次执行下面两条命令：

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行完提示"操作成功完成"，重启系统。重启后再次打开管理员 PowerShell，把 WSL 的默认版本设为 2：

wsl --set-default-version 2

如果提示需要更新 WSL2 内核，去微软官网下载"WSL2 Linux 内核更新包"安装即可。没有安装任何 Linux 发行版也没关系，Docker Desktop 会自行创建后端环境，没必要为了 Docker 单独装一个 Ubuntu。这里多说一句：WSL 本身是一个完整的 Linux 运行环境，你可以把它理解成 Windows 里内置了一个轻量子系统，Docker Desktop 把它作为运行容器的底座，稳定性和性能都优于老旧的 Hyper-V 方案。

3.2 安装Docker Desktop本体及初始配置

从 Docker 官网下载 Docker Desktop for Windows 安装包，双击后一路 Next，在安装类型界面保持默认的"Use WSL 2 instead of Hyper-V"即可。安装完成后桌面端会自动启动，首次打开会要求接受服务协议，并询问是否登录 Docker 账号。个人使用场景我建议先不登录，功能上不受影响，后续有需要再登。需要注意一下，Docker 目前对大型企业有商业授权要求，个人学习和小团队使用社区版免费套餐完全够用。

Docker Desktop 启动后，右下角托盘区域的鲸鱼图标会转圈，等它变成绿色常亮就表示引擎已经就绪。此时打开任意终端窗口，执行docker version，如果下方显示 Server 相关信息，说明客户端和守护进程的通信已经建立。这个命令是 Windows 上验证 Docker 是否装成功最重要的检查点，只看到 Client 内容而 Server 连接失败，说明引擎没起来。

首次启动如果发现 WSL2 后端里创建的虚拟磁盘占用了 C 盘太多空间，可以去 Docker Desktop 的 Settings -> Resources -> Advanced 里调整磁盘镜像位置，或者在%USERPROFILE%下配置 WSL 的安装目录。我建议一开始就把 WSL 的分发版本目录迁移到数据盘，避免 C 盘越涨越满。

3.3 两个高频报错及完整排查链

先把话说清楚：Docker Desktop 安装后只要出现下面这两个报错，一般是环境问题而不是 Docker Desktop 安装包坏了，不要反复重装，那是最浪费时间的做法。

第一个是virtualization support not detected，中文意思是"未检测到虚拟化支持"。排查步骤按顺序来：

1. 检查 BIOS 是否开启了虚拟化。重启进 BIOS，找到 Intel Virtualization Technology（Intel 平台）或 SVM Mode（AMD 平台），设为 Enabled，保存重启。
2. Windows 功能里勾选"虚拟机平台"和"适用于 Linux 的 Windows 子系统"。管理员 PowerShell 执行上面 3.1 节的两条 dism 命令，即使提示已开启，再执行一次也无妨。
3. 检查是否跟其他虚拟机软件冲突。本机同时装了虚拟机软件且占用了 VT-x 时，Docker Desktop 可能检测不到虚拟化，部分场景需要先关闭第三方虚拟机或启用 Windows 的 Hyper-V 兼容层。

第二个报错是命令行执行 docker 命令时提示failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen。这个报错本质就是客户端连不上 Docker 引擎。排查链路是：先看托盘鲸鱼图标是否绿色，如果不是，说明桌面端没启动成功；接着执行wsl --status和wsl -l -v确认 WSL 环境状态是否正常；然后把 Docker Desktop 关掉重开，到 Settings -> General 里确认勾选了"Use the WSL 2 based engine"；如果依然连不上，执行wsl --update把 WSL 升级到最新版，再重启 Docker Desktop。

这两个报错我都亲手排查过很多次，结论很明确：九成以上是 WSL2 环境没就绪或者虚拟化未开启，跟 Docker Desktop 本身的安装质量没关系。

4. Linux安装Docker：Ubuntu与CentOS的两种主流路径

服务器环境里，最常见的是 Ubuntu 和 CentOS 两个体系。它们的安装思路基本一致，但细节上有差别，我分开写。

4.1 Ubuntu：官方脚本和手动配源两种方式

如果你图省事，可以用 Docker 官方的一键安装脚本：

curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh

这个脚本会自动检测系统版本、配置安装源并安装 docker-ce 等组件，适合快速搭建开发环境。脚本安装完成后执行：

sudo systemctl enable --now docker

如果是国内网络环境，脚本可能在下载阶段就很慢或者失败，这时我更推荐手动配源的方式。步骤如下：

sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg 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 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

如果download.docker.com访问不顺畅，可以把最后写入的软件源地址换成国内镜像源地址，注意保持路径结构一致。配好后再执行一次sudo apt update && sudo apt install -y docker-ce。这种方式的好处是版本明确，以后apt upgrade就能升级，卸载时也干净。

4.2 CentOS 7：装完如何升级到新版Docker

CentOS 7 上经常遇到的问题是系统源里的 Docker 版本太旧，或者之前用yum install docker装过老版本。升级前建议先把旧版本清理掉，避免核心包冲突：

sudo yum remove -y docker docker-common docker-selinux docker-engine

然后安装依赖工具并配置 Docker 官方仓库：

sudo yum install -y yum-utils device-mapper-persistent-data lvm2 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.io sudo systemctl enable --now docker

这里必须提醒一句：CentOS 7 默认内核是 3.10，新版 Docker 在这个内核上虽然能运行，但某些功能可能受限，如果后面遇到存储驱动或网络相关的异常，优先考虑升级内核，而不是退回到旧版 Docker。另外 CentOS 7 的 SELinux 和 Docker 偶有配合问题，生产环境不建议直接永久关闭 SELinux，而是优先排查日志确认根因。

4.3 权限错误与服务启动失败：两个最常见的拦路虎

装完之后执行docker ps，如果看到docker: permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock，这是非常经典的权限问题。原理是 Docker 守护进程通过 Unix Socket 与客户端通信，而那个 socket 文件默认只有 root 用户有访问权限。解决办法是把当前用户加入 docker 组：

sudo usermod -aG docker $USER newgrp docker

newgrp docker让当前终端立即生效，不用重新登录。如果后来发现加入 docker 组后仍然提示权限不足，检查一下是不是组缓存没刷新，重新登录一次会话即可。

第二个常见问题是systemctl start docker之后服务一直起不来。看日志的正确姿势是：

sudo systemctl status docker sudo journalctl -xeu docker

日志里最常见的原因可以分为三类：一是/etc/docker/daemon.json配置格式错误，比如多写了一个逗号或者引号不匹配，导致 Docker 服务一启动就退出；二是系统中的 iptables 或 nftables 与 Docker 默认规则冲突，通常出现在新版本 Ubuntu 上；三是 containerd 启动失败连带 Docker 起不来。排查时先确认 daemon.json 存在且内容合法，再逐条看 journal 日志指向哪个模块。凡是动过 docker 配置文件之后服务起不来的，优先怀疑 JSON 格式，这个坑我踩过不止一次。

5. 镜像与网络：装好后最容易卡住的难点

很多人以为 Docker 装完就万事大吉，结果第一次docker pull就卡住了。镜像下载和网络通信是使用频率最高、也最容易让人困惑的部分，我单独拿出来讲。

5.1 拉取镜像慢？配置镜像加速器

docker pull慢或者直接超时，是新手碰到最多的网络问题。原因很直接：默认的官方镜像仓库在海外网络环境下连通性不稳定，国内直连往往不顺畅。行业内的常规解决方案是给 Docker 配置镜像加速器，也就是 registry mirror。

Linux 环境下，编辑或新建/etc/docker/daemon.json：

{ "registry-mirrors": ["https://<你的ID>.mirror.aliyuncs.com"] }

这里<你的ID>.mirror.aliyuncs.com是阿里云容器镜像服务提供的专属加速地址，登录控制台后每个账号都能拿到自己的地址，填入后执行：

sudo systemctl daemon-reload sudo systemctl restart docker

验证是否生效：

docker info | grep -A 5 "Registry Mirrors"

如果看到配置的加速地址，说明已经生效。Windows 桌面端的配置入口在 Settings -> Docker Engine，改完 JSON 后点击 Apply & Restart。配置加速器之后如果再遇到某个特定镜像拉不下来，还可以试试直接把镜像全名里的仓库地址替换成镜像加速服务对应的域名，不过这种操作依赖具体服务是否提供镜像转发，建议优先用 registry mirror。

这里要额外提醒一句：有些容器运行时并不走 Docker 的命令行，而是直接使用 containerd，比如 K8s 节点。这种情况下daemon.json里的加速配置对 K8s 不生效，需要去/etc/containerd/config.toml里单独配置 mirror 项。要是你只在单机环境用 Docker，可以跳过这条，但如果你准备往容器编排方向走，迟早会遇到，提前有个印象。

5.2 容器里访问不了外网、容器之间连不上：网络排查

"网络不通"这四个字背后可能对应完全不同的问题，排查前先明确是下面哪一种。

第一种是容器内访问不了外网。比如docker run --rm -it alpine sh进入容器后执行ping 8.8.8.8不通。优先检查宿主机的 IP 转发是否开启，执行sysctl net.ipv4.ip_forward，输出为 0 则说明没开，需要临时开启：

sudo sysctl -w net.ipv4.ip_forward=1

如果是能 ping 通 IP 但解析不了域名，基本可以确定是 DNS 问题。在容器里查看cat /etc/resolv.conf，看 DNS 配置是否正确。宿主机的 DNS 配置存在较大问题的，可以在daemon.json里给全局容器指定 DNS，例如"dns": ["223.5.5.5", "8.8.8.8"]，然后重启 Docker。

第二种是容器之间互相访问不通。默认情况下 Docker 会创建一个名为 bridge 的桥接网络，容器可以分配到 IP 并互相 ping 通，但按容器名访问却不行。原因是默认 bridge 网络不提供内置 DNS 解析，容器重启后 IP 还会变。解决办法是创建自定义网络，只有在自定义网络中 Docker 才内置 DNS，容器之间可以用容器名互访：

docker network create app-net docker run -d --name nginx-a --network app-net nginx docker run -d --name nginx-b --network app-net nginx

然后在 nginx-b 容器里执行ping nginx-a，能通。这个差别是很多 Redis 集群、微服务项目起不来的真实原因，值得记牢。

5.3 端口映射不生效的几种原因

还有一类高频问题：容器明明在跑，但从宿主机访问localhost:3306或者通过公网 IP 访问对应端口就是连不上。可以从下面几个方向排查。

先看端口映射是否真的建立。执行：

docker ps

确认端口列显示0.0.0.0:3306->3306/tcp。如果容器启动时-p 3306:3306写错，比如左边写了不存在的宿主机端口，或者少写了冒号，映射就不会生效。再看宿主机端口是否被其他进程占用，执行docker run -p 3306:3306时如果报port is already allocated，说明端口被占，换一个宿主机端口即可。

再看防火墙是否拦截。Linux 上如果启用了 firewalld 或 ufw，即使 Docker 端口映射成功，流量也可能在宿主机防火墙层被丢弃。临时开放端口测试的方法：

sudo firewall-cmd --add-port=3306/tcp --permanent && sudo firewall-cmd --reload

云服务器还涉及安全组规则，需要到云控制台把对应端口加进白名单。很多同学在本地能访问、到云服务器上就死活不通，八成就是这个原因。最后用ss -tlnp | grep 3306确认宿主机实际监听情况，如果监听的是 IPv6 地址而 Docker 映射在 IPv4，访问时也要区分。

6. 从安装到跑通：三个拿来即用的实战

环境装好，网络和镜像问题也理清了，现在终于可以进入最有价值的环节：跑真实服务。我选了三个最典型的场景：带数据卷的数据库、需要容器间通信的 Redis 主从、以及生态里常见的 GitLab 社区版。做完这三个，你对 Docker 的理解会有一个明显提升。

6.1 快速命令速查表

先放一张我平时最常用的命令速查表，实战中会频繁用到：

这里不追求把所有命令一次背下来，重点是理解命令的构成规律：大部分操作都是docker <动作> <对象>，加-d表示后台运行，加-p表示端口映射，加-v表示挂载数据卷，加--name给容器起名。规律掌握了，没见过的命令也能猜出七八分。

6.2 实战一：跑一个MySQL 8.0

MySQL 是使用频率最高的容器场景之一，也特别适合用来理解数据卷为什么重要。执行：

docker run -d \ --name mysql8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=YourPassword \ -v mysql-data:/var/lib/mysql \ mysql:8.0

-e MYSQL_ROOT_PASSWORD是初始化 root 密码的必填环境变量；-v mysql-data:/var/lib/mysql把宿主机上的命名数据卷挂载到容器里的 MySQL 数据目录，这样就算容器被删除，数据库文件依然保留在mysql-data卷里，下次再启动挂载同一个卷就能无缝恢复。

跑起来之后进入容器验证：

docker exec -it mysql8 mysql -uroot -p

如果你用客户端工具连接时报认证插件错误，常见原因是 MySQL 8.0 默认认证插件是caching_sha2_password，部分老客户端不兼容。启动时给 MySQL 容器加上--default-authentication-plugin=mysql_native_password命令参数，或者在创建用户时指定认证方式，都能解决。

日志是排查容器化 MySQL 的第一抓手。执行docker logs mysql8，如果发现初始化失败，多半是环境变量没设置、端口被占或者数据目录权限异常。记住一个原则：容器里服务起不来，先看日志，不要凭感觉去容器里改配置。

6.3 实战二：用自定义网络搭一个Redis主从

Redis 主从是比较适合演示自定义网络的例子。先创建一个自定义网络：

docker network create redis-net

启动主节点：

docker run -d \ --name redis-master \ --network redis-net \ -p 6379:6379 \ redis:7 redis-server --appendonly yes

启动从节点：

docker run -d \ --name redis-slave \ --network redis-net \ -p 6380:6379 \ redis:7 redis-server --replicaof redis-master 6379

注意从节点配置里用的是redis-master这个容器名，而不是某个 IP。这正是自定义网络的价值所在：容器名可以被自动解析成对应容器的 IP，主从关系不受容器重建和 IP 变化的影响。如果你把这两个容器放在默认 bridge 网络里，--replicaof redis-master 6379会直接解析失败，因为默认网络没有内置 DNS。验证主从关系是否建立：

docker exec -it redis-slave redis-cli info replication

看到role:slave，并且master_link_status:up，说明主从已经连通。这个实战同时复习了自定义网络和容器间通信，比单纯背命令有意义得多。

6.4 实战三：直接使用社区镜像部署GitLab社区版

部署 GitLab 一般是最能直观感受 Docker 优势的场景之一。官方镜像包好了整个 GitLab 社区版：

docker run -d \ --name gitlab \ --restart always \ -p 8080:80 \ -p 8443:443 \ -e GITLAB_ROOT_PASSWORD=YourPassword \ gitlab/gitlab-ce

访问http://localhost:8080就能看到 GitLab 的登录界面。这里需要注意，GitLab 的镜像比较大，首次启动初始化通常需要几分钟，期间页面刷新不出来是正常的，用docker logs -f gitlab观察日志，等到日志里出现 GitLab 已经就绪的提示再访问。--restart always表示容器退出后会自动重启，适合托管这类需要长期运行的服务。

GitLab 只是生态中的一个例子。实际上现在很多工具链都是"拉镜像直接跑"的玩法：数据分析可以用 Metabase 镜像，国产数据库像人大金仓也有官方镜像，安全测试环境可以用现成的 DVWA 靶场镜像，甚至有人把 Hadoop 的完整实验环境也做成了镜像，还有机器人开发场景里用容器跑 ROS2 Humble 环境，以及近期比较热的 AI 推理场景，像通过镜像拉起 vLLM 加载 Qwen3-embedding 这类模型服务。Docker 到了一个镜像之后，软件的环境问题就不再是问题了。

6.5 给新手的几条经验

最后分享几条我实际用下来的体会。第一，不要一上来就研究 Docker Compose 和 K8s，先把单个容器的run、ps、logs、exec、stop、rm玩熟，Compose 本质上是多个容器的批处理配置，基础不牢时写出来的配置也很难排查。第二，遇到问题先看日志和docker info，而不是到处重装，90% 的 Docker 问题都能从日志里看到线索。第三，镜像加速和自定义网络是解决多数安装后困惑的关键，花十分钟提前配置好，后面能省下数小时的排错时间。第四，尽量避免在生产环境使用-it交互式启动容器，长期运行的容器应当用-d配合健康检查和自动重启策略。

安装这一关过了，后面学 Docker 的路会顺畅很多。希望这篇能帮你在自己的电脑上顺利跑起第一个容器，之后再用到什么再深入学习也不迟。