Docker容器技术入门：从核心概念到实战部署全解析

1. 从“虚拟机”到“容器”为什么Docker是开发者的新宠如果你和我一样在职业生涯早期接触服务器部署大概率是从一台台笨重的虚拟机开始的。那时候为了部署一个简单的Web应用你需要先装一个VMware或者VirtualBox然后吭哧吭哧地安装一个完整的操作系统再配置环境、安装依赖。整个过程耗时耗力而且每次迁移都像搬家一样充满了不确定性。直到我遇到了Docker这种“一次构建处处运行”的体验彻底改变了我的工作流。简单来说Docker是一个开源的容器化平台。你可以把它理解为一个超级轻量级的“虚拟机”但它和虚拟机有本质区别。虚拟机VM是在物理硬件之上通过一个叫Hypervisor的中间层虚拟出完整的操作系统Guest OS再在上面跑应用。而Docker容器则直接运行在宿主机的操作系统内核之上它只“打包”了应用运行所必需的库、依赖和配置共享宿主机的内核。这就好比虚拟机是建了一栋带地基、水电、装修的完整房子而Docker容器只是一个拎包入住的标准化集装箱公寓。这种差异带来的好处是革命性的。首先启动速度天差地别。启动一个完整的虚拟机需要分钟级而启动一个Docker容器通常只需要秒级甚至毫秒级。其次资源占用大幅降低。一个虚拟机动辄占用几个G的磁盘和几百M的内存而一个精简的Docker容器镜像可能只有几十M运行时内存开销也小得多。最后也是最重要的环境一致性得到了完美解决。你在自己笔记本上构建、测试好的容器镜像可以百分百确信它在测试服务器、生产服务器上以完全相同的方式运行彻底告别了“在我机器上是好的”这种经典难题。结合你提到的“docker desktop failed to start because virtualisation support wasn’t detected”这个高频搜索问题这恰恰是新手入门时最容易遇到的第一个门槛。这个问题直指Docker运行的核心依赖硬件虚拟化支持。Docker DesktopWindows/macOS上的桌面版为了在非Linux系统上运行Linux容器需要依赖一个轻量级的Linux虚拟机通常是WSL2或Hyper-V。如果电脑的BIOS/UEFI设置中没有开启虚拟化技术Intel VT-x / AMD-V这个虚拟机就无法启动Docker Desktop自然也就罢工了。这从侧面说明了理解Docker的底层原理对于解决实际问题至关重要。那么谁需要学习Docker呢我认为任何与软件交付、部署、运维相关的角色都绕不开它。开发者可以用它来搭建一致的本地开发环境测试工程师可以用它快速复现各种测试场景运维工程师则用它来实现服务的快速部署、扩缩容和迁移。可以说Docker已经成为现代软件工程基础设施中的“普通话”。2. 核心概念拆解镜像、容器、仓库与守护进程在动手之前我们必须先理清Docker的几个核心概念。这些概念是理解后续所有操作的基础很多初学者觉得Docker命令复杂往往是因为对这些概念的关系模糊不清。2.1 镜像容器的“蓝图”与“只读模板”镜像是Docker世界的基石。你可以把它想象成一个只读的、分层的文件系统快照。它包含了运行某个软件所需的所有内容代码、运行时环境、系统工具、系统库和设置。镜像是静态的、不可变的。当你从Docker Hub一个公共镜像仓库拉取一个nginx:latest镜像时你得到的就是一个构建好的、可以启动Nginx Web服务器的模板。镜像采用联合文件系统和分层构建的机制。每一层代表Dockerfile镜像构建说明书中的一条指令。例如FROM ubuntu:20.04是一层RUN apt-get update是另一层COPY ./app /app又是一层。这种分层设计带来了巨大的好处共享与复用如果两个镜像都基于ubuntu:20.04那么宿主机上只需要存储一份ubuntu:20.04的基础层。构建高效当你修改Dockerfile并重新构建镜像时Docker会利用缓存只重建发生变化层之后的所有层大大加快了构建速度。体积小巧你只需要存储你自定义的层基础层可以复用。一个常见的误解是镜像就是一个完整的操作系统。其实不然一个极简的Alpine Linux镜像可能只有5MB它只包含了运行应用最核心的组件这正是Docker轻量化的秘密。2.2 容器镜像的运行实例容器是镜像的运行实例。当你执行docker run nginx时Docker引擎会以nginx镜像为模板创建一个可写的容器层通常称为“容器层”或“读写层”然后在其上启动进程。这个“容器层”是关键。所有对运行中容器的修改比如写入日志、创建临时文件、安装新软件都发生在这个可写层上。而底部的镜像层始终保持只读。这种设计意味着你可以基于同一个镜像同时运行成百上千个互不干扰的容器。当容器被删除时这个可写层也会被一并删除所以容器本身是无状态的。任何需要持久化的数据都必须通过“数据卷”挂载到宿主机上。你可以把容器理解为一个隔离的进程。它通过Linux的Namespace技术如PID、Network、Mount Namespace实现了进程、网络、文件系统等的隔离通过Cgroups技术实现了CPU、内存等资源的限制。但它与宿主机共享内核因此比虚拟机轻量得多。2.3 仓库镜像的“App Store”仓库是集中存放镜像的地方类似于代码仓库GitHub。Docker官方维护了一个公共仓库——Docker Hub上面有无数官方和个人维护的镜像从操作系统、数据库到各种中间件和应用应有尽有。除了公共仓库企业通常会搭建私有仓库如Harbor用于存放内部构建的、包含商业代码的镜像保障安全。docker pull命令从仓库拉取镜像docker push命令将本地镜像推送到仓库。2.4 Docker引擎背后的“总指挥”Docker引擎是一个客户端-服务器架构的应用主要包含以下组件Docker Daemon常驻后台的守护进程负责管理镜像、容器、网络、存储等核心对象。我们通过命令行发送的指令最终都由它来执行。REST API一套供程序调用的接口Daemon通过它对外提供服务。Docker CLI我们最常打交道的命令行工具。当我们输入docker run时CLI会通过REST API向Daemon发送指令。理解了这个架构就能明白为什么有时候Docker命令会报“Cannot connect to the Docker daemon”的错误——这通常意味着Docker Daemon没有启动或者当前用户没有权限连接它的Socket。3. 手把手实战安装、配置与第一个容器理论说再多不如动手跑一遍。我们以在Linux系统Ubuntu 20.04为例上安装Docker CE社区版开始。为什么选Linux因为Docker原生运行在Linux上在这里学习能接触到最核心的原理避开Windows/macOS上那些由Docker Desktop引入的额外抽象层。3.1 在Ubuntu上安装Docker引擎注意生产环境请务必参考Docker官方文档并选择与系统版本匹配的安装方式。以下为演示流程。首先更新软件包索引并安装一些必要的工具这些工具允许apt通过HTTPS使用仓库sudo apt-get update sudo apt-get install \ ca-certificates \ curl \ gnupg \ lsb-release接下来添加Docker的官方GPG密钥和稳定版仓库# 创建密钥环目录 sudo mkdir -p /etc/apt/keyrings # 下载并导入GPG密钥 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更新源并安装Docker引擎、CLI及相关组件sudo apt-get update sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin安装完成后启动Docker服务并设置开机自启sudo systemctl start docker sudo systemctl enable docker最后验证安装是否成功。运行经典的hello-world镜像sudo docker run hello-world如果终端打印出“Hello from Docker!”等信息说明Docker已经正确安装并运行。一个关键的权限问题默认情况下运行docker命令需要sudo权限因为Docker Daemon的Unix Socket属于root用户。为了日常使用方便可以将当前用户加入docker用户组sudo usermod -aG docker $USER执行此命令后必须完全退出当前终端会话并重新登录用户组变更才会生效。之后你就可以直接使用docker命令而无需前缀sudo了。3.2 运行你的第一个实用容器Nginx现在我们来运行一个真正有用的容器。Nginx是一个高性能的Web服务器它的Docker镜像非常流行。拉取Nginx镜像如果不指定标签默认拉取latestdocker pull nginx运行一个Nginx容器docker run --name my-nginx -p 8080:80 -d nginx让我们拆解这个命令--name my-nginx给容器起一个名字方便后续管理如停止、重启否则Docker会分配一个随机名字。-p 8080:80端口映射。将宿主机的8080端口映射到容器的80端口Nginx默认监听80。这样你访问http://localhost:8080就能看到容器内的Nginx欢迎页面。-d后台运行模式。容器会在后台启动终端不会被阻塞。nginx要使用的镜像名。现在打开浏览器访问http://localhost:8080你应该能看到“Welcome to nginx!”的页面。恭喜你的第一个服务容器已经跑起来了查看正在运行的容器docker ps查看所有容器包括已停止的docker ps -a3.3 容器基本生命周期管理掌握了运行还要会管理。容器的生命周期命令是使用频率最高的。停止与启动容器# 停止运行中的容器 docker stop my-nginx # 启动已停止的容器 docker start my-nginx # 重启容器 docker restart my-nginxstop发送SIGTERM信号允许进程优雅退出超时后再发送SIGKILL强制终止。start会保留容器原有的配置如端口映射重新启动。进入容器内部有时需要排查问题或执行命令。docker exec -it my-nginx /bin/bash-i保持标准输入打开。-t分配一个伪终端。/bin/bash在容器内执行的命令这里表示启动一个Bash shell。执行完操作后输入exit即可退出容器但容器不会停止因为exec只是附加了一个新的进程。查看容器日志这是排查应用问题的首要步骤。# 查看最新日志 docker logs my-nginx # 实时跟踪日志输出类似 tail -f docker logs -f my-nginx删除容器当容器不再需要时。# 删除已停止的容器 docker rm my-nginx # 强制删除运行中的容器 docker rm -f my-nginx切记删除容器会同时删除其可写层所有未持久化的数据都会丢失。4. 构建自定义镜像编写你的第一个Dockerfile使用现成的镜像很方便但更多时候我们需要将自己的应用打包成镜像。这就需要用到Dockerfile。Dockerfile是一个文本文件包含了一系列构建镜像的指令。4.1 Dockerfile指令详解让我们通过一个简单的Node.js应用示例来理解每条指令的作用。假设我们有一个简单的app.js文件const http require(http); const server http.createServer((req, res) { res.writeHead(200, { Content-Type: text/plain }); res.end(Hello from Dockerized Node.js!\n); }); server.listen(3000, () { console.log(Server running at http://localhost:3000/); });在同目录下创建Dockerfile注意没有后缀名# 第一阶段构建阶段 FROM node:16-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci --onlyproduction # 第二阶段运行阶段 FROM node:16-alpine WORKDIR /app # 从builder阶段复制生产依赖 COPY --frombuilder /app/node_modules ./node_modules # 复制应用源码 COPY . . # 声明容器运行时监听的端口 EXPOSE 3000 # 定义容器启动时执行的命令 CMD [node, app.js]这是一个使用了多阶段构建的优化Dockerfile它比单阶段构建产生的镜像更小、更安全。我们来逐行解析FROM node:16-alpine AS builderFROM指定基础镜像。所有Dockerfile都必须以FROM开始。这里我们选择官方的Node.js 16镜像并使用基于Alpine Linux的变体因为它体积极小。AS builder为此构建阶段命名以便在后续阶段中引用。WORKDIR /app设置工作目录。相当于在容器内执行了cd /app。后续的COPY、RUN、CMD等指令都会在这个目录下执行。使用WORKDIR比直接用RUN cd /app更清晰、更可靠。COPY package*.json ./将宿主机当前目录下的package.json和package-lock.json文件复制到容器的/app目录。这里有个最佳实践先复制依赖声明文件而不是所有源码。因为RUN npm install这步的产物node_modules可以被Docker的构建缓存利用。只要package.json没变即使源码变了Docker也会直接使用缓存的依赖层极大加速构建。RUN npm ci --onlyproductionRUN在构建镜像时执行命令。这里我们使用npm ci而不是npm install。npm ci严格根据package-lock.json安装依赖能确保每次构建的依赖树完全一致适合自动化环境。--onlyproduction只安装生产依赖不安装devDependencies进一步减小镜像体积。第二阶段FROM node:16-alpine开始一个新的、干净的构建阶段。这样最终镜像只包含运行应用所必需的内容而不包含构建工具如npm、编译器和中间文件使得镜像更小、更安全。COPY --frombuilder /app/node_modules ./node_modules从名为builder的第一阶段将已经安装好的node_modules目录复制到当前阶段。这是多阶段构建的精髓。COPY . .将宿主机当前目录的所有源码复制到容器的/app目录。EXPOSE 3000这是一个声明性指令它告诉Docker这个容器在运行时将监听3000端口。它本身并不会发布端口。端口映射仍然需要在docker run时通过-p参数指定。CMD [node, app.js]指定容器启动时默认执行的命令。每个Dockerfile只能有一个CMD指令。这里使用exec格式JSON数组推荐使用这种格式因为它能避免shell解析带来的问题。它相当于在容器内执行node app.js。4.2 构建与运行自定义镜像在包含Dockerfile和app.js的目录下执行构建命令docker build -t my-node-app:v1 .-t my-node-app:v1为构建的镜像打上标签格式为名称:版本。标签有助于版本管理。.构建上下文路径。Docker Daemon会将这个目录下的所有文件打包发送给构建进程。因此务必注意.dockerignore文件的使用避免将node_modules、日志等无用或敏感文件打包进去导致构建缓慢或镜像臃肿。构建成功后运行它docker run -d -p 3000:3000 --name my-running-app my-node-app:v1访问http://localhost:3000就能看到“Hello from Dockerized Node.js!”的输出。4.3 镜像管理与优化技巧查看镜像docker images给镜像打新标签docker tag my-node-app:v1 my-registry.com/username/my-node-app:latest推送镜像到私有仓库以Docker Hub为例需先docker logindocker push my-registry.com/username/my-node-app:latest删除本地镜像# 删除指定镜像 docker rmi my-node-app:v1 # 删除所有悬空镜像未被任何容器引用的中间层镜像 docker image prune # 强制删除所有未被使用的镜像 docker image prune -a镜像优化心得使用.dockerignore文件像.gitignore一样列出不需要加入构建上下文的文件和目录能显著减少构建上下文大小提升构建速度。多阶段构建是王道对于编译型语言如Go、Java或需要构建步骤的前端项目多阶段构建能分离构建环境和运行环境产出极简的最终镜像。选择合适的基础镜像优先选择官方镜像并选择Alpine等精简版本。但要注意某些库在Alpine上可能需要额外安装如果遇到兼容性问题可退而选择-slim版本。合并RUN指令在保证可读性的前提下将多个RUN指令用连接成一个可以减少镜像的层数。但过度合并会影响缓存利用率需要权衡。注意层顺序将变化频率低的层如安装系统包放在前面变化频率高的层如复制应用代码放在后面能更好地利用Docker的构建缓存。5. 数据持久化与网络互联让容器变得有用容器默认是无状态的重启后数据就没了。但在真实场景中数据库数据、应用日志、上传的文件都需要持久化。同时多个容器之间也需要通信。这就引出了Docker的另外两大核心功能数据卷和网络。5.1 数据卷容器数据的“外接硬盘”数据卷是宿主机上的一个目录或文件它绕过了容器的联合文件系统可以被一个或多个容器挂载和使用。数据卷的生命周期独立于容器删除容器不会删除数据卷。创建和管理数据卷# 创建一个命名的数据卷 docker volume create my-data # 查看所有数据卷 docker volume ls # 查看数据卷详情如挂载点 docker volume inspect my-data # 删除未使用的数据卷 docker volume prune在运行容器时使用数据卷# 将数据卷挂载到容器内的 /data 路径 docker run -d --name mysql-db \ -v my-data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDsecret \ mysql:8.0这里-v my-data:/var/lib/mysql将名为my-data的数据卷挂载到容器内的MySQL数据目录。即使容器被删除数据依然保存在my-data卷中。绑定挂载另一种更直接的方式将宿主机的特定目录挂载到容器内。docker run -d --name nginx-with-config \ -v /host/path/nginx.conf:/etc/nginx/nginx.conf:ro \ -v /host/path/html:/usr/share/nginx/html \ nginx-v /host/path/nginx.conf:/etc/nginx/nginx.conf:ro将宿主机的配置文件挂载进去并设置为只读ro防止容器内进程误修改。绑定挂载非常适合开发环境你可以在宿主机上用熟悉的IDE修改代码容器内能实时看到变化。提示生产环境更推荐使用命名数据卷因为它的生命周期由Docker管理与宿主机文件系统解耦移植性更好。而绑定挂载依赖于宿主机的特定路径。5.2 Docker网络容器间的通信桥梁默认情况下Docker会创建三种网络docker network ls你会看到bridge默认、host、none。bridge桥接网络默认网络模式。Docker会创建一个名为docker0的虚拟网桥每个容器会分配一个虚拟网卡并连接到这个网桥。容器之间可以通过IP地址通信但需要通过-p参数映射端口才能被宿主机外部访问。host主机网络容器不会虚拟出自己的网卡而是直接使用宿主机的IP和端口。此时容器在网络层面没有隔离性能最好但端口容易冲突。none无网络容器有独立的Network Namespace但不进行任何网络配置需要手动配置网络。创建自定义桥接网络默认的bridge网络下容器只能通过IP互通。创建自定义桥接网络则容器之间可以通过容器名互相访问这对于多容器应用如微服务非常方便。# 创建一个自定义网络 docker network create my-app-network # 运行容器时指定网络 docker run -d --name mysql --network my-app-network -e MYSQL_ROOT_PASSWORDsecret mysql:8.0 docker run -d --name webapp --network my-app-network -p 8080:80 my-web-app现在在webapp容器内部你可以直接使用mysql这个主机名来连接到数据库容器比如数据库连接字符串可以配置为jdbc:mysql://mysql:3306/mydb。Docker内置的DNS服务会自动解析容器名。容器间网络隔离不同的自定义网络是相互隔离的。你可以创建frontend-network和backend-network将前端和后端服务分别接入实现网络层面的隔离增强安全性。6. Docker Compose告别繁琐的多容器管理当你的应用由多个服务组成比如一个Web应用一个数据库一个缓存用一堆docker run命令来管理会非常痛苦。Docker Compose就是用来解决这个问题的工具。它允许你使用一个YAML文件docker-compose.yml来定义和运行多个容器。6.1 编写你的第一个docker-compose.yml假设我们有一个简单的WordPress博客应用它需要MySQL数据库。手动运行需要分别启动MySQL和WordPress容器并处理好网络和数据卷。用Compose则简单得多。创建一个docker-compose.yml文件version: 3.8 services: db: image: mysql:8.0 # 如果本地没有镜像会自动拉取 volumes: - db_data:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: somewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress networks: - wp-network wordpress: depends_on: - db image: wordpress:latest ports: - 8080:80 restart: always environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress WORDPRESS_DB_NAME: wordpress volumes: - wp_data:/var/www/html networks: - wp-network volumes: db_data: wp_data: networks: wp-network: driver: bridge关键字段解析version指定Compose文件格式的版本。services定义要运行的各个容器服务。image指定使用的镜像。volumes定义数据卷挂载。顶层的volumes声明了命名卷db_data和wp_data服务中直接引用。这样数据就持久化了。ports端口映射格式为宿主机端口:容器端口。environment设置容器内的环境变量。这是配置应用如数据库连接信息的推荐方式比写死在镜像里更灵活。networks指定服务加入的网络。这里所有服务都加入了自定义的wp-network所以WordPress容器可以用db这个服务名访问MySQL。depends_on声明依赖关系。Compose会先启动db服务再启动wordpress服务。但请注意这只控制启动顺序不等待服务就绪。对于数据库应用层应有重连机制。restart: always设置容器退出时总是重启这对于需要保持长期运行的服务非常有用。6.2 使用Compose管理应用生命周期在包含docker-compose.yml的目录下执行以下命令启动所有服务后台模式docker-compose up -d-d代表后台运行。Compose会创建网络、数据卷然后按依赖顺序拉取镜像并启动容器。查看运行状态docker-compose ps查看所有服务的日志docker-compose logs查看特定服务日志docker-compose logs wordpress实时跟踪日志docker-compose logs -f wordpress停止所有服务docker-compose down这个命令会停止并删除所有容器、网络默认创建的。但不会删除数据卷这是为了保护你的数据。如果你想同时删除数据卷需要加-v参数docker-compose down -v使用前请务必确认。停止服务但不删除容器docker-compose stop重启服务docker-compose restart一键构建、创建、启动服务如果服务定义中包含了build字段docker-compose up --build -d6.3 Compose在开发与生产中的实践开发环境Compose是本地开发的利器。你可以定义一个docker-compose.yml里面包含你的应用、数据库、缓存、消息队列等所有依赖。新同事克隆代码后只需一条docker-compose up命令就能获得一个完整的、与生产环境高度一致的开发环境极大降低了搭建环境的成本。生产环境对于简单的单机部署Compose也完全胜任。但需要注意移除端口映射生产环境通常会有Nginx等反向代理在前端因此Compose文件中可以只定义容器间的内部端口不映射到宿主机高危端口。使用环境变量文件将敏感配置如密码、密钥写入.env文件并在Compose文件中通过env_file字段引入避免密码硬编码在YAML文件中。指定镜像标签生产环境务必使用明确的镜像标签如myapp:v1.2.3而不是latest以确保每次部署的版本一致性。资源限制在deploy.resources或旧版本的mem_limit,cpus字段中为服务设置CPU和内存限制防止某个容器耗尽主机资源。对于更复杂的集群部署、服务发现、动态扩缩容就需要用到Docker Swarm或Kubernetes这类容器编排平台了但Compose是理解多容器应用编排的绝佳起点。7. 避坑指南与进阶学习路径回顾开头提到的“virtualisation support not detected”问题这只是Docker学习路上无数个坑中的一个。下面我总结了一些常见问题和个人踩坑经验。7.1 常见问题排查思路Docker命令执行报错Cannot connect to the Docker daemon检查Daemon状态sudo systemctl status docker。如果未运行则启动它sudo systemctl start docker。检查用户组确保当前用户已加入docker组并且已重新登录。检查Socket权限有时/var/run/docker.sock的权限可能异常。容器启动后立即退出查看日志docker logs container_id是第一步通常错误信息会直接打印出来。检查前台进程容器内必须有一个前台进程在运行。如果Dockerfile的CMD是启动一个后台服务脚本脚本启动服务后自己退出了那么容器也会因为主进程结束而退出。确保CMD或ENTRYPOINT指定的命令是持续运行的前台命令。交互式运行排查使用docker run -it --entrypoint /bin/sh image进入容器shell手动执行启动命令观察输出。磁盘空间不足Docker会占用大量磁盘空间尤其是镜像、容器层和构建缓存。定期清理# 删除所有已停止的容器、未使用的网络、悬空镜像和构建缓存 docker system prune -a # 谨慎使用会清理一切未使用的资源包括数据卷除非加 --volumes也可以配置Docker Daemon的日志驱动和日志轮转策略防止容器日志撑爆磁盘。端口冲突运行容器时提示Bind for 0.0.0.0:8080 failed: port is already allocated。解决方案更改宿主机映射端口如-p 8081:80或者停止并删除正在占用端口的容器。7.2 从入门到进阶的学习建议掌握基础操作后你可以沿着以下路径深入深入Dockerfile学习更多指令如ARG构建参数、ENV环境变量、ENTRYPOINT入口点与CMD配合使用、HEALTHCHECK健康检查。理解镜像分层原理优化构建速度和镜像大小。容器安全了解容器安全最佳实践。比如不以root用户运行容器使用USER指令、定期扫描镜像漏洞、使用可信的基础镜像、最小化镜像攻击面。容器编排当你需要管理数十上百个容器时就需要编排工具。Docker SwarmDocker原生的轻量级编排工具概念简单适合中小规模集群。Kubernetes事实上的容器编排标准功能强大但学习曲线陡峭。可以从Minikube或Kind在本地搭建学习环境开始。CI/CD集成将Docker融入你的持续集成/持续部署流水线。在CI阶段构建镜像并推送到镜像仓库在CD阶段从仓库拉取镜像并部署到服务器。GitLab CI、Jenkins、GitHub Actions等都提供了良好的Docker支持。监控与日志学习如何使用docker stats查看容器资源使用情况如何将容器日志收集到ELK、Loki等集中式日志系统如何利用cAdvisor、Prometheus监控容器集群。我个人最大的体会是学习Docker不要停留在命令记忆上一定要理解其背后的设计哲学一次构建处处运行隔离与共享的平衡声明式配置。理解了这些无论是解决具体问题还是学习更上层的编排工具都会事半功倍。从今天起尝试把你手头的一个小项目Docker化这是最好的学习方式。