https://x.com/i/grok/share/a8bf720367dd444fa62947b5d6eb11e3linux提供给docker什么底层机制使docker可以虚拟化制作镜像启动容器Linux 为 Docker 提供的底层核心机制主要包括以下三大关键技术这也是容器技术的基石1. Namespaces命名空间 —— 实现资源隔离让容器“看不见”外界Namespaces 是 Linux 内核提供的一种隔离机制它让一个进程组看到的世界与宿主机或其他容器完全不同。Docker 主要使用以下几种 NamespaceNamespace 类型隔离的内容Docker 中的作用PID进程 ID容器内只能看到自己的进程PID 1 是容器主进程看不到宿主机其他进程Mount文件系统挂载点容器有独立的根文件系统rootfs看不到宿主机其他目录Network网络栈网卡、IP、端口等容器有自己的网络接口、IP 地址、路由表UTS主机名和域名容器有独立的主机名IPC进程间通信信号量、消息队列容器内进程通信隔离User用户和用户组容器内 root 不等于宿主机 root提升安全性Cgroupcgroup 视图较新内核隔离 cgroup 层次原理总结Namespaces 修改了进程的视图view让进程“以为”自己独占整个系统但实际上只是内核做了映射和隔离。2. CgroupsControl Groups控制组 —— 实现资源限制与计量Namespaces 解决了“隔离”但没有解决“资源抢占”问题。多个容器运行在同一台机器上如果其中一个疯狂占用 CPU 或内存会影响其他容器。Cgroups 的作用就是限制限制容器能使用的 CPU、内存、磁盘 I/O、网络带宽等资源。计量统计容器实际使用了多少资源。优先级控制可以给不同容器设置不同的资源权重。冻结/恢复可以暂停整个容器中的所有进程。常见子系统subsystem包括cpu、memory、blkio、devices、freezer 等。3. Union Filesystem联合文件系统 / OverlayFS —— 实现镜像分层与高效存储这是 Docker 制作镜像和启动容器时非常重要的机制。Docker 镜像是分层存储的每一层对应 Dockerfile 中的一条指令如 RUN、COPY。使用 OverlayFS或 AUFS、btrfs 等将多层只读镜像层 最上面一层可写容器层 联合挂载union mount 成一个统一的目录。写时复制Copy-on-Write修改文件时不会破坏底层镜像层而是在最上层复制一份再修改极大节省空间和加快启动速度。这也是为什么多个容器使用同一个镜像时镜像层是共享的只占用一份磁盘空间。容器启动非常快不需要复制整个文件系统。其他辅助内核机制Capabilities细粒度权限控制容器默认只拥有部分 Linux 能力而不是完整 root。Seccomp系统调用过滤限制容器能执行哪些内核系统调用。AppArmor / SELinux进一步加强安全策略。chroot / pivot_root切换根文件系统。整体工作流程简化版当你执行 docker run 时Docker实际是 containerd runc会请求 Linux 内核创建各种 Namespaces隔离视图。配置 Cgroups设置资源限制。使用 OverlayFS 挂载镜像层 可写层构造 rootfs。在这个隔离环境中以 PID 1 启动容器内的进程例如 java -jar app.jar 或 tomcat。一句话总结Docker 并没有真正的“虚拟化”一个完整的操作系统它只是巧妙利用 Linux 内核提供的 Namespaces隔离、Cgroups资源控制和 UnionFS分层文件系统把一个普通进程包装成“看起来像独立系统”的轻量级容器。这就是容器比传统虚拟机轻量、启动快、资源利用率高的根本原因。容器和联合文件系统是linux提供的两个独立的功能吗这是一个非常深刻的问题答案是是的它们是完全独立的。不仅如此如果要从 Linux 内核的底层视角来看Linux 内核里其实根本不存在“容器”Container这个单一的功能模块或代码。我们平时所说的“容器”比如 Docker、Podman实际上是上层的软件工具把 Linux 提供的几个完全独立的底层内核特性巧妙地“拼装”在一起从而为用户制造出的一种“隔离环境”的错觉。要理解它们的关系我们需要拆解一下构成“容器”的三大独立支柱1. 制造隔离的魔法Namespaces命名空间这是 Linux 内核提供的一个独立功能。它的作用是隔离系统资源。 比如你让一个进程运行在一个独立的 PID Namespace 里这个进程就会以为自己是系统里的 1 号进程就像刚开机一样它看不到外面其他程序的进程。同理还有网络Network、挂载点Mount、用户User等多种命名空间。它的角色负责给程序建一间“密室”让程序觉得这台电脑上只有它自己。2. 限制资源的枷锁Cgroups控制组这也是 Linux 内核的一个独立功能。它的作用是限制和监控资源使用。 虽然 Namespaces 让程序以为自己拥有整个世界但 Cgroups 会在暗中限制它你最多只能用 20% 的 CPU最多只能用 512MB 的内存。它的角色负责控制这间“密室”里能消耗多少水电煤。3. 高效分发的基础UnionFS联合文件系统这就是你在上一个问题中了解到的功能如 OverlayFS。它负责把多个目录层叠在一起提供写时复制CoW的能力。它的角色负责给这间“密室”极其高效地提供“家具和装修”也就是操作系统文件和依赖库。它们是如何协作的以 Docker 为例早期的容器技术比如 LXC其实只用了 Namespaces 和 Cgroups并没有强制使用联合文件系统。那时的容器更像是一个轻量级的虚拟机你要给它准备文件就得老老实实拷贝一整套 Linux 文件系统进去。Docker 的伟大创新就在于它把“联合文件系统”引入了容器的世界Docker 利用UnionFS把软件运行所需的操作系统环境、依赖库打包成一层层的“镜像”只读层。当你启动容器时Docker 会请求 Linux 内核利用Namespaces和Cgroups创建一个隔离的运行环境。然后Docker 再利用UnionFS把那些只读的镜像层挂载到这个隔离环境里并在最上面加一个薄薄的读写层。总结来说Namespaces 和 Cgroups 组成了容器的“躯壳”运行时的隔离而 UnionFS 赋予了容器灵魂轻量级、可复用的镜像分发机制。证明它们独立的例子为了证明它们可以脱离彼此独立存在我们可以看看它们各自单飞的场景没有容器的 UnionFS比如前面提到的 Live U 盘系统或者很多路由器如 OpenWrt它们的底层固件是只读的用户修改的配置通过 OverlayFS 写在上层恢复出厂设置就是直接把上层清空。这里完全没有容器的身影。没有 UnionFS 的容器你完全可以通过chroot命令配合 Linux 的 Namespaces 工具如unshare命令自己手动创建一个没有任何镜像分层概念的隔离环境。这就是最原始的“容器”它直接使用传统的 ext4 等文件系统。联合文件系统和平时用的文件系统什么区别平时用的传统文件系统如 Windows 的 NTFS、macOS 的 APFS 或 Linux 的 Ext4与联合文件系统Union File System如 OverlayFS、AUFS在设计理念和工作机制上有本质的区别。最核心的差异可以用一句话概括传统文件系统是一块单层的画布而联合文件系统是一摞透明的幻灯片。为了更清晰地理解我们可以从以下几个关键维度进行对比1. 结构与视图传统文件系统采用扁平化的视角。一个挂载点直接对应一个物理分区或逻辑卷。你看到的文件和目录就是磁盘上实实在在存储的数据。联合文件系统采用分层叠加的架构。它本身通常不直接管理底层硬件而是将分布在不同物理位置的多个目录称为“分支”或“层”“联合”挂载到同一个虚拟目录下。就像把多张透明的幻灯片叠在一起上层的图案会遮挡下层相同位置的图案但你最终看到的是所有幻灯片叠加后的一张完整图像。2. 修改与写入机制传统文件系统就地覆写当你打开并修改一个文件并点击保存时文件系统会直接在底层磁盘上覆写Overwrite旧的数据。联合文件系统写时复制联合文件系统通常由多个“只读层”和一个最顶端的“读写层”组成。当你尝试修改一个位于只读层的文件时系统不会直接修改它而是触发**写时复制Copy-on-Write, CoW**机制系统将该文件从下方的只读层复制到最顶端的可写层。你的所有修改都在这个新复制出的文件上进行。下层的原始文件保持不变但在虚拟视图中被上层的新文件“遮蔽”了。3. 删除机制传统文件系统删除指令会直接将文件从磁盘索引中移除并释放相关数据块。联合文件系统如果你想删除一个位于底层只读层的文件系统无法真正删掉它。相反它会在顶层的读写层创建一个特殊的**“标记文件”Whiteout**。这个标记文件的作用是告诉系统“在展示最终视图时请隐藏这个文件。”核心区别对比特性传统文件系统 (如 Ext4, NTFS)联合文件系统 (如 OverlayFS)架构设计单层直接管理磁盘块多层叠加建立在其他文件系统之上修改机制就地覆盖 (Overwrite)写时复制 (Copy-on-Write)底层状态随时会被修改底层通常是完全只读、不可变的空间利用修改文件不增加额外副本空间修改底层文件需先复制到顶层占用新空间挂载方式一个挂载点对应一个存储设备多个目录联合挂载到一个虚拟视图联合文件系统用来做什么因为这种独特的“分层”和“写时复制”特性联合文件系统在日常电脑操作中很少作为主文件系统但它在特定领域是不可或缺的底层技术Docker 与容器技术这是目前最广泛的应用。一个完整的 Linux 操作系统镜像可能有几百兆但如果你要运行 10 个相同的容器不需要复制 10 份完整的系统。所有容器共享底层相同的只读镜像层每个容器只拥有一个极小且独立的读写层来存储自己运行产生的临时数据。这极大地节省了硬盘空间并加快了启动速度。Live CD / Live USB当你用 U 盘体验一个无需安装的 Linux 系统时U 盘上的系统镜像是只读的防止被破坏。你在体验过程中创建的文件、修改的设置实际上被联合文件系统写入到了电脑内存RAM中的一个临时可写层里。重启后内存断电清空系统又恢复到最初的状态。docker每个阶段都有一个镜像但只保留最后一个阶段的镜像多阶段构建Multi-stage build的工作机制在一个 Dockerfile 中每出现一个 FROM 指令就代表开启一个新的构建阶段stage。每个阶段都会在构建过程中生成一个中间镜像intermediate image。但最终只有最后一个阶段的镜像会被保留并打上你指定的 tag比如 docker build -t myapp:latest . 时打的标签。前面的所有中间阶段builder 阶段等构建完成后默认不会被保留为独立的具名镜像它们的内容除了通过 COPY --from... 复制出来的文件会被丢弃。实际例子说明以我们之前用的 Java Dockerfile 为例FROM eclipse-temurin:21-jdk AS builder # ← 阶段1builder WORKDIR /app COPY . . RUN ./mvnw clean package -DskipTests FROM eclipse-temurin:21-jre-alpine # ← 阶段2最终阶段没有 AS 名字 WORKDIR /app COPY --frombuilder /app/target/*.jar app.jar ENTRYPOINT [java, -jar, app.jar]构建过程实际发生了什么Docker 先构建 阶段1builder → 生成一个很大的中间镜像包含完整 JDK、Maven、源码、编译后的 target 目录等。然后构建 阶段2 → 从阶段1 中只复制 app.jar 过来生成最终的小镜像只包含 JRE app.jar。构建结束时你用 docker images 看到的只有 一个镜像myapp:latest基于最后一个 FROM。阶段1 的中间镜像不会显示为具名镜像通常显示为 none:nonedangling image或者直接被 Docker 的构建缓存管理。重要补充中间镜像不会完全消失它们会被存放在 构建缓存build cache 中下次构建相同内容时可以复用加快构建速度。如果你执行 docker image prune 或 docker builder prune这些 dangling 的中间镜像可能会被清理掉。你可以手动指定构建某个中间阶段用于调试docker build --target builder -t myapp-builder .这样就会把 builder 阶段打上标签并保留下来。总结回答你的问题每个阶段都会生成一个镜像 → 对的构建过程中。只保留最后一个阶段的镜像 → 完全正确这就是多阶段构建最大的价值之一让你用“大而全”的环境去构建最终只产出一个“小而干净”的运行时镜像。这样既保证了构建的完整性又极大减小了最终推送到仓库和部署的镜像体积。如果你想验证一下可以试试下面命令docker build -t my-java-app . docker images | grep my-java-app # 应该只看到一个 docker images -f danglingtrue # 可以看到一些 none 的中间镜像每个容器启动时都自带镜像的目录每个容器启动时都自带镜像的目录是的每个容器启动时都会“自带”镜像中的所有目录和文件但这并不是真正复制一份完整的文件到容器里而是通过一种巧妙的分层机制实现的。下面我用简单易懂的方式给你讲解原理1. Docker 镜像和容器的文件系统原理镜像Image是只读的镜像由多层layers组成每一层对应 Dockerfile 中的一条指令FROM、RUN、COPY 等。这些层都是只读的不能修改。容器启动时Docker 会把镜像的所有层叠加在一起使用 Union File System如 overlay2。在最上面再加一层可写层Container Layer / writable layer专门给这个容器使用。容器看到的文件系统 镜像所有层只读 最上面的可写层呈现为一个统一的目录视图。关键点容器启动时不会把镜像里的文件完整复制一份到容器这样会非常浪费空间和时间。而是通过**联合挂载Union Mount**的方式让容器“看到”镜像里的目录和文件就好像这些文件本来就存在于容器中一样。你在容器里用 ls /app、ls /usr/local/tomcat 等命令看到的目录都是来自镜像的。2. 实际表现每个容器启动时都会拥有镜像中定义的所有目录结构/app、/usr、/opt/jre、GeoServer 的 webapps 目录等。修改文件时如果你在容器内修改、删除或新增文件这些操作只会发生在最上面的可写层不会影响镜像本身。多个容器使用同一个镜像它们共享下面的只读镜像层只各自拥有自己的可写层。这样非常节省磁盘空间。3. 与你之前场景的关联GeoServer 镜像不管你是用官方镜像还是自定义镜像容器启动后镜像里打包好的 /usr/local/tomcat/webapps/geoserver/ 目录、插件目录如果构建时 COPY 进去了等都会自动出现在容器中。自定义 JRE Java 应用你用 COPY --frombuilder ... app.jar 打包进去的 app.jar以及自定义 JRE 的 /opt/jre 目录每次启动容器时都会自带。用 -v 挂载的情况如果你挂载了宿主机目录例如 -v $(pwd)/data:/app/data则挂载点会覆盖镜像中原有的对应目录内容。4. 验证方法你可以在容器中执行以下命令查看# 进入容器 docker exec -it 容器名或ID bash # 查看当前目录结构 ls -l / # 查看特定目录比如 GeoServer 或你的 app ls -l /app ls -l /usr/local/tomcat/webapps/geoserver这些目录内容都来自你构建的镜像层。总结一句话回答你是的每个容器启动时都会自带镜像中所有的目录和文件。这是通过 UnionFS联合文件系统 镜像只读层 容器可写层 的机制实现的镜像层是共享的不会每次都复制效率很高。如果你想更深入了解镜像分层具体是怎么存储的可写层和镜像层的区别在实际使用中有什么影响还是针对 GeoServer 自定义镜像的目录结构有疑问告诉我具体想了解哪部分我可以继续详细解释。这是项目结构这个Dockerfile在什么时候执行这个 Dockerfile 只在执行 docker build 命令时被读取和执行不会在 docker run 时执行。具体执行时机结合你的项目结构你的项目是标准的 Maven Spring Boot 项目结构如下从图片中看到项目根目录下有pom.xmlDockerfiledocker-entrypoint.shsrc/main/java/...源码target/Maven 打包后生成的目录里面通常有 xxx.jar.gitignore 等Dockerfile 执行的完整流程是这样的1.你先在项目根目录执行 Maven 打包这一步很重要mvn clean package这会在 target/ 目录下生成你的 Spring Boot 可执行 JAR 文件例如 pipe-health-archives-1.0.0.jar 或类似名称。你的 Dockerfile 第一阶段的 ARG JAR_FILEtarget/*.jar 和 COPY ${JAR_FILE} application.jar 正是依赖这个 JAR 文件。2.然后执行 docker build 命令此时 Dockerfile 才真正开始工作docker build -t pipe-health-archives .Docker 会读取项目根目录下的 Dockerfile。把当前目录项目根目录作为 build context构建上下文把需要的文件发送给 Docker daemon。然后逐行从上到下执行 Dockerfile 中的每一条指令第一阶段builder复制 target/*.jar → 解压成 layered JAR。第二阶段复制分层文件 docker-entrypoint.sh → 设置 ENTRYPOINT。只有在这个 docker build 过程中Dockerfile 的所有指令FROM、COPY、RUN、ENTRYPOINT 等才会被真正执行。3.构建完成后得到一个 Docker 镜像image。Dockerfile 的使命就完成了它不会再被执行。4.之后执行 docker rundocker run -p 8080:8080 pipe-health-archives这时 Dockerfile 完全不参与。Docker 只根据构建好的镜像启动容器执行镜像中设置的 ENTRYPOINT [./docker-entrypoint.sh]。重要提醒针对你的项目结构target/ 目录Dockerfile 依赖 target/*.jar所以必须先运行 mvn clean package否则 COPY 会失败找不到 JAR。推荐加上 .dockerignore 文件强烈建议 在项目根目录创建 .dockerignore内容至少包含target/* .git .idea logs *.log .mvn mvnw mvnw.cmd这样可以避免把不必要的文件尤其是 target 中旧文件、.idea 配置等发送到构建上下文提高构建速度和安全性。如果你想让 docker build 自动帮你打包 JAR可以修改 Dockerfile 在 builder 阶段加入 Maven 构建但当前你的写法是“先本地 mvn package再 docker build” 的常见方式。一句话总结Dockerfile 只在 docker build 命令构建镜像的时候被执行。你的操作顺序应该是mvn clean package → docker build -t xxx . → docker run ...如果你现在执行 docker build 时遇到找不到 JAR、权限问题或者想让我帮你优化这个 Dockerfile例如让它自动执行 Maven 打包可以把报错信息或你的构建命令贴出来我继续帮你分析