Docker 基础与概念
Docker 用来把应用及其运行时打成 镜像，在本机、CI、生产用同一套文件系统与进程环境跑起来。它和具体编程语言无关：Python、Node、Go、静态站点都可以容器化。
很多仓库的 Dockerfile / Compose 不是你说了算的——先跟现有文件与 CI 构建命令；只有新项目，或团队明确要改造时，再套推荐写法。
集群里怎么编排这些镜像，见 K8s 基础与架构。
容器解决什么
| 痛点 | 容器怎么帮 |
|---|---|
| 「我机器能跑、你机器不行」 | 同一镜像、同一层依赖 |
| 系统库 / 原生依赖难装 | 构建阶段装好，运行镜像可精简 |
| 运行时版本漂移 | FROM 钉死基础镜像标签 |
| 本地工具链与生产不一致 | 生产以镜像为准，本机可用 Compose 贴近 |
容器边界是 镜像文件系统 + 进程；语言自带的「虚拟环境 / node_modules」等仍可能出现在镜像内部，只是协作单元变成了镜像，而不是每台机器手装一遍。
核心概念（极简）
| 概念 | 一句话 |
|---|---|
| 镜像（image） | 只读模板：系统层 + 依赖 + 应用 |
| 容器（container） | 镜像跑起来的进程实例 |
| 层（layer） | Dockerfile 每步大致对应一层；依赖与源码分开拷，利于缓存 |
| Dockerfile | 描述如何构建镜像的脚本 |
| 仓库（registry） | 存放/分发镜像（Docker Hub、GHCR、私有仓等） |
| Compose | 用 YAML 定义并启动多个容器（应用 + 数据库等） |
docker build -t my-app:dev .
docker run --rm -p 8080:8080 my-app:dev
docker compose up --build
-p 主机端口:容器端口 把容器端口映射到本机。容器里的 localhost 只指向该容器自己；同 Compose 网络里访问其他服务要用服务名（如 db:5432）。细节见后续 Compose / 网络篇。
先认现场
| 标志 | 含义 | 你通常该怎么做 |
|---|---|---|
Dockerfile / Dockerfile.* | 镜像构建入口 | 读注释与 CI 里的 docker build 参数 |
docker-compose.yml / compose.yaml | 本地多服务编排 | docker compose up（以 README 为准） |
.dockerignore | 构建上下文排除项 | 保留对本地依赖目录、.git、缓存的忽略 |
基础镜像（node: / python: / golang: / nginx: …） | 运行时选型 | 与仓库技术栈对齐，勿随意换族 |
| 仅有 K8s/Helm、无本地 Docker 文档 | 部署在集群侧 | 问清本地是否还需 Compose |
本机工具链 vs 镜像
语言版本管理器 / 本机 SDK → 开发体验
锁文件 / 依赖清单 → 装哪一棵依赖树
Dockerfile / Compose → 如何构建与本地联调
CI → 构建、扫描、推送镜像
生产运行以 镜像标签 为准；本机 SDK 版本应与基础镜像 主版本对齐，避免「本地过、镜像挂」。
要点
- Docker 是通用运行时封装；先跟仓库现有 Dockerfile / Compose / CI
- 镜像是模板，容器是进程实例；层让构建可缓存
- 协作单元是镜像标签，不是每台机器手装一遍依赖
- 编排到多机见 K8s；本模块先把镜像与本地联调讲清楚
面试速记
- 镜像和容器有什么区别？ 镜像是只读模板；容器是镜像跑起来的进程实例（可写层叠在镜像之上）。
- 为什么用容器？ 同一镜像在本机/CI/生产一致，减少「我机器能跑」问题，并把依赖打进交付物。
- 层（layer）是什么？ Dockerfile 指令大致对应层；未变的层可复用缓存，加快构建。
- Registry 干什么？ 存放与分发镜像（Docker Hub、GHCR、私有仓）。
- 本机 Node/Python 版本和镜像不一致会怎样？ 本地能跑、镜像里可能挂；应对齐基础镜像主版本，并以镜像/CI 为准。