mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-08-10 16:37:34 +00:00
Add new content and update versions
This commit is contained in:
yeasy
@@ -2,7 +2,9 @@
|
||||
|
||||
本节将通过一个简单的 Web 应用例子，带你快速体验 Docker 的核心流程：构建镜像、运行容器。
|
||||
|
||||
在学习 Docker 之前，我们先来理解为什么这个例子适合初学者。Docker 的核心价值在于 **一致性交付**：无论你在本地、云端还是他人的机器上运行容器，应用的行为都应该保持一致。这个 Nginx + 静态 HTML 的例子之所以被广泛采用，是因为它展现了 Docker 工作流的三个核心阶段：
|
||||
### 为什么选择 Nginx + HTML 作为入门例子？
|
||||
|
||||
在学习 Docker 之前，我们先来理解为什么这个例子是最适合初学者的。Docker 的核心价值在于**一致性交付**——无论你在本地、云端还是他人的机器上运行容器，应用的行为都是完全一致的。这个 Nginx + 静态 HTML 的例子之所以被广泛采用，是因为它展现了 Docker 工作流的三个核心阶段：
|
||||
|
||||
1. **镜像定义（Image Layer）**：通过 Dockerfile 描述如何把应用打包成一个自包含的单元
|
||||
2. **镜像构建（Build）**：执行 `docker build`，Docker 根据 Dockerfile 逐层构建镜像
|
||||
@@ -27,8 +29,6 @@ FROM nginx:alpine
|
||||
COPY index.html /usr/share/nginx/html/index.html
|
||||
```
|
||||
|
||||
这里的 `/usr/share/nginx/html/` 是 Nginx 官方镜像默认提供静态页面的目录。把 `index.html` 复制到这个位置后，Nginx 启动时就会直接对外提供该页面，因此这个例子能把“准备文件 -> 打包镜像 -> 启动服务”的最短路径展示得很清楚。
|
||||
|
||||
### 1.1.3 构建镜像
|
||||
|
||||
打开终端，进入该目录，执行构建命令：
|
||||
|
||||
@@ -79,7 +79,9 @@ Docker 使用 [Go 语言](https://golang.google.cn/)开发，基于 Linux 内核
|
||||
|
||||
> 如果你对这些底层技术感兴趣，可以阅读本书的[底层实现](../12_implementation/README.md)章节。
|
||||
|
||||
**Docker 架构演进**：Docker 的底层实现经历了多次演进：
|
||||
#### Docker 架构演进
|
||||
|
||||
Docker 的底层实现经历了多次演进：
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
@@ -104,13 +106,13 @@ flowchart LR
|
||||
|
||||
### 1.2.5 Docker 的历史与生态
|
||||
|
||||
**Docker** 最初是 `dotCloud` 公司创始人 [Solomon Hykes](https://github.com/shykes) 发起的一个公司内部项目，于 [2013 年 3 月以 Apache 2.0 授权协议开源](https://en.wikipedia.org/wiki/Docker_%28software%29)。
|
||||
**Docker** 最初是 `dotCloud` 公司创始人 [Solomon Hykes](https://github.com/shykes) 在法国期间发起的一个公司内部项目，于 [2013 年 3 月以 Apache 2.0 授权协议开源](https://en.wikipedia.org/wiki/Docker_%28software%29)。
|
||||
|
||||
Docker 的发展历程：
|
||||
|
||||
- **2013 年 3 月**：开源发布
|
||||
- **2013 年底**：dotCloud 公司改名为 Docker，Inc。
|
||||
- **2015 年**：成立[开放容器联盟 (OCI)](https://opencontainers.org/)，推动容器标准化
|
||||
- **截至 2026 年 4 月**：[GitHub 项目](https://github.com/moby/moby)超过 7 万星标
|
||||
- **至今**：[GitHub 项目](https://github.com/moby/moby)超过 7 万星标
|
||||
|
||||
Docker 的成功推动了整个容器生态的发展，催生了 Kubernetes、Podman 等众多相关项目。笔者认为，Docker 最大的贡献不仅是技术本身，更是它 **让容器技术从系统管理员的工具变成了每个开发者都能使用的标准工具**。
|
||||
|
||||
+12
-10
@@ -45,7 +45,9 @@
|
||||
|
||||
### 1.3.2 Docker 如何解决这些问题
|
||||
|
||||
Docker 的出现为上述问题提供了系统性的解决方案。它通过 “一次构建，到处运行” 的核心理念，从根本上改变了软件交付的方式。
|
||||
Docker 的出现为上述问题提供了完美的解决方案。它通过 “一次构建，到处运行” 的核心理念，从根本上改变了软件交付的方式。
|
||||
|
||||
#### 核心理念：一次构建，到处运行
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
@@ -99,27 +101,27 @@ $ docker compose up
|
||||
#### 3. 资源效率
|
||||
|
||||
Docker 容器共享宿主机内核，无需为每个应用运行完整的操作系统。以一台 64GB 内存的物理服务器为例：
|
||||
- **传统虚拟机方案**：每个虚拟机都需要额外运行一套完整操作系统，会带来持续的基础资源开销；随着实例数增加，可真正分配给业务进程的内存会被不断压缩。
|
||||
- **Docker 方案**：容器直接共享宿主机系统，只保留宿主机和容器引擎的基础开销，因此通常能把更多内存留给实际业务负载。
|
||||
- **传统虚拟机方案**：每个虚拟机都需要运行完整的操作系统（每个额外占用如 2GB 内存），产生大量资源开销，实际可用于应用的内存可能只有约 18GB。
|
||||
- **Docker 方案**：容器直接共享宿主机系统，只需付出很少的基础开销（OS 及引擎约 4GB），即可将约 60GB 的内存全部用于实际应用。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph VM ["传统虚拟机方案 ❌"]
|
||||
direction TB
|
||||
Server1["物理服务器 (64GB 内存)"]
|
||||
subgraph VMs ["可用应用内存: 较少"]
|
||||
subgraph VMs ["可用应用内存: 约 18GB"]
|
||||
direction LR
|
||||
VM1["VM 1: 应用 1<br/>(含独立 OS 开销)"]
|
||||
VM2["VM 2: 应用 2<br/>(含独立 OS 开销)"]
|
||||
VM3["VM 3: 应用 3<br/>(含独立 OS 开销)"]
|
||||
VM1["VM 1: 应用 1<br/>(含 2GB OS)"]
|
||||
VM2["VM 2: 应用 2<br/>(含 2GB OS)"]
|
||||
VM3["VM 3: 应用 3<br/>(含 2GB OS)"]
|
||||
end
|
||||
Server1 --- VMs
|
||||
end
|
||||
|
||||
subgraph Docker ["Docker 方案 ✅"]
|
||||
direction TB
|
||||
Server2["物理服务器 (64GB 内存)<br/>含宿主 OS 与引擎基础开销"]
|
||||
subgraph Containers ["可用应用内存: 更多"]
|
||||
Server2["物理服务器 (64GB 内存)<br/>含约 4GB OS及引擎配置"]
|
||||
subgraph Containers ["可用应用内存: 约 60GB"]
|
||||
direction LR
|
||||
C1["容器 1: 应用 1<br/>(按需分配)"]
|
||||
C2["容器 2: 应用 2<br/>(按需分配)"]
|
||||
@@ -158,7 +160,7 @@ Docker 可以在几乎任何平台上运行：
|
||||
|
||||
#### 6. 微服务架构的基石
|
||||
|
||||
现代微服务实践大量采用容器技术作为交付基础。Docker 让你可以先把每个服务标准化封装；而在更大规模场景下，通常还需要配合编排、服务发现、网络治理和可观测性体系一起落地：
|
||||
现代微服务架构几乎都依赖容器技术。Docker 让你可以：
|
||||
|
||||
- **隔离服务**：每个服务运行在独立容器中，互不干扰
|
||||
- **独立扩展**：哪个服务负载高，就单独扩展哪个
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
本章将带领你进入 **Docker** 的世界。
|
||||
|
||||
> **版本提示**：本书内容及示例基于 **Docker Engine v29.x** 及以上版本。自 Docker Engine v29 起，全新安装默认启用 `containerd image store` 作为镜像存储后端；这意味着后续涉及多架构镜像、本地镜像元数据和供应链安全能力的章节，会以这一路径为背景展开说明。
|
||||
> **版本提示**：本书内容及示例基于 **Docker Engine v29.x** 及以上版本。值得注意的是，自 Docker Engine v29 起，官方在全新安装场景下 **默认启用 `containerd image store` 作为镜像存储后端**（取代传统 classic store 路径下的 graph driver 体系）。这项底层革新极大增强了 Docker 对多架构镜像（Multi-platform）以及软件供应链安全元数据（Attestations, SBOM, Provenance）的本地支持原生性。
|
||||
|
||||
## 本章内容
|
||||
|
||||
|
||||
Reference in New Issue
Block a user