Docker 核心与镜像构建

• 层缓存命中的机制（指令哈希）
• 缓存失效的触发（指令变化、上下文变化）
• 构建缓存优化

Docker 构建时按 Dockerfile 的每条指令生成一层，构建缓存以层为单位：若某条指令的操作（RUN 命令、COPY 的源、基础镜像等）与缓存匹配，则复用该层，不重新执行。命中条件：指令内容、基础镜像、上下文相关文件（COPY 的源文件内容）未变。失效：一旦某条指令不匹配（如 COPY 的文件内容变了、RUN 命令变了），其后所有层缓存全部失效需重建。优化：把不常变的指令放前面（先 COPY 依赖清单再 RUN 安装，利用缓存），把频繁变化的文件放最后 COPY，避免缓存大面积失效。BuildKit 用更细粒度的缓存与 remote cache 提升命中。

层缓存命中以"指令+上下文内容"为键，一旦中间失效则后续全失效，调整指令顺序是优化缓存的关键。

• 镜像分层的只读性与 COW
• 修改文件新增层而非修改原层
• 构建缓存基于层复用与失效

Docker 镜像由多个只读层叠加，底层是基础镜像，每层只记录相对上一层的变更。容器运行时在只读层之上加可写层，采用写时复制（COW）：修改文件时不在原层改动，而是把要改的文件复制到可写层再修改（或新增指针），因此原层保持不可变。这保证镜像可共享、可复用、可安全叠层。构建缓存基于层复用：Dockerfile 的每条指令生成一层，若某指令的输入（指令+上下文）与已有层相同，则复用该层（命中缓存），否则该层失效并重建，其后层全部失效。因此层复用取决于指令与上下文是否变化，优化指令顺序可提升缓存命中。

层不可变 + COW 是分层存储的基础，构建缓存按层复用，输入变化即失效，理解层语义是镜像优化关键。

• seccomp、AppArmor、SELinux 配置
• no-new-privileges 等
• 安全选项的适用

docker run --security-opt 配置容器安全选项，常用：1) seccomp=profile.json：指定 seccomp 配置文件限制系统调用（默认使用 Docker 默认 seccomp profile）；2) apparmor=PROFILE：指定 AppArmor profile；3) label=type:...：配置 SELinux label；4) no-new-privileges：禁止容器进程提升权限（防止 setuid 提权），是重要的安全加固；5) seccomp=unconfined：关闭 seccomp（不推荐）。这些选项从不同层面限制容器能力（系统调用、进程权限、MAC），降低容器逃逸与提权风险，是容器安全加固的关键。

--security-opt 控制 seccomp/AppArmor/SELinux/no-new-privileges 等安全机制，是容器纵深安全之一。

• Linux capabilities 概念
• --cap-drop 最小权限
• --cap-add 按需添加

Linux capabilities 把 root 的超级权限拆分为细粒度权限（如 CAP_NET_ADMIN、CAP_SYS_ADMIN）。Docker 容器默认拥有一组白名单能力（非全部 root 权限），--cap-drop 可移除不需要的能力（如 --cap-drop ALL 后按需 --cap-add 添加），实现最小权限；--cap-add 添加特定能力（如 --cap-add NET_ADMIN 允许容器管理网络）。安全最佳实践：drop 全部能力只保留必需，避免容器拥有危险能力（如 CAP_SYS_ADMIN 可导致容器逃逸）。相比 --privileged（放开全部），cap 控制更精细安全。

caps 把 root 权限细粒度化，--cap-drop 最小权限、--cap-add 按需，是比 --privileged 更安全的控制方式。

• --memory 限制内存（含 swap）
• --cpus 限制 CPU 配额
• 资源限制与 OOM

docker run --memory 512m 限制容器内存上限，超过可能触发 OOM kill；--memory-swap 设置"内存+swap"的总和上限（不设置时默认为内存限制的两倍，即最多允许与内存等量的 swap）。--cpus 2 限制容器可用的 CPU 配额（对应 cgroup cpu cfs 配额，2 表示最多 2 个核的算力），--cpuset-cpus 可绑定到指定 CPU 核。资源限制通过 cgroup 实现，保证容器不抢占宿主机资源、多容器隔离。注意：--memory 是硬上限，超限 OOM；--cpus 是配额非硬绑定，需结合业务实际设置。K8s 用 requests/limits 对应类似语义。

--memory 与 --cpus 通过 cgroup 限制容器资源，是资源隔离与防争抢的关键，超限内存触发 OOM。

• overlay2 的 lower/upper 层与 COW
• 镜像层与容器层
• 性能与适用

overlay2 是 Docker 的默认存储驱动，基于 Linux overlay 文件系统。它把镜像层作为 lowerdir（只读层），容器可写层作为 upperdir，通过合并视图呈现。修改文件时使用 COW（写时复制）：把要改的文件从 lower 复制到 upper 再修改，不修改原层。overlay2 相比旧版 overlay、devicemapper 性能更好（页缓存共享、无块设备开销）、内存占用低，是 Linux 上的推荐驱动。它要求底层文件系统支持（如 xfs/ext4 的 d_type）。overlay2 支持层复用、镜像共享与高效容器运行。

overlay2 用 lower/upper 合并视图 + COW 实现镜像分层与容器可写层，性能好、内存占用低，是默认驱动。

• BuildKit 的 cache 导出/导入
• --cache-from 使用远程缓存
• 加速 CI 构建

BuildKit 支持把构建缓存导出到镜像仓库或本地并可复用。--cache-from 指定从何处加载缓存：docker build --cache-from=myimage:cache 从仓库中的 cache stage 加载缓存，--cache-from=type=registry,ref=... 或 type=local 指定缓存源。构建时先尝试从缓存源加载层缓存，命中则跳过重建，加速 CI 构建（尤其多阶段构建）。配合 --cache-to 导出缓存，形成"构建→导出缓存→下次加载"的循环。远程缓存适合跨机器/CI 复用构建缓存，缩短构建时间。

--cache-from 从远程/本地缓存源加载层缓存，配合 --cache-to 导出，实现跨构建复用以加速 CI 构建。

• profiles 标记服务
• 按 profile 启用服务
• 环境差异管理

Docker Compose profiles 通过给服务打 profile 标签，实现按需启用服务集合。在 compose 文件中给服务加 profiles: ["dev"]，启动时用 docker compose --profile dev up 只启动带 dev profile 的服务（不带 profile 的服务默认启动）。可用于按环境（dev/test/prod）区分服务集合，或按功能（如额外工具、监控）按需启用。相比拆分多个 compose 文件，profiles 在单一文件中管理环境差异更简洁。覆盖默认不支持 profile 的版本需注意。

profiles 用服务标签+启动参数按环境/功能启用服务子集，是精简 compose 管理环境差异的方式。

• tag 标识镜像版本
• 语义化版本与 latest
• 不可变 tag 与 digest

Docker 通过 tag 标识镜像版本，如 image:1.2.3、image:latest。版本管理实践：1) 用语义化版本（如 1.2.3、release-v1.2.3）标识可追溯版本，避免只依赖 latest；2) 用 digest（镜像摘要）精确引用不可变镜像，image@sha256:...，保证部署可复现；3) 多 tag 策略（如同时打 latest 和具体版本），latest 指向最新但不稳定，生产应锁定具体版本/digest；4) 配合 CI 自动打 tag 与清理。核心：tag 是可变指针，digest 是不可变标识，生产环境用 digest 或锁定版本保证可复现与可审计。

tag 是版本标签（可变），digest 是不可变标识，生产用具体版本/digest 保证可复现，避免 latest 漂移。

• rootless 以非 root 用户运行 dockerd 与容器
• 降低 root 权限风险
• 限制与要求

Docker rootless 模式让 dockerd 与容器以非 root 用户运行（无需 root），降低容器逃逸到 root 的风险。实现：通过 rootlesskit 为用户命名空间创建隔离环境，容器在用户命名空间内运行，无特权。收益：守护进程与容器不再以 root 权限运行，攻击面缩小。限制：需要新内核支持（unprivileged userns）、部分功能受限（如特定网络端口绑定、某些存储驱动）、性能可能略降，且需 rootlesskit 依赖。适合安全敏感、非特权环境，但生产复杂场景仍常用 rootful。

rootless 用用户命名空间让容器以非 root 运行，降低权限风险，但需内核支持与功能权衡。

• overlay 网络跨多主机
• VXLAN 隧道
• 与 swarm 结合

Docker overlay 网络让跨多个 Docker 主机的容器能直接通信（同一虚拟网络），底层用 VXLAN 隧道封装容器流量，在主机间传递。overlay 网络需要 Docker 集群（swarm 模式）或支持，创建 docker network create -d overlay mynet。每台主机上容器通过 VXLAN 加入同一逻辑网络，可实现跨主机服务发现与负载均衡。VXLAN 带来封装开销，但隔离与扩展性好。overlay 网络是容器集群跨主机组网的关键，K8s 用 CNI 实现类似功能。

overlay 网络用 VXLAN 隧道跨主机连接容器，实现统一虚拟网络，是容器集群组网的基础。

• overlay2 的文件系统层叠
• devicemapper 的块设备方案
• 适用场景与性能

overlay2 基于内核 overlay 文件系统，镜像层直接叠加在文件系统上，页缓存共享、内存占用低、性能好，是 Linux 默认推荐驱动，适合绝大多数容器场景。devicemapper 基于块设备（thin provisioning），每个容器有独立块设备，隔离性好但性能差（镜像层每次复制）、内存占用高、配置复杂，曾是旧版 Docker 默认，现已不推荐。适用场景：overlay2 适合通用生产与性能敏感场景；devicemapper 仅在特定 legacy 环境或需要块级隔离时使用。现代推荐统一用 overlay2（或映射到合适文件系统）。

overlay2 文件层叠性能好、是默认，devicemapper 块设备隔离但性能差，已基本被 overlay2 取代。

• dive 逐层分析镜像
• 定位层体积与缓存失效
• 镜像瘦身

dive 是镜像分析工具，可交互式查看每个镜像层的内容、大小、每个文件/目录的占用，帮助定位镜像体积膨胀的根因（如某层引入了大文件、重复文件、未清理的缓存）。用法：dive image:tag，交互界面显示层树、每层文件变化、浪费空间（如重复文件、删除的文件残留在更底层）。定位缓存失效：对比镜像层，看哪些层因指令/上下文变化被重建。通过 dive 找到可删除的层或文件，优化 Dockerfile（多阶段、清理缓存）缩小镜像。dive 是镜像体积优化与构建分析的标准工具。

dive 逐层分析镜像文件与体积，定位浪费空间与缓存失效，指导 Dockerfile 优化与镜像瘦身。

• --build-arg 传递 ARG
• ARG 与 ENV 的区别
• 敏感信息注意事项

docker build --build-arg KEY=value 把构建参数传给 Dockerfile 中声明的 ARG KEY，用于构建期参数化（如版本号、镜像源、环境）。ARG 仅在构建期存在（不进入最终镜像环境变量），ENV 会进入容器运行时。注意：ARG 值会出现在镜像历史中（docker history 可看到），不宜传敏感信息（密码/密钥），需用 secret 或 BuildKit secrets。--build-arg 常配合 --platform 或 CI 动态传入。合理使用 ARG 使镜像构建可复用、可参数化。

--build-arg 传 ARG（构建期参数），ARG 不进运行时环境，但会出现在镜像历史，敏感信息勿用。

• docker exec 在运行容器执行命令
• 交互式调试（-it bash）
• 调试注意事项

docker exec -it <container> bash 在运行中的容器内启动交互式 shell 进行调试，docker exec <container> <cmd> 执行单条命令。可用于查看进程、日志、网络、文件系统、环境变量。注意：1) 调试用 exec 会在容器内创建新进程，尽量用只读/临时命令避免污染；2) 容器可能没有 bash/shell，需用可用的解释器（如 sh）；3) 生产环境调试需谨慎，避免对运行容器造成影响；4) exec 依赖容器内运行进程，若容器已退出需先启动。docker exec 是容器内问题排查的常用入口。

docker exec 在运行容器起进程/命令调试，但需注意容器内工具可用性与生产安全。

• docker inspect 输出 JSON 元数据
• 容器/镜像/网络等对象
• 常见字段与用法

docker inspect <container|image|network> 输出对象详情的 JSON 元数据。容器可查：状态、PID、网络、端口、挂载、环境变量、资源限制、创建时间等；镜像可查：Config（entrypoint、cmd、env）、layers、架构、大小、digest 等。可用 --format 或 -f 用 Go 模板提取特定字段（如 docker inspect -f '{{.State.Status}}' cont）。docker inspect 是用来获取容器/镜像精确配置与状态信息的标准工具，常用于脚本与排障。

docker inspect 输出 JSON 元数据，可查容器状态/网络/挂载与镜像配置，用 -f 提取字段便于脚本化。

• docker system prune 清理未使用资源
• 各类 prune 命令
• 清理风险与注意事项

docker system prune 清理未使用的资源（已停止容器、未使用的网络、悬空镜像、构建缓存），释放磁盘。带 -a 会连未使用的镜像（无容器引用）也清理，--volumes 清理未使用卷。其他：docker image prune、docker container prune、docker build 缓存清理（docker builder prune）。风险：-a/--volumes 会删除可能还有用的数据（尤其卷），需谨慎，最好先确认无引用。定期清理可避免磁盘占满，但要在确认后执行。

docker system prune 清理未使用资源释放磁盘，-a/--volumes 需谨慎防误删数据。

• hadolint 检查 Dockerfile 规范
• 规则与最佳实践
• CI 门禁落地

hadolint 是 Dockerfile 静态检查工具，检查 Dockerfile 是否符合最佳实践（镜像书写、使用非 root、避免 apt 缓存、合并 RUN、固定版本、避免特权等），输出违规规则。在 CI 落地：1) 在 CI 流水线对 Dockerfile 运行 hadolint，结果作为门禁（违规即失败，如 hadolint Dockerfile 检查退出码）；2) 配置 ignore 忽略合理规则、设定规则集；3) 结合镜像扫描（trivy）与构建检查，形成 Dockerfile 规范门禁。hadolint 让 Dockerfile 规范可在 CI 中强制执行，提升镜像质量与安全。

hadolint 静态检查 Dockerfile 规范，在 CI 中作为门禁（违规即失败）强制执行最佳实践，提升镜像质量。

• PID 1 接收信号与僵尸回收的特殊性
• 直接跑应用作为 PID 1 的问题
• tini/dumb-init 的价值

容器内 PID 1（init 进程）有特殊职责：负责处理信号（如 SIGTERM/SIGINT）并对后续子进程做僵尸回收（reap）。若直接运行应用作为 PID 1：1) 容器停止时内核向 PID 1 发信号，但应用若不处理信号，容器无法优雅退出（可能被强制 kill）；2) PID 1 不自动回收僵尸子进程，容器内可能积累僵尸进程。tini/dumb-init 作为轻量 init，作为 PID 1 启动，负责转发信号给应用、回收子进程，使容器能优雅退出、无僵尸。工程价值：保证容器健康退出与资源回收，是容器最佳实践。

PID 1 需处理信号与回收僵尸，直接跑应用作为 PID 1 会信号处理不当与僵尸堆积，init 工具解决此问题。

• docker.sock 是守护进程控制接口
• 挂载导致容器可控制宿主机 Docker
• 规避措施

挂载 /var/run/docker.sock 到容器，等于让容器进程获得对宿主机 Docker 守护进程的控制权（可创建特权容器、操作宿主机文件系统、逃逸），是高危操作。风险：容器内恶意代码可通过 docker.sock 创建挂载宿主目录的特权容器，实现宿主机逃逸与提权。规避：1) 避免挂载 docker.sock 给不受信容器；2) 若必须（如 CI、容器管理工具），使用受限的 Docker API 代理、最小权限、只读挂载、控制网络；3) 用更安全的替代（如 DinD、k8s sidecar、专用 API）；4) 对挂载 docker.sock 的容器严格审计。核心是"docker.sock 即宿主机 root 权限，需最小化暴露"。

docker.sock 是守护进程控制面，挂载即宿主机控制权，风险极高，需避免或最小化且严格限制。

• 各镜像仓库的功能差异
• 镜像清理策略（GC、保留）
• 不可变 digest 部署收益

镜像仓库选型：Docker Hub 是官方公共仓库，简单但无私有细粒度治理；Harbor 是 CNCF 项目，提供 RBAC、漏洞扫描、复制、签名、GC 与审计，适合企业私有仓库；Nexus 是通用制品仓库，支持多种制品（Maven/npm/镜像）但容器功能不如 Harbor 深度。运维重点：1) 镜像清理策略：用 GC 清理未被引用的 blob、用保留策略清理过期 tag，避免仓库膨胀；2) 不可变 digest 部署：用镜像 digest（sha256）而非可变 tag 部署，保证部署可复现、防篡改、供应链可审计。选型按企业治理需求（RBAC/扫描/复制）与生态配合。

选型按治理需求（Harbor 功能全、Nexus 通用、Hub 简单），运维重点是清理策略与不可变 digest 部署。

• manager 负责集群管理与调度
• Raft 一致性
• 多 manager 高可用

Docker Swarm manager 节点负责集群管理：接收服务定义、调度任务、维护集群状态、管理 worker。多个 manager 通过 Raft 共识算法选主并保持状态一致，实现高可用（leader 故障自动切换）。manager 上运行 swarmkit 服务，管理 service、task、node。worker 节点由 manager 分配任务。多 manager 建议奇数个（如 3 或 5）保证 quorum 与故障容错。manager 承担集群控制面，是 Swarm 集群的核心。

manager 是 Swarm 控制面，用 Raft 保证多 manager 一致与高可用，建议奇数个 manager 保 quorum。

• Swarm secrets 的存储与分发
• 加密与权限
• 与 config 的区别

Docker Swarm secrets 用于向服务安全分发敏感信息（密码、密钥、token）。创建 docker secret create，secrets 存储在 swarm 的 Raft 加密存储中，创建后内容不可查看（只有服务能读取）。服务运行时可挂载 secret 到容器（内存文件系统），容器内可读。secret 只能给被授权的服务（--secret 关联），实现最小权限，且不保存在镜像或未加密环境变量中。相比 config（非敏感配置），secret 专用于敏感信息且加密。K8s 的 Secret 类似此概念。

Swarm secrets 加密存储于 Raft，仅授权服务挂载读取，避免敏感信息泄露在镜像/环境变量。

• 各日志驱动的特点
• 日志轮转与大小限制
• 磁盘占满防护

Docker 日志驱动：json-file 是默认，把日志写入文件，需配置轮转；journald 用 systemd journal 管理，便于与系统日志统一；splunk/fluentd 等转发到外部日志系统，适合集中化。生产运维重点：1) 日志轮转：配置 json-file 的 max-size 与 max-file 限制日志文件大小与数量，防止容器日志无限增长占满磁盘；2) 磁盘占满防护：设定 daemon.json 的日志限制、监控磁盘、定期清理；3) 集中化：用日志采集（logspout/fluentd）转发到 ELK 等。选型按"是否需要集中化、与系统日志集成、磁盘成本"。日志不控制会迅速占满磁盘，是常见事故。

日志驱动按集中化需求选型，核心是配置轮转与大小限制防磁盘占满，并监控清理。

• docker-slim 分析并裁剪镜像
• minify 原理（保留运行所需）
• 兼容性风险与场景

docker-slim 通过分析镜像运行所需的最小文件/依赖，生成瘦身镜像（minify），大幅减小体积。原理：动态分析应用启动时访问的文件、库、可执行文件，保留运行所需，删除其余。收益：镜像体积显著减小、减小攻击面与传输。风险：分析基于应用运行路径，若应用有时间/条件分支在分析时未触达，可能误删所需文件导致运行失败（兼容性风险）；涉及动态加载、编译、特殊依赖时需谨慎验证。适用场景：静态/简单应用、减小传输与部署；复杂运行时的应用需充分测试。瘦身后必须回归验证。

docker-slim 裁剪运行所需之外的文件减小镜像，但动态分析可能漏删引发运行失败，需充分验证。

• tag 是可变指针
• digest 是不可变标识
• 生产用 digest 可复现与审计

镜像 tag 是可变指针（如 latest），可被重新指向不同镜像，导致不同环境部署到不同内容、无法复现；digest（sha256）是镜像内容的不可变标识，同一 digest 永远对应同一镜像。生产用 digest 部署：1) 保证可复现（同一 digest 部署的是同一镜像，不因 tag 漂移变化）；2) 供应链审计（可追溯部署的精确镜像）；3) 防篡改（digest 校验内容）。Mutable tag 适合开发便捷，但生产应锁定 digest 或确认不可变的精确版本 tag。这是可复现与安全的最佳实践。

tag 可变导致漂移，digest 不可变保证可复现与审计，生产锁定 digest 或精确版本避免变悄悄变化。