docker

01-docker 简介

01- 为什么会有docker 出现

一款产品从开发到上线，从操作系统，到运行环境，再到应用配置。作为开发+运维之间的协作我们需要关心很多东西，这也是很多互联网公司都不得不面对的问题，特别是各种版本的迭代之后，不同版本环境的兼容，对运维人员都是考验
Docker之所以发展如此迅速，也是因为它对此给出了一个标准化的解决方案。
环境配置如此麻烦，换一台机器，就要重来一次，费力费时。很多人想到，能不能从根本上解决问题，软件可以带环境安装？也就是说，安装的时候，把原始环境一模一样地复制过来。开发人员利用 Docker 可以消除协作编码时“在我的机器上可正常工作”的问题。

之前在服务器配置一个应用的运行环境，要安装各种软件，Java/Tomcat/MySQL/JDBC驱动包等。安装和配置这些东西有多麻烦就不说了，它还不能跨平台。假如我们是在 Windows 上安装的这些环境，到了 Linux 又得重新装。况且就算不跨操作系统，换另一台同样操作系统的服务器，要移植应用也是非常麻烦的。

docker 解决软件代码环境依赖的问题，将代码和环境一起打包。

02-docker理念简介

Docker是基于Go语言实现的云开源项目。
Docker的主要目标是“Build，Ship and Run Any App,Anywhere”，也就是通过对应用组件的封装、分发、部署、运行等生命周期的管理，使用户的APP（可以是一个WEB应用或数据库应用等等）及其运行环境能够做到“一次封装，到处运行”。

Linux 容器技术的出现就解决了这样一个问题，而 Docker 就是在它的基础上发展过来的。将应用运行在 Docker 容器上面，而 Docker 容器在任何操作系统上都是一致的，这就实现了跨平台、跨服务器。只需要一次配置好环境，换到别的机子上就可以一键部署好，大大简化了操作

解决了运行环境和配置问题软件容器，方便做持续集成并有助于整体发布的容器虚拟化技术。

03-传统虚拟机和容器的对比

虚拟机（virtual machine）就是带环境安装的一种解决方案。
它可以在一种操作系统里面运行另一种操作系统，比如在Windows 系统里面运行Linux 系统。应用程序对此毫无感知，因为虚拟机看上去跟真实系统一模一样，而对于底层系统来说，虚拟机就是一个普通文件，不需要了就删掉，对其他部分毫无影响。这类虚拟机完美的运行了另一套系统，能够使应用程序，操作系统和硬件三者之间的逻辑不变。

虚拟机的缺点：
1 资源占用多 2 冗余步骤多 3 启动慢

由于前面虚拟机存在这些缺点，Linux 发展出了另一种虚拟化技术：Linux 容器（Linux Containers，缩写为 LXC）。
Linux 容器不是模拟一个完整的操作系统，而是对进程进行隔离。有了容器，就可以将软件运行所需的所有资源打包到一个隔离的容器中。容器与虚拟机不同，不需要捆绑一整套操作系统，只需要软件工作所需的库资源和设置。系统因此而变得高效轻量并保证部署在任何环境中的软件都能始终如一地运行。

比较了 Docker 和传统虚拟化方式的不同之处：
*传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整操作系统，在该系统上再运行所需应用进程；
*而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。
* 每个容器之间互相隔离，每个容器有自己的文件系统，容器之间进程不会相互影响，能区分计算资源。

04-docker 可以做什么

更快速的应用交付和部署

传统的应用开发完成后，需要提供一堆安装程序和配置说明文档，安装部署后需根据配置文档进行繁杂的配置才能正常运行。Docker化之后只需要交付少量容器镜像文件，在正式生产环境加载镜像并运行即可，应用安装配置在镜像里已经内置好，大大节省部署配置和测试验证时间。
更便捷的升级和扩缩容

随着微服务架构和Docker的发展，大量的应用会通过微服务方式架构，应用的开发构建将变成搭乐高积木一样，每个Docker容器将变成一块“积木”，应用的升级将变得非常容易。当现有的容器不足以支撑业务处理时，可通过镜像运行新的容器进行快速扩容，使应用系统的扩容从原先的天级变成分钟级甚至秒级。
更简单的系统运维

应用容器化运行后，生产环境运行的应用可与开发、测试环境的应用高度一致，容器会将应用程序相关的环境和状态完全封装起来，不会因为底层基础架构和操作系统的不一致性给应用带来影响，产生新的BUG。当出现程序异常时，也可以通过测试环境的相同容器进行快速定位和修复。
更高效的计算资源利用

Docker是内核级虚拟化，其不像传统的虚拟化技术一样需要额外的Hypervisor支持，所以在一台物理机上可以运行很多个容器实例，可大大提升物理服务器的CPU和内存的利用率。

05-docker 官网

docker官网：http://www.docker.com
Docker Hub官网: https://hub.docker.com/

02-docker 安装

01-前提条件

02-docker 的基本组成

镜像（image)

容器(container)

仓库（repository)

03-docker 的架构图

04-centos7安装docker

目前 centos7 生命周期已经结束，但是安装方法应该差不多

一、主流版本现状

‌CentOS 7‌：生命周期已于 ‌2024年6月30日‌ 正式结束，不再接收官方安全补丁和功能更新，仅能通过第三方源获取有限维护，不建议在新生产环境部署。
‌CentOS 8‌：已于2021年底提前终止官方支持，目前已完全停止所有官方更新。
‌CentOS Stream‌：是红帽官方主推的滚动更新替代分支，作为 RHEL 的上游开发版本持续迭代，目前主流使用版本为 CentOS Stream 8、CentOS Stream 9，可长期获取官方更新支持。

centos6

centos7

具体安装步骤参考官网或者询问大模型

https://docs.docker.com/engine/install/

注意在国内，推荐使用国内的docker 镜像仓库安装相关的镜像。

05-镜像加速器配置

06-hello world 分析

docker run hello-world

07-为什么Docker 比VM虚拟机快

03-docker 常用命令

01- 帮助启动类

02-镜像命令

docker images

docker search

docker search --limit 5 redis 显示前五条

docker pull

docker images 是用于列出本地 Docker 镜像的命令，参数 -a、-q 以及组合参数 -aq（即 -a -q）的主要区别在于‌显示内容的范围‌和‌输出格式‌。

以下是三者的详细对比：

docker images -a

‌含义‌：列出本地‌所有‌镜像。
‌特点
- 默认情况下，docker images会隐藏中间层镜像（即没有 Repository 和 Tag，显示为 <none> 的镜像）。
- 加上 -a (或 --all) 参数后，会显示包括‌中间层镜像‌在内的所有镜像层。
- 输出包含完整信息列：REPOSITORY（仓库名）、TAG（标签）、IMAGE ID（镜像ID）、CREATED（创建时间）、SIZE（大小）。
‌适用场景
- 调试镜像构建过程，检查中间层是否正确生成。
- 查看完整的镜像依赖链。
- 识别未被标记的“悬空”中间层镜像，以便清理磁盘空间。

docker images -q

‌含义‌：仅显示镜像的 ‌ID‌。
‌特点
- -q (或 --quiet) 参数会让输出变得非常简洁，只打印镜像的唯一标识符（Image ID）。
- 默认情况下，它只显示顶层镜像（最终镜像）的 ID，不显示中间层。
‌适用场景
- 在脚本中使用，便于将镜像 ID 传递给其他命令（如批量删除、批量导出等）。
- 快速获取特定镜像的 ID。

docker images -aq (或 docker images -a -q)

‌含义‌：列出‌所有‌镜像（含中间层）的 ‌ID‌。
‌特点
- 这是 -a 和 -q 的组合使用。
- 它不仅显示顶层镜像的 ID，还显示所有中间层镜像的 ID。
- 输出结果是一长串镜像 ID 列表。
适用场景
- ‌批量删除所有镜像‌：常用于清理环境，例如执行 docker rmi $(docker images -aq) 可以强制删除本地所有镜像（包括中间层）。
- 需要获取所有镜像层 ID 进行底层分析或脚本处理时。

总结对比表

表格

命令	显示内容	是否包含中间层	输出格式	典型用途
`docker images`	镜像详细信息 (Repo, Tag, ID, Size等)	否	表格形式	日常查看已拉取/构建的最终镜像
`docker images -a`	镜像详细信息 (Repo, Tag, ID, Size等)	‌是‌	表格形式	调试构建过程，查看完整镜像层结构
`docker images -q`	仅镜像 ID	否	纯文本 ID 列表	脚本中获取顶层镜像 ID
`docker images -aq`	仅镜像 ID	‌是‌	纯文本 ID 列表	批量删除所有镜像，获取所有层 ID

示例输出差异

假设本地有一个基于 alpine 构建的简单镜像，其构建过程产生了一个中间层。

‌docker images‌:

textREPOSITORY   TAG       IMAGE ID       CREATED          SIZE
my-app       latest    abc123456789   10 minutes ago   5MB

‌docker images -a‌:

textREPOSITORY   TAG       IMAGE ID       CREATED          SIZE
my-app       latest    abc123456789   10 minutes ago   5MB
<none>       <none>    def987654321   10 minutes ago   5MB  <-- 中间层
alpine       latest    fedcba987654   2 weeks ago      5MB

‌docker images -q‌:
```
textabc123456789
fedcba987654
```

‌docker images -aq‌:

textabc123456789
def987654321
fedcba987654

docker system df

docker system df 是 Docker 提供的一个用于‌查看 Docker 守护进程磁盘使用情况‌的核心命令。它能快速展示镜像、容器、数据卷和构建缓存这四类主要资源占用的空间大小，并明确指出哪些空间是可以回收（清理）的。

该命令类似于 Linux 系统中的 df -h，但专门针对 Docker 内部的对象进行统计。

命令输出详解

执行 docker system df 后，通常会看到如下表格：

textTYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          24        12        4.2GB     2.1GB (50%)
Containers      15        8         1.3GB     1.3GB (100%)
Local Volumes   5         3         750MB     400MB (53%)
Build Cache     18        0         1.8GB     1.8GB (100%)

各列含义如下：

‌TYPE（类型）

‌：Docker 对象的类型，包括：
- Images：本地存储的所有镜像。
- Containers：所有容器（包括运行中和已停止的）。
- Local Volumes：本地命名数据卷。
- Build Cache：构建镜像时产生的中间层缓存（Docker BuildKit 产生）。
‌TOTAL（总数）‌：该类型对象的总数量。
‌ACTIVE（活跃数）‌：当前正在被使用或引用的对象数量。
- 对于镜像：指被至少一个容器（无论运行与否）引用的镜像。
- 对于容器：指处于“运行”状态的容器（注：不同版本定义略有差异，通常指未被标记为可删除的状态，但在 df 语境下，通常指非悬空状态）。更准确的理解是：Active 表示该资源当前有依赖关系，不能简单通过 prune 清理。
- 对于卷：指被至少一个容器挂载使用的卷。
‌SIZE（占用大小）：该类型对象占用的总磁盘空间。
- ‌注意‌：这里的 Size 是‌逻辑大小‌。由于 Docker 镜像采用分层存储且共享底层，多个镜像可能共享同一层数据，因此所有镜像 Size 之和可能大于实际物理磁盘占用。
‌RECLAIMABLE（可回收空间）：可以通过清理操作释放的空间大小及百分比。
- 这是排查磁盘爆满时最关注的指标。高百分比意味着存在大量无用资源（如悬空镜像、已停止容器、未挂载卷）。

常用参数

‌-v 或 --verbose‌：显示详细信息。
- 默认命令只给出汇总数据。加上 -v 后，会列出每个具体镜像、容器、卷的 ID、名称、大小和状态，方便定位具体是哪个大文件或镜像占用了空间。
- 示例：docker system df -v
‌--format‌：自定义输出格式。
- 支持 Go 模板或 JSON 格式，便于脚本处理。
- 示例：docker system df --format "{{.Type}}\t{{.Size}}"

如何根据输出清理空间

根据 RECLAIMABLE 列的提示，可以使用 docker system prune 系列命令进行清理：

表格

目标资源	清理命令	说明
‌所有未使用资源‌	`docker system prune`	清理停止的容器、未使用的网络、悬空镜像（dangling images）和构建缓存。‌默认不删除卷‌。
‌所有未使用镜像‌	`docker system prune -a`	除了上述内容，还会删除所有未被任何容器引用的镜像（不仅仅是悬空镜像）。‌慎用‌，可能导致下次启动容器时需要重新拉取镜像。
‌未使用的卷‌	`docker system prune --volumes`	清理未被任何容器引用的数据卷。‌危险操作‌，可能导致数据丢失，请确认数据已备份或不再需要。
‌组合清理‌	`docker system prune -a --volumes`	清理所有未使用的镜像、容器、网络和卷。这是最彻底的清理方式，‌务必谨慎使用‌。

排查磁盘爆满的实战思路

当服务器磁盘告警时，可按以下步骤操作：

‌全局概览‌：运行 docker system df，查看哪一类资源（Images/Containers/Volumes/Cache）占比最高且可回收空间大。
‌深入定位‌：
- 如果是 ‌Images‌ 占用高：运行 docker system df -v 查看具体是哪个镜像大，或使用 docker images --sort=size 排序。
- 如果是 ‌Containers‌ 占用高：通常是容器日志膨胀。检查 /var/lib/docker/containers/<container-id>/<container-id>-json.log 文件大小。可通过配置 daemon.json 中的 log-driver 和 max-size 限制日志大小。
- 如果是 ‌Build Cache‌ 占用高：运行 docker builder prune 清理构建缓存。
‌执行清理‌：根据定位结果，选择对应的 prune 命令或手动删除特定对象（docker rmi, docker rm, docker volume rm）。
注意事项

‌数据备份‌：在执行涉及卷（Volumes）的清理操作前，务必确认重要数据已备份，因为卷中的数据删除后不可恢复。
‌生产环境谨慎使用 -a‌：docker system prune -a 会删除所有未被运行的容器引用的镜像，这可能导致其他依赖这些镜像的服务在重启时失败（需要重新拉取）。建议在生产环境中仅清理悬空镜像（不带 -a）。
‌逻辑大小 vs 物理大小‌：docker system df 显示的镜像大小是逻辑大小，实际磁盘占用可能更小（因为共享层）。若需查看精确的物理磁盘占用，需结合 du -sh /var/lib/docker 等系统命令分析。

docker rmi

docker rmi 是 Docker 中用于‌删除本地镜像‌的命令。它的核心作用是从主机节点中移除一个或多个镜像及其关联的标签。

基本语法

docker rmi [OPTIONS] IMAGE [IMAGE...]

‌IMAGE‌：可以是镜像名称（如 mysql:5.7）、镜像 ID（短 ID 或长 ID）或镜像摘要（Digest）。

常用参数

参数	简写	说明
`--force`	`-f`	‌强制删除‌。即使有容器正在引用该镜像，也会强制移除镜像标签并尝试删除镜像数据。若镜像被运行中的容器引用，通常需先停止/删除容器或使用此参数强制解除引用（注意：这不会删除容器本身，但可能导致容器无法重新启动）。
`--no-prune`		‌不删除未标记的父镜像‌。默认情况下，如果删除某个镜像后，其父镜像（中间层）变得未被任何镜像引用，Docker 会自动删除这些悬空的父镜像。使用此参数可保留这些父镜像。

使用示例

✅ 删除单个镜像

通过镜像名和标签删除：

docker rmi mysql:5.7

通过镜像 ID 删除：

docker rmi ee7cbd482336

✅ 批量删除所有镜像

‌⚠️ 高危操作‌：这将删除本地所有镜像，请谨慎使用。

docker rmi $(docker images -q)

或者使用更现代的过滤方式删除所有未使用的镜像：

docker image prune -a -f

✅ 删除悬空镜像（Dangling Images）

悬空镜像是指没有标签且未被任何容器引用的中间层镜像（在 docker images 中显示为 <none>）。

bashdocker rmi $(docker images -f "dangling=true" -q)
# 或者推荐使用
docker image prune -f

关键注意事项
‌删除标签 vs 删除镜像‌：
- 如果一个镜像有多个标签（例如 test:latest 和 test:v1 指向同一个 Image ID），执行 docker rmi test:latest ‌只会移除该标签‌，镜像数据本身不会被删除，直到所有指向该 Image ID 的标签都被移除。
- 只有当最后一个标签被移除，且没有容器引用该镜像时，镜像的数据层才会被真正从磁盘上清除。
‌容器引用限制‌：
- 默认情况下，如果有容器（无论运行与否）正在使用该镜像，docker rmi 会报错并拒绝删除。
- 必须先删除依赖该镜像的容器（docker rm <container_id>），或者使用 -f 参数强制移除镜像标签（但容器仍存在，只是启动时会因找不到镜像而失败）。
‌docker rmi vs docker rm‌：
- docker rmi：删除‌镜像‌（Image）。
- docker rm：删除‌容器‌（Container）。
- 两者对象不同，切勿混淆。
‌不可恢复性‌：
- 镜像一旦删除，本地即消失。如果该镜像未推送到远程仓库（Registry），且没有其他备份，将无法恢复。建议在执行批量删除前，先用 docker images 确认列表。
最佳实践建议

‌日常清理‌：推荐使用 docker system prune 或 docker image prune，它们能更安全地自动识别并清理未使用的资源。
‌CI/CD 环境‌：在自动化脚本中，可使用 docker rmi -f $(docker images -q) 快速清理环境，但需确保后续步骤会重新拉取所需镜像。
‌生产环境‌：避免随意使用 -f 强制删除，应先检查是否有服务依赖该镜像，防止服务中断。

03- 容器命令

docker run

docker run 是 Docker 中最核心、最常用的命令，用于‌基于指定镜像创建并启动一个新的容器‌。它实际上是 docker create（创建容器）和 docker start（启动容器）两个操作的组合。

基本语法

docker run [OPTIONS] IMAGE [COMMAND] [ARG...]

‌IMAGE‌：必填项，指定要运行的镜像名称及标签（如 nginx:latest）。如果本地不存在该镜像，Docker 会自动从配置的仓库（默认为 Docker Hub）拉取。
‌COMMAND‌：可选项，覆盖镜像默认的启动命令（CMD/ENTRYPOINT）。

常用参数分类

🚀 运行模式

-d：‌后台运行‌（Detached mode），容器在后台启动，命令行立即返回容器 ID。
-it：‌交互模式‌。-i 保持标准输入打开，-t 分配伪终端。常用于调试或进入容器内部（如 docker run -it ubuntu /bin/bash）。
--rm：容器退出后‌自动删除‌。常用于一次性任务或测试，避免产生大量已停止的容器占用空间。

🌐 网络与端口

-p <宿主机端口>:<容器端口>：‌端口映射‌。将宿主机的端口流量转发到容器内部。例如 -p 8080:80 表示访问宿主机的 8080 端口即访问容器的 80 端口。
-P：‌随机端口映射‌。将容器暴露的所有端口随机映射到宿主机的高位端口。
--network <网络名>：指定容器连接的网络模式（如 bridge, host, none 或自定义网络）。

💾 存储与环境

-v <宿主机路径>:<容器路径>：‌卷挂载‌。将宿主机的目录或命名卷挂载到容器中，实现数据持久化或共享。
-e <KEY>=<VALUE>：‌设置环境变量‌。向容器内注入配置信息。
--name <名称>：为容器指定一个易记的名称，否则 Docker 会随机生成一个名字。

⚙️ 资源与安全

-m / --memory：限制容器最大内存使用量（如 512m）。
--cpus：限制容器可用的 CPU 核心数（如 1.5）。
--restart <策略>：设置重启策略。常用值：no（默认，不重启）、on-failure（出错时重启）、always（始终重启）。
--privileged：赋予容器‌特权模式‌，使其拥有几乎等同于宿主机的 root 权限（慎用，存在安全风险）。

典型使用示例

✅ 后台运行 Web 服务

# 启动 Nginx，后台运行，映射端口 8080->80，命名为 web-server，出错自动重启
docker run -d \
  --name web-server \
  -p 8080:80 \
  --restart on-failure \
  nginx:latest

✅ 交互式调试环境

# 启动 Ubuntu 容器，进入 bash 交互界面，退出后自动删除容器
docker run -it --rm ubuntu:22.04 /bin/bash

✅ 带数据存储的应用

# 启动 MySQL，挂载本地目录用于数据持久化，设置 root 密码环境变量
docker run -d \
  --name mysql-db \
  -v /my/data:/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=my-secret-pw \
  -p 3306:3306 \
  mysql:8.0

执行流程简述

当执行 docker run 时，Docker 守护进程按以下顺序操作：

‌镜像检查‌：检查本地是否有指定镜像，若无则从 Registry 拉取。
‌创建容器‌：基于镜像创建一个可写的容器层，分配唯一的容器 ID，配置网络、存储、资源限制等元数据。
‌分配命名空间‌：为容器隔离 PID、网络、IPC、Mount 等命名空间。
‌启动进程‌：在容器内执行指定的命令（或镜像默认的 ENTRYPOINT/CMD），将其作为主进程（PID 1）运行。
‌状态监控‌：守护进程持续监控主进程状态，若进程退出，根据 --restart 策略决定是否重启。
注意事项

‌镜像标签‌：生产环境建议明确指定镜像版本标签（如 nginx:1.25-alpine），避免使用 latest，以确保部署的一致性和可复现性。
‌端口冲突‌：使用 -p 映射端口时，需确保宿主机对应端口未被其他进程占用。
‌数据持久化‌：容器文件系统是临时的，容器删除后数据会丢失。重要数据务必通过 -v 挂载卷或使用命名卷进行持久化。
‌资源限制‌：建议始终设置内存和 CPU 限制，防止单个容器因异常消耗过多资源导致宿主机不稳定。

docker ps

docker ps 是 Docker 中最常用的命令之一，用于‌列出当前系统中的容器信息‌。默认情况下，它只显示‌正在运行（Running）‌的容器。通过搭配不同的参数，你可以查看已停止的容器、过滤特定条件的容器，或者自定义输出格式以便在脚本中使用。

基本语法

docker ps [OPTIONS]

核心参数详解

参数	简写	说明
`--all`	`-a`	显示‌所有‌容器，包括已停止（Exited）、创建中（Created）等状态的容器。默认只显示运行中的。
`--quiet`	`-q`	‌静默模式‌，仅显示容器 ID。常用于批量操作（如批量删除、批量停止）。
`--filter`	`-f`	根据条件‌过滤‌输出。支持按状态、名称、镜像、标签等过滤。
`--format`		使用 Go template ‌自定义输出格式‌。可输出表格、JSON 或特定字段。
`--latest`	`-l`	显示最近创建的‌一个‌容器（无论状态如何）。
`--last`	`-n`	显示最近创建的 ‌n‌ 个容器。例如 `-n 5` 显示最近 5 个。
`--size`	`-s`	显示容器的文件大小（逻辑大小和虚拟大小）。
`--no-trunc`		显示完整信息，不截断输出（如完整的容器 ID 和镜像名称）。

输出字段含义

执行 docker ps 后，默认输出包含以下列：

‌CONTAINER ID‌: 容器的唯一标识符（短 ID）。
‌IMAGE‌: 容器启动时使用的镜像名称及标签。
‌COMMAND‌: 容器启动时执行的命令（即镜像中的 CMD 或 ENTRYPOINT）。
‌CREATED‌: 容器创建的时间。
‌STATUS : 容器当前的状态。常见状态包括：
- Up: 正在运行。
- Exited: 已停止退出。
- Created: 已创建但未启动。
- Restarting: 正在重启。
- Paused: 已暂停。
- Dead: 死亡状态（通常需手动清理）。
‌PORTS‌: 端口映射信息。格式为 宿主机IP:宿主机端口->容器端口/协议。若未映射则不显示。
‌NAMES‌: 容器的名称。若启动时未指定 --name，Docker 会随机生成一个名字。

常用实战示例

✅ 基础查询

# 查看正在运行的容器
docker ps

# 查看所有容器（包括已停止的）
docker ps -a

# 查看最近创建的 3 个容器
docker ps -n 3

# 查看最近创建的 1 个容器
docker ps -l

✅ 过滤查询（Filter）

# 查找所有已停止的容器
docker ps -a --filter "status=exited"

# 查找正在运行的容器
docker ps --filter "status=running"

# 查找基于特定镜像创建的容器
docker ps --filter "ancestor=nginx:latest"

# 查找带有特定标签的容器
docker ps --filter "label=com.example.version=1.0"

# 查找名称包含 "web" 的容器
docker ps --filter "name=web"

✅ 格式化输出（Format）

# 仅显示容器 ID（常用于脚本批量操作，如批量删除）
docker ps -aq

# 自定义表格输出：只显示 ID、名称和状态
docker ps --format "table {{.ID}}\t{{.Names}}\t{{.Status}}"

# 输出 JSON 格式（便于程序解析）
docker ps --format '{{json .}}'

# 显示容器大小
docker ps -s

✅ 组合高级用法

# 批量停止所有正在运行的容器
docker stop $(docker ps -q)

# 批量删除所有已停止的容器
docker rm $(docker ps -a --filter "status=exited" -q)

# 查看某个特定容器的完整 ID 和名称
docker ps -a --no-trunc --filter "name=my-container" --format "{{.ID}} {{.Names}}"

注意事项
‌默认行为‌：不加任何参数时，docker ps ‌不会‌显示已停止的容器。若发现容器“消失”了，请先尝试 docker ps -a。
‌状态判断‌：STATUS 列不仅显示状态，还显示运行时长。例如 Up 2 hours 表示已运行 2 小时；Exited (0) 5 minutes ago 表示 5 分钟前正常退出（退出码 0）。
‌性能影响‌：在容器数量极大（成千上万）的生产环境中，频繁执行 docker ps -a 可能会稍慢，建议结合 -f 过滤或使用 --format 减少输出数据量以提升性能。
‌与 docker container ls 的关系‌：docker ps 是 docker container ls 的别名，两者功能完全一致。新版 Docker 文档更倾向于使用 docker container ls，但 docker ps 因简短仍被广泛使用。

退出容器

退出 Docker 容器主要有两种方式，具体取决于你希望容器在退出后‌继续运行‌还是‌停止运行‌。

退出但保持容器运行（分离会话）

如果你是通过 docker exec -it <container_id> /bin/bash 进入正在运行的容器内部，想要退出交互界面但‌不终止‌容器进程：

‌操作方法‌：依次按下键盘组合键 ‌Ctrl+P‌，然后立即按下 ‌Ctrl+Q‌。
‌效果‌：你会回到宿主机的终端命令行，而容器在后台继续保持 Up（运行）状态。
‌适用场景‌：临时进入容器调试或查看文件，操作完成后需要容器继续提供服务。

退出并停止容器

如果你希望退出容器的同时‌终止‌容器的运行：

‌操作方法：
- 在容器内的命令行输入 ‌exit‌ 并回车。
- 或者直接按下键盘组合键 ‌Ctrl+D‌。
‌效果：
- 如果是通过 docker exec 进入的辅助进程，退出该 shell 会话通常不会停止容器主进程（除非该 shell 是主进程）。
- 如果是通过 docker run -it 启动的前台容器，执行 exit 或 Ctrl+D 会结束容器的主进程，导致容器状态变为 Exited（已停止）。
‌适用场景‌：调试完成、临时测试任务结束，或者确实需要停止该容器以释放资源。

从外部停止正在运行的容器

如果容器是在后台运行（使用 docker run -d 启动），且你当前不在容器内部，可以使用以下命令从宿主机停止它：

# 停止指定容器
docker stop <容器ID或名称>

# 强制停止（如果正常停止无响应）
docker kill <容器ID或名称>

总结对比

表格

需求	操作方式	容器状态变化	常用场景
‌暂时离开，容器继续跑‌	`Ctrl+P` 然后 `Ctrl+Q`	保持 `Running`	运维检查、临时调试
‌结束任务，停止容器‌	`exit` 或 `Ctrl+D`	变为 `Exited`	测试结束、前台应用退出
‌远程/外部停止‌	`docker stop <ID>`	变为 `Exited`	服务维护、批量管理

‌注意‌：在使用 Ctrl+P + Ctrl+Q 时，请确保按顺序快速敲击，中间不要插入其他按键，否则可能被识别为容器内的普通输入字符。

docker start

docker start 是 Docker 中用于‌启动一个或多个已停止（Exited/Created）的容器‌的命令。

与 docker run 不同，docker start ‌不会‌创建新容器，也不会重新应用启动时的参数（如端口映射、环境变量、卷挂载等），它只是将现有的容器实例从停止状态恢复到运行状态，并保留其之前的所有配置和数据状态。

基本语法

docker start [OPTIONS] CONTAINER [CONTAINER...]

‌CONTAINER‌：可以是一个或多个容器的 ID 或名称。

常用参数

参数	简写	说明
`--attach`	`-a`	‌附加模式‌。启动容器后，将当前终端的标准输入/输出连接到容器的主进程。常用于查看启动日志或交互。
`--interactive`	`-i`	‌交互模式‌。通常与 `-a` 一起使用（`-ai`），允许用户通过 stdin 向容器发送输入。即使容器未以 `-it` 启动，也可尝试附加输入。
`--checkpoint`		从指定的检查点恢复容器（需启用实验性功能）。
`--detach-keys`		覆盖分离容器时的键盘组合键（默认 `Ctrl-p, Ctrl-q`）。

‌注意‌：docker start ‌不支持‌修改容器的运行时配置（如端口、环境变量、内存限制等）。如果需要修改这些配置，必须删除旧容器并使用新的参数重新 docker run。

使用示例

✅ 启动单个已停止的容器

bash# 启动名为 my-nginx 的容器
docker start my-nginx

# 启动指定 ID 的容器
docker start a1b2c3d4e5f6

✅ 批量启动多个容器

bash# 同时启动多个容器
docker start container1 container2 container3

✅ 启动并附加到终端（查看日志/交互）

bash# 启动容器并立即附加到其输出流，便于观察启动过程或日志
docker start -a my-container

# 启动并允许交互输入（适用于需要 stdin 的应用）
docker start -ai my-container

docker start vs docker run vs docker restart

表格

命令	作用对象	是否创建新容器	是否应用新参数	典型场景
`docker run`	镜像	‌是‌	‌是‌	首次部署服务，或需要更改配置时
`docker start`	已停止的容器	否	否	恢复之前停止的服务，保持数据状态
`docker restart`	运行中或已停止的容器	否	否	快速重启服务（相当于 stop + start）

常见问题与注意事项
‌无法修改配置‌：
如果你发现容器启动后行为不符合预期（如端口不对、环境变量缺失），检查是否错误地使用了 docker start。docker start 只能恢复容器‌上次创建时‌的配置。若需修改，请执行：
```
bashdocker rm <container_name>
docker run [新参数...] <image>
```
‌容器启动后立即退出‌：
如果执行 docker start 后容器很快又变为 Exited 状态，通常是因为容器的主进程（PID 1）执行完毕或崩溃。
- 使用 docker logs <container_name> 查看容器内部日志，排查应用错误。
- 确保容器启动命令是长期运行的进程（如 Web 服务器、数据库），而非一次性脚本（除非使用 docker run --rm 运行临时任务）。
‌依赖顺序‌：
如果容器间存在依赖关系（如应用容器依赖数据库容器），请确保先启动被依赖的容器（如 DB），再启动应用容器。docker start 不会自动处理依赖顺序。
‌资源占用‌：
启动容器会重新占用 CPU、内存和网络资源。确保宿主机有足够的资源容纳新启动的容器。
最佳实践

‌自动化运维：在脚本中，可结合
```
docker ps -a --filter "status=exited" -q
```
获取所有已停止容器的 ID，然后批量启动：
```
docker start $(docker ps -a --filter "status=exited" -q)
```
‌健康检查‌：启动关键服务后，建议使用 docker inspect --format='{{.State.Health.Status}}' <container> 或等待几秒后检查端口，确保服务真正就绪。
‌日志监控：对于重要服务，启动后建议立即跟随日志：
```
docker start my-app && docker logs -f my-app
```

docker restart &

docker stop &

docker kill

docker rm

docker rm 是 Docker 中用于‌删除一个或多个容器‌的命令。它主要作用于容器的元数据和文件系统层，但‌不会‌删除容器所使用的镜像、数据卷（Volumes）或网络配置，除非显式指定相关参数。

基本语法

docker rm [OPTIONS] CONTAINER [CONTAINER...]

‌CONTAINER‌：可以是容器的 ID（短 ID 或长 ID）或名称。支持同时删除多个容器，用空格分隔。

常用参数详解

参数	简写	说明
`--force`	`-f`	‌强制删除‌。即使容器正在运行，也会先发送 SIGKILL 信号终止容器进程，然后删除容器。适用于清理僵死或无法停止的容器。
`--volumes`	`-v`	‌删除关联的匿名卷‌。如果容器挂载了匿名卷（即启动时未指定名称的卷），使用此参数会在删除容器时一并删除这些卷。‌注意‌：命名卷（Named Volumes）不会被删除，需手动执行 `docker volume rm`。
`--link`	`-l`	‌删除容器链接‌。仅删除与其他容器的链接关系，而不删除容器本身。常用于清理遗留的网络链接别名。

使用示例

✅ 删除单个已停止的容器

这是最安全的操作方式，要求容器处于 Exited 状态。

# 通过名称删除
docker rm my_container

# 通过 ID 删除
docker rm a1b2c3d4e5f6

✅ 强制删除运行中的容器

如果容器正在运行且无法通过 docker stop 正常停止，可以使用 -f 参数。

docker rm -f my_running_container
# 等价于先执行 docker kill，再执行 docker rm

✅ 删除容器并清理匿名卷

在删除测试容器时，同时清理其产生的临时数据卷，避免磁盘空间浪费。

docker rm -v my_test_container

✅ 批量删除容器

结合 docker ps 命令，可以高效清理大量容器。

‌删除所有已停止的容器‌：

docker rm $(docker ps -aq --filter "status=exited")
# 或者使用更现代的 prune 命令（推荐）
docker container prune -f

‌删除所有容器（包括运行中的）‌：
```
docker rm -f $(docker ps -aq)
```
‌按名称模式批量删除‌：
例如删除所有名称包含 "test" 的容器：
```
docker rm -f $(docker ps -a | grep "test" | awk '{print $1}')
```

docker rm 与相关命令的区别

表格

命令	作用对象	是否删除数据	典型场景
`docker rm`	‌容器‌ (Container)	否（除非加 `-v` 删匿名卷）	清理不再需要的容器实例
`docker rmi`	‌镜像‌ (Image)	否	清理本地镜像文件
`docker volume rm`	‌数据卷‌ (Volume)	‌是‌	清理持久化存储数据
`docker system prune`	‌所有未使用资源‌	是（容器、镜像、网络、构建缓存）	一键清理系统垃圾

常见问题与注意事项
‌无法删除运行中的容器‌：
- ‌错误信息‌：You cannot remove a running container <ID>. Stop the container before attempting removal or use -f
- ‌解决‌：先执行 docker stop <ID> 停止容器，再执行 docker rm <ID>；或者直接执行 docker rm -f <ID>。
‌数据丢失风险‌：
- docker rm 会删除容器的可写层（Writable Layer），其中包含容器运行时产生的所有非挂载数据。
- 如果重要数据存储在容器内部而非挂载卷中，删除前务必使用 docker cp 或 docker commit 备份数据。
- 使用 -v 参数时需谨慎，确认关联的卷确实是临时的匿名卷，以免误删重要数据。
‌权限问题‌：
- 在 Linux 系统中，如果当前用户不在 docker 组内，可能需要使用 sudo docker rm ...。
‌最佳实践‌：
- ‌先停后删‌：在生产环境中，建议先优雅停止容器（docker stop），确认服务已下线后再删除（docker rm），以避免数据损坏或服务中断。
- ‌使用 --rm 标志‌：对于一次性任务（如 CI/CD 中的测试容器），建议在启动时直接使用 docker run --rm ...，这样容器退出后会自动删除，无需手动执行 docker rm。

越来越卷单一职责变成多职责 - 变成 ai 全栈

docker top

docker top 是 Docker 提供的一个用于‌查看指定容器内正在运行的进程‌的命令。它类似于 Linux 系统中的 top 或 ps 命令，但作用范围仅限于目标容器的命名空间（PID Namespace），帮助用户监控容器内部的活动、调试应用或排查问题。

基本语法

docker top [OPTIONS] CONTAINER [ps OPTIONS]

‌CONTAINER‌：必填项，指定要查看的容器名称或 ID。
‌ps OPTIONS‌：可选项，支持传递标准 ps 命令的参数来自定义输出格式（如 -eo pid,comm）。

核心功能与输出

默认情况下，docker top 会显示容器内所有用户态进程的简要信息，通常包含以下列：

‌UID‌：运行进程的用户 ID。
‌PID‌：进程在‌容器命名空间内‌的进程 ID（注意：这不是宿主机的 PID）。
‌PPID‌：父进程 ID。
‌C‌：CPU 使用率。
‌STIME‌：进程启动时间。
‌TTY‌：控制终端。
‌TIME‌：进程累计使用的 CPU 时间。
‌CMD‌：启动进程的命令。

‌示例输出：‌

textUID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                1                   0                   0                   10:10               ?                   00:00:01            nginx: master process nginx
nginx               6                   1                   0                   10:10               ?                   00:00:00            nginx: worker process
nginx               7                   1                   0                   10:10               ?                   00:00:00            nginx: worker process

常用参数与自定义输出

✅ 自定义显示字段

你可以使用 -eo 参数配合 ps 支持的字段格式，只查看关心的信息。

# 仅显示 PID 和命令名
docker top my_container -eo pid,comm

# 显示 PID、父 PID、完整命令参数
docker top my_container -eo pid,ppid,args

# 监控资源占用较高的进程（显示 PID、CPU%、内存%、命令）
docker top my_container -eo pid,pcpu,pmem,comm

✅ 限制显示行数

# 只显示最近创建的 3 个进程
docker top my_container -n 3

关键注意事项
‌容器必须处于运行状态‌
docker top 只能查看正在运行（Running）的容器。如果容器已停止（Exited），命令会报错：

Error response from daemon: Container ... is not running
请先使用 docker ps 确认容器状态。
‌PID 隔离视角‌
输出的 PID 是容器内部的进程 ID，与宿主机上的 PID ‌不同‌。
- 若需查看容器主进程在宿主机上的 PID，可使用：
```
docker inspect --format='{{.State.Pid}}' <container_name>
```
‌权限要求‌
执行该命令通常需要 Docker 守护进程的访问权限。非 root 用户需加入 docker 用户组，否则可能因权限不足报错。
‌与 docker stats 的区别‌
- docker top：关注‌进程列表‌和具体命令，适合排查“哪个进程在跑”、“启动参数是什么”。
- docker stats：关注‌资源聚合指标‌（CPU、内存、网络、IO 的总体使用率），适合监控“容器整体负载有多高”。
典型应用场景

‌调试应用启动失败‌：查看容器内是否有预期进程在运行，或者进程是否异常退出。
‌排查僵尸进程‌：检查容器内是否存在大量状态异常的子进程。
‌安全审计‌：确认容器内是否运行了未经授权的进程或脚本。

‌结合 exec 深入诊断：

docker top

若信息不足，可进入容器内部使用更强大的工具：

# 进入容器查看完整进程树
docker exec -it my_container ps auxf

# 若容器内安装了 htop，可查看交互式资源监控
docker exec -it my_container htop

总结对比

特性	`docker top`	`docker ps`	`linux top`
‌作用对象‌	单个容器内的进程	所有容器的状态	宿主机所有进程
‌主要用途‌	调试容器内部应用	管理容器生命周期	监控系统整体负载
‌PID 视角‌	容器命名空间	无	宿主机命名空间

通过合理使用 docker top，你可以快速透视容器内部的运行状态，是容器运维和开发调试中不可或缺的工具。

docker inspect

docker inspect 是 Docker 中用于‌获取容器或镜像底层详细信息（元数据）‌的核心命令。它以 ‌JSON 格式‌返回对象的完整配置和状态信息，包括网络设置、挂载卷、环境变量、启动命令、日志路径等，是调试容器、排查网络问题以及编写自动化脚本时不可或缺的工具。

基本语法

docker inspect [OPTIONS] NAME | ID [NAME | ID ...]

‌NAME | ID‌：指定要检查的容器或镜像的名称或 ID。支持同时检查多个对象。
‌OPTIONS‌：常用参数包括 -f（格式化输出）、--type（指定对象类型）等。

核心功能与输出结构

默认情况下，docker inspect 会返回一个包含所有详细信息的 JSON 数组。对于容器，主要包含以下关键部分：

‌Id‌：容器的完整 ID。
‌Created‌：创建时间。
‌State‌：运行状态（Running, Paused, Restarting, OOMKilled, Dead, Status, ExitCode 等）。
‌Image‌：所用镜像的 SHA256 ID。
‌Config‌：容器配置，包括环境变量（Env）、启动命令（Cmd）、入口点（Entrypoint exposed Ports 等。
‌HostConfig‌：主机配置，包括端口绑定（PortBindings）、重启策略（RestartPolicy）、资源限制（Memory, CpuShares）等。
‌NetworkSettings‌：网络设置，包括 IP 地址、MAC 地址、网关、端口映射详情等。
‌Mounts‌：挂载信息，包括卷名称、源路径、目标路径、读写权限等。
‌LogPath‌：容器日志文件在宿主机上的绝对路径。

常用实战示例

✅ 查看特定字段（使用 --format / -f）

由于默认输出信息量巨大，通常使用 Go 模板语言提取关键信息。

‌获取容器 IP 地址‌：

docker inspect --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <container_id>

‌获取容器 MAC 地址‌：

docker inspect --format '{{range .NetworkSettings.Networks}}{{.MacAddress}}{{end}}' <container_id>

‌获取容器日志路径‌：

docker inspect --format '{{.LogPath}}' <container_id>

‌查看启动命令（CMD）和入口点（ENTRYPOINT）‌：

# 查看 CMD
docker inspect --format '{{.Config.Cmd}}' <container_id>

# 查看 Entrypoint
docker inspect --format '{{.Config.Entrypoint}}' <container_id>

‌查看容器运行状态‌：

docker inspect --format '{{.State.Status}}' <container_id>

‌查看端口映射详情‌：

docker inspect --format '{{.HostConfig.PortBindings}}' <container_id>

✅ 简单过滤（结合 grep）

如果不熟悉 Go 模板，可以使用 grep 快速查找关键字段（注意：输出较多，建议配合上下文查看）：

# 查找 IP 地址
docker inspect <container_id> | grep IPAddress

# 查找日志路径
docker inspect <container_id> | grep LogPath

✅ 指定对象类型

如果名称可能冲突（例如既有名为 web 的容器又有名为 web 的镜像），可以使用 --type 明确指定：

docker inspect --type=container web
docker inspect --type=image web

高级技巧：结合 jq 解析 JSON

对于复杂的查询，推荐使用 jq 工具处理 JSON 输出，比 Go 模板更灵活易读。

# 安装 jq (Ubuntu/Debian)
sudo apt-get install jq

# 查看容器的完整 Config 配置
docker inspect <container_id> | jq '.[0].Config'

# 查看所有挂载卷的目标路径
docker inspect <container_id> | jq '.[0].Mounts[].Destination'

# 查看环境变量
docker inspect <container_id> | jq '.[0].Config.Env'

注意事项
‌JSON 格式‌：输出始终是 JSON 格式，即使只查一个对象，结果也是一个包含单个元素的数组 [{...}]。在使用 jq 或编程解析时需注意索引（如 .[0]）。
‌敏感信息‌：docker inspect 会显示所有环境变量，包括可能包含密码或密钥的变量。在生产环境中分享输出时需脱敏。
‌性能影响‌：对于大量容器或复杂网络配置，频繁执行 docker inspect 可能会有轻微性能开销，但在常规运维中可忽略。
‌容器必须存在‌：如果指定的容器或镜像不存在，命令会报错。建议先通过 docker ps 或 docker images 确认名称或 ID 正确。

总结对比

需求	推荐命令	说明
‌查看容器简要状态‌	`docker ps`	快速概览，适合日常监控
‌查看容器内部进程‌	`docker top`	类似 Linux `top`，关注进程列表
‌查看容器详细配置‌	`docker inspect`	‌最全面‌，适合调试、脚本自动化、获取 IP/日志路径等底层信息
‌查看镜像构建历史‌	`docker history`	关注镜像层的构建命令，间接推断启动参数来源

通过熟练掌握 docker inspect 及其格式化输出，你可以高效地获取容器的任何底层细节，极大地提升容器化应用的运维和调试效率。

进入容器

docker cp

docker cp 是 Docker 提供的一个实用命令，用于在‌本地主机（宿主机）‌与‌Docker 容器‌之间复制文件或目录。它类似于 Linux 系统中的 cp 命令，但专门针对容器环境进行了优化，无需进入容器内部即可进行文件传输。

以下是关于 docker cp 的详细使用指南：

基本语法

#从容器复制到主机
docker cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH

# 从主机复制到容器
docker cp [OPTIONS] SRC_PATH CONTAINER:DEST_PATH

‌CONTAINER‌: 容器的名称或 ID。
‌SRC_PATH‌: 源文件路径。如果是容器内路径，必须是绝对路径；如果是主机路径，可以是相对或绝对路径。
‌DEST_PATH‌: 目标文件路径。

常用参数选项

参数	作用说明
`-a`, `--archive`	‌归档模式‌。保留源文件的权限、所有者、时间戳等属性（类似 `cp -a`）。
`-L`, `--follow-link`	跟随符号链接。如果源路径是符号链接，则复制链接指向的实际文件/目录。默认情况下只复制链接本身。
`-p`	保留源文件的时间戳。
`-r`, `-R`, `--recursive`	‌递归复制‌。当源路径是目录时，必须使用此参数以复制整个目录及其内容。

使用示例

场景一：从容器复制文件/目录到主机

‌复制单个文件：‌
将容器 my_container 中的 /app/config.json 复制到当前主机的当前目录下。

docker cp my_container:/app/config.json ./config.json

‌复制整个目录：‌
将容器 my_container 中的 /var/log/app_logs 目录递归复制到主机的 /tmp/backup 目录。

docker cp -r my_container:/var/log/app_logs /tmp/backup

场景二：从主机复制文件/目录到容器

‌复制单个文件：‌
将主机当前的 index.html 文件复制到容器 my_container 的 /usr/share/nginx/html/ 目录下。

docker cp index.html my_container:/usr/share/nginx/html/

‌复制整个目录：‌
将主机本地的 ./data 目录递归复制到容器 my_container 的 /opt/data 路径下。

docker cp -r ./data my_container:/opt/data

关键注意事项
‌容器状态‌：
docker cp 既可以在容器‌运行中执行‌，也可以在容器‌停止状态下执行‌。只要容器存在（未被删除），即可进行文件拷贝。
‌路径处理规则‌：
- ‌容器内路径‌：始终建议使用‌绝对路径‌（以 / 开头）。
- ‌主机路径‌：可以是相对路径或绝对路径。
- ‌末尾斜杠 / 的影响：
  - 如果目标路径以 / 结尾（例如 my_container:/tmp/），Docker 会将源文件放入该目录下，保持原名。
  - 如果目标路径不以 / 结尾且是一个已存在的目录，行为可能因 Docker 版本略有差异，建议明确指定文件名或使用尾部斜杠以确保意图清晰。
  - 如果目标路径不存在，Docker 通常会尝试创建该路径（如果是文件，则创建文件；如果是目录结构，可能需确保父目录存在）。
‌权限问题‌：
- 复制到容器内时，需确保容器内的目标路径具有‌写入权限‌。如果目标目录属于 root 用户且权限受限，普通用户运行的进程可能无法写入，此时可能需要以 root 身份进入容器调整权限，或在 docker run 时指定用户。
- 复制到主机时，需确保当前主机用户对目标目录有写入权限。
‌性能与大文件‌：
- docker cp 适用于中小文件的临时传输。
- 对于‌大文件‌或‌频繁的数据交换‌，建议使用 ‌Docker Volumes（卷）‌ 或 ‌Bind Mounts（绑定挂载）‌。这种方式不仅性能更好，而且能实现数据持久化，避免容器删除后数据丢失。
‌常见报错 No such container:path‌：
- 检查容器名称或 ID 是否正确（使用 docker ps -a 查看）。
- 检查容器内的源路径是否存在且拼写正确（可使用 docker exec -it <容器名> ls <路径> 验证）。
- 确保路径格式正确，容器路径前必须有容器名/ID 和冒号（如 container:/path）。
与 COPY 指令的区别

‌docker cp‌：用于‌运行时‌或‌停止状态‌的容器与主机之间的即时文件传输，常用于调试、日志提取或临时配置更新。
‌COPY (在 Dockerfile 中)‌：用于在‌构建镜像‌时将文件从主机复制到镜像层中。这是构建不可变基础设施的标准方式，不应依赖 docker cp 来修改生产环境容器的核心应用代码。

熟练掌握 docker cp 能极大提升日常开发和运维效率，特别是在排查问题和快速部署配置文件时非常有用。

导入和导出

总结常用命令

04-docker 镜像

01- docker 镜像的分层概念

02- docker commit

docker commit 是 Docker 提供的一个核心命令，用于将‌容器的当前状态‌保存为一个新的‌镜像‌。它相当于给正在运行或已停止的容器拍一张“快照”，并将这张快照打包成可分发、可复用的镜像文件。

虽然 Dockerfile 是构建镜像的标准推荐方式（具备可重复性和版本控制），但 docker commit 在调试、快速原型开发和紧急故障保留等场景中具有独特的即时性优势。

基本语法

docker commit [OPTIONS] CONTAINER [REPOSITORY[:TAG]]

‌CONTAINER‌: 源容器的名称或 ID。
‌REPOSITORY[:TAG]‌: 新镜像的名称和标签（例如 my_app:v1）。如果不指定标签，默认为 latest。

常用参数选项

参数	全称	作用说明
`-a`	`--author`	指定镜像的作者信息，格式如 `"Name <email>"`。有助于团队协作时追溯来源。
`-m`	`--message`	添加提交说明（类似 Git commit message），记录本次变更的目的或内容。
`-p`	`--pause`	‌默认启用‌。在提交过程中暂停容器，以确保文件系统状态的一致性。可通过 `-p=false` 关闭。
`-c`	`--change`	应用 Dockerfile 指令来修改新镜像的配置。例如：`-c 'ENV MODE=prod'` 或 `-c 'CMD ["python", "app.py"]'`。

使用示例

场景一：基础提交

将名为 temp_container 的容器保存为名为 my_nginx 的镜像，标签为 v1。

docker commit temp_container my_nginx:v1

场景二：带元数据和配置修改的高级提交

将容器 dev_app 保存为镜像，指定作者、添加说明，并修改启动命令和环境变量。

docker commit \
  -a "DevOps Team <dev@example.com>" \
  -m "Installed debug tools and updated config" \
  -c 'ENV APP_ENV=development' \
  -c 'CMD ["python", "debug_server.py"]' \
  dev_app \
  my_app:debug-v2

核心原理与注意事项

只保存“可写层”变更

Docker 容器由底层的只读镜像层和顶层的可写容器层组成。docker commit ‌仅捕获容器可写层中的文件差异‌（如新安装的文件、修改的配置）。

‌重要限制‌：它‌不会‌保存挂载卷（Volume）或绑定挂载（Bind Mount）中的数据。例如，如果你通过 -v /host/data:/container/data 挂载了数据，这些数据的变更不会包含在 commit 生成的镜像中。这是为了保持镜像的无状态性和可移植 a性。

适用场景

‌快速调试与实验‌：在交互式容器中解决复杂的依赖冲突或配置问题后，快速保存成果，避免重新编写 Dockerfile 并等待漫长构建。
‌故障现场保留‌当生产容器出现异常时，立即 commit 保存当前状态，供后续离线分析。
‌定制基础镜像‌：基于官方镜像安装通用工具（如 vim, curl, git）后 commit，作为团队内部的基础开发镜像。

潜在风险与最佳实践

‌镜像体积膨胀‌：如果在容器内进行了大量临时操作（如下载包、编译代码未清理），commit 会将所有中间文件打包进镜像，导致体积巨大。
- 建议: 提交前在容器内执行清理命令（如 apt clean, rm -rf /tmp/*）。
‌缺乏可审计性‌：Commit 生成的镜像是一个“黑盒”，无法像 Dockerfile 那样清晰看到构建步骤。
- 建议: 仅用于临时或开发环境。‌生产环境严禁直接使用 commit 镜像上线‌，应将验证成功的操作步骤转化为 Dockerfile 进行标准化构建。
‌敏感信息泄露：如果容器内包含硬编码的密码或密钥，commit 会将它们永久写入镜像层，即使后续删除文件，历史层中仍可能找回。
- 建议: 提交前务必检查并清除敏感数据，或使用 --change 覆盖相关环境变量。

与 Dockerfile 的对比

特性	docker commit	Dockerfile
‌构建方式‌	命令式（基于运行时状态）	声明式（基于脚本指令）
‌可重复性‌	低（依赖手动操作，易出错）	高（自动化构建，结果一致）
‌版本控制‌	困难（难以追踪具体变更细节）	容易（配合 Git 管理脚本）
‌构建速度‌	快（无需重新执行所有步骤）	慢（需从头或缓存构建）
‌推荐场景‌	调试、临时快照、紧急备份	生产环境、CI/CD 流水线

总结来说，docker commit 是一个强大的辅助工具，适合“先探索后固化”的工作流。但在正式交付时，应始终回归到 Dockerfile 以确保基础设施即代码（IaC）的最佳实践。

05-本地镜像发布到阿里云

从阿里云仓库下载上传的镜像

06-docker 私有仓库

将本地镜像推送到私有仓库

07-docker 容器数据卷

01-容器数据卷是什么

02-容器卷和主机互联互通

03-容器卷 ro 和 rw 读写规则

04-容器卷之间的继承

08-docker常用软件安装

01-tomcat 安装

Tomcat 是 Apache 软件基金会开发的开源 Java Web 应用服务器‌，核心定位是轻量级的 Servlet/JSP 容器，专门用于运行和管理 Java 编写的动态网站与后端服务。它相当于 Java Web 应用的“运行载体”，让你写的 Java 代码能对外提供可访问的 HTTP 服务。

核心用途

‌运行 Java 动态程序‌：负责加载、管理 Servlet 和 JSP 组件，处理用户浏览器发来的动态请求，执行 Java 业务逻辑并返回结果。
‌提供标准 Web 服务‌：默认监听 8080 端口，作为 HTTP 服务器接收客户端请求，完成协议解析和响应返回，支持 HTTP/1.1、HTTP/2 等协议。
‌自动化部署应用‌：支持将打包好的 WAR 文件放入 webapps 目录自动解压部署，同时支持配置多个虚拟主机，在单台服务器上托管多个独立 Web 应用。
‌全场景开发支撑‌：是 Java 开发者调试 JSP、Servlet 程序的标准环境，Spring Boot 等主流框架也默认将其作为内嵌服务器，大幅降低微服务部署门槛。

核心特点

‌轻量高效‌：相比 WebLogic 等重型企业级服务器，安装包仅几十MB，启动速度快、资源占用极低，在低配服务器或嵌入式设备中也能流畅运行。
‌开源免费‌：基于 Apache 2.0 许可证完全开源，无商业授权成本，全球活跃社区持续维护，漏洞修复和版本迭代及时。
‌跨平台兼容‌：完美支持 Windows、Linux、macOS 等几乎所有主流操作系统，一次编译打包即可在任意平台部署运行。
‌高可扩展性‌：通过 server.xml 等配置文件可灵活调整线程池、SSL 证书、会话持久化等参数，还支持自定义扩展组件满足个性化需求。

典型使用场景

‌开发调试环境‌：本地 IDE（IDEA/Eclipse）集成 Tomcat，实现代码热部署，实时预览和调试 Java Web 项目。
‌中小规模生产部署‌：独立部署中小型 Java Web 站点、RESTful API 服务，支撑日常业务流量。
‌生产集群架构‌：与 Nginx 配合使用，Nginx 负责处理静态资源、负载均衡和 SSL 加密，Tomcat 专注处理 Java 动态请求，是互联网行业最经典的组合架构。
‌边缘/嵌入式场景‌：凭借极小的资源占用，在资源受限的物联网设备中提供 Web 管理界面服务。

关键注意点

Tomcat 不是完整的全栈 Java EE 服务器，它仅实现了 Servlet、JSP、WebSocket 等核心规范，不支持 EJB、JMS 等重型企业级特性，这也是它保持轻量和高性能的核心原因。

02-mysql 安装

‌MySQL 是 Oracle 旗下全球最流行的开源关系型数据库管理系统（RDBMS）‌，核心作用是安全、高效地存储、管理和查询各类结构化数据，是网站、App 和企业系统的核心“数据管家”。它凭借轻量、免费、易上手的特性，成为 Web 开发领域的事实标准数据库，也是 LNMP/LAMP 技术栈的核心组件之一。

📊 核心功能与用途

‌结构化数据存储‌：将用户信息、订单记录、商品资料等数据按行和列存入不同数据表，通过表间关联实现复杂数据管理，比直接存文件更安全、更易检索。
‌标准 SQL 操作‌：支持使用通用的 SQL 语言完成数据的增删改查，开发者可以快速上手编写查询逻辑，实现业务数据的读写操作。
‌高并发事务处理‌：默认的 InnoDB 存储引擎完全支持 ACID 事务特性，确保电商支付、订单提交等关键操作的数据一致性，避免出现数据冲突或丢失。
‌多场景数据支撑‌：广泛应用于电商平台、博客论坛、企业 CRM/OA 系统、移动 App 后端，甚至能支撑千万级记录的大规模数据存储。

✨ 核心优势特点

‌开源免费‌：社区版完全开源免费，大幅降低中小企业和个人开发者的使用成本，同时支持商业版获取官方技术支持。
‌跨平台兼容‌：完美支持 Windows、Linux、macOS 等几乎所有主流操作系统，可在任意服务器环境中稳定部署。
‌高性能低资源‌：多线程架构充分利用 CPU 资源，优化的 SQL 查询算法能高效处理大量并发访问，体积小、启动快，资源占用远低于 Oracle、DB2 等重型数据库。
‌灵活可扩展‌：支持主从复制、读写分离、集群部署等方案，可通过分库分表轻松支撑 TB 级别的数据规模，满足业务增长需求。
‌丰富存储引擎‌：提供 InnoDB（事务优先）、MyISAM（读速优先）、Memory（内存级高速）等多种存储引擎，可根据业务场景灵活选择。

🔧 典型使用场景

‌Web 应用后端‌：几乎所有主流内容管理系统（WordPress、Discuz!）都默认使用 MySQL 存储文章、用户、评论数据，是网站开发的标配数据库。
‌中小微业务系统‌：企业内部的 OA 办公、客户管理、财务记录等系统，用 MySQL 即可完全满足数据存储需求，无需高额的商业数据库授权成本。
‌互联网高并发场景‌：电商大促、社交平台等流量高峰场景，通过主从复制和读写分离架构，可轻松支撑每秒上万次的数据库请求。
‌数据分析支撑‌：配合 Python、Java 等编程语言，存储和管理结构化业务数据，为数据统计、报表分析提供可靠的数据源支撑。

⚠️ 关键注意点

MySQL 采用社区版+商业版的双授权模式，普通开发和非核心业务使用社区版即可满足需求；如果用于核心生产环境，建议开启定期自动备份，同时配置主从复制避免单点故障导致数据丢失。