Docker面试题手册

Docker 容器默认以 root 运行——如果容器被攻破，攻击者获得容器内的 root 权限，可能逃逸到宿主机。安全的第一步：不要用 root 跑应用。不要用 root 跑应用USER appuser 之后的所有操作（CMD、ENTRYPOINT）都以 appuser 身份执行。即使应用有漏洞，攻击者只有普通用户权限。docker run 指定用户如果 Dockerfile 里没有 USER，运行时指定：覆盖 Dockerfile 里的 USER 指令。UID 1000 通常是宿主机的第一个普通用户。只读文件系统把容器文件系统挂载为只读，攻击者无法写入恶意文件。 给 /tmp 临时写入空间（很多应用需要）。限制能力（Capabilities）Linux capabilities 是细粒度的权限控制。Docker 默认给容器少量 capability，但还可以更严格：删掉所有能力， 只加回绑定 1024 以下端口的能力。按需添加，不给多余的权限。Rootless DockerDocker 默认以 root 运行 daemon——即使容器里不是 root，daemon 本身是 root。Rootless 模式让整个 Docker daemon 以普通用户运行：Rootless 模式的限制：不能绑定 80/443 端口（需要 1024 以上），没有 cgroup 资源限制，网络功能受限。适合 CI/CD 和开发环境，生产环境不成熟。资源限制防止恶意或失控的容器吃光宿主机资源：限制容器最多 100 个进程，防止 fork bomb。安全检查清单容器不以 root 运行（USER 指令或 --user 参数）文件系统只读（--read-only）最小 capability（--cap-drop ALL + 按需 cap-add）资源限制（memory、cpus、pids）不挂载 Docker socket（-v /var/run/docker.sock 是最危险的操作）镜像来自可信源（不用来历不明的镜像）

Docker 容器是不可变的——更新不是在容器里改代码，而是用新镜像替换旧容器。关键是怎么替换才能不停服。最简单的更新：停旧启新有停机时间。适合内部工具、非关键服务。停机时间取决于镜像拉取速度和启动时间。滚动更新：Docker SwarmSwarm 的滚动更新逐个替换容器，始终保持部分实例在线：更新过程中部分容器跑 v1，部分跑 v2，用户无感知。如果新版本有问题，回滚：蓝绿部署准备两套环境（蓝和绿），切换流量：蓝绿部署零停机，但需要双倍资源。适合关键服务的版本更新。Docker Compose 更新Compose 会检测镜像是否变化，只重建有变更的容器。但不是滚动更新——旧容器先停再启新容器，有短暂停机。健康检查确保更新安全更新后容器必须通过健康检查才算成功。连续失败 3 次，标记为 unhealthy。配合滚动更新，unhealthy 的新容器不会继续替换旧容器。回滚策略不管用什么更新方式，都要有回滚能力：保留旧版本镜像（不要 docker rmi 删掉）数据库变更要向后兼容（新版本能读旧 schema）配置文件版本化管理（.env 用 git 追踪）回滚就是 docker run 旧版本镜像。如果数据库迁移了且不兼容旧版本，回滚也救不了——所以数据库变更要分步做。

Docker 日志分两类：容器标准输出（docker logs）和应用自己的日志文件。docker logs应用必须把日志输出到 stdout/stderr 才能用 docker logs 查看。日志轮转（防止磁盘爆满）每个容器最多 3 个文件，每个 10MB，超过自动轮转。集中化日志多容器环境下逐个 docker logs 不现实。用日志聚合：Loki + Grafana：轻量，推荐ELK Stack：功能全但重Fluentd：日志收集器排查技巧grep 过滤：docker logs my-container 2>&1 | grep ERROR多容器：docker compose logs -f启动失败：docker logs $(docker ps -lq)

容器网络问题分三类：容器间不通、容器访问不了外网、外部访问不了容器。按层级排查：DNS → 端口映射 → 防火墙。容器间通信问题不在同一个网络：docker network connect my-network container-b。Docker 内置 DNS 只在同网络内生效。用服务名（ping redis）而不是 IP。ping redis 失败但 IP 能通是 DNS 问题。端口映射问题常见错误：忘了 -p 参数、端口冲突、只绑定了 127.0.0.1。容器访问不了外网DNS 失败时手动指定：docker run --dns 8.8.8.8。防火墙拦截Docker 修改 iptables 实现端口映射。ufw 开启但没放行 Docker 链会拦截流量。确保 DEFAULTFORWARDPOLICY="ACCEPT"。网络模式bridge（默认）：需要端口映射和 DNShost：直接用宿主机网络，性能好但隔离差none：无网络生产环境推荐 bridge + 自定义网络。

容器内存持续增长最终被 OOM Kill 是 Docker 最常见的问题之一。排查步骤：确认是不是真的泄漏 → 定位哪个容器 → 找到代码里的泄漏点。确认问题内存持续增长不回落大概率是泄漏。短暂增长后稳定不一定是泄漏——可能是 JVM/Node.js 堆还没触发 GC。检查 OOM 事件容器内定位语言级分析Node.js：用 v8.writeHeapSnapshot() 生成堆快照Java：用 jmap -dump 生成堆 dumpPython：用 tracemalloc 或 objgraph用 Chrome DevTools 或 MAT 分析堆快照，找 Retained Size 最大的对象。常见原因全局列表/缓存只加不删（最常见）事件监听器没有 removeEventListener数据库连接没有释放临时缓解只治标不治本，排查期间防止 OOM Kill。

微服务架构的核心是一个服务一个进程——Docker 的容器天然就是为此设计的。每个微服务打包成独立镜像，独立部署、独立扩缩容。一个服务一个容器每个服务有自己的 Dockerfile，独立构建和部署。服务间通信同一 Docker 网络内，容器用服务名互相访问（http://user-service:3000），Docker 内置 DNS 自动解析。跨主机通信需要额外方案：Docker Swarm 用 Overlay 网络，Kubernetes 用 Service。扩缩容Compose 的 --scale 适合开发测试。生产环境用 K8s 的 HPA 自动扩缩容。配置管理不要把配置写死在镜像里。用环境变量注入，不同环境用不同 .env 文件。Docker 微服务的局限Docker Compose 适合 5-10 个服务的项目。超过 10 个服务应该用 Kubernetes——它提供自动扩缩容、滚动更新、服务发现、健康检查等编排能力。

Docker 跑数据库能快速搭建开发环境，但生产环境要格外注意数据持久化、性能和备份。一句话：开发环境放心用，生产环境谨慎用。数据持久化：第一优先级容器删了数据就没了——这是 Docker 跑数据库最大的风险。必须用 Volume 挂载数据目录：# MySQL：把 /var/lib/mysql 挂到宿主机docker run -d -v mysql_data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=secret mysql:8# PostgreSQL：把 /var/lib/postgresql/data 挂出来docker run -d -v pg_data:/var/lib/postgresql/data -e POSTGRES_PASSWORD=secret postgres:16-v mysql_data:/var/lib/mysql 用 Docker Volume（推荐）。也可以用宿主机目录 -v /data/mysql:/var/lib/mysql，但权限管理更麻烦。验证持久化：docker rm -f 删掉容器后重新 docker run（同一个 volume），数据还在。开发环境：docker-compose 一键搭建# docker-compose.ymlservices: db: image: postgres:16 environment: POSTGRES_DB: myapp POSTGRES_PASSWORD: dev123 ports: - "5432:5432" volumes: - pg_data:/var/lib/postgresql/data redis: image: redis:7 ports: - "6379:6379"volumes: pg_data:docker compose up -d 一键启动 PostgreSQL + Redis。ports 映射到宿主机，本地开发工具（psql、DBeaver）直连。生产环境的注意事项1. 不要把数据库密码放环境变量环境变量对容器内所有进程可见，docker inspect 也能看到。用 Docker Secrets（Swarm）或文件挂载：docker run -d -v /secrets/db_password.txt:/run/secrets/db_password:ro mysql:82. 设置资源限制数据库不加限制会吃光宿主机内存：docker run -d --memory=4g --memory-swap=4g --cpus=2 mysql:8同时在数据库配置里调整缓存大小（MySQL 的 innodb_buffer_pool_size，PG 的 shared_buffers），让它和容器内存限制匹配。3. 健康检查healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 10s timeout: 5s retries: 3容器"运行中"不代表数据库"可用"——MySQL 可能还在做崩溃恢复。健康检查确保只有真正可用的数据库接收连接。备份# MySQL 备份docker exec mysql_container mysqldump -u root -p secret mydb > backup.sql# PostgreSQL 备份docker exec pg_container pg_dump -U postgres mydb > backup.sql定时备份：用 cron + 上面的命令，把 SQL 文件推到 S3 或其他存储。不要把备份文件存在容器里。生产环境该不该用 Docker 跑数据库？适合：中小规模、团队能力有限、需要快速部署。用 Docker 统一运维比手动管理多台数据库服务器简单。不适合：高性能场景（I/O 密集型数据库）、需要极致调优、合规要求禁止容器化。Docker 的网络和存储有一层抽象，理论上比裸机慢 5-10%。大多数场景这 5% 可以忽略，但对 TPS 要求极高的系统可能不行。折中方案：数据库跑在宿主机或托管数据库（RDS），只把应用放在 Docker 里。

Docker 安全最佳实践包括：使用官方或可信的基础镜像、定期更新镜像以修复安全漏洞、避免在镜像中存储敏感信息（使用环境变量或 secrets）、以非 root 用户运行容器、限制容器的资源使用、使用 --read-only 标志使容器文件系统只读、使用 Docker Content Trust 验证镜像签名、限制容器的 capabilities（使用 --cap-drop 和 --cap-add）、使用 AppArmor 或 SELinux 增强安全隔离、定期审计和监控容器。

Docker 容器与消息队列的结合可以实现异步处理和解耦。常用消息队列：RabbitMQ、Kafka、Redis、ActiveMQ。部署方式：1）使用官方镜像部署消息队列；2）使用 Docker Compose 编排消息队列和应用容器；3）使用数据卷持久化消息数据；4）配置集群模式提高可用性（如 Kafka 集群）。最佳实践：合理设置资源限制、配置持久化存储、实现消息确认机制、监控队列状态、设置告警。注意事项：消息队列的启动顺序、网络配置、数据备份、故障恢复。

Docker 容器与缓存服务的部署可以显著提升应用性能。常用缓存服务：Redis、Memcached。部署方式：1）使用官方镜像部署缓存服务；2）配置数据卷持久化缓存数据（如 Redis AOF/RDB）；3）使用 Docker Compose 编排缓存和应用容器；4）配置缓存集群模式（如 Redis Cluster）。性能优化：使用 host 网络模式减少网络开销、调整内存配置、使用持久化模式避免数据丢失。最佳实践：设置合理的过期时间、监控缓存命中率、实现缓存预热、配置主从复制提高可用性。

Docker 容器信号处理是容器优雅关闭的关键。Docker 在停止容器时发送 SIGTERM 信号，容器内的进程应该捕获该信号并执行清理操作（如关闭连接、保存状态）。如果进程在超时时间（默认 10 秒）内未退出，Docker 会发送 SIGKILL 信号强制终止。在 Dockerfile 中使用 STOPSIGNAL 指令可以自定义停止信号。应用代码中需要正确处理信号，例如在 Python 中使用 signal.signal()，在 Node.js 中使用 process.on('SIGTERM')。对于多进程容器，需要使用 init 系统（如 dumb-init、tini）来正确传递信号。

Docker 容器性能优化可以从多个方面入手：1）选择合适的基础镜像（alpine、distroless 等）减小镜像体积；2）使用多阶段构建只保留必要文件；3）合并 RUN 指令减少镜像层数；4）利用构建缓存，将变化少的指令放在前面；5）清理不必要的文件和缓存（apt-get clean、rm -rf /var/lib/apt/lists/*）；6）使用 .dockerignore 排除不需要的文件；7）优化应用代码和依赖；8）合理设置资源限制避免资源浪费；9）使用健康检查确保应用正常运行；10）定期更新基础镜像和依赖包获取性能改进和安全修复。

Docker 容器服务发现机制用于动态发现和连接容器化服务。实现方式：1）Docker 内置 DNS：容器通过容器名互相解析；2）环境变量注入：Docker 将链接容器的信息注入环境变量；3）第三方服务发现工具：Consul、Etcd、Zookeeper；4）Kubernetes Service：通过 Service 对象提供服务发现；5）服务网格：Istio、Linkerd 提供高级服务发现功能。负载均衡：Docker Swarm 内置负载均衡，Kubernetes 使用 Service 和 Ingress。最佳实践：使用服务注册中心、实现健康检查、支持动态更新、配置超时和重试。

Docker 容器网络性能优化可以从多个方面入手：1）选择合适的网络模式（host 模式性能最好但隔离性差）；2）使用自定义网络而非默认 bridge 网络；3）优化 MTU 设置以匹配网络环境；4）减少网络层级和跳数；5）使用 DNS 缓存减少域名解析延迟；6）启用网络性能调优参数（如 TCP Fast Open）；7）使用 overlay 网络时优化 VXLAN 配置；8）合理设置容器网络带宽限制；9）使用服务网格优化服务间通信；10）监控网络性能指标及时发现问题。

Docker 容器自动扩缩容可以根据负载动态调整容器数量。在 Docker Swarm 中，使用 docker service scale 服务名=副本数 手动扩缩容，或配合外部监控工具实现自动扩缩容。Kubernetes 提供 Horizontal Pod Autoscaler（HPA）基于 CPU、内存或自定义指标自动扩缩容。实现自动扩缩容需要：1）配置资源请求和限制；2）设置扩缩容指标和阈值；3）配置最小和最大副本数；4）选择合适的扩缩容策略（如稳定窗口、扩缩容比例）。自动扩缩容可以提高资源利用率，降低成本，同时保证服务性能。

Docker 容器调试常用方法：1）使用 docker logs 查看容器日志；2）使用 docker exec -it 容器名 /bin/bash 进入容器交互式 shell；3）使用 docker inspect 查看容器详细配置和状态；4）使用 docker top 查看容器内运行的进程；5）使用 docker stats 查看容器资源使用情况；6）使用 docker port 查看端口映射；7）使用 docker diff 查看容器文件系统变化。对于启动失败的容器，可以使用 docker run --rm -it 镜像名 /bin/bash 手动启动调试。调试时建议使用 --cap-add=SYS_PTRACE 和 --security-opt seccomp=unconfined 参数以获得更多调试能力。

Docker 容器重启策略包括：no（不自动重启，默认）、on-failure（容器非正常退出时重启，可设置最大重试次数）、always（总是重启，除非手动停止）、unless-stopped（总是重启，除非手动停止或 Docker 守护进程重启）。使用 --restart 参数指定重启策略。在生产环境中，always 或 unless-stopped 是常用选择，确保服务高可用性。on-failure 适合可能临时失败但可以自动恢复的服务。

Docker 容器镜像仓库的选择需要考虑多个因素：Docker Hub（官方仓库，镜像丰富，但有拉取限制）、GitHub Container Registry（与 GitHub 集成，适合开源项目）、GitLab Container Registry（与 GitLab CI/CD 集成）、Harbor（企业级私有仓库，支持漏洞扫描、镜像签名）、AWS ECR（AWS 云服务，与 AWS 集成）、Google GCR（Google Cloud 集成）、Azure ACR（Azure 集成）。选择建议：个人学习用 Docker Hub，企业内部用 Harbor，云原生应用用对应云厂商的仓库。注意镜像大小、拉取速度、安全扫描、访问控制等功能。

Docker 容器与虚拟机的混合部署可以结合两者的优势。部署场景：1）使用容器运行无状态应用，使用虚拟机运行有状态应用（如数据库）；2）使用容器运行微服务，使用虚拟机运行传统单体应用；3）使用容器进行快速迭代，使用虚拟机运行稳定的核心业务。网络互通：通过桥接网络、overlay 网络或 host 网络实现容器和虚拟机通信。存储共享：使用共享存储（NFS、Ceph）或数据卷挂载。管理工具：使用 Kubernetes 管理容器，使用虚拟化管理平台（如 vSphere）管理虚拟机。注意事项：资源分配、网络配置、安全策略统一。

CMD 指令在 Dockerfile 中用于指定容器启动时默认执行的命令。如果在启动容器时指定了其他命令，CMD 中的命令将被覆盖。CMD 可以与 ENTRYPOINT 指令配合使用，以更灵活地定义容器的运行行为。