Docker
Docker 通过对 Linux 内核特性的封装，将应用及其运行环境打包为一个标准化的可移植单元。从工程视角来看，Docker 最大的贡献不在于发明了容器技术本身，而是定义了一套从镜像构建、分发到运行的完整工作流，让容器从一项内核特性变成了开发者的日常工具。在这套工作流的推动下，持续集成、微服务部署、环境一致性等问题有了统一且可复现的解决方案。
架构与核心组件
Docker 采用经典的 C/S 架构。Docker Daemon（dockerd）作为服务端运行在宿主机上，负责管理镜像、容器、网络和存储卷等资源。Docker CLI 通过 REST API 与 Daemon 通信，用户在命令行执行的每一条 docker 命令最终都会转化为对 Daemon 的 HTTP 调用。Docker Registry（如 Docker Hub、Harbor）负责镜像的存储和分发，构成了镜像的全球供应链。
这个架构有一个值得注意的工程细节：Docker CLI 和 Daemon 之间通过 Unix Socket（/var/run/docker.sock）通信，这意味着任何有权限访问该 Socket 的用户都可以控制 Docker Daemon，等同于拥有宿主机的 root 权限。在生产环境中，通常需要通过用户组权限、Socket 权限或 rootless 模式来降低这个风险。
Docker Daemon 的内部由多个组件协作完成工作。containerd 是容器运行时的核心，负责管理容器的完整生命周期，包括镜像拉取、容器创建、启动和停止。containerd 之下是 runc，它是 OCI（Open Container Initiative）标准的参考实现，负责利用 Linux Namespace 和 Cgroup 实际创建和运行容器。containerd 和 runc 的分离意味着 Docker 可以支持多种运行时实现，这也是后来 Kubernetes 能够通过 CRI（Container Runtime Interface）对接不同容器运行时的技术基础。
Kubernetes 的 CRI 标准进一步推动了运行时的解耦。CRI 定义了 Kubernetes 与容器运行时之间的 gRPC 接口规范，使得 Kubernetes 不再直接依赖 Docker Daemon。在 CRI 体系下，containerd 可以直接与 Kubernetes 通信，省去了 Docker Daemon 这一层，降低了架构复杂度和资源开销。这也是为什么 Kubernetes 社区在 v1.24 之后正式移除了对 Docker 的内置支持——不是因为 Docker 不够好，而是因为中间层的省略让整个链路更短、更可控。
镜像构建与分层存储
Docker 镜像是容器运行的模板，它基于 UnionFS（联合文件系统）实现分层存储。每一层对应 Dockerfile 中的一条指令，层与层之间通过内容寻址机制关联。这种设计有两个关键的工程意义：当多个镜像共享相同的基础层时，磁盘上只需存储一份；当镜像的某一层发生变化时，只需重新构建该层及以上的内容，下层的缓存可以被复用。
Dockerfile 中的指令顺序直接影响镜像的构建效率和最终体积。将变化频率低的指令（如安装系统依赖）放在前面，将变化频率高的指令（如复制应用代码）放在后面，可以充分利用层缓存加速构建。对于编译型语言的项目，多阶段构建是控制镜像体积的有效手段——第一阶段使用完整的编译工具链构建产物，第二阶段仅将编译产物复制到精简的运行时镜像中，最终镜像可以只包含运行时依赖而不携带编译工具链。
在镜像管理方面，标签语义化是工程团队常被忽视但影响深远的问题。生产环境中应避免使用 latest 标签，因为它指向的镜像内容不可预测。推荐使用 v1.2.3 这样的语义化版本标签，并结合 Git commit hash 构建镜像标签，使镜像版本与代码版本形成精确的追溯关系。
网络模型
Docker 提供了多种网络模式以适应不同的使用场景。Bridge 是默认模式，Docker 在宿主机上创建一个虚拟网桥（docker0），每个容器通过 veth pair 连接到该网桥，容器之间通过网桥进行二层通信。Bridge 网络为容器提供了独立的网络命名空间和 IP 地址，同时通过 NAT 规则让容器可以访问外部网络。需要注意的是，Bridge 模式下容器与宿主机之间的通信会经过 NAT 转换，在高吞吐场景下会有轻微的性能损耗。
Host 模式让容器直接使用宿主机的网络命名空间，不进行任何网络隔离。这种模式在需要容器直接暴露端口或需要较高网络性能的场景下有优势，但容器与宿主机共享网络栈也意味着端口冲突的风险，且无法在同一台宿主机上运行多个监听相同端口的服务实例。
Overlay 网络用于解决跨主机容器通信的问题。它通过 VXLAN 封装在底层物理网络之上建立虚拟网络，使得分布在不同宿主机上的容器可以像在同一局域网中一样通信。Overlay 网络主要在 Docker Swarm 或需要跨主机容器直接通信的场景中使用，在 Kubernetes 环境中，跨主机网络通常由 CNI 插件负责实现。
Macvlan 网络让容器直接连接到物理网络，每个容器拥有一个独立的 MAC 地址和 IP 地址，在网络拓扑中表现为一台独立的物理机。这种模式适用于需要容器与物理网络设备直接交互的场景，但实现前提是物理网络设备支持混杂模式。
存储管理
Docker 的存储方案需要解决一个核心问题：容器的可写层在容器删除后即被销毁，如何持久化需要保留的数据。Docker 提供了三种存储机制来应对不同的持久化需求。
Volume 是 Docker 推荐的数据持久化方式，由 Docker 自身管理存储位置（默认在 /var/lib/docker/volumes/ 下），生命周期独立于容器。Volume 的优势在于不依赖宿主机的目录结构，便于迁移和管理，在 Swarm 模式下还可以实现跨主机的数据共享。在编排场景中，Volume 是首选方案。
Bind Mount 直接将宿主机的目录或文件挂载到容器中，映射关系明确，适合开发环境中将源代码目录挂载到容器内实现热更新。但 Bind Mount 的路径是硬编码的宿主机路径，在多主机环境下不具备可移植性，生产环境中的使用需要谨慎。
Tmpfs 将数据存储在宿主机的内存中，容器停止后数据立即消失。它适用于存放敏感信息或临时处理的中间数据，避免了磁盘写入的延迟。
存储驱动（Storage Driver）的选择也会影响容器的 I/O 性能。OverlayFS2 是当前推荐的存储驱动，利用内核原生的 OverlayFS 实现分层文件系统，在大多数 Linux 发行版上有较好的性能表现。在设备映射器（devicemapper）或 Btrfs 等驱动上，I/O 性能可能存在显著差异，建议在生产环境中根据实际负载进行基准测试后选择。
容器隔离与资源控制
容器的隔离建立在 Linux Namespace 之上。PID Namespace 让容器只能看到自己的进程树，Network Namespace 提供独立的网络栈，Mount Namespace 隔离文件系统视图，UTS Namespace 隔离主机名，IPC Namespace 隔离进程间通信，User Namespace 隔离用户和用户组。这些 Namespace 的组合为容器构建了一个相对独立的运行环境，但需要注意的是，Namespace 提供的是视图隔离而非安全隔离，容器内的 root 用户在特定条件下仍然可能影响宿主机。
Cgroup（Control Group）负责资源限制，防止容器无限制地消耗宿主机资源。通过 --cpus 限制 CPU 使用量，--memory 限制内存上限，--pids-limit 限制进程数量。在实际工程中，资源限制不是可选的配置，而是生产环境的必要措施。未设置资源限制的容器可能因内存泄漏或 CPU 密集型操作拖垮整台宿主机，影响同一节点上运行的所有服务。
从安全加固的角度来看，容器的默认隔离级别并不够。Seccomp 可以限制容器可执行的系统调用集合，AppArmor 或 SELinux 提供强制访问控制，--read-only 标志将容器根文件系统设为只读，--cap-drop 移除不必要的 Linux Capabilities。这些措施组合使用，可以有效缩小容器的攻击面，降低容器逃逸的风险。
工程实践中的常见问题
在长期使用 Docker 的过程中，有几个高频问题值得记录。镜像体积膨胀是最常见的一个，通过多阶段构建、使用精简基础镜像（如 Alpine）、清理构建缓存（.dockerignore 排除不必要的文件）可以有效控制。构建缓存失效也是一个痛点，理解 Docker 的层缓存机制并合理安排 Dockerfile 指令顺序，可以显著缩短构建时间。
容器日志堆积导致磁盘满是需要主动监控的问题。Docker 默认的日志驱动不限制日志文件大小，长时间运行的服务容器可能产生大量日志。通过在 Daemon 配置或容器启动时设置 --log-opt max-size 和 --log-opt max-file，可以对日志进行轮转控制，避免磁盘被撑满。
在 CI/CD 流水线中，Docker 镜像的构建和推送通常是耗时最长的环节之一。构建缓存服务（如 BuildKit 的缓存导出/导入功能）和镜像仓库的分层缓存机制可以显著提升构建效率。在大型工程中，合理拆分 Dockerfile、利用基础镜像预构建依赖层，是值得投入的优化方向。