一、Docker 知识梳理

1、什么是 Docker?

Docker 是一个开源的容器化平台,它允许开发者将应用程序及其依赖打包到一个轻量级、可移植的容器中。这些容器可以在任何支持 Docker 的环境中运行,确保“一次构建,随处运行”(Build Once, Run Anywhere)。

Docker 利用操作系统的内核特性(如 Linux 的 cgroupsnamespaces)实现进程隔离与资源限制,无需像传统虚拟机那样运行完整的操作系统,因此更加轻量高效。


2、Docker 解决了什么问题?

1. 环境不一致问题

  • 开发、测试、生产等环境配置不同,常导致“在我机器上能跑”的问题。
  • Docker 将应用和其运行环境一起打包,保证行为一致性。

2. 部署复杂性高

  • 传统部署需手动安装依赖、配置服务,易出错且耗时。
  • 使用 Docker 只需拉取镜像并启动容器,部署过程标准化、自动化。

3. 资源利用率低

  • 虚拟机每个实例都运行完整操作系统,资源开销大。
  • Docker 容器共享宿主机内核,启动快、占用少,提升服务器密度。

4. 应用之间缺乏隔离

  • 多个应用共存于同一服务器时,可能因端口冲突、依赖版本等问题相互干扰。
  • Docker 容器彼此隔离,互不影响,增强系统稳定性与安全性。

5. CI/CD 流程难以标准化

  • 缺乏统一的交付单元,自动化流水线复杂。
  • Docker 镜像作为标准构建产物,天然支持持续集成与持续部署。

Docker 不仅是一种技术,更是一种现代化软件交付范式
它通过容器化实现了开发、测试、运维的一致性,支撑了微服务、云原生、DevOps 等先进架构与实践,在提升研发效率、保障系统稳定性和优化资源利用方面具有不可替代的价值。

3、Docker 的典型应用场景

1. 微服务架构

  • 将单体应用拆分为多个独立服务,每个服务运行在自己的容器中。
  • 容器间通过定义良好的 API 通信,便于独立开发、部署和扩展。

2. 持续集成与持续部署(CI/CD)

  • 在 CI 流水线中构建 Docker 镜像,确保测试与生产环境一致。
  • 通过镜像版本管理实现快速回滚、灰度发布等 DevOps 实践。

3. 开发环境标准化

  • 团队成员使用相同的 Docker 镜像,避免“在我电脑上能跑”的问题。
  • 一键启动包含数据库、缓存、消息队列等依赖的完整开发栈。

4. 多环境一致性部署

  • 开发、测试、预发布、生产环境均使用同一镜像,消除环境差异。
  • 极大降低因配置漂移导致的故障风险。

5. 云原生与 Kubernetes 编排

  • Docker 是 Kubernetes 等容器编排平台的基础运行单元。
  • 支持弹性伸缩、服务发现、滚动更新等云原生能力。

6. 快速搭建临时环境

  • 用于演示、培训、测试或 PoC(概念验证),可秒级启动完整应用栈。
  • 使用后一键清理,不留残留。

4、Docker 的核心优势

优势说明
轻量高效容器共享宿主机内核,无需虚拟化完整操作系统,启动快(毫秒级)、资源占用低。
可移植性强镜像格式统一,可在任何支持 Docker 的平台(Linux、Windows、macOS、云服务器)运行。
环境一致性应用与其依赖打包在一起,彻底解决“依赖地狱”和环境不一致问题。
隔离性好每个容器拥有独立的文件系统、网络和进程空间,互不干扰。
标准化交付镜像作为标准交付物,简化从开发到运维的协作流程。
生态丰富拥有庞大的社区支持和官方/第三方镜像仓库(如 Docker Hub),涵盖主流软件和服务。
易于自动化与 Jenkins、GitLab CI、GitHub Actions 等工具无缝集成,支持自动化构建与部署。

5、基本概念

  1. 镜像(Image):Docker 镜像是一个只读的模板,包含了运行一个容器所需的所有文件系统和配置信息,如操作系统、应用程序及其依赖项等。它类似于虚拟机的镜像,但更轻量级,多个容器可以共享同一个镜像。
  2. 容器(Container):容器是基于镜像创建的运行实例,是镜像的运行时实体。容器之间相互隔离,每个容器都有自己独立的文件系统、进程空间等。容器可以被启动、停止、删除,是 Docker 实现应用部署和运行的基本单位。
  3. Dockerfile:文本文件,描述如何自动构建镜像(例如指定基础镜像、安装软件、复制文件等)。
  4. 仓库(Repository):仓库是用来存储镜像的地方,可以类比为代码的版本控制系统。Docker Hub 是 Docker 官方提供的公共仓库,用户可以在其中查找和下载各种公开的镜像,同时也可以将自己创建的镜像上传到 Docker Hub 或私有仓库中。私有仓库:企业内部搭建,用于存储私有镜像;官方仓库:由软件官方维护的镜像仓库,如 nginx、mysql。
  5. 卷(Volume)
    定义:Docker 提供的持久化存储机制,用于在容器生命周期之外保存数据。
    优势:独立于容器存在,支持跨容器共享,性能优于绑定挂载(bind mount)

6、Docker 与 VM(虚拟机)的差别

  1. 资源占用
    • VM:虚拟机需要为每个实例分配独立的操作系统、硬件资源(如 CPU、内存、磁盘等),资源占用较大。
    • Docker:容器共享宿主机的操作系统内核,只需要包含应用及其依赖项,资源占用小,能够在相同硬件条件下运行更多的实例。
  2. 启动速度
    • VM:启动一个虚拟机通常需要几十秒到几分钟不等,因为需要加载完整的操作系统。
    • Docker:容器启动速度非常快,通常在秒级,因为不需要启动完整的操作系统,只需启动应用进程。
  3. 隔离性
    • VM:虚拟机通过硬件虚拟化实现隔离,每个虚拟机拥有独立的操作系统和硬件资源,隔离性强,但性能开销也较大。
    • Docker:容器基于操作系统内核的 Namespace 和 Cgroups 技术实现隔离,在同一宿主机上的容器共享内核,隔离性相对较弱,但能满足大多数应用场景,且性能更好。

7、docker 架构

Docker 架构是基于客户端-服务器模式的,其中包括多个关键组件,确保容器化应用的高效构建、管理和运行。

Docker 的架构设计使得开发者能够轻松地将应用程序与其所有依赖封装在一个可移植的容器中,并在不同的环境中一致地运行。

docker 架构

  • Docker 客户端是用户与 Docker 守护进程交互的命令行界面(CLI)。它是用户与 Docker 系统的主要交互方式,用户通过 Docker CLI 发出命令,这些命令被发送到 Docker 守护进程,由守护进程执行相应的操作。
  • Docker 守护进程(通常是 dockerd)是 Docker 架构的核心,负责管理容器生命周期、构建镜像、分发镜像等任务。守护进程监听来自 Docker 客户端的请求,并且通过 Docker API 执行这些请求。守护进程将负责容器、镜像等 Docker 对象的管理,并根据请求的参数启动容器、删除容器、修改容器配置等。
  • Docker 引擎 API 是 Docker 提供的 RESTful 接口,允许外部客户端与 Docker 守护进程进行通信。通过这个 API,用户可以执行各种操作,如启动容器、构建镜像、查看容器状态等。API 提供了 HTTP 请求的接口,支持跨平台调用。
  • Docker Compose 是一个用于定义和运行多容器 Docker 应用的工具。通过 Compose,用户可以使用一个 docker-compose.yml 配置文件定义多个容器(服务),并可以通过一个命令启动这些容器。Docker Compose 主要用于开发、测试和部署多容器的应用。
  • Docker Swarm 是 Docker 提供的集群管理和调度工具。它允许将多个 Docker 主机(节点)组织成一个集群,并通过 Swarm 集群管理工具来调度和管理容器。Swarm 可以实现容器的负载均衡、高可用性和自动扩展等功能。
  • Docker 网络允许容器之间相互通信,并与外部世界进行连接。Docker 提供了多种网络模式来满足不同的需求,如 bridge 网络(默认)、host 网络和 overlay 网络等。
  • Docker 卷是一种数据持久化机制,允许数据在容器之间共享,并且独立于容器的生命周期。与容器文件系统不同,卷的内容不会随着容器的销毁而丢失,适用于数据库等需要持久存储的应用。

8、Docker Desktop

Docker 并非是一个通用的容器工具,它依赖于已存在并运行的 Linux 内核环境。

因此,Docker 必须部署在 Linux 内核的系统上。如果其他系统想部署 Docker 就必须安装一个虚拟 Linux 环境。

Docker 实质上是在已经运行的 Linux 下制造了一个隔离的文件环境,因此它执行的效率几乎等同于所部署的 Linux 主机。

Docker Desktop 是 Docker 官方推出的 本地容器化开发环境,用于在 macOS / Windows(以及部分 Linux) 上。

宿主系统(macOS / Windows)
 └── Docker Desktop
      └── Linux 虚拟机
           └── Docker Engine
                ├── Images
                ├── Containers
                └── Volumes

安装好后要配置镜像源,否则 docker pull 拉取会失败。




二、Docker安装

Docker 在 Linux 与 Windows 下的安装指南

Docker 支持在多种操作系统上运行,但其底层实现依赖于 Linux 内核特性(如 namespaces 和 cgroups)。因此,在 Linux 上可原生运行 Docker,而在 Windows 上则需借助虚拟化技术。以下是两种平台的详细安装方法。

1、Linux 下安装 Docker

以 Ubuntu/Debian 为例(其他发行版类似,参考 Docker 官方文档)。

1. 卸载旧版本(如有)
sudo apt remove docker docker-engine docker.io containerd runc

2. 安装必要依赖
sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release

3. 添加 Docker 官方 GPG 密钥
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

4. 设置稳定版仓库
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

5. 安装 Docker Engine
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

6. 验证安装
sudo docker run hello-world

7. (可选)免 sudo 使用 Docker
sudo usermod -aG docker $USER

2、Windows 下安装 Docker

1. 安装 WSL 2
wsl --install

2. 重启计算机

3. 下载 Docker Desktop
https://www.docker.com/products/docker-desktop

4. 运行安装程序并完成安装

5. 启动 Docker Desktop

6. 验证安装
docker --version
docker run hello-world


三、Docker 容器的使用

1、 获取镜像(Pull Image)

从 Docker Hub 或其他镜像仓库拉取镜像:
`docker pull nginx:latest`

2、 启动容器(Run Container)

前台运行(交互式)
`docker run -it ubuntu:22.04 /bin/bash`

后台运行(Detached Mode)

`docker run -d --name my-nginx nginx:latest`

常用选项说明
- `-d`:后台运行  
- `-it`:交互式终端(`-i` 保持 STDIN 打开,`-t` 分配伪终端)  
- `--name`:指定容器名称  
- `-p host_port:container_port`:端口映射,如 `-p 8080:80`  
- `-v host_path:container_path`:挂载卷,如 `-v /data:/app`

3、 停止容器(Stop Container)

停止正在运行的容器:
`docker stop my-nginx`

强制终止容器(相当于 kill):

`docker kill my-nginx`

4、 查看容器信息

列出所有容器(包括已停止的)
`docker ps -a`

列出正在运行的容器
`docker ps`

查看容器详细信息(JSON 格式)
`docker inspect my-nginx`

查看容器日志
`docker logs my-nginx`
>`-f` 可实时跟踪日志(类似 `tail -f`):  
> 
> `docker logs -f my-nginx`

5、 在运行中的容器中执行命令

在后台容器中执行命令(无需进入容器):

`docker exec -it my-nginx /bin/bash`

仅执行单条命令并返回结果:

`docker exec my-nginx ls /usr/share/nginx/html`

6、 容器的导入与导出

导出容器为 tar 文件(保存文件系统快照)

`docker export my-nginx > my-nginx.tar`tar 文件导入为新镜像

`cat my-nginx.tar | docker import - my-nginx:imported`

> 注意:`export/import` 仅保留文件系统,**不包含元数据**(如 CMD、EXPOSE 等)。若需完整镜像,请使用 `save/load`(见下文补充)。

(补充)镜像的保存与加载(推荐用于镜像迁移)

`docker save nginx:latest > nginx.tar`

`docker load < nginx.tar`

7、 删除容器

删除已停止的容器:

`docker rm my-nginx`

强制删除正在运行的容器(先 stop 再 rm):

`docker rm -f my-nginx`

批量删除所有已停止的容器:

`docker container prune`

四、docker镜像的使用

1、 查找可用镜像(Search Images)

在 Docker Hub 中搜索公共镜像:

`docker search nginx`

> 支持关键词过滤,例如:  

> `docker search --filter "is-official=true" ubuntu`

2、 列出本地镜像(List Images)

查看本地所有镜像:
`docker images`

或使用更现代的命令:

`docker image ls`

列出镜像的精简 ID:

`docker images -q`

3、 拉取镜像(Pull Image)

从仓库(默认 Docker Hub)拉取指定镜像:
`docker pull redis:7.0`

拉取最新版(等同于 `:latest`):

`docker pull redis`

从私有仓库拉取:

`docker pull myregistry.local:5000/myimage:tag`

4、 删除镜像(Remove Image)

删除指定镜像(需先停止并删除依赖该镜像的所有容器):
`docker rmi nginx:latest`

强制删除(即使有容器依赖):
`docker rmi -f nginx:latest`

批量删除无标签(<none>)镜像:
`docker image prune`

删除所有未被容器使用的镜像:
`docker image prune -a`

5、 构建镜像(Build Image)

基于当前目录下的 `Dockerfile` 构建镜像:
`docker build -t myapp:v1 .`

指定 Dockerfile 路径:

`docker build -f ./path/to/Dockerfile -t myapp:v1 .`

6、 设置/添加标签(Tagging)

为已有镜像创建新标签(不复制数据,仅创建引用):
`docker tag myapp:v1 myapp:latest`

为推送至私有仓库打标签:
`docker tag myapp:v1 registry.example.com/myapp:v1`

7、 更新镜像

Docker 本身**不提供“更新镜像”命令**,通常通过以下方式实现“更新”:

### 方法一:重新拉取最新版本

`docker pull nginx:latest`
> 注意:若本地已有同名同 tag 镜像,会覆盖其内容(实际是新增层,旧镜像变为 <none>)。

### 方法二:修改 Dockerfile 后重新构建
`docker build -t myapp:v2 .`

### 方法三:基于运行中容器提交为新镜像(不推荐用于生产)

`docker commit running-container myapp:updated`

8、 保存与加载镜像(用于迁移)

将镜像保存为 tar 文件:
`docker save nginx:latest > nginx.tar`tar 文件加载镜像:
`docker load < nginx.tar`

>`export/import`(针对容器)不同,`save/load` **保留完整镜像元数据**(如 ENTRYPOINT、ENV、标签等)。

五、docker容器连接

1、主机通过端口访问容器内服务

Docker 容器默认与宿主机网络隔离。若需从外部(如浏览器、其他主机)访问容器内运行的服务(如 Web 服务、数据库),必须通过 端口映射(Port Mapping) 将容器端口暴露到宿主机。

常见用法示例:
- 映射 TCP 端口(默认协议为 TCP):
`docker run -d -p 8080:80 nginx`

- 指定宿主机 IP(仅允许特定网卡访问):
`docker run -d -p 127.0.0.1:8080:80 nginx`

- 显式指定协议(TCP/UDP):
`cker run -d -p 53:53/udp dns-server`

`docker run -d -p 8080:80/tcp -p 9000:9000/udp myapp`

- 随机分配宿主机端口(仅指定容器端口):
`docker run -d -p 80 nginx`
-P(大写):自动映射所有暴露端口
  • 自动将容器中通过 EXPOSE 声明的端口随机映射到宿主机高位端口(32768–65535)
  • 仅适用于 Dockerfile 中使用了 EXPOSE 指令的镜像

示例:

假设镜像 Dockerfile 中有 EXPOSE 80 443
`docker run -d -P nginx`

实际效果等价于:
 `docker run -d -p 32769:80 -p 32770:443 nginx`
协议说明
- **默认协议是 TCP**,无需显式写出。
- 若需 UDP,必须显式指定 `/udp`。
- 同一容器端口可同时映射 TCP 和 UDP(需两条 `-p`):

`docker run -d -p 123:123/tcp -p 123:123/udp ntp-server`
查看容器对外暴露的端口
方法 1:使用 `docker ps`
方法 2:使用 `docker port`
查看指定容器的端口映射详情:
`docker port my-nginx`

方法 3:使用 `docker inspect`获取完整网络配置(含端口):
实际访问方式
假设容器运行 Web 服务(监听 `80` 端口),并执行:

`docker run -d --name web -p 8080:80 nginx`

则可通过以下方式访问:

- **本地访问**:`http://localhost:8080`
- **局域网其他设备访问**:`http://<宿主机IP>:8080`
- **仅限本机访问(安全限制)**:

`docker run -d -p 127.0.0.1:8080:80 nginx`
> 此时外部设备无法访问,仅本机可连
注意事项
  • 宿主机端口不能冲突(同一端口只能被一个服务占用)。
  • -p 可多次使用以映射多个端口。
  • 使用 -P 时,需确保 Dockerfile 中有 EXPOSE 指令,否则无端口被映射。
  • 生产环境建议明确使用 -p,避免随机端口带来的管理复杂性。

六、Docker 容器互联

1. 概念说明

Docker 容器互联(Container Linking / Networking)是指多个容器之间能够通过网络互相通信,例如 Web 应用容器连接数据库容器。

早期使用 --link(已弃用),现代推荐使用 自定义桥接网络(Custom Bridge Network),它支持:

  • 自动 DNS 解析(通过容器名)
  • 网络隔离
  • 更好的安全性和可维护性

2. 使用自定义桥接网络实现容器互联(推荐方式)

步骤 1:创建自定义桥接网络

`docker network create mynet`

> 默认驱动为 `bridge`,也可显式指定:  
> `docker network create --driver bridge mynet`

步骤 2:启动容器并加入同一网络

启动数据库容器:
`docker run -d --name db --network mynet redis:latest`

启动应用容器(自动可通过 `db` 域名访问数据库):
`docker run -d --name web --network mynet nginx`

步骤 3:验证容器间通信

进入 `web` 容器,测试是否能解析 `db` 并连通:
`docker exec -it web ping db`

或使用 `nslookup` 查看 DNS 解析:
`docker exec -it web nslookup db`

✅ 成功说明:Docker 内置 DNS 服务已将容器名 db 解析为其 IP 地址。

3. DNS 配置机制

在自定义桥接网络中,Docker 提供内置的 嵌入式 DNS 服务器(监听 127.0.0.11),行为如下:

  • 容器通过 容器名称–name 指定的名称 作为主机名进行解析。

  • 支持别名(Aliases):
    docker run -d --name app --network mynet --network-alias myapp --network-alias service1 nginx
    其他容器可通过 myappservice1 访问该容器。

  • /etc/hosts 文件不再动态更新(与旧版 --link 不同),全部依赖 DNS。

查看容器内 DNS 配置:
docker exec web cat /etc/resolv.conf
输出通常包含:
nameserver 127.0.0.11和 options ndots:0

不需要在宿主机额外配置 DNS 服务。Docker 容器内的 nameserver 127.0.0.11Docker 引擎内置的嵌入式 DNS 服务器,由 Docker 自动提供和管理,完全运行在容器网络命名空间内部,与宿主机的 DNS 配置无关。

. nameserver 127.0.0.11 是什么?

  • 这是 Docker 为每个加入自定义网络(如通过 docker network create 创建的 bridge 网络)的容器自动注入的 DNS 服务器地址。
  • 它是一个虚拟 IP,由 Docker 的网络子系统(libnetwork)实现,仅在容器内部有效
  • 功能包括:
    • 解析同一网络中的其他容器名网络别名(如 ping db → 解析为数据库容器 IP)
    • 若查询非容器域名(如 google.com),则自动转发到宿主机的 DNS 或 Docker 配置的上游 DNS

✅ 用户无需安装、启动或配置任何 DNS 服务,Docker 自动完成。

options ndots:0 的作用

这是 /etc/resolv.conf 中的一条 resolver 配置,用于控制 何时将域名视为“绝对域名”

默认行为(无 ndotsndots:1):

  • 当你查询 db 时,系统可能尝试先拼接搜索域(search domain),例如:db.mydomain.local,这可能导致延迟或错误解析。

设置 ndots:0 后:

  • 表示:只要域名中包含至少 0 个点(即所有域名)都直接作为绝对域名查询
  • 实际效果:跳过搜索域(search domain)拼接,直接向 DNS 服务器查询原始名称
举例说明:

在容器内执行:
ping db
有 ndots:0 → 直接查询 db(Docker 内部 DNS 立即响应)
无 ndots:0(如 ndots:1)→ 先尝试 db.default.svc.cluster.local(若在 Kubernetes 环境)或 db.,失败后才查 db,增加延迟
✅ 在 Docker 容器中设置 ndots:0 是为了确保容器名能被快速、准确地解析为内部服务,避免因系统默认搜索域导致解析失败或变慢。

因此,当你看到容器内 /etc/resolv.conf 包含:
nameserver 127.0.0.11 options ndots:0

这正是 Docker 为实现高效、可靠的服务发现而自动配置的标准行为,无需手动干预。

4. 多网络与跨网络通信

### 将已有容器加入新网络

`docker network connect mynet2 web`

### 从网络中断开容器
```bash
docker network disconnect mynet web`

> 容器可同时属于多个网络,但**不同网络之间默认不互通**(除非通过网关或路由配置)。

5. 实际示例:Web + Redis 架构

1. 创建网络
`docker network create app-network`

2. 启动 Redis
`docker run -d --name redis-db --network app-network redis:7-alpine`

3. 启动 Python 应用(假设镜像为 myapp)
`docker run -d --name myapp --network app-network -p 5000:5000 myapp`

4. 应用代码中可直接使用主机名 "redis-db" 连接 Redis
//示例(Python):
//`redis.Redis(host='redis-db', port=6379)`

6. 注意事项

  • 默认桥接网络(bridge)不支持 DNS 解析!只有自定义桥接网络才支持通过容器名通信。
  • 容器重启后 IP 可能变化,但DNS 名称始终有效
  • 生产环境中建议为每个应用创建独立网络,实现隔离。
  • 若需从宿主机访问容器服务,仍需使用 -p 映射端口;容器间通信无需 -p

七、Docker仓库管理

Docker 仓库(Registry)是用于存储和分发 Docker 镜像的服务。掌握 Docker 仓库管理对 DevOps、CI/CD 流程、微服务部署等至关重要。以下是关于 Docker 仓库管理的系统性总结,包括核心概念、常用命令、项目中的使用流程及操作实现。


1、核心概念

1. Docker Registry 类型

  • Docker Hub:官方公共仓库(https://hub.docker.com),支持公开/私有镜像。
  • 私有 Registry:企业内部自建,如使用 registry 官方镜像搭建。
  • 云厂商 Registry:如阿里云 ACR、AWS ECR、Google GCR、Azure ACR 等。

2. 镜像命名规范

[registry-host:port]/[namespace]/[image-name]:[tag]

示例:

  • nginx:latest → 默认从 Docker Hub 拉取
  • myregistry.local:5000/myapp:v1.0 → 从私有仓库拉取

2、常用命令

功能命令
登录仓库docker login [registry-url]
退出登录 docker logout [registry-url]
拉取镜像docker pull <image>
推送镜像docker push <image>
查看本地镜像docker images
打标签(重命名)docker tag <src> <target>
删除本地镜像docker rmi <image>
搜索镜像(仅限 Docker Hub)docker search <keyword>

注意:推送前必须确保目标镜像名包含目标仓库地址。


3、项目中的实际使用流程

典型 CI/CD 流程(以 GitLab CI + 私有 Registry 为例):

  1. 开发阶段

    • 开发者编写代码,本地构建测试镜像:
      docker build -t myapp:dev .
      
  2. CI 构建 & 推送

    • 提交代码触发 CI 流水线:
      • 构建镜像并打上版本标签(如 Git commit ID 或语义化版本)
      • 登录私有仓库
      • 推送镜像到仓库
      # .gitlab-ci.yml 示例
      build-and-push:
        script:
          - docker build -t registry.example.com/project/myapp:$CI_COMMIT_SHORT_SHA .
          - docker login -u $REGISTRY_USER -p $REGISTRY_PASS registry.example.com
          - docker push registry.example.com/project/myapp:$CI_COMMIT_SHORT_SHA
      
  3. CD 部署

    • 在 Kubernetes / Docker Swarm / ECS 等平台拉取指定镜像部署:
      # k8s deployment.yaml
      containers:
        - name: myapp
          image: registry.example.com/project/myapp:a1b2c3d
      
  4. 镜像生命周期管理

    • 定期清理旧镜像(通过 CI 脚本或 Registry 自带策略)
    • 使用语义化标签(如 v1.2.0, latest, staging)区分环境

4、私有 Registry 搭建与操作实现

1. 快速启动私有 Registry

docker run -d -p 5000:5000 --name registry registry:2

2. 推送镜像到私有 Registry

# 打标签
docker tag myapp:latest localhost:5000/myapp:v1

# 推送
docker push localhost:5000/myapp:v1

3. 支持 HTTPS(生产环境必需)

  • 使用 Let’s Encrypt 证书或自签名证书
  • 配置 Docker 客户端信任 insecure registry(仅测试):
    // /etc/docker/daemon.json
    {
      "insecure-registries": ["myregistry.local:5000"]
    }
    
    然后重启 Docker:systemctl restart docker

4. 镜像删除(Registry v2 不直接支持 delete)

需启用删除功能并调用 API:

# 启动时开启 delete
docker run -d -p 5000:5000 -e REGISTRY_STORAGE_DELETE_ENABLED=true registry:2

# 获取 digest
curl -I -H "Accept: application/vnd.docker.distribution.v2+json" \
  http://localhost:5000/v2/myapp/manifests/v1

# 删除
curl -X DELETE http://localhost:5000/v2/myapp/manifests/<digest>

注意:实际生产中建议使用 Harbor 等增强型 Registry,支持 UI、RBAC、漏洞扫描、镜像复制等。


5、最佳实践

  1. 使用语义化版本标签,避免滥用 latest
  2. 镜像瘦身:多阶段构建、使用 Alpine 基础镜像
  3. 安全
    • 私有仓库启用认证(如 htpasswd、OAuth、LDAP)
    • 定期扫描镜像漏洞(Trivy、Clair)
  4. 镜像不可变性:同一 tag 不应被覆盖(尤其生产环境)
  5. 镜像元数据:通过 LABEL 添加作者、构建时间、Git commit 等信息

6、扩展工具推荐

  • Harbor:CNCF 毕业项目,企业级 Registry
  • Nexus Repository / JFrog Artifactory:支持多格式制品(包括 Docker)
  • Skopeo:跨 Registry 镜像复制、检查(无需拉取到本地)
  • Docker Content Trust (DCT):镜像签名验证

通过以上知识体系,可高效、安全地在项目中管理 Docker 镜像生命周期,支撑现代化云原生应用交付。

7、如何学习

Docker 仓库管理听起来“高大上”,但核心操作其实很简单

🕒 学会要多久?

  • 基础使用(能干活):1~2 小时
    只需掌握:docker builddocker tagdocker push/pull + 登录仓库。
  • 熟练应用(项目实战):1~3 天
    结合 Git、CI/CD 工具(如 GitHub Actions)自动推镜像。
  • 高级管理(私有仓库/安全):1~2 周
    搭建私有仓库、权限控制、镜像清理等(多数人用云服务,不用自己搞)。

💡 90% 的开发者只需要前两个阶段!企业通常直接用 Docker Hub / 阿里云 ACR / AWS ECR 这类托管服务,根本不用自己搭 Registry。


极简学习路径(今天就能上手)

第一步:5 分钟搞定官方仓库(Docker Hub)
  1. 注册 Docker Hub 账号
  2. 本地操作:
# 1. 构建镜像(假设你有个 Dockerfile)
docker build -t 你的用户名/项目名:版本号 .

# 2. 登录
docker login

# 3. 推送到 Docker Hub
docker push 你的用户名/项目名:版本号

✅ 完成!别人可以用 docker pull 你的用户名/项目名:版本号 拉取你的镜像。

第二步:用云厂商私有仓库(更安全,推荐生产用)

阿里云容器镜像服务(ACR) 为例:

  1. 在阿里云控制台创建 命名空间镜像仓库
  2. 按页面提示操作(会自动生成命令):
# 登录阿里云仓库(密码是你的阿里云账号密码或令牌)
docker login --username=你的账号 registry.cn-hangzhou.aliyuncs.com

# 打标签(把本地镜像关联到阿里云仓库地址)
docker tag 本地镜像名 registry.cn-hangzhou.aliyuncs.com/命名空间/镜像名:版本

# 推送
docker push registry.cn-hangzhou.aliyuncs.com/命名空间/镜像名:版本

⚠️ 注意:把 registry.cn-hangzhou.aliyuncs.com 换成你实际的仓库地址(不同地域不同)。


🚫 你不需要立刻学这些(先跳过!)

  • 自己搭建私有 Registry(除非公司要求)
  • 镜像删除 API、Harbor 高级功能
  • Docker Content Trust 签名
  • 复杂的 CI/CD 集成(先手动推,再自动化)

💡 关键心态

  • 先跑通流程:哪怕只是把一个 nginx 镜像推到 Docker Hub,也算成功!
  • 遇到报错就查:90% 的问题都是 没登录镜像名没带仓库地址
  • 用云服务省心:阿里云/腾讯云/华为云都有免费额度的私有仓库,比自己搭简单 100 倍。

🌰 举个真实例子

假设你写了个 Python Web 应用:

  1. 写好 Dockerfile
  2. 本地测试:docker run -p 8000:8000 myapp
  3. 推到阿里云:
    docker tag myapp:latest registry.cn-shanghai.aliyuncs.com/myteam/myapp:v1
    docker push registry.cn-shanghai.aliyuncs.com/myteam/myapp:v1
    
  4. 服务器上部署:
    docker run registry.cn-shanghai.aliyuncs.com/myteam/myapp:v1
    

全程只需 4 条命令,10 分钟搞定!


总结:别被“仓库管理”这个词吓到,它本质就是“上传下载镜像”。先花 1 小时动手试一次,你就已经超过 50% 的人了!🚀




八、Dockerfile 学习与实际应用

Dockerfile 是 Docker 中用于定义镜像构建过程的文本文件,它包含一系列指令(instructions),每条指令描述如何一步步构建一个 Docker 镜像。掌握 Dockerfile 的编写是 DevOps、容器化部署和微服务架构中的基础技能。


1、Dockerfile 基础知识

1. 核心指令概览

指令说明
FROM指定基础镜像(必须是第一条非注释指令)
RUN构建时执行命令(创建新层)
CMD容器启动时默认执行的命令(可被 docker run 覆盖)
ENTRYPOINT容器主进程入口(与 CMD 配合使用,不易被覆盖)
COPY从宿主机复制文件/目录到镜像中
ADD类似 COPY,但支持自动解压 tar 和远程 URL(一般推荐用 COPY)
WORKDIR设置工作目录(后续指令如 RUN、CMD 等在此目录下执行)
ENV设置环境变量
EXPOSE声明容器运行时监听的端口(仅为文档用途,不实际发布端口)
VOLUME创建挂载点,用于持久化数据
USER指定运行容器的用户(默认 root)
ARG构建时传入的变量(仅在构建阶段有效)
LABEL为镜像添加元数据(如作者、版本等)
HEALTHCHECK定义容器健康检查方式
ONBUILD为子镜像设置触发指令(较少使用)

2. 构建上下文(Build Context)

  • docker build 命令会将指定目录(上下文)打包发送给 Docker 引擎。
  • 所有 COPY/ADD 操作只能引用上下文内的文件。
  • 最佳实践:使用 .dockerignore 排除无关文件(如 node_modules、.git、日志等)。

3. 分层机制与缓存

  • Docker 镜像由多个只读层组成,每条指令生成一层。
  • 构建时会利用缓存:如果某层未变,则后续层可复用缓存。
  • 优化建议
    • 将变化频率低的指令放在前面(如安装依赖)。
    • 合并频繁变动的小操作(如 apt update && apt install -y xxx 写在一行)。

4. 多阶段构建(Multi-stage Build)

适用于编译型语言(如 Go、Java、C++),减少最终镜像体积:

# 第一阶段:构建
FROM golang:1.22 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

# 第二阶段:运行
FROM alpine:latest
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]

这段内容是一个 多阶段 Dockerfile,用于构建和运行一个用 Go(Golang) 编写的程序。它利用了 Docker 的 多阶段构建(multi-stage build) 特性,目的是生成一个体积小、安全的最终镜像。下面逐行解析:

第一阶段:构建(Builder 阶段)

FROM golang:1.22 AS builder
  • 使用官方的 golang:1.22 镜像作为基础镜像。
  • 给这个构建阶段起一个别名 builder,以便后续引用。
WORKDIR /app
  • 在容器中设置工作目录为 /app
COPY . .
  • 将当前主机目录下的所有文件(包括源代码)复制到容器的 /app 目录中。
RUN go build -o myapp .
  • 在容器内执行 Go 编译命令,将当前目录(.)中的 Go 代码编译成名为 myapp 的可执行二进制文件。
  • 该二进制文件是静态链接的(Go 默认行为),不依赖外部 Go 环境。

第二阶段:运行(Runtime 阶段)

FROM alpine:latest
  • 使用轻量级的 alpine:latest 镜像作为最终运行环境的基础镜像(通常只有几 MB)。
  • Alpine Linux 是一个安全、轻量的 Linux 发行版,适合容器部署。
RUN apk --no-cache add ca-certificates
  • 安装 ca-certificates 包,确保程序在需要 HTTPS 请求时能验证 SSL/TLS 证书。
  • --no-cache 选项避免缓存包索引,减小镜像体积。
WORKDIR /root/
  • 设置工作目录为 /root/(也可以设为 /app 或其他路径,这里只是示例)。
COPY --from=builder /app/myapp .
  • 从第一阶段(别名为 builder)中复制编译好的二进制文件 /app/myapp 到当前阶段的当前目录(即 /root/)。
  • 这是多阶段构建的核心:只复制必要的产物,不包含 Go 编译器、源码等。
CMD ["./myapp"]
  • 指定容器启动时运行的命令:执行 ./myapp

总结优点

  • 镜像体积小:最终镜像基于 Alpine,仅包含运行所需二进制和证书,不含 Go 工具链。
  • 安全性高:没有源代码和开发工具暴露在生产镜像中。
  • 构建与运行分离:符合最佳实践,便于 CI/CD 流程管理。

⚠️ 注意:如果 Go 程序使用 CGO(如调用 C 库),则不能直接在 Alpine 上运行纯静态二进制,可能需要额外处理(如使用 scratch 镜像或确保动态库兼容)。但大多数纯 Go 程序默认是静态编译的,可安全运行于 Alpine。


2、Dockerfile 最佳实践

  1. 使用官方或可信的基础镜像

    • node:20-alpinepython:3.11-slim
    • 避免使用 latest 标签(不可控版本)
  2. 最小化镜像体积

    • 使用 Alpine 或 -slim 镜像
    • 清理临时文件(如 apt cleanrm -rf /var/lib/apt/lists/*
  3. 避免敏感信息硬编码

    • 不要在 Dockerfile 中写密码、密钥
    • 使用 --build-arg(谨慎)或运行时挂载 secret
  4. 明确指定用户

    • 避免以 root 运行应用:
      RUN adduser -D myuser
      USER myuser
      
  5. 合理使用 HEALTHCHECK

    HEALTHCHECK --interval=30s --timeout=3s \
      CMD curl -f http://localhost:8080/health || exit 1
    
  6. 标准化标签(LABEL)

    LABEL maintainer="dev@example.com"
    LABEL version="1.0.0"
    LABEL description="My web service"
    

3、实际工作中的典型场景

场景 1:Node.js 应用

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force
COPY . .
EXPOSE 3000
USER node
CMD ["node", "server.js"]

场景 2:Python Flask 应用(多阶段)

# 构建阶段
FROM python:3.11 AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt

# 运行阶段
FROM python:3.11-slim
WORKDIR /app
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
USER 1000
CMD ["gunicorn", "app:app"]

场景 3:前端 React 应用(Nginx 静态托管)

# 构建
FROM node:20 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 托管
FROM nginx:alpine
COPY --from=build /app/build /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf
EXPOSE 80

4、调试与优化技巧

  • 查看构建过程docker build -t myapp .
  • 进入中间层调试docker run -it <中间层ID> sh
  • 分析镜像大小docker history myimage 或使用 dive 工具
  • 安全扫描docker scan myimage(需 Docker Desktop 或 Snyk 集成)

5、常见误区

误区正确做法
在 Dockerfile 中使用绝对路径 COPY使用相对路径,确保在构建上下文中
多个 RUN 分开写导致缓存失效合并为单条 RUN(用 && 连接)
忽略 .dockerignore添加 .dockerignore 减少上下文体积
CMD 和 ENTRYPOINT 混淆理解两者差异:ENTRYPOINT 是主命令,CMD 是默认参数
在镜像中存储日志或状态数据使用 volume 或外部存储

总结

Dockerfile 是容器化的核心配置文件,其编写质量直接影响镜像的安全性、体积、可维护性和构建效率。在实际工作中,应遵循最小化原则、分层优化、多阶段构建等最佳实践,并结合 CI/CD 流程自动化构建与部署。

如需进一步深入,可学习:

  • BuildKit(Docker 新一代构建引擎,支持并行、secret mount 等)
  • Docker Compose 与 Dockerfile 协同
  • 镜像签名与 OCI 规范

九、CI/CD

CI/CD 是 持续集成(Continuous Integration)持续交付/持续部署(Continuous Delivery / Continuous Deployment) 的缩写,是现代软件开发中用于自动化构建、测试和发布流程的一套实践和工具链。它的核心目标是提高软件交付的速度、质量和可靠性


1、CI:持续集成(Continuous Integration)

定义
开发人员频繁地(通常每天多次)将代码变更合并到共享的主干(如 mainmaster 分支)中,并在每次合并后自动触发构建和测试

关键特点

  • 每次提交都自动运行单元测试、集成测试等。
  • 快速发现集成错误(“早发现问题,早修复”)。
  • 避免“集成地狱”(长时间分支开发后难以合并)。

示例流程

  1. 开发者推送代码到 Git 仓库。
  2. CI 系统(如 GitHub Actions、GitLab CI、Jenkins)自动拉取代码。
  3. 自动运行 go buildgo test 等命令。
  4. 如果测试失败,立即通知开发者。

2、CD:持续交付 / 持续部署(Continuous Delivery / Deployment)

✅ 持续交付(Continuous Delivery)
  • 每次通过 CI 的代码变更都会被自动构建、测试并打包成可部署的版本
  • 但部署到生产环境需要人工批准(例如点击“上线”按钮)。
  • 目标:随时可以安全地发布新版本
🚀 持续部署(Continuous Deployment)
  • 在持续交付的基础上更进一步:所有通过测试的变更自动部署到生产环境,无需人工干预。
  • 要求有非常完善的自动化测试和监控机制。

💡 简单区分:

  • 持续交付 = 自动准备 + 手动发布
  • 持续部署 = 全自动发布

3、CI/CD 的典型流程(以 Web 应用为例)

测试通过

持续交付

持续部署

开发者提交代码

Git 仓库

CI 系统触发

自动构建 Docker 镜像

运行自动化测试

推送到镜像仓库

CD 阶段

等待人工确认部署

自动部署到生产环境


4、常用 CI/CD 工具

类型工具示例
云原生GitHub Actions, GitLab CI/CD, Bitbucket Pipelines
自托管Jenkins, Drone, Tekton
企业级CircleCI, Travis CI, Azure DevOps
Kubernetes 集成Argo CD(侧重 GitOps 部署)

5、为什么需要 CI/CD?

  • ✅ 减少人为操作错误
  • ✅ 加快发布频率(从几周一次到每天多次)
  • ✅ 提高代码质量(自动化测试保障)
  • ✅ 快速回滚(如果新版本出问题)
  • ✅ 团队协作更高效(标准化流程)

6、与之前 Dockerfile 的联系

你之前看到的多阶段 Dockerfile,通常就是 CI/CD 流程中的构建步骤的一部分。例如:

# GitHub Actions 示例片段
- name: Build and push Docker image
  run: |
    docker build -t myapp .
    docker push myapp

这个 docker build 就会使用你写的那个多阶段 Dockerfile,生成一个轻量、安全的生产镜像,然后由 CD 阶段部署到服务器或 Kubernetes 集群。

总结一句话
CI/CD 是让“写代码 → 测试 → 上线”全过程自动化、可靠、快速的工程实践。




十、Docker Compose

Docker Compose 是 Docker 官方提供的一个用于定义和运行多容器 Docker 应用程序的工具。通过一个 YAML 文件(通常命名为 docker-compose.yml),你可以配置应用程序所需的所有服务(如 Web 服务器、数据库、缓存等),然后使用一条命令即可启动或停止整个应用栈。


1、Docker Compose 的核心概念

  • 服务(Service):一个应用的组成部分,例如一个 Web 应用、一个数据库。每个服务对应一个容器。
  • 项目(Project):由多个服务组成的一组容器,默认以目录名作为项目名。
  • Compose 文件(docker-compose.yml):YAML 格式的配置文件,描述了所有服务及其依赖关系、网络、卷等。

2、安装 Docker Compose

大多数现代 Docker Desktop(Windows/macOS)已内置 Compose。Linux 用户可单独安装:

sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

验证安装:

docker-compose --version

注意:Docker Compose v2 已集成到 Docker CLI 中,可直接使用 docker compose(无连字符)命令。


3、基本语法示例(docker-compose.yml)

version: '3.8'

services:
  web:
    build: .
    ports:
      - "5000:5000"
    volumes:
      - .:/app
    depends_on:
      - db
    environment:
      - DATABASE_URL=postgresql://user:pass@db:5432/mydb

  db:
    image: postgres:15
    environment:
      POSTGRES_DB: mydb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: pass
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

说明:

  • web 服务从当前目录构建镜像(Dockerfile 需存在)。
  • db 服务使用官方 PostgreSQL 镜像。
  • volumes 实现数据持久化。
  • depends_on 表示启动顺序(但不等待服务就绪)。
  • 环境变量用于配置连接信息。

4、在实际项目中如何使用 Docker Compose

场景:开发一个 Python Flask + PostgreSQL 应用

1. 项目结构
my-flask-app/
├── app.py
├── requirements.txt
├── Dockerfile
└── docker-compose.yml
2. 编写 Dockerfile(用于构建 web 服务)
FROM python:3.11-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt

COPY . .

CMD ["python", "app.py"]
3. 编写 docker-compose.yml(如上所示)
4. 启动项目
docker compose up --build
  • --build:强制重新构建镜像(首次或代码变更时需要)
  • 默认前台运行;加 -d 可后台运行:docker compose up -d
5. 常用命令
命令作用
docker compose up启动所有服务
docker compose down停止并删除容器、网络(默认不删卷)
docker compose logs -f web查看 web 服务日志
docker compose exec db psql -U user mydb进入数据库容器执行命令
docker compose build仅构建镜像

5、生产环境 vs 开发环境

虽然 Compose 主要用于本地开发和测试,但也可用于简单部署(如小型项目、CI/CD 测试环境)。对于复杂生产环境,建议结合 Kubernetes 或使用 Docker Swarm。

可通过多个 Compose 文件覆盖配置:

docker compose -f docker-compose.yml -f docker-compose.prod.yml up

例如 docker-compose.prod.yml 可关闭 volume 挂载、启用 HTTPS、调整资源限制等。


6、最佳实践

  1. 不要在 Compose 中硬编码敏感信息 → 使用 .env 文件或 secrets。
  2. 合理使用 volumes → 避免数据丢失(尤其是数据库)。
  3. 健康检查(healthcheck) → 确保服务真正就绪后再启动依赖服务。
  4. 版本控制 Compose 文件 → 便于团队协作。
  5. 使用 .dockerignore → 避免不必要的文件传入构建上下文。

7、总结

Docker Compose 极大简化了多容器应用的本地开发流程。它让开发者只需关注业务逻辑,而无需手动管理多个容器的启动顺序、网络连接和配置。在微服务架构日益普及的今天,掌握 Compose 是现代开发者的基本技能之一。

如果你有具体项目场景(如 Laravel + MySQL + Redis、Node.js + MongoDB 等),我可以提供针对性的 docker-compose.yml 示例。

十一、文件覆盖

“文件覆盖配置” 在 Docker Compose 中的含义、作用和使用场景。

1、“文件覆盖配置”是什么意思?

在 Docker Compose 中,“文件覆盖配置” 指的是:

通过多个 docker-compose.yml 文件叠加(merge)的方式,动态组合出最终的完整配置。

Docker Compose 支持同时指定多个 YAML 配置文件,后面的文件会覆盖或补充前面文件中的配置项。

命令示例:

docker compose -f docker-compose.yml -f docker-compose.override.yml up
  • -f 表示指定一个 Compose 文件。
  • 多个 -f 按从左到右的顺序合并。
  • 后面的文件可以:
    • 覆盖已有字段(如修改端口、环境变量)
    • 新增服务或配置(如添加调试工具)

💡 默认情况下,如果你只运行 docker compose up,Compose 会自动加载当前目录下的:

  • docker-compose.yml
  • 以及 docker-compose.override.yml(如果存在)

所以 override 文件是“隐式自动加载”的覆盖文件。


2、为什么要覆盖配置?——核心目的

✅ 1. 区分环境(开发 / 测试 / 生产)

这是最常见的原因。

  • 基础配置docker-compose.yml):定义所有环境共用的部分(如服务结构、镜像名称)。
  • 覆盖配置(如 docker-compose.prod.yml):仅包含生产环境特有的设置(如关闭调试、绑定真实域名、不挂载代码卷)。
示例对比:

docker-compose.yml(通用)

services:
  web:
    build: .
    ports:
      - "5000"
    environment:
      DB_HOST: db

docker-compose.override.yml(开发用,默认加载)

services:
  web:
    ports:
      - "5000:5000"   # 开发时暴露端口到宿主机
    volumes:
      - .:/app        # 挂载源码,支持热更新
    environment:
      DEBUG: "true"

docker-compose.prod.yml(生产用,手动指定)

services:
  web:
    ports:
      - "80:5000"     # 生产监听 80 端口
    # 不挂载卷(使用构建好的镜像)
    environment:
      DEBUG: "false"
      SECRET_KEY: ${SECRET_KEY}

这样,同一套代码,只需切换 Compose 文件,就能适配不同环境。


✅ 2. 团队协作:个性化开发配置

每个开发者可能有不同的本地设置(如端口冲突、数据库密码不同)。

  • 公共配置放在 docker-compose.yml
  • 个人配置放在 docker-compose.override.yml不提交到 Git
  • 通过 .gitignore 忽略 docker-compose.override.yml

这样既共享基础结构,又允许个性化。


✅ 3. 临时调试或测试

比如临时加一个监控工具(如 adminerredisinsight):

docker compose -f docker-compose.yml -f debug-tools.yml up

debug-tools.yml 只定义额外服务,不影响主配置。


3、覆盖规则(合并逻辑)

Docker Compose 的合并遵循以下原则:

类型行为
标量值(字符串、数字)后面的文件覆盖前面的
列表(如 ports, volumes后面的文件替换整个列表(不是追加!)
字典(如 environment合并键值对,相同 key 被覆盖

⚠️ 注意:portsvolumes整体替换,不是追加。
如果想保留原有端口并新增,必须在覆盖文件中重新写全所有端口


4、最佳实践建议

  1. 基础配置docker-compose.yml(提交到 Git)
  2. 开发默认覆盖docker-compose.override.yml(通常不提交)
  3. 生产/测试专用docker-compose.prod.ymldocker-compose.test.yml(提交)
  4. 使用 .env 文件配合变量(如 ${DB_PASSWORD}),避免硬编码
  5. 文档化不同环境的启动命令,例如在 MakefileREADME.md 中写明:
dev:
	docker compose up

prod:
	docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

总结

问题回答
什么是文件覆盖配置?用多个 YAML 文件叠加生成最终配置,后文件可覆盖前文件内容
配置是谁的?Docker Compose 中定义的服务运行参数(端口、环境、卷等)
为什么要覆盖?实现环境隔离(开发/生产)、个性化配置、临时调试,提升灵活性和安全性

通过合理使用覆盖机制,你可以用一套代码、多套配置,轻松应对各种部署场景。

十二、Swarm 集群管理

太长了,单开一篇
Docker Swarm

Logo

码道开发者社区,聚焦华为云码道 CodeArts 代码智能体,沉淀 Agent、Skill、鸿蒙开发实战内容,供开发者查阅资料、交流技术、分享工程实践

更多推荐