mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-08-10 08:27:25 +00:00
Update Grafana to v13, add version notes
This commit is contained in:
yeasy
@@ -10,6 +10,8 @@
|
||||
|
||||
比如我们想要创建一个 [OpenVZ](https://openvz.org) 的 Ubuntu 16.04 [模板](https://wiki.openvz.org/Download/template/precreated)的镜像：
|
||||
|
||||
> **版本提示**：示例中的 Ubuntu 16.04 (Xenial) 已于 2021 年 4 月停止支持。如果用于生产环境，建议更新至 Ubuntu 22.04 LTS 或更新版本。
|
||||
|
||||
```bash
|
||||
$ docker import \
|
||||
http://download.openvz.org/template/precreated/ubuntu-16.04-x86_64.tar.gz \
|
||||
@@ -50,6 +52,8 @@ $ docker image ls alpine
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
alpine latest baa5d63471ea 5 weeks ago 4.803 MB
|
||||
```
|
||||
|
||||
> **版本提示**：`alpine:latest` 为最新版本的 Alpine Linux。如果需要特定版本号（如 `alpine:3.20`），可以明确指定以确保可重现性。
|
||||
保存镜像的命令为：
|
||||
|
||||
```bash
|
||||
|
||||
@@ -60,6 +60,8 @@ Docker 镜像的每一层都有一个唯一的 ID，这个 ID 是根据该层的
|
||||
|
||||
Docker 使用联合文件系统 (Union FS) 与写时复制思路来实现这种分层挂载。传统的实现方式常见于 `overlay2`、`aufs`、`btrfs`、`zfs` 等存储驱动；而在 Docker Engine 29.0 及之后的全新安装中，默认镜像后端已经变为 containerd image store，它使用 snapshotter 来管理这些层。
|
||||
|
||||
> **版本背景**：Docker Engine 29.0（发布于 2024 年 2 月）是一个重要版本分界点，引入了 containerd image store 作为默认镜像存储后端。这对镜像管理、OCI 合规性和供应链安全都有深远影响。如果你的 Docker 版本低于 29.0，镜像存储仍使用传统的 classic store 路径。
|
||||
|
||||
虽然底层实现细节不同，但它们都遵循上述的 **分层 + CoW** 模型；因此，无论你看到的是 `overlay2` 还是 containerd snapshotter，理解镜像层、容器层和写时复制的方式都是一样重要的。
|
||||
|
||||
> 想要深入了解 Overlay2 等文件系统的具体实现原理，包括 WorkDir、UpperDir、LowerDir 等底层细节，请阅读 **[第十二章 底层实现](../12_implementation/README.md)** 中的 **[联合文件系统](../12_implementation/12.4_ufs.md)** 章节。
|
||||
|
||||
+18
-16
@@ -29,6 +29,8 @@ Hello world
|
||||
```
|
||||
这与直接执行 `/bin/echo 'Hello world'` 几乎没有区别，但实际上已经启动了一个完整的 Ubuntu 容器来执行这条命令。
|
||||
|
||||
> **版本说明**：示例使用 `ubuntu:24.04`，这是最新 LTS 版本。如需其他版本，可替换为 `ubuntu:22.04`、`ubuntu:20.04` 等。
|
||||
|
||||
#### 交互式容器
|
||||
|
||||
启动一个可以交互的 bash 终端：
|
||||
@@ -82,25 +84,25 @@ flowchart TD
|
||||
|
||||
| 选项 | 说明 | 示例 |
|
||||
|------|------|------|
|
||||
| `-d` | 后台运行 (detach)| `docker run -d nginx` |
|
||||
| `-it` | 交互式终端 | `docker run -it ubuntu bash` |
|
||||
| `--name` | 指定容器名称 | `docker run --name myapp nginx` |
|
||||
| `--rm` | 退出后自动删除容器 | `docker run --rm ubuntu echo hi` |
|
||||
| `-d` | 后台运行 (detach)| `docker run -d nginx:latest` |
|
||||
| `-it` | 交互式终端 | `docker run -it ubuntu:24.04 bash` |
|
||||
| `--name` | 指定容器名称 | `docker run --name myapp nginx:latest` |
|
||||
| `--rm` | 退出后自动删除容器 | `docker run --rm ubuntu:24.04 echo hi` |
|
||||
|
||||
#### 端口映射
|
||||
|
||||
```bash
|
||||
## 将容器的 80 端口映射到宿主机的 8080 端口
|
||||
|
||||
$ docker run -d -p 8080:80 nginx
|
||||
$ docker run -d -p 8080:80 nginx:latest
|
||||
|
||||
## 随机映射端口
|
||||
|
||||
$ docker run -d -P nginx
|
||||
$ docker run -d -P nginx:latest
|
||||
|
||||
## 只绑定到 localhost
|
||||
|
||||
$ docker run -d -p 127.0.0.1:8080:80 nginx
|
||||
$ docker run -d -p 127.0.0.1:8080:80 nginx:latest
|
||||
```
|
||||
|
||||
#### 数据卷挂载
|
||||
@@ -108,15 +110,15 @@ $ docker run -d -p 127.0.0.1:8080:80 nginx
|
||||
```bash
|
||||
## 挂载命名卷
|
||||
|
||||
$ docker run -v mydata:/data nginx
|
||||
$ docker run -v mydata:/data nginx:latest
|
||||
|
||||
## 挂载宿主机目录
|
||||
|
||||
$ docker run -v /host/path:/container/path nginx
|
||||
$ docker run -v /host/path:/container/path nginx:latest
|
||||
|
||||
## 只读挂载
|
||||
|
||||
$ docker run -v /host/path:/container/path:ro nginx
|
||||
$ docker run -v /host/path:/container/path:ro nginx:latest
|
||||
```
|
||||
|
||||
#### 环境变量
|
||||
@@ -136,11 +138,11 @@ $ docker run --env-file .env myapp
|
||||
```bash
|
||||
## 限制内存
|
||||
|
||||
$ docker run -m 512m nginx
|
||||
$ docker run -m 512m nginx:latest
|
||||
|
||||
## 限制 CPU
|
||||
|
||||
$ docker run --cpus=1.5 nginx
|
||||
$ docker run --cpus=1.5 nginx:latest
|
||||
```
|
||||
|
||||
### 5.1.5 启动已终止容器
|
||||
@@ -186,11 +188,11 @@ root@ba267838cc1b:/# ps
|
||||
```bash
|
||||
## 这个容器会立即退出（echo 执行完就结束了）
|
||||
|
||||
$ docker run ubuntu echo "hello"
|
||||
$ docker run ubuntu:24.04 echo "hello"
|
||||
|
||||
## 解决：使用能持续运行的命令
|
||||
|
||||
$ docker run -d nginx # nginx 是持续运行的服务
|
||||
$ docker run -d nginx:latest # nginx 是持续运行的服务
|
||||
```
|
||||
详细解释见[后台运行](5.2_daemon.md)。
|
||||
|
||||
@@ -201,11 +203,11 @@ $ docker run -d nginx # nginx 是持续运行的服务
|
||||
```bash
|
||||
## 错误：没有 -p 参数，外部无法访问
|
||||
|
||||
$ docker run -d nginx
|
||||
$ docker run -d nginx:latest
|
||||
|
||||
## 正确：映射端口
|
||||
|
||||
$ docker run -d -p 80:80 nginx
|
||||
$ docker run -d -p 80:80 nginx:latest
|
||||
```
|
||||
|
||||
#### Q：容器内修改的文件丢失
|
||||
|
||||
@@ -122,17 +122,19 @@ $ docker container ls -a
|
||||
```bash
|
||||
## Web 服务器
|
||||
|
||||
$ docker run -d -p 80:80 nginx
|
||||
$ docker run -d -p 80:80 nginx:latest
|
||||
|
||||
## 数据库
|
||||
|
||||
$ docker run -d -p 3306:3306 mysql:8
|
||||
$ docker run -d -p 3306:3306 mysql:8.0
|
||||
|
||||
## 缓存服务
|
||||
|
||||
$ docker run -d -p 6379:6379 redis
|
||||
$ docker run -d -p 6379:6379 redis:latest
|
||||
```
|
||||
|
||||
> **版本说明**：示例使用常见的标签如 `latest` 或稳定大版本号如 `mysql:8.0`。具体版本可根据需求调整，生产环境建议明确指定版本号（如 `mysql:8.0.35`）而非使用 `latest`。
|
||||
|
||||
#### 2. 调试时先用前台模式
|
||||
|
||||
当容器启动有问题时，**去掉 `-d` 参数** 可以直接看到输出和错误：
|
||||
@@ -140,7 +142,7 @@ $ docker run -d -p 6379:6379 redis
|
||||
```bash
|
||||
## 有问题的容器，先前台运行看看发生了什么
|
||||
|
||||
$ docker run myimage:latest
|
||||
$ docker run myimage:v1.0.0
|
||||
```
|
||||
|
||||
#### 3. 使用 --rm 自动清理
|
||||
@@ -161,7 +163,7 @@ Hello, World!
|
||||
```bash
|
||||
## 后台启动
|
||||
|
||||
$ docker run -d --name myapp myimage:latest
|
||||
$ docker run -d --name myapp myimage:v1.0.0
|
||||
|
||||
## 查看最近 100 行日志
|
||||
|
||||
@@ -194,7 +196,7 @@ $ docker logs -t myapp
|
||||
|
||||
3. **以交互模式调试**：
|
||||
```bash
|
||||
$ docker run -it myimage:latest /bin/sh
|
||||
$ docker run -it myimage:v1.0.0 /bin/sh
|
||||
# 进入容器手动执行命令，查找问题
|
||||
|
||||
```
|
||||
|
||||
@@ -204,7 +204,7 @@ $ docker stop $(docker ps -q) && docker container prune -f
|
||||
```dockerfile
|
||||
## Dockerfile 示例
|
||||
|
||||
FROM node:22
|
||||
FROM node:22-alpine
|
||||
...
|
||||
|
||||
## 使用 exec 形式确保信号能传递给 node 进程
|
||||
@@ -212,6 +212,8 @@ FROM node:22
|
||||
CMD ["node", "server.js"]
|
||||
```
|
||||
|
||||
> **版本说明**：示例使用 `node:22-alpine`，这是一个精简的 Node.js 22 版本镜像。可根据需求替换为其他版本（如 `node:20-alpine`、`node:latest`）。
|
||||
|
||||
#### Q：容器无法停止
|
||||
|
||||
```bash
|
||||
|
||||
@@ -13,6 +13,8 @@ $ docker export 7691a814370e > ubuntu.tar
|
||||
```
|
||||
这样将导出容器快照到本地文件。
|
||||
|
||||
> **版本说明**：导出的容器快照不包含镜像版本历史，导入时可以自定义标签和版本号。
|
||||
|
||||
### 5.5.2 导入容器快照
|
||||
|
||||
可以使用 `docker import` 从容器快照文件中再导入为镜像，例如
|
||||
|
||||
@@ -6,6 +6,16 @@
|
||||
|
||||
本章将具体介绍如何来管理一个容器，包括创建、启动和停止等。
|
||||
|
||||
## 版本号说明
|
||||
|
||||
本章示例涉及多个 Docker 镜像，遵循以下版本号最佳实践：
|
||||
|
||||
- **官方镜像**（如 `ubuntu`、`nginx`、`mysql`）：使用具体大版本号（如 `ubuntu:24.04`、`mysql:8.0`）而非 `latest`，确保示例的可重复性
|
||||
- **镜像标签约定**：
|
||||
- `latest` 或 `v1.0.0` 等：带标签的自定义镜像，示例中指定具体版本
|
||||
- `24.04`、`8.0`：官方镜像的稳定版本分支
|
||||
- 生产环境建议：指定精确版本号（如 `nginx:1.24.0`、`mysql:8.0.35`）而非仅大版本号
|
||||
|
||||
* [启动容器](5.1_run.md)
|
||||
* [守护态运行](5.2_daemon.md)
|
||||
* [终止容器](5.3_stop.md)
|
||||
|
||||
@@ -15,15 +15,17 @@
|
||||
你可以使用官方 `registry` 镜像来运行。
|
||||
|
||||
```bash
|
||||
$ docker run -d -p 5000:5000 --restart=always --name registry registry
|
||||
$ docker run -d -p 5000:5000 --restart=always --name registry registry:2
|
||||
```
|
||||
|
||||
> **版本说明**：使用 `registry:2` 表示 Docker Registry 2.x 版本，这是当前推荐的版本。旧版本 Registry 1.x 已停止维护，不建议使用。
|
||||
这将使用官方的 `registry` 镜像来启动私有仓库。默认情况下，仓库会被创建在容器的 `/var/lib/registry` 目录下。你可以通过 `-v` 参数来将镜像文件存放在本地的指定路径。例如下面的例子将上传的镜像放到本地的 `/opt/data/registry` 目录。
|
||||
|
||||
```bash
|
||||
$ docker run -d \
|
||||
-p 5000:5000 \
|
||||
-v /opt/data/registry:/var/lib/registry \
|
||||
registry
|
||||
registry:2
|
||||
```
|
||||
|
||||
### 6.2.2 在私有仓库上传、搜索、下载镜像
|
||||
|
||||
@@ -122,11 +122,13 @@ $ mkdir auth
|
||||
|
||||
$ docker run --rm \
|
||||
--entrypoint htpasswd \
|
||||
httpd:alpine \
|
||||
httpd:2.4-alpine \
|
||||
-Bbn username password > auth/nginx.htpasswd
|
||||
```
|
||||
> 将上面的 `username` `password` 替换为你自己的用户名和密码。
|
||||
|
||||
> **版本说明**：使用 `httpd:2.4-alpine` 基于 Apache 2.4 的精简镜像。如需其他版本，可替换为 `httpd:latest` 或指定具体版本号如 `httpd:2.4.58-alpine`。
|
||||
|
||||
### 6.3.4 编辑 Docker Compose 配置
|
||||
|
||||
编辑 `compose.yaml` (或 `docker-compose.yml`) 配置如下：
|
||||
@@ -134,7 +136,7 @@ $ docker run --rm \
|
||||
```yaml
|
||||
services:
|
||||
registry:
|
||||
image: registry
|
||||
image: registry:2
|
||||
ports:
|
||||
- "443:443"
|
||||
volumes:
|
||||
@@ -145,6 +147,8 @@ volumes:
|
||||
registry-data:
|
||||
```
|
||||
|
||||
> **版本说明**：Compose 配置中明确指定 `registry:2` 版本。生产环境建议固定版本号（如 `registry:2.8.3`）而非使用 `latest`，以保证部署的可重复性。
|
||||
|
||||
### 6.3.5 修改 Hosts 文件
|
||||
|
||||
编辑 `/etc/hosts`
|
||||
@@ -187,6 +191,8 @@ $ docker image rm docker.domain.com/username/ubuntu:24.04
|
||||
|
||||
$ docker pull docker.domain.com/username/ubuntu:24.04
|
||||
```
|
||||
|
||||
> **版本说明**：示例使用 `ubuntu:24.04`，这是最新 LTS 版本。推送到私有仓库时保持了原有的版本标签，建议生产环境明确指定镜像版本号。
|
||||
如果我们退出登录，尝试推送镜像。
|
||||
|
||||
```bash
|
||||
|
||||
@@ -8,8 +8,10 @@
|
||||
$ docker run -d --name nexus3 --restart=always \
|
||||
-p 8081:8081 \
|
||||
--mount src=nexus-data,target=/nexus-data \
|
||||
sonatype/nexus3
|
||||
sonatype/nexus3:3.69
|
||||
```
|
||||
|
||||
> **版本说明**：使用 `sonatype/nexus3:3.69` 指定稳定的 Nexus 版本。使用具体版本号而非 `latest` 可以避免意外升级带来的不兼容问题。
|
||||
首次运行需等待 3-5 分钟，你可以使用 `docker logs nexus3 -f` 查看日志：
|
||||
|
||||
```bash
|
||||
@@ -18,10 +20,12 @@ $ docker logs nexus3 -f
|
||||
2021-03-11 15:31:21,990+0000 INFO [jetty-main-1] *SYSTEM org.sonatype.nexus.bootstrap.jetty.JettyServer -
|
||||
-------------------------------------------------
|
||||
|
||||
Started Sonatype Nexus OSS 3.30.0-01
|
||||
Started Sonatype Nexus OSS 3.69.0
|
||||
|
||||
-------------------------------------------------
|
||||
```
|
||||
|
||||
> **版本说明**：上述日志中显示的是 Nexus 3.69 版本的启动日志。具体版本号会随着容器镜像版本而不同。
|
||||
如果你看到以上内容，说明 `Nexus` 已经启动成功，你可以使用浏览器打开 `http://YourIP:8081` 访问 `Nexus` 了。
|
||||
|
||||
首次运行请通过以下命令获取初始密码：
|
||||
|
||||
@@ -6,6 +6,16 @@
|
||||
|
||||
大部分时候，并不需要严格区分这两者的概念。
|
||||
|
||||
## 版本号说明
|
||||
|
||||
本章涉及的 Registry 和相关工具版本说明：
|
||||
|
||||
- **Docker Registry**：使用 `registry:2` 推荐版本，已停止维护的 `registry:1` 不建议使用
|
||||
- **Nexus 3**：建议指定具体版本（如 `sonatype/nexus3:3.69`）而非 `latest`，避免自动升级带来的兼容性问题
|
||||
- **镜像标签规范**：
|
||||
- 生产环境推送至仓库时应明确指定版本号（如 `myapp:v1.0.0`）
|
||||
- 避免依赖 `latest` 标签，因为其含义存在歧义且易导致版本混淆
|
||||
|
||||
## 为什么需要私有仓库？
|
||||
|
||||
在讨论具体的安装和配置前，让我们先理解：**什么时候你应该建设私有仓库？**
|
||||
|
||||
@@ -82,6 +82,7 @@ RUN pwd # 输出 /app
|
||||
|
||||
```docker
|
||||
## 构建阶段
|
||||
## 建议使用 node:20 或 node: 等具体版本标签，避免使用 latest
|
||||
|
||||
FROM node:20 AS builder
|
||||
WORKDIR /build
|
||||
@@ -91,6 +92,7 @@ COPY . .
|
||||
RUN npm run build
|
||||
|
||||
## 生产阶段
|
||||
## 建议使用 nginx:alpine 或其他具体版本
|
||||
|
||||
FROM nginx:alpine
|
||||
WORKDIR /usr/share/nginx/html
|
||||
@@ -103,6 +105,7 @@ COPY --from=builder /build/dist .
|
||||
#### 1. 尽早设置 WORKDIR
|
||||
|
||||
```docker
|
||||
# 建议使用 node:20 等主/次版本号标签
|
||||
FROM node:20
|
||||
WORKDIR /app # 尽早设置
|
||||
|
||||
|
||||
@@ -34,6 +34,7 @@ Starting ──成功──> Healthy ──失败N次──> Unhealthy
|
||||
#### Web 服务检查
|
||||
|
||||
```docker
|
||||
# 注：nginx 镜像推荐使用具体的版本标签（如 nginx:1.25-alpine）
|
||||
FROM nginx
|
||||
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*
|
||||
|
||||
|
||||
@@ -60,6 +60,7 @@ server {
|
||||
第一阶段进行前端构建。
|
||||
|
||||
```docker
|
||||
# 注：node 镜像推荐使用具体的版本标签（如 node:20-alpine）
|
||||
FROM node:alpine as frontend
|
||||
|
||||
COPY package.json /app/
|
||||
@@ -81,6 +82,7 @@ RUN set -x ; cd /app \
|
||||
第二阶段安装 Composer 依赖。
|
||||
|
||||
```docker
|
||||
# 注：composer 镜像推荐使用具体的版本标签（如 composer:2.x）
|
||||
FROM composer as composer
|
||||
|
||||
COPY database/ /app/database/
|
||||
@@ -101,6 +103,7 @@ RUN set -x ; cd /app \
|
||||
第三阶段对以上阶段生成的文件进行整合。
|
||||
|
||||
```docker
|
||||
# 注：php 镜像版本号已包含 major.minor（8.3），生产环境可根据需要调整
|
||||
FROM php:8.3-fpm-alpine as laravel
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
@@ -125,6 +128,7 @@ RUN set -x ; cd ${LARAVEL_PATH} \
|
||||
### 7.18.5 最后一个阶段构建 NGINX 镜像
|
||||
|
||||
```docker
|
||||
# 注：nginx 镜像推荐使用具体的版本标签（如 nginx:1.25-alpine）
|
||||
FROM nginx:alpine as nginx
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
@@ -175,6 +179,7 @@ $ docker run -dit --rm --network=laravel -p 8080:80 my/nginx
|
||||
完整的 `Dockerfile` 文件如下。
|
||||
|
||||
```docker
|
||||
# 注：生产环境推荐使用具体的版本标签，如 node:20-alpine、composer:2.x、php:8.3-fpm-alpine、nginx:1.25-alpine
|
||||
FROM node:alpine as frontend
|
||||
|
||||
COPY package.json /app/
|
||||
@@ -225,6 +230,7 @@ RUN set -x ; cd ${LARAVEL_PATH} \
|
||||
&& php artisan package:discover
|
||||
|
||||
FROM nginx:alpine as nginx
|
||||
```
|
||||
|
||||
ARG LARAVEL_PATH=/app/laravel
|
||||
|
||||
|
||||
@@ -164,6 +164,7 @@ curl -s http://myip.ipip.net -i
|
||||
#### 实现方式
|
||||
|
||||
```docker
|
||||
# 建议使用 redis:7 或 redis:latest，具体版本号根据生产需求选择
|
||||
FROM redis:7-alpine
|
||||
COPY docker-entrypoint.sh /usr/local/bin/
|
||||
ENTRYPOINT ["docker-entrypoint.sh"]
|
||||
@@ -216,6 +217,7 @@ docker-entrypoint.sh redis-server docker-entrypoint.sh bash
|
||||
### 7.5.6 场景三：带参数的应用
|
||||
|
||||
```docker
|
||||
# 建议使用 python:3.12 或 python:3，具体版本号根据应用兼容性需求选择
|
||||
FROM python:3.12-slim
|
||||
WORKDIR /app
|
||||
COPY . .
|
||||
|
||||
@@ -18,14 +18,14 @@ ENV <key1>=<value1> <key2>=<value2> ...
|
||||
#### 设置单个变量
|
||||
|
||||
```docker
|
||||
ENV NODE_VERSION 20.10.0
|
||||
ENV NODE_VERSION 20
|
||||
ENV APP_ENV production
|
||||
```
|
||||
|
||||
#### 设置多个变量
|
||||
|
||||
```docker
|
||||
ENV NODE_VERSION=20.10.0 \
|
||||
ENV NODE_VERSION=20 \
|
||||
APP_ENV=production \
|
||||
APP_NAME="My Application"
|
||||
```
|
||||
@@ -158,15 +158,15 @@ $ docker build --build-arg NODE_VERSION=18 -t myapp .
|
||||
```docker
|
||||
## ✅ 好：版本集中管理
|
||||
|
||||
ENV NGINX_VERSION=1.25.0 \
|
||||
NODE_VERSION=20.10.0 \
|
||||
PYTHON_VERSION=3.12.0
|
||||
ENV NGINX_VERSION=1.25 \
|
||||
NODE_VERSION=20 \
|
||||
PYTHON_VERSION=3.12
|
||||
|
||||
RUN apt-get install nginx=${NGINX_VERSION}
|
||||
|
||||
## ❌ 差：版本分散在各处
|
||||
|
||||
RUN apt-get install nginx=1.25.0
|
||||
RUN apt-get install nginx=1.25
|
||||
```
|
||||
|
||||
#### 2. 不要存储敏感信息
|
||||
|
||||
@@ -35,6 +35,7 @@ ARG <参数名>[=<默认值>]
|
||||
|
||||
```docker
|
||||
## 定义有默认值的 ARG
|
||||
## 建议使用主版本号，如 20 而非 20.10.0，这样可以自动获取最新的补丁版本
|
||||
|
||||
ARG NODE_VERSION=20
|
||||
|
||||
@@ -113,17 +114,19 @@ RUN echo "Running with Node $NODE_VERSION"
|
||||
#### 1. 控制基础镜像版本
|
||||
|
||||
```docker
|
||||
ARG ALPINE_VERSION=3.19
|
||||
# 推荐使用主版本号（如 3），或指定次版本号（如 3.19），避免指定完整补丁版本
|
||||
ARG ALPINE_VERSION=3
|
||||
FROM alpine:${ALPINE_VERSION}
|
||||
```
|
||||
```bash
|
||||
$ docker build --build-arg ALPINE_VERSION=3.18 .
|
||||
$ docker build --build-arg ALPINE_VERSION=3.19 .
|
||||
```
|
||||
|
||||
#### 2. 设置软件版本
|
||||
|
||||
```docker
|
||||
ARG NGINX_VERSION=1.25.0
|
||||
# 使用次版本号 (1.25) 而非完整版本号 (1.25.0)，以便自动更新到最新补丁版本
|
||||
ARG NGINX_VERSION=1.25
|
||||
|
||||
RUN curl -fsSL https://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz | tar -xz
|
||||
```
|
||||
@@ -197,7 +200,7 @@ $ docker build --build-arg HTTP_PROXY=http://proxy:8080 .
|
||||
#### 1. 为 ARG 提供合理默认值
|
||||
|
||||
```docker
|
||||
## ✅ 好：有默认值
|
||||
## ✅ 好：有默认值，建议使用主或次版本号而非完整版本号
|
||||
|
||||
ARG NODE_VERSION=20
|
||||
|
||||
@@ -222,12 +225,13 @@ RUN echo "password=$DB_PASSWORD" > /app/.env
|
||||
#### 3. 使用 ARG 提高构建灵活性
|
||||
|
||||
```docker
|
||||
# 推荐使用次版本号标签，允许Docker自动拉取最新的补丁版本
|
||||
ARG BASE_IMAGE=python:3.12-slim
|
||||
FROM ${BASE_IMAGE}
|
||||
|
||||
## 可以构建不同基础镜像的版本
|
||||
|
||||
## docker build --build-arg BASE_IMAGE=python:3.14-alpine .
|
||||
## docker build --build-arg BASE_IMAGE=python:3-slim .
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
@@ -120,6 +120,7 @@ VOLUME /data
|
||||
#### 数据库持久化
|
||||
|
||||
```docker
|
||||
# 建议使用 postgres:16 或 postgres:latest，具体版本号根据数据库兼容性需求选择
|
||||
FROM postgres:16
|
||||
VOLUME /var/lib/postgresql/data
|
||||
```
|
||||
@@ -173,6 +174,7 @@ $ docker inspect mycontainer --format '{{json .Mounts}}' | jq
|
||||
```yaml
|
||||
services:
|
||||
db:
|
||||
# 建议使用 postgres:16 或其他具体版本，避免 latest
|
||||
image: postgres:16
|
||||
volumes:
|
||||
# 命名卷（推荐）
|
||||
|
||||
+12
-1
@@ -72,6 +72,17 @@ docker build [选项] <上下文路径/URL/->
|
||||
例如，在 Dockerfile 所在目录执行：
|
||||
|
||||
```bash
|
||||
docker build -t my-image:v1 .
|
||||
docker build -t my-image:1.0 .
|
||||
```
|
||||
|
||||
### 关于版本号最佳实践
|
||||
|
||||
本章中的 Dockerfile 示例使用的基础镜像标签遵循以下原则：
|
||||
|
||||
- **通用标签**（如 `ubuntu:24.04`、`alpine`、`nginx`）：保持原样，无需修改
|
||||
- **基础镜像版本号**（如 `node:20`、`python:3.12`）：使用主或次版本号而非完整版本号（patch），这样可以自动获取最新的补丁版本，确保获得安全更新
|
||||
- **避免**：不建议使用 `latest` 标签和完整的 patch 版本号（如 `20.10.0`）作为基础镜像，因为这会导致构建的不可重现性或安全风险
|
||||
|
||||
读者在使用这些示例时，应根据实际生产环境需求选择合适的版本号。
|
||||
|
||||
更多关于 `docker build` 的用法，我们在实战中会结合具体指令进行演示。
|
||||
|
||||
@@ -171,7 +171,7 @@ $ docker run -d \
|
||||
--name postgres \
|
||||
-e POSTGRES_PASSWORD=secret \
|
||||
-v postgres_data:/var/lib/postgresql/data \
|
||||
postgres:16
|
||||
postgres:16 # 确保与环境兼容的 PostgreSQL 版本
|
||||
|
||||
## 即使删除容器，数据仍然保留
|
||||
|
||||
@@ -183,7 +183,7 @@ $ docker run -d \
|
||||
--name postgres \
|
||||
-e POSTGRES_PASSWORD=secret \
|
||||
-v postgres_data:/var/lib/postgresql/data \
|
||||
postgres:16
|
||||
postgres:16 # 确保与环境兼容的 PostgreSQL 版本
|
||||
```
|
||||
|
||||
#### 场景二：多容器共享数据
|
||||
|
||||
@@ -53,7 +53,7 @@ docker network inspect my-overlay-net
|
||||
docker service create --name web \
|
||||
--network my-overlay-net \
|
||||
--replicas 3 \
|
||||
nginx:latest
|
||||
nginx # 确保与环境兼容的 Nginx 版本
|
||||
|
||||
# 单机环境下也可以让普通容器加入 attachable overlay 网络
|
||||
docker run -d --name container1 --network my-overlay-net busybox sleep 1d
|
||||
@@ -111,14 +111,14 @@ docker run -d \
|
||||
--dns 8.8.8.8 \
|
||||
--dns 1.1.1.1 \
|
||||
--dns-search example.com \
|
||||
nginx:latest
|
||||
nginx # 确保与环境兼容的 Nginx 版本
|
||||
|
||||
# DNS 选项
|
||||
docker run -d \
|
||||
--dns-option ndots:2 \
|
||||
--dns-option timeout:1 \
|
||||
--dns-option attempts:3 \
|
||||
nginx:latest
|
||||
nginx # 确保与环境兼容的 Nginx 版本
|
||||
|
||||
# 查看容器 DNS 配置
|
||||
docker exec <container_id> cat /etc/resolv.conf
|
||||
@@ -171,8 +171,8 @@ networks:
|
||||
docker network create mynet
|
||||
|
||||
# 运行服务
|
||||
docker run -d --name web --network mynet nginx:latest
|
||||
docker run -d --name db --network mynet postgres:latest
|
||||
docker run -d --name web --network mynet nginx # 确保与环境兼容的 Nginx 版本
|
||||
docker run -d --name db --network mynet postgres # 确保与环境兼容的 PostgreSQL 版本
|
||||
|
||||
# 在其他容器中通过服务名访问
|
||||
docker run -it --network mynet busybox sh
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
**BuildKit** 是下一代的镜像构建组件，在 [moby/buildkit](https://github.com/moby/buildkit) 开源。
|
||||
|
||||
> **重要**：自 Docker 23.0 起，BuildKit 已成为 **默认稳定构建器**，无需手动启用。Docker Engine v29 进一步将 Containerd 镜像存储设为默认，提升与 Kubernetes 的互操作性。
|
||||
> **重要**：自 Docker 23 起，BuildKit 已成为 **默认稳定构建器**，无需手动启用。Docker Engine 29 进一步将 Containerd 镜像存储设为默认，提升与 Kubernetes 的互操作性。
|
||||
|
||||
目前，Docker Hub 自动构建已经支持 BuildKit，具体请参考 [docker-practice/docker-hub-buildx](https://github.com/docker-practice/docker-hub-buildx)。
|
||||
|
||||
@@ -159,7 +159,7 @@ $ docker build -t test --ssh default=$SSH_AUTH_SOCK .
|
||||
|
||||
Docker Compose 同样支持 BuildKit，这使得多服务应用的构建更加高效。
|
||||
|
||||
自 Docker 23.0 起，BuildKit 已默认启用，无需额外配置。如果使用旧版本，可设置 `DOCKER_BUILDKIT=1` 环境变量启用。
|
||||
自 Docker 23 起，BuildKit 已默认启用，无需额外配置。如果使用旧版本，可设置 `DOCKER_BUILDKIT=1` 环境变量启用。
|
||||
|
||||
### 10.1.3 官方文档
|
||||
|
||||
|
||||
@@ -43,7 +43,7 @@ $ docker buildx build --sbom=true -t myimage .
|
||||
>
|
||||
> **正确的解决路径有两条**：
|
||||
> 1. **推送到远端仓库**：使用 `docker buildx build --sbom=true --push -t myimage:tag` 时，SBOM 会正确保存到远端仓库。远端 OCI 兼容的镜像仓库能够完整存储这些元数据。
|
||||
> 2. **启用 containerd image store**：在 Docker 守护进程中启用 `containerd image store` 特性（Docker v29+，新安装场景默认启用，Docker Desktop 上也更容易直接使用），可以在本地查看和管理 SBOM 等 attestation 元数据。
|
||||
> 2. **启用 containerd image store**：在 Docker 守护进程中启用 `containerd image store` 特性（Docker 29+，新安装场景默认启用，Docker Desktop 上也更容易直接使用），可以在本地查看和管理 SBOM 等 attestation 元数据。
|
||||
|
||||
### 10.2.2 官方文档
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ $ docker manifest inspect hello-world
|
||||
|
||||
`docker buildx` 是构建多架构镜像的最佳实践工具，它屏蔽了底层的复杂性，提供了一键构建多架构镜像的能力。
|
||||
|
||||
在 Docker 19.03+ 版本中，`docker buildx` 是推荐的用于构建多架构镜像的工具。它使用 `BuildKit` 作为后端，可以大大简化构建过程。
|
||||
在 Docker 19.03+ 版本中，`docker buildx` 是推荐的用于构建多架构镜像的工具。它使用 `BuildKit` 作为后端，可以大大简化构建过程（Docker 23+ 默认启用 BuildKit）。
|
||||
|
||||
#### 新建 `builder` 实例
|
||||
|
||||
|
||||
+2
-2
@@ -2,7 +2,7 @@
|
||||
|
||||
Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持 [Moby BuildKit](10.1_buildkit.md) 提供的功能。提供了与 docker build 相同的用户体验，并增加了许多新功能。
|
||||
|
||||
> Buildx 需要 Docker v19.03+。在较新版本中已更常用且功能更完整。
|
||||
> Buildx 需要 Docker v19.03+ （Docker 19.03 及以上版本）。在较新版本中已更常用且功能更完整。
|
||||
|
||||
## 本章内容
|
||||
|
||||
@@ -13,4 +13,4 @@ Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持
|
||||
* [构建多种系统架构支持的 Docker 镜像](10.3_multi-arch-images.md)
|
||||
|
||||
> **供应链安全与存储后端前瞻**：现代软件供应链中，镜像来源证明（Provenance，在 BuildKit 中默认以 `mode=min` 添加）和软件物料清单（SBOM，可通过 `--sbom=true` 显式开启）已经成为极其重要的构建产出。这些 Attestations 数据会作为 manifest 附着在 **镜像索引 (Image Index)** 上。
|
||||
> 正是基于此诉求，自 Docker Engine v29 起在**新安装场景**默认启用的 `containerd image store` 提供对 Image Index 的完美本地支持能力，解决了传统经典存储后端（Classic Store）无法有效处理带 Attestations 镜像索引的瓶颈。这使得你可以利用 `docker buildx imagetools inspect` 等手段，甚至做到无需拉取完整镜像内容即可在 Registry 或本地高效校验镜像的安全元数据。
|
||||
> 正是基于此诉求，自 Docker Engine 29 起在**新安装场景**默认启用的 `containerd image store` 提供对 Image Index 的完美本地支持能力，解决了传统经典存储后端（Classic Store）无法有效处理带 Attestations 镜像索引的瓶颈。这使得你可以利用 `docker buildx imagetools inspect` 等手段，甚至做到无需拉取完整镜像内容即可在 Registry 或本地高效校验镜像的安全元数据。
|
||||
|
||||
@@ -4,7 +4,7 @@ Docker Buildx 是 Docker 构建系统的重要进化，提供了高效、安全
|
||||
|
||||
| 概念 | 要点 |
|
||||
|------|------|
|
||||
| **BuildKit** | 下一代构建引擎，Docker 23.0+ 默认启用 |
|
||||
| **BuildKit** | 下一代构建引擎，Docker 23+ 默认启用 |
|
||||
| **缓存挂载** | `RUN --mount=type=cache` 加速依赖安装 |
|
||||
| **Secret 挂载** | `RUN --mount=type=secret` 安全传递密钥 |
|
||||
| **buildx build** | 替代 `docker build`，支持更多构建功能 |
|
||||
|
||||
@@ -19,7 +19,7 @@ $ chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose
|
||||
|
||||
```bash
|
||||
$ docker compose version
|
||||
Docker Compose version vX.Y.Z
|
||||
Docker Compose version v5.x
|
||||
```
|
||||
|
||||
### 11.2.3 卸载
|
||||
|
||||
@@ -2,6 +2,11 @@
|
||||
|
||||
> 本小节内容适合 `Python` 开发人员阅读。
|
||||
|
||||
> **版本说明**：本示例使用以下镜像版本：
|
||||
> - Python：3.12-slim（可替换为其他 3.x 版本）
|
||||
> - PostgreSQL：16（可替换为其他 16.x、15.x 等版本）
|
||||
> - Django：>=5.0,<6.0（可根据项目需求调整）
|
||||
|
||||
本节将使用 Docker Compose 配置并运行一个 **Django + PostgreSQL** 应用。笔者不仅会介绍具体步骤，还会解释每个配置项的作用，以及开发环境和生产环境的差异。
|
||||
|
||||
### 11.6.1 架构概览
|
||||
|
||||
@@ -2,6 +2,11 @@
|
||||
|
||||
> 本小节内容适合 Ruby 开发人员阅读。
|
||||
|
||||
> **版本说明**：本示例使用以下镜像版本：
|
||||
> - Ruby：3.2（可替换为其他 3.x 版本）
|
||||
> - PostgreSQL：16（可替换为其他 16.x、15.x 等版本）
|
||||
> - Rails：~> 7.1（可根据项目需求调整）
|
||||
|
||||
本节使用 Docker Compose 配置并运行一个 **Rails + PostgreSQL** 应用。
|
||||
|
||||
### 11.7.1 架构概览
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
## 11.8 实战 WordPress
|
||||
|
||||
> **版本说明**：本示例使用以下镜像版本：
|
||||
> - MySQL：8.0（可替换为其他 8.x 版本，或使用 MariaDB 替代）
|
||||
> - WordPress：latest（建议在生产环境指定具体版本，如 6.x）
|
||||
|
||||
WordPress 是全球最流行的内容管理系统 (CMS)。使用 Docker Compose 可以在几分钟内搭建一个包含数据库、Web 服务和持久化存储的生产级 WordPress 环境。
|
||||
|
||||
---
|
||||
|
||||
@@ -95,11 +95,11 @@ flowchart TD
|
||||
|
||||
---
|
||||
|
||||
### 12.1.4 Docker Engine v29+ 变化
|
||||
### 12.1.4 Docker Engine v29.x 变化
|
||||
|
||||
从 Docker Engine v29 开始，架构进一步简化和标准化：
|
||||
从 Docker Engine v29.x 开始，架构进一步简化和标准化：
|
||||
|
||||
- **Containerd 镜像存储 (Image Store)**：在 v29+ 的新安装场景中默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。
|
||||
- **Containerd 镜像存储 (Image Store)**：在 v29.x 的新安装场景中默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。
|
||||
- **优势**：多平台镜像支持更好、镜像拉取更快 (lazy pulling)、与 K8s 共享镜像。
|
||||
|
||||
---
|
||||
|
||||
@@ -88,11 +88,11 @@ flowchart LR
|
||||
|
||||
### 12.4.4 Docker 支持的存储驱动
|
||||
|
||||
Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, devicemapper），到被广泛使用的现代经典 graph driver (`overlay2`)，再到当下（Engine v29 及以后）**在新安装场景中默认启用的 containerd 镜像存储引擎（containerd image store）** 的演进。
|
||||
Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, devicemapper），到被广泛使用的现代经典 graph driver (`overlay2`)，再到当下（Engine v29.x 及以后）**在新安装场景中默认启用的 containerd 镜像存储引擎（containerd image store）** 的演进。
|
||||
|
||||
| 存储后端 / 驱动 | 核心特性说明 | 推荐程度 |
|
||||
|---------|------|---------|
|
||||
| **containerd image store**| (v29+ 新一代默认后端，新装默认) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储。 | ✅**强烈推荐 (现代默认)** |
|
||||
| **containerd image store**| (v29.x 新一代默认后端，新装默认) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储。 | ✅**强烈推荐 (现代默认)** |
|
||||
| **overlay2**| (经典 Graph Driver) 传统架构下的现代 Linux 默认驱动，性能优秀，但在处理复杂溯源元数据（索引）时受限。 | ✅**推荐 (主要后备)** |
|
||||
| **aufs** | 早期默认，兼容性好 | 遗留系统 |
|
||||
| **btrfs**/**zfs** | 使用原生稳定文件系统快照能力 | 特定场景 |
|
||||
@@ -113,7 +113,7 @@ Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, device
|
||||
$ docker info | grep "Storage Driver"
|
||||
Storage Driver: overlay2
|
||||
|
||||
## 在 Engine v29+ 中，可以通过如下输出验证是否开启了 containerd 镜像后端：
|
||||
## 在 Engine v29.x 中，可以通过如下输出验证是否开启了 containerd 镜像后端：
|
||||
$ docker info | grep "containerd image store"
|
||||
containerd image store: true
|
||||
```
|
||||
|
||||
@@ -271,6 +271,8 @@ $ kubectl get node -o yaml | grep CIDR
|
||||
podCIDRs:
|
||||
```
|
||||
```bash
|
||||
# 注意：v0.28.2 为编写本文档时的最新版本，请根据需要替换为当前版本
|
||||
# 参见 https://github.com/flannel-io/flannel/releases
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.28.2/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
|
||||
`kubeadm` 提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令，作为快速创建 `Kubernetes` 集群的最佳实践。
|
||||
|
||||
> **版本说明**：本文档基于 Kubernetes v1.36 编写。Kubernetes 版本更新较快（约每 4 个月一个新版本），本文档中的第三方工具版本（如 cri-dockerd、flannel）仅为示例，请根据实际需求更新至当前版本。更完整的安装和兼容性说明请以 [Kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) 为准。
|
||||
|
||||
> ⚠️ **强烈提示：Docker 与 Kubernetes 环境的时代分界**
|
||||
>
|
||||
> 自 Kubernetes v1.24 起，内置的 `dockershim` 组件已被正式移除。这意味着 **Kubernetes 不再将 Docker Engine 作为默认内置的容器运行时**。虽然 Docker 仍然是你本地构建、管理镜像的绝佳工具，但它已不再是 kubelet 的默认运行时选项。
|
||||
@@ -22,6 +24,8 @@
|
||||
|
||||
```bash
|
||||
# 安装 cri-dockerd
|
||||
# 注意：v0.3.24 为编写本文档时的最新版本，请根据需要替换为当前版本
|
||||
# 参见 https://github.com/Mirantis/cri-dockerd/releases
|
||||
|
||||
$ cd /tmp
|
||||
$ wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.24/cri-dockerd-0.3.24.amd64.tgz
|
||||
@@ -50,6 +54,8 @@ $ sudo /usr/local/bin/cri-dockerd --version
|
||||
|
||||
```bash
|
||||
# 安装 cri-dockerd
|
||||
# 注意：v0.3.24 为编写本文档时的最新版本，请根据需要替换为当前版本
|
||||
# 参见 https://github.com/Mirantis/cri-dockerd/releases
|
||||
|
||||
$ cd /tmp
|
||||
$ wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.24/cri-dockerd-0.3.24.amd64.tgz
|
||||
@@ -282,6 +288,8 @@ $ kubectl get node -o yaml | grep CIDR
|
||||
podCIDRs:
|
||||
```
|
||||
```bash
|
||||
# 注意：v0.28.2 为编写本文档时的最新版本，请根据需要替换为当前版本
|
||||
# 参见 https://github.com/flannel-io/flannel/releases
|
||||
$ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.28.2/Documentation/kube-flannel.yml
|
||||
```
|
||||
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
|
||||
[Kind](https://kind.sigs.k8s.io/) (Kubernetes in Docker) 是一个使用 Docker 容器作为节点运行本地 Kubernetes 集群的工具。主要用于测试 Kubernetes 本身，也非常适合本地开发和 CI 环境。
|
||||
|
||||
> **版本说明**：本文档基于 Kind v0.31.0 编写。Kind 会根据下载时的默认行为自动拉取对应的 Kubernetes 版本。建议定期更新 Kind 到最新版本以获得最新的 Kubernetes 支持。详见 [Kind Releases](https://github.com/kubernetes-sigs/kind/releases)。
|
||||
|
||||
### 14.4.1 为什么选择 Kind
|
||||
|
||||
Kind 相比其他本地集群方案 (如 Minikube) 有以下显著优势：
|
||||
@@ -27,6 +29,8 @@ brew install kind
|
||||
|
||||
```bash
|
||||
# Linux AMD64
|
||||
# 注意：v0.31.0 为编写本文档时的最新版本，请根据需要替换为当前版本
|
||||
# 参见 https://github.com/kubernetes-sigs/kind/releases
|
||||
|
||||
curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.31.0/kind-linux-amd64
|
||||
chmod +x ./kind
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
|
||||
[K3s](https://k3s.io/) 是一个轻量级的 Kubernetes 发行版，由 Rancher Labs 开发。它专为边缘计算、物联网、CI、ARM 等资源受限的环境设计。K3s 被打包为单个二进制文件，只有不到 100MB，但通过了 CNCF 的一致性测试。
|
||||
|
||||
> **版本说明**：K3s 版本与 Kubernetes 版本对应。安装脚本会自动拉取最新稳定版本。如需指定特定版本，可在安装时设置 `INSTALL_K3S_VERSION` 环境变量。详见 [K3s Releases](https://github.com/k3s-io/k3s/releases)。
|
||||
|
||||
### 14.5.1 核心特性
|
||||
|
||||
* **轻量级**：移除过时的、非必须的 Kubernetes 功能 (如传统的云提供商插件)，使用 SQLite 作为默认数据存储 (也支持 Etcd/MySQL/Postgres)。
|
||||
@@ -33,6 +35,8 @@ NAME STATUS ROLES AGE VERSION
|
||||
k3s-master Ready control-plane,master 1m v1.36.0+k3s1
|
||||
```
|
||||
|
||||
> **版本说明**：输出中的 `v1.36.0+k3s1` 为编写本文档时的版本示例。实际输出版本号取决于你所安装的 K3s 版本。更多信息请参见 [K3s Releases](https://github.com/k3s-io/k3s/releases)。
|
||||
|
||||
### 14.5.3 快速使用
|
||||
|
||||
K3s 内置了 `kubectl` 命令 (通过 `k3s kubectl` 调用)，为了方便，通常会建立别名或配置 `KUBECONFIG`。
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 15.1 简介
|
||||
|
||||
> **版本说明：** 本章内容基于 etcd 3.5 系列版本编写（当前最新为 v3.5.x）。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本信息。
|
||||
|
||||
如图 15-1 所示，etcd 项目使用该标识。
|
||||
|
||||
|
||||
|
||||
@@ -13,6 +13,7 @@
|
||||
例如，使用 `curl` 工具下载压缩包，并解压。
|
||||
|
||||
```bash
|
||||
# 下载 etcd v3.5.29 版本（请访问 https://github.com/etcd-io/etcd/releases 获取最新版本）
|
||||
$ curl -L https://github.com/etcd-io/etcd/releases/download/v3.5.29/etcd-v3.5.29-linux-amd64.tar.gz -o etcd-v3.5.29-linux-amd64.tar.gz
|
||||
|
||||
## 国内用户可选择就近的网络加速方式（以可用镜像站为准）
|
||||
@@ -60,6 +61,8 @@ hello world
|
||||
|
||||
镜像名称为 `quay.io/coreos/etcd`，可以通过下面的命令启动 `etcd` 服务监听到 `2379` 和 `2380` 端口。
|
||||
|
||||
> **版本说明：** 示例中使用 `v3.5.29` 标签。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新可用版本标签。
|
||||
|
||||
```bash
|
||||
$ docker run \
|
||||
-p 2379:2379 \
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 15.3 集群
|
||||
|
||||
> **版本说明：** 本节示例使用 etcd v3.5.29。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本信息。
|
||||
|
||||
下面我们使用 [Docker Compose](../11_compose/README.md) 模拟启动一个 3 节点的 `etcd` 集群。
|
||||
|
||||
编辑 `compose.yaml` (或 `docker-compose.yml`) 文件
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 15.4 使用 etcdctl
|
||||
|
||||
> **版本说明：** 本节示例基于 etcd 3.5 系列版本。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本信息。
|
||||
|
||||
`etcdctl` 是一个命令行客户端，它能提供一些简洁的命令，供用户直接跟 `etcd` 服务打交道，而无需基于 `HTTP API` 方式。这在某些情况下将很方便，例如用户对服务进行测试或者手动修改数据库内容。我们也推荐在刚接触 `etcd` 时通过 `etcdctl` 命令来熟悉相关的操作，这些操作跟 `HTTP API` 实际上是对应的。
|
||||
|
||||
`etcd` 项目二进制发行包中已经包含了 `etcdctl` 工具，没有的话，可以从 [github.com/etcd-io/etcd/releases](https://github.com/etcd-io/etcd/releases) 下载。
|
||||
|
||||
+3
-1
@@ -1,6 +1,8 @@
|
||||
# 第十五章 Etcd 项目
|
||||
|
||||
`etcd` 是 `CoreOS` 团队发起的一个管理配置信息和服务发现 (`Service Discovery`) 的项目，在这一章里面，我们将基于 `etcd 3.x` 版本介绍该项目的目标，安装和使用，以及实现的技术。
|
||||
`etcd` 是 `CoreOS` 团队发起的一个管理配置信息和服务发现 (`Service Discovery`) 的项目，在这一章里面，我们将基于 `etcd 3.5 系列`版本介绍该项目的目标，安装和使用，以及实现的技术。
|
||||
|
||||
> **版本说明：** 本章示例基于 etcd 3.5 系列版本编写。etcd 官方维护最新两个次版本（当前为 3.5 和 3.6）。请访问 [etcd 官方发布页](https://github.com/etcd-io/etcd/releases) 获取最新版本信息。
|
||||
|
||||
## 本章内容
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 16.1 简介
|
||||
|
||||
> **版本说明**：各云平台的容器服务版本更新频繁。本章示例适用于常见的 Kubernetes API 版本。建议访问各云厂商官方文档（如 [AWS EKS](https://aws.amazon.com/eks/)、[Azure AKS](https://azure.microsoft.com/en-us/services/kubernetes-service/)、[Google GKE](https://cloud.google.com/kubernetes-engine)、[阿里云 ACK](https://www.aliyun.com/product/kubernetes)、[腾讯云 TKE](https://cloud.tencent.com/product/tke)）获取最新信息。
|
||||
|
||||
随着容器技术的普及，目前主流的云计算服务商都提供了成熟的容器服务。与容器相关的云计算服务主要分为以下几种类型：
|
||||
|
||||
### 16.1.1 容器编排托管服务
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# 第十六章 容器与云计算
|
||||
|
||||
> **版本说明**：云平台的 Kubernetes 版本和容器服务功能更新迅速。本章示例使用通用的 API 版本（如 `apps/v1`），建议查阅各云厂商官方文档获取最新的服务版本和配置指南。
|
||||
|
||||
Docker 目前已经得到了众多公有云平台的支持，并成为除虚拟机之外的核心云业务。
|
||||
|
||||
除了 AWS、Google、Azure 等，国内的各大公有云厂商，基本上都同时支持了虚拟机服务和基于 Kubernetes 的容器云业务。有的还推出了其他服务，例如[容器镜像服务](https://cloud.tencent.com/act/cps/redirect?redirect=11588&cps_key=3a5255852d5db99dcd5da4c72f05df61)让用户在云上享有安全高效的镜像托管、分发等服务。
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 17.1 Fedora CoreOS 简介
|
||||
|
||||
> **版本说明**：Fedora CoreOS 定期发布更新。建议访问 [官方下载页面](https://getfedora.org/coreos/download/) 获取最新版本和兼容性信息。
|
||||
|
||||
[Fedora CoreOS](https://getfedora.org/coreos/) 是一个自动更新的，最小的，整体的，以容器为中心的操作系统，不仅适用于集群，而且可独立运行，并针对运行 Kubernetes 进行了优化。它旨在结合 CoreOS Container Linux 和 Fedora Atomic Host 的优点，将 Container Linux 中的 [Ignition](https://github.com/coreos/ignition) 与 [rpm-ostree](https://github.com/coreos/rpm-ostree) 和 Project Atomic 中的 SELinux 强化等技术相集成。其目标是提供最佳的容器主机，以安全，大规模地运行容器化的工作负载。
|
||||
|
||||
### 17.1.1 FCOS 特性
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 17.3 Podman - 下一代 Linux 容器工具
|
||||
|
||||
> **版本说明**：Podman 保持活跃的开发和发布周期。建议访问 [Podman 官方文档](https://podman.io/docs) 和 [GitHub Releases](https://github.com/containers/podman/releases) 获取最新版本。
|
||||
|
||||
[Podman](https://github.com/containers/podman) 是一个无守护进程、与 Docker 命令高度兼容的下一代 Linux 容器工具。它由 Red Hat 开发，旨在提供一个更安全的容器运行环境。
|
||||
|
||||
### 17.3.1 Podman vs Docker
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 17.4 Buildah - 容器镜像构建工具
|
||||
|
||||
> **版本说明**：Buildah 与 Podman 和 Skopeo 共同维护。建议查阅 [Buildah 官方文档](https://buildah.io/) 和 [GitHub Releases](https://github.com/containers/buildah/releases) 了解最新版本。
|
||||
|
||||
本节介绍 Buildah，包括其基础概念、应用场景以及基本指令。
|
||||
|
||||
### 17.4.1 Buildah 简介
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 17.5 Skopeo - 容器镜像管理工具
|
||||
|
||||
> **版本说明**：Skopeo 属于 containers 项目生态。建议访问 [Skopeo 官方仓库](https://github.com/containers/skopeo) 和 [GitHub Releases](https://github.com/containers/skopeo/releases) 获取最新版本信息。
|
||||
|
||||
本节介绍 Skopeo，包括其基础概念、应用场景以及基本指令。
|
||||
|
||||
### 17.5.1 Skopeo 简介
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 17.6 containerd - 核心容器运行时
|
||||
|
||||
> **版本说明**：containerd 和 nerdctl 保持活跃的发布周期。建议查阅 [containerd 官方文档](https://containerd.io/) 和 [nerdctl GitHub Releases](https://github.com/containerd/nerdctl/releases) 获取最新版本信息。
|
||||
|
||||
本节介绍 containerd，它是现代容器技术栈中最为核心的基础组件之一。了解 containerd 有助于更深入地理解 Docker 和 Kubernetes 的底层运行机制。
|
||||
|
||||
### 17.6.1 containerd 简介
|
||||
@@ -16,6 +18,8 @@
|
||||
|
||||
### 17.6.2 与 Docker 和 Kubernetes 的关系
|
||||
|
||||
> **版本说明**：本章节涉及 containerd、Docker 和 Kubernetes 的多个版本。建议查阅官方文档了解最新的兼容性信息。
|
||||
|
||||
理解 containerd，首先要理清它与用户日常操作的 Docker 以及 Kubernetes 的关系。
|
||||
|
||||
#### Docker 的架构
|
||||
@@ -36,8 +40,8 @@
|
||||
Kubernetes 作为一个容器编排系统，为了屏蔽底层不同容器运行时的实现差异，引入了 CRI（Container Runtime Interface）标准。
|
||||
|
||||
- 早期版本中，Kubernetes 默认使用 docker 作为运行时，通过一个名为 `dockershim` 的桥接组件对接 Docker，Docker 再对接 containerd。
|
||||
- 随着 containerd 原生支持了 CRI 插件，Kubernetes 开始直接与 containerd 通信，去掉了 `dockershim` 和 `dockerd` 的中间层。这就是为什么从 Kubernetes v1.24 开始”弃用 Docker”引发了广泛关注，实际上 Kubernetes 只是弃用 `dockershim`，底层依然在使用从 Docker 基因中诞生的 containerd。
|
||||
- containerd 2.0 移除了已弃用的 CRI v1alpha2 接口，仅保留 CRI v1（Kubernetes 自 v1.26 起仅支持 CRI v1）。如果集群中仍有依赖 CRI v1alpha2 的组件，升级 containerd 2.x 前需先完成迁移。containerd 2.3（2026 年 4 月）是 2.x 系列首个 LTS 版本，支持从 1.7 LTS 直接升级，生产环境推荐使用。
|
||||
- 随着 containerd 原生支持了 CRI 插件，Kubernetes 开始直接与 containerd 通信，去掉了 `dockershim` 和 `dockerd` 的中间层。这就是为什么从 Kubernetes 1.24+ 开始”弃用 Docker”引发了广泛关注，实际上 Kubernetes 只是弃用 `dockershim`，底层依然在使用从 Docker 基因中诞生的 containerd。参见 [Kubernetes 官方文档](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd)。
|
||||
- containerd 2.0+ 移除了已弃用的 CRI v1alpha2 接口，仅保留 CRI v1（Kubernetes 1.26+ 仅支持 CRI v1）。如果集群中仍有依赖 CRI v1alpha2 的组件，升级 containerd 2.x 前需先完成迁移。containerd 2.3+ 是 2.x 系列首个 LTS 版本，支持从 1.7 LTS 直接升级，生产环境推荐使用。详见 [containerd 发布说明](https://github.com/containerd/containerd/releases)。
|
||||
|
||||
### 17.6.3 为什么直接使用 containerd？
|
||||
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 17.7 安全容器运行时
|
||||
|
||||
> **版本说明**：Kata Containers、gVisor 和 Firecracker 均为活跃开发的项目。建议查阅各项目官方文档获取最新版本和兼容性信息：[Kata Containers](https://katacontainers.io/)、[gVisor](https://gvisor.dev/)、[Firecracker](https://firecracker-microvm.github.io/)。
|
||||
|
||||
本节介绍容器技术生态中的安全运行时机制，主要探讨在隔离性和安全性上比标准 Linux 容器更进一步的方案，重点介绍 Kata Containers 和 gVisor。
|
||||
|
||||
### 17.7.1 为什么需要安全容器？
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
## 17.8 WebAssembly 与容器
|
||||
|
||||
> **版本说明**：WebAssembly 和相关的 Wasm 运行时（如 WasmEdge、Spin）处于快速演进阶段。建议查阅 [WebAssembly 官方文档](https://webassembly.org/)、[WasmEdge](https://wasmedge.org/) 和 [Spin](https://developer.fermyon.com/spin) 官方文档获取最新信息。
|
||||
|
||||
本节介绍 WebAssembly (简写为 Wasm) 以及它为何成为现代容器生态中备受瞩目的前沿技术路线。
|
||||
|
||||
### 17.8.1 什么是 WebAssembly？
|
||||
|
||||
@@ -1,5 +1,10 @@
|
||||
# 第十七章 容器其它生态
|
||||
|
||||
> **版本说明**：本章介绍的工具和运行时（Podman、Buildah、Skopeo、containerd、Kata Containers、gVisor、WasmEdge 等）都保持活跃的开发。建议：
|
||||
> - 查阅各项目官方文档获取最新版本
|
||||
> - 在生产环境使用前验证版本兼容性
|
||||
> - 关注官方发布说明了解重大变更
|
||||
|
||||
本章将介绍 Docker 和 Kubernetes 之外的容器生态技术。
|
||||
|
||||
## 本章内容
|
||||
|
||||
@@ -103,7 +103,7 @@ $ docker version
|
||||
此后，Docker 守护进程会在执行任何 API 请求前，将请求转发给授权插件进行审批。
|
||||
|
||||
> [!CAUTION]
|
||||
> 重要的安全事项：在配置 Authorization Plugin 时，务必确保插件本身的可靠性和及时更新。2026 年 4 月披露的 CVE-2026-34040 表明，不完整的 AuthZ 验证可能导致攻击者绕过授权检查并获得宿主机访问权限。建议：
|
||||
> 重要的安全事项：在配置 Authorization Plugin 时，务必确保插件本身的可靠性和及时更新。历史上已发现多个 AuthZ 验证绕过漏洞，可能导致攻击者绕过授权检查并获得宿主机访问权限。建议：
|
||||
> - 定期审计授权插件的日志，检查是否有可疑的请求被错误允许。
|
||||
> - 使用来自可信来源的授权插件，并保持其版本最新。
|
||||
> - 将授权检查结果与其他安全措施（如 TLS 认证、Rootless 模式）结合使用，构建纵深防御。
|
||||
|
||||
@@ -51,7 +51,11 @@ rule_files:
|
||||
|
||||
#### 2. 编写 Docker Compose 文件
|
||||
|
||||
创建 `compose.yaml` (或 `docker-compose.yml`)。下面示例使用的是 2026 年 4 月的稳定版本。对于生产环境部署，建议查阅 [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/installation/) 确认最新推荐版本：
|
||||
创建 `compose.yaml` (或 `docker-compose.yml`)。下面示例使用的是相对较新的稳定版本。**镜像版本提示**：本示例中 Prometheus、Grafana、node-exporter、cAdvisor 的版本号仅为参考。生产环境部署前，请查阅以下官方资源确认最新推荐版本：
|
||||
- [Prometheus 官方文档](https://prometheus.io/docs/prometheus/latest/installation/)
|
||||
- [Grafana 官方发布](https://grafana.com/grafana/download)
|
||||
- [node-exporter 发布页](https://github.com/prometheus/node_exporter/releases)
|
||||
- [cAdvisor 发布页](https://github.com/google/cadvisor/releases)
|
||||
|
||||
```yaml
|
||||
services:
|
||||
@@ -71,7 +75,7 @@ services:
|
||||
- monitoring
|
||||
|
||||
grafana:
|
||||
image: grafana/grafana:11.3.0
|
||||
image: grafana/grafana:13.0.1
|
||||
ports:
|
||||
- "3000:3000"
|
||||
environment:
|
||||
|
||||
@@ -17,7 +17,7 @@ ELK (Elasticsearch，Logstash，Kibana) 是目前业界最流行的开源日志
|
||||
|
||||
#### 1. 编写 Compose 文件
|
||||
|
||||
1. 编写 `compose.yaml` (或 `docker-compose.yml`) 配置如下（示例基于 Elasticsearch 9.x，请查阅 [Elastic 官方文档](https://www.elastic.co/docs/) 确认最新版本与配置兼容性）：
|
||||
1. 编写 `compose.yaml` (或 `docker-compose.yml`) 配置如下。**版本提示**：本示例使用 Elasticsearch 9.x、Kibana 9.x、Fluentd 等组件的特定版本号，仅作为参考。生产环境部署前，请查阅 [Elastic 官方文档](https://www.elastic.co/docs/) 和 [Fluentd 官方文档](https://docs.fluentd.org/) 确认最新版本与配置兼容性。
|
||||
|
||||
```yaml
|
||||
services:
|
||||
|
||||
@@ -163,6 +163,9 @@ scrape_configs:
|
||||
|
||||
**完整监控栈部署：**
|
||||
|
||||
> [!TIP]
|
||||
> 以下示例中的镜像标签（如 `prom/prometheus:v3.11.0`、`prom/node-exporter:v1.11.1`、`ghcr.io/google/cadvisor:v0.56.2`、`grafana/grafana:13.0.1`）仅为参考。在生产环境部署前，请访问各项目的官方发布页或文档获取最新版本号。
|
||||
|
||||
```yaml
|
||||
services:
|
||||
prometheus:
|
||||
@@ -211,7 +214,7 @@ services:
|
||||
- monitoring
|
||||
|
||||
grafana:
|
||||
image: grafana/grafana:11.3.0
|
||||
image: grafana/grafana:13.0.1
|
||||
container_name: grafana
|
||||
ports:
|
||||
- "3000:3000"
|
||||
|
||||
Reference in New Issue
Block a user