From 92ea9623b25735bbdc7ceab4443055b7939c66a2 Mon Sep 17 00:00:00 2001 From: Baohua Yang Date: Sun, 22 Feb 2026 12:42:15 -0800 Subject: [PATCH] Fix naming of the chapter dir --- 03_install/summary.md | 27 ++ {08_data_network/data => 08_data}/README.md | 0 .../_images/types-of-mounts.png | Bin .../data => 08_data}/bind-mounts.md | 0 {08_data_network/data => 08_data}/summary.md | 0 {08_data_network/data => 08_data}/tmpfs.md | 0 {08_data_network/data => 08_data}/volume.md | 0 08_data_network/README.md | 6 - 08_data_network/network/README.md | 344 ------------------ 08_data_network/network/summary.md | 26 -- 09_network/README.md | 41 +++ 09_network/container_linking.md | 62 ++++ 09_network/custom_network.md | 93 +++++ .../network => 09_network}/dns.md | 18 +- 09_network/network_isolation.md | 81 +++++ 09_network/network_types.md | 78 ++++ .../network => 09_network}/port_mapping.md | 52 +-- 09_network/summary.md | 24 ++ .../10.1_buildkit.md | 8 +- .../9.2_buildx.md => 10_buildx/10.2_buildx.md | 6 +- .../10.3_multi-arch-images.md | 8 +- {09_buildx => 10_buildx}/README.md | 2 +- 10_buildx/summary.md | 19 + .../11.1_introduction.md | 6 +- .../11.2_install.md | 10 +- .../10.3_usage.md => 11_compose/11.3_usage.md | 6 +- .../11.4_commands.md | 8 +- .../11.5_compose_file.md | 70 ++-- .../11.6_django.md | 26 +- .../10.7_rails.md => 11_compose/11.7_rails.md | 30 +- .../11.8_wordpress.md | 16 +- .../10.9_lnmp.md => 11_compose/11.9_lnmp.md | 2 +- {10_compose => 11_compose}/README.md | 2 +- .../demo/app/Dockerfile | 0 {10_compose => 11_compose}/demo/app/app.py | 0 .../demo/app/docker-compose.yml | 0 .../demo/django/.gitignore | 0 .../demo/django/Dockerfile | 0 .../demo/django/docker-compose.yml | 0 .../demo/django/requirements.txt | 0 .../demo/wordpress/docker-compose.yml | 0 11_compose/summary.md | 21 ++ .../12.1_arch.md | 16 +- .../12.2_namespace.md | 20 +- .../12.3_cgroups.md | 20 +- .../12.4_ufs.md | 16 +- .../12.5_container_format.md | 2 +- .../12.6_network.md | 8 +- .../README.md | 2 +- .../summary.md | 8 +- .../README.md | 0 .../_images/k8s_architecture.png | Bin .../_images/kube-proxy.png | Bin .../_images/kubernetes_design.jpg | Bin .../_images/kubernetes_logo.png | Bin .../advanced.md | 12 +- .../concepts.md | 20 +- .../design.md | 10 +- .../intro.md | 16 +- .../practice.md | 12 +- 13_kubernetes_concepts/summary.md | 19 + .../README.md | 0 .../dashboard.md | 10 +- .../docker-desktop.md | 6 +- .../k3s.md | 10 +- .../kind.md | 14 +- .../kubeadm-docker.md | 22 +- .../kubeadm.md | 24 +- .../kubectl.md | 36 +- 14_kubernetes_setup/summary.md | 17 + .../systemd.md | 2 +- {14_etcd => 15_etcd}/README.md | 0 {14_etcd => 15_etcd}/_images/etcd_logo.png | Bin {14_etcd => 15_etcd}/cluster.md | 2 +- .../demo/cluster/docker-compose.yml | 0 {14_etcd => 15_etcd}/etcdctl.md | 6 +- {14_etcd => 15_etcd}/install.md | 8 +- {14_etcd => 15_etcd}/intro.md | 2 +- 15_etcd/summary.md | 17 + {15_cloud => 16_cloud}/README.md | 0 {15_cloud => 16_cloud}/_images/ECS.jpg | Bin .../_images/aliyun-logo.png | Bin {15_cloud => 16_cloud}/_images/aws-logo.jpg | Bin .../_images/qcloud-logo.jpg | Bin {15_cloud => 16_cloud}/alicloud.md | 2 +- {15_cloud => 16_cloud}/aws.md | 2 +- {15_cloud => 16_cloud}/intro.md | 8 +- {15_cloud => 16_cloud}/multicloud.md | 8 +- {15_cloud => 16_cloud}/summary.md | 2 +- {15_cloud => 16_cloud}/tencentCloud.md | 2 +- {16_ecosystem => 17_ecosystem}/README.md | 2 +- .../coreos_README.md | 0 .../coreos_install.md | 14 +- .../coreos_intro.md | 6 +- .../demo/example.fcc | 0 {16_ecosystem => 17_ecosystem}/podman.md | 24 +- 17_ecosystem/summary.md | 25 ++ {17_security => 18_security}/README.md | 0 {17_security => 18_security}/control_group.md | 2 +- {17_security => 18_security}/daemon_sec.md | 2 +- .../kernel_capability.md | 2 +- {17_security => 18_security}/kernel_ns.md | 2 +- {17_security => 18_security}/other_feature.md | 2 +- {17_security => 18_security}/summary.md | 2 +- .../README.md | 2 +- {18_observability => 19_observability}/elk.md | 8 +- .../prometheus.md | 8 +- .../summary.md | 4 +- {19_cases => 20_cases}/README.md | 2 +- {19_cases => 20_cases}/ci/README.md | 0 {19_cases => 20_cases}/ci/actions/README.md | 4 +- {19_cases => 20_cases}/ci/devops_workflow.md | 8 +- {19_cases => 20_cases}/ci/drone/.env.example | 0 {19_cases => 20_cases}/ci/drone/.gitignore | 0 {19_cases => 20_cases}/ci/drone/README.md | 10 +- .../ci/drone/demo/.drone.yml | 0 .../ci/drone/demo/README.md | 4 +- {19_cases => 20_cases}/ci/drone/demo/app.go | 0 .../ci/drone/docker-compose.yml | 0 {19_cases => 20_cases}/ci/drone/install.md | 8 +- {19_cases => 20_cases}/ide/README.md | 0 {19_cases => 20_cases}/ide/vsCode.md | 6 +- {19_cases => 20_cases}/os/README.md | 0 {19_cases => 20_cases}/os/alpine.md | 10 +- {19_cases => 20_cases}/os/busybox.md | 10 +- {19_cases => 20_cases}/os/centos.md | 8 +- {19_cases => 20_cases}/os/debian.md | 8 +- {19_cases => 20_cases}/os/summary.md | 2 +- README.md | 4 + SUMMARY.md | 191 +++++----- 130 files changed, 1001 insertions(+), 852 deletions(-) create mode 100644 03_install/summary.md rename {08_data_network/data => 08_data}/README.md (100%) rename {08_data_network/data => 08_data}/_images/types-of-mounts.png (100%) rename {08_data_network/data => 08_data}/bind-mounts.md (100%) rename {08_data_network/data => 08_data}/summary.md (100%) rename {08_data_network/data => 08_data}/tmpfs.md (100%) rename {08_data_network/data => 08_data}/volume.md (100%) delete mode 100644 08_data_network/README.md delete mode 100644 08_data_network/network/README.md delete mode 100644 08_data_network/network/summary.md create mode 100644 09_network/README.md create mode 100644 09_network/container_linking.md create mode 100644 09_network/custom_network.md rename {08_data_network/network => 09_network}/dns.md (84%) create mode 100644 09_network/network_isolation.md create mode 100644 09_network/network_types.md rename {08_data_network/network => 09_network}/port_mapping.md (70%) create mode 100644 09_network/summary.md rename 09_buildx/9.1_buildkit.md => 10_buildx/10.1_buildkit.md (97%) rename 09_buildx/9.2_buildx.md => 10_buildx/10.2_buildx.md (93%) rename 09_buildx/9.3_multi-arch-images.md => 10_buildx/10.3_multi-arch-images.md (95%) rename {09_buildx => 10_buildx}/README.md (95%) create mode 100644 10_buildx/summary.md rename 10_compose/10.1_introduction.md => 11_compose/11.1_introduction.md (97%) rename 10_compose/10.2_install.md => 11_compose/11.2_install.md (93%) rename 10_compose/10.3_usage.md => 11_compose/11.3_usage.md (97%) rename 10_compose/10.4_commands.md => 11_compose/11.4_commands.md (98%) rename 10_compose/10.5_compose_file.md => 11_compose/11.5_compose_file.md (93%) rename 10_compose/10.6_django.md => 11_compose/11.6_django.md (95%) rename 10_compose/10.7_rails.md => 11_compose/11.7_rails.md (92%) rename 10_compose/10.8_wordpress.md => 11_compose/11.8_wordpress.md (95%) rename 10_compose/10.9_lnmp.md => 11_compose/11.9_lnmp.md (86%) rename {10_compose => 11_compose}/README.md (94%) rename {10_compose => 11_compose}/demo/app/Dockerfile (100%) rename {10_compose => 11_compose}/demo/app/app.py (100%) rename {10_compose => 11_compose}/demo/app/docker-compose.yml (100%) rename {10_compose => 11_compose}/demo/django/.gitignore (100%) rename {10_compose => 11_compose}/demo/django/Dockerfile (100%) rename {10_compose => 11_compose}/demo/django/docker-compose.yml (100%) rename {10_compose => 11_compose}/demo/django/requirements.txt (100%) rename {10_compose => 11_compose}/demo/wordpress/docker-compose.yml (100%) create mode 100644 11_compose/summary.md rename 11_implementation/11.1_arch.md => 12_implementation/12.1_arch.md (95%) rename 11_implementation/11.2_namespace.md => 12_implementation/12.2_namespace.md (96%) rename 11_implementation/11.3_cgroups.md => 12_implementation/12.3_cgroups.md (95%) rename 11_implementation/11.4_ufs.md => 12_implementation/12.4_ufs.md (95%) rename 11_implementation/11.5_container_format.md => 12_implementation/12.5_container_format.md (94%) rename 11_implementation/11.6_network.md => 12_implementation/12.6_network.md (97%) rename {11_implementation => 12_implementation}/README.md (98%) rename {11_implementation => 12_implementation}/summary.md (94%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/README.md (100%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/_images/k8s_architecture.png (100%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/_images/kube-proxy.png (100%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/_images/kubernetes_design.jpg (100%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/_images/kubernetes_logo.png (100%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/advanced.md (90%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/concepts.md (97%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/design.md (95%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/intro.md (93%) rename {12_kubernetes_concepts => 13_kubernetes_concepts}/practice.md (88%) create mode 100644 13_kubernetes_concepts/summary.md rename {13_kubernetes_setup => 14_kubernetes_setup}/README.md (100%) rename {13_kubernetes_setup => 14_kubernetes_setup}/dashboard.md (92%) rename {13_kubernetes_setup => 14_kubernetes_setup}/docker-desktop.md (89%) rename {13_kubernetes_setup => 14_kubernetes_setup}/k3s.md (92%) rename {13_kubernetes_setup => 14_kubernetes_setup}/kind.md (88%) rename {13_kubernetes_setup => 14_kubernetes_setup}/kubeadm-docker.md (95%) rename {13_kubernetes_setup => 14_kubernetes_setup}/kubeadm.md (96%) rename {13_kubernetes_setup => 14_kubernetes_setup}/kubectl.md (77%) create mode 100644 14_kubernetes_setup/summary.md rename {13_kubernetes_setup => 14_kubernetes_setup}/systemd.md (80%) rename {14_etcd => 15_etcd}/README.md (100%) rename {14_etcd => 15_etcd}/_images/etcd_logo.png (100%) rename {14_etcd => 15_etcd}/cluster.md (99%) rename {14_etcd => 15_etcd}/demo/cluster/docker-compose.yml (100%) rename {14_etcd => 15_etcd}/etcdctl.md (98%) rename {14_etcd => 15_etcd}/install.md (96%) rename {14_etcd => 15_etcd}/intro.md (99%) create mode 100644 15_etcd/summary.md rename {15_cloud => 16_cloud}/README.md (100%) rename {15_cloud => 16_cloud}/_images/ECS.jpg (100%) rename {15_cloud => 16_cloud}/_images/aliyun-logo.png (100%) rename {15_cloud => 16_cloud}/_images/aws-logo.jpg (100%) rename {15_cloud => 16_cloud}/_images/qcloud-logo.jpg (100%) rename {15_cloud => 16_cloud}/alicloud.md (98%) rename {15_cloud => 16_cloud}/aws.md (98%) rename {15_cloud => 16_cloud}/intro.md (90%) rename {15_cloud => 16_cloud}/multicloud.md (94%) rename {15_cloud => 16_cloud}/summary.md (96%) rename {15_cloud => 16_cloud}/tencentCloud.md (99%) rename {16_ecosystem => 17_ecosystem}/README.md (86%) rename {16_ecosystem => 17_ecosystem}/coreos_README.md (100%) rename {16_ecosystem => 17_ecosystem}/coreos_install.md (83%) rename {16_ecosystem => 17_ecosystem}/coreos_intro.md (97%) rename {16_ecosystem => 17_ecosystem}/demo/example.fcc (100%) rename {16_ecosystem => 17_ecosystem}/podman.md (90%) create mode 100644 17_ecosystem/summary.md rename {17_security => 18_security}/README.md (100%) rename {17_security => 18_security}/control_group.md (97%) rename {17_security => 18_security}/daemon_sec.md (98%) rename {17_security => 18_security}/kernel_capability.md (98%) rename {17_security => 18_security}/kernel_ns.md (98%) rename {17_security => 18_security}/other_feature.md (97%) rename {17_security => 18_security}/summary.md (97%) rename {18_observability => 19_observability}/README.md (92%) rename {18_observability => 19_observability}/elk.md (97%) rename {18_observability => 19_observability}/prometheus.md (95%) rename {18_observability => 19_observability}/summary.md (95%) rename {19_cases => 20_cases}/README.md (87%) rename {19_cases => 20_cases}/ci/README.md (100%) rename {19_cases => 20_cases}/ci/actions/README.md (94%) rename {19_cases => 20_cases}/ci/devops_workflow.md (95%) rename {19_cases => 20_cases}/ci/drone/.env.example (100%) rename {19_cases => 20_cases}/ci/drone/.gitignore (100%) rename {19_cases => 20_cases}/ci/drone/README.md (93%) rename {19_cases => 20_cases}/ci/drone/demo/.drone.yml (100%) rename {19_cases => 20_cases}/ci/drone/demo/README.md (93%) rename {19_cases => 20_cases}/ci/drone/demo/app.go (100%) rename {19_cases => 20_cases}/ci/drone/docker-compose.yml (100%) rename {19_cases => 20_cases}/ci/drone/install.md (95%) rename {19_cases => 20_cases}/ide/README.md (100%) rename {19_cases => 20_cases}/ide/vsCode.md (72%) rename {19_cases => 20_cases}/os/README.md (100%) rename {19_cases => 20_cases}/os/alpine.md (96%) rename {19_cases => 20_cases}/os/busybox.md (97%) rename {19_cases => 20_cases}/os/centos.md (96%) rename {19_cases => 20_cases}/os/debian.md (98%) rename {19_cases => 20_cases}/os/summary.md (96%) diff --git a/03_install/summary.md b/03_install/summary.md new file mode 100644 index 0000000..f7e83b9 --- /dev/null +++ b/03_install/summary.md @@ -0,0 +1,27 @@ +## 3.11 本章小结 + +Docker 支持在多种平台上安装和使用,选择合适的安装方式是顺利使用 Docker 的第一步。 + +| 平台 | 推荐方式 | 说明 | +|------|---------|------| +| **Ubuntu/Debian** | 官方 APT 仓库 | 最完善的支持,推荐首选 | +| **CentOS/Fedora** | 官方 YUM/DNF 仓库 | 注意关闭 SELinux 或配置策略 | +| **macOS** | Docker Desktop | 图形化安装,包含 Compose 和 Kubernetes | +| **Windows 10/11** | Docker Desktop (WSL 2) | 需启用 WSL 2 后端 | +| **Raspberry Pi** | 官方安装脚本 | 支持 ARM 架构 | +| **离线环境** | 二进制包安装 | 适用于无法联网的服务器 | + +### 3.11.1 安装后验证 + +安装完成后,运行以下命令验证 Docker 是否正常工作: + +```bash +$ docker version +$ docker run --rm hello-world +``` + +### 3.11.2 延伸阅读 + +- [镜像加速器](3.9_mirror.md):解决国内拉取镜像慢的问题 +- [开启实验特性](3.10_experimental.md):使用最新功能 +- [Docker Hub](../06_repository/6.1_dockerhub.md):官方镜像仓库 diff --git a/08_data_network/data/README.md b/08_data/README.md similarity index 100% rename from 08_data_network/data/README.md rename to 08_data/README.md diff --git a/08_data_network/data/_images/types-of-mounts.png b/08_data/_images/types-of-mounts.png similarity index 100% rename from 08_data_network/data/_images/types-of-mounts.png rename to 08_data/_images/types-of-mounts.png diff --git a/08_data_network/data/bind-mounts.md b/08_data/bind-mounts.md similarity index 100% rename from 08_data_network/data/bind-mounts.md rename to 08_data/bind-mounts.md diff --git a/08_data_network/data/summary.md b/08_data/summary.md similarity index 100% rename from 08_data_network/data/summary.md rename to 08_data/summary.md diff --git a/08_data_network/data/tmpfs.md b/08_data/tmpfs.md similarity index 100% rename from 08_data_network/data/tmpfs.md rename to 08_data/tmpfs.md diff --git a/08_data_network/data/volume.md b/08_data/volume.md similarity index 100% rename from 08_data_network/data/volume.md rename to 08_data/volume.md diff --git a/08_data_network/README.md b/08_data_network/README.md deleted file mode 100644 index 885bbeb..0000000 --- a/08_data_network/README.md +++ /dev/null @@ -1,6 +0,0 @@ -# 第八章数据与网络管理 - -本章将介绍 Docker 中的数据管理与网络配置。 - -* [数据管理](data/README.md) -* [网络配置](network/README.md) diff --git a/08_data_network/network/README.md b/08_data_network/network/README.md deleted file mode 100644 index 140a9f8..0000000 --- a/08_data_network/network/README.md +++ /dev/null @@ -1,344 +0,0 @@ -# 网络配置 - -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: - -## 8.6 Docker 网络概述 - -Docker 容器需要网络来: - -- 与外部世界通信 (访问互联网、被外部访问) -- 容器之间相互通信 -- 与宿主机通信 - -Docker 在安装时会自动配置网络基础设施,大多数情况下开箱即用。 - -## 8.6 默认网络架构 - -Docker 启动时自动创建以下网络组件: - -```mermaid -graph TD - subgraph Host [宿主机] - eth0[物理网卡 eth0
192.168.1.100] - docker0[docker0 网桥
172.17.0.1] - - subgraph Containers - subgraph ContainerA [容器 A] - eth0_A[eth0
172.17.0.2] - end - subgraph ContainerB [容器 B] - eth0_B[eth0
172.17.0.3] - end - end - - eth0 <--> docker0 - docker0 <--> eth0_A - docker0 <--> eth0_B - end - - Internet((互联网)) <--> eth0 -``` - -### 8.6.1 核心组件 - -相关信息如下表: - -| 组件 | 说明 | -|------|------| -| **docker0** | 虚拟网桥,充当交换机角色 | -| **veth pair** | 虚拟网卡对,一端在容器内,一端连接网桥 | -| **容器 eth0** | 容器内的网卡 | -| **IP 地址** | 自动从 172.17.0.0/16 网段分配 | - -### 8.6.2 数据流向 - -如下代码块所示,展示了相关示例: - -```mermaid -flowchart LR - subgraph Comm1 ["容器间通信"] - direction LR - C1A["容器 A (172.17.0.2)"] --> D0A["docker0"] --> C1B["容器 B (172.17.0.3)"] - end - - subgraph Comm2 ["访问外网"] - direction LR - C2A["容器 A (172.17.0.2)"] --> D0B["docker0"] --> Eth0A["eth0"] --> InternetA["互联网"] - end - - subgraph Comm3 ["被外部访问,需端口映射"] - direction LR - Req["外部请求"] --> Eth0B["eth0"] --> D0C["docker0"] --> C3A["容器 A"] - end -``` - ---- - -## 8.6 Docker 网络类型 - -查看默认网络: - -```bash -$ docker network ls -NETWORK ID NAME DRIVER SCOPE -abc123... bridge bridge local -def456... host host local -ghi789... none null local -``` - -| 网络类型 | 说明 | 适用场景 | -|---------|------|---------| -| **bridge** | 默认类型,容器连接到虚拟网桥 | 大多数单机场景 | -| **host** | 容器直接使用宿主机网络栈 | 需要最高网络性能时 | -| **none** | 禁用网络 | 完全隔离的容器 | -| **overlay** | 跨主机网络 | Docker Swarm 集群 | -| **macvlan** | 容器拥有独立 MAC 地址 | 需要直接接入物理网络 | - ---- - -## 8.6 用户自定义网络 (推荐) - -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: - -### 8.6.1 为什么要用自定义网络 - -默认 bridge 网络的局限: - -| 问题 | 自定义网络的优势 | -|------|-----------------| -| 只能用 IP 通信 | 支持容器名 DNS 解析 | -| 所有容器在同一网络 | 更好的隔离性 | -| 需要 --link (已废弃)| 原生支持服务发现 | - -### 8.6.2 创建自定义网络 - -运行以下命令: - -```bash -## 创建网络 - -$ docker network create mynet - -## 查看网络详情 - -$ docker network inspect mynet -``` - -### 8.6.3 使用自定义网络 - -运行以下命令: - -```bash -## 启动容器并连接到自定义网络 - -$ docker run -d --name web --network mynet nginx -$ docker run -d --name db --network mynet postgres - -## 在 web 容器中可以直接用容器名访问 db - -$ docker exec web ping db -PING db (172.18.0.3): 56 data bytes -64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.083 ms -``` - -### 8.6.4 容器名 DNS 解析 - -自定义网络自动提供 DNS 服务: - -```mermaid -flowchart LR - subgraph MyNet ["mynet 网络 : web 容器可以用 'db' 作为主机名访问 db 容器"] - direction LR - Web["web
172.18.0.2"] -- "DNS: 'db' → 172.18.0.3" --> DB["db
172.18.0.3"] - end -``` - ---- - -## 8.6 容器互联 - -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: - -### 8.6.1 同一网络内的容器 - -同一自定义网络内的容器可以直接通信: - -```bash -## 创建网络 - -$ docker network create app-net - -## 启动应用和数据库 - -$ docker run -d --name redis --network app-net redis -$ docker run -d --name app --network app-net myapp - -## app 容器中可以用 redis:6379 连接 Redis - -... -``` - -### 8.6.2 连接到多个网络 - -一个容器可以连接到多个网络: - -```bash -## 启动容器 - -$ docker run -d --name multi-net-container --network frontend nginx - -## 再连接到另一个网络 - -$ docker network connect backend multi-net-container - -## 查看容器的网络 - -$ docker inspect multi-net-container --format '{{json .NetworkSettings.Networks}}' -``` - -### 8.6.3 ⚠️ --link 已废弃 - -运行以下命令: - -```bash -## 旧方式(不推荐) - -$ docker run --link db:database myapp - -## 新方式(推荐) - -$ docker network create mynet -$ docker run --network mynet --name db postgres -$ docker run --network mynet --name app myapp -``` - ---- - -## 8.6 端口映射 - -容器默认只能在 Docker 网络内访问。要从外部访问容器,需要端口映射: - -### 8.6.1 基本语法 - -运行以下命令: - -```bash -## -p 宿主机端口:容器端口 - -$ docker run -d -p 8080:80 nginx -``` - -### 8.6.2 映射方式 - -相关信息如下表: - -| 参数 | 说明 | 示例 | -|------|------|------| -| `-p 8080:80` | 指定端口映射 | 宿主机 8080 → 容器 80 | -| `-p 80` | 随机宿主机端口 | 随机端口 → 容器 80 | -| `-P` | 自动映射所有暴露端口 | 随机端口 → 所有 EXPOSE 端口 | -| `-p 127.0.0.1:8080:80` | 只绑定本地 | 仅本机可访问 | -| `-p 8080:80/udp` | UDP 端口 | UDP 协议 | - -### 8.6.3 查看端口映射 - -运行以下命令: - -```bash -$ docker port mycontainer -80/tcp -> 0.0.0.0:8080 -``` - -### 8.6.4 端口映射示意图 - -如下代码块所示,展示了相关示例: - -```mermaid -flowchart TD - Req["外部请求 http://宿主机IP:8080"] --> Host["宿主机:8080"] - Host -- "iptables NAT" --> Container["容器 nginx:80"] -``` - ---- - -## 8.6 网络隔离 - -不同网络之间默认隔离: - -```bash -## 创建两个网络 - -$ docker network create frontend -$ docker network create backend - -## 容器 A 在 frontend - -$ docker run -d --name web --network frontend nginx - -## 容器 B 在 backend - -$ docker run -d --name db --network backend postgres - -## web 无法直接访问 db(不同网络) - -$ docker exec web ping db -ping: db: Name or service not known -``` - -这种隔离有助于安全:前端容器无法直接访问数据库网络。 - ---- - -## 8.6 常用命令 - -运行以下命令: - -```bash -## 列出网络 - -$ docker network ls - -## 创建网络 - -$ docker network create mynet - -## 查看网络详情 - -$ docker network inspect mynet - -## 连接容器到网络 - -$ docker network connect mynet mycontainer - -## 断开网络连接 - -$ docker network disconnect mynet mycontainer - -## 删除网络 - -$ docker network rm mynet - -## 清理未使用的网络 - -$ docker network prune -``` - ---- - -## 8.6 本章小结 - -相关信息如下表: - -| 概念 | 要点 | -|------|------| -| **默认网络** | docker0 网桥,172.17.0.0/16 网段 | -| **自定义网络** | 推荐使用,支持容器名 DNS 解析 | -| **端口映射** | `-p 宿主机端口:容器端口` 暴露服务 | -| **网络隔离** | 不同网络默认隔离,增强安全性 | -| **--link** | 已废弃,使用自定义网络替代 | - -## 8.6 延伸阅读 - -- [配置 DNS](dns.md):自定义 DNS 设置 -- [端口映射](port_mapping.md):高级端口配置 -- [Compose 网络](../../10_compose/10.5_compose_file.md):Compose 中的网络配置 diff --git a/08_data_network/network/summary.md b/08_data_network/network/summary.md deleted file mode 100644 index 19df4a4..0000000 --- a/08_data_network/network/summary.md +++ /dev/null @@ -1,26 +0,0 @@ -## 8.9 本章小结 - -相关信息如下表: - -| 场景 | DNS 行为 | 备注 | -|------|----------|------| -| **默认网络** | 继承宿主机 | 不支持容器名解析 | -| **自定义网络** | Docker 嵌入式 DNS | ✅ 支持容器名解析 | -| **手动指定** | 使用 `--dns` | 覆盖默认配置 | - -### 8.9.1 延伸阅读 - -- [网络模式](README.md):Docker 网络概览 -- [端口映射](port_mapping.md):外部访问 - -| 要点 | 说明 | -|------|------| -| **-p** | 指定端口映射 (常用),如 `8080:80` | -| **-P** | 随机映射所有 EXPOSE 的端口 | -| **安全性** | 默认监听所有 IP,敏感服务应绑定 `127.0.0.1` | -| **查看** | 使用 `docker port` 或 `docker ps` | - -### 8.9.2 延伸阅读 - -- [EXPOSE 指令](../../07_dockerfile/7.9_expose.md):在 Dockerfile 中声明端口 -- [网络模式](README.md):Host 模式不需要端口映射 diff --git a/09_network/README.md b/09_network/README.md new file mode 100644 index 0000000..9eaf425 --- /dev/null +++ b/09_network/README.md @@ -0,0 +1,41 @@ +# 网络配置 + +Docker 容器需要网络来与外部世界通信、容器之间相互通信以及与宿主机通信。Docker 在安装时会自动配置网络基础设施,大多数情况下开箱即用。 + +## 概述 + +Docker 启动时自动创建以下网络组件: + +```mermaid +graph TD + subgraph Host [宿主机] + eth0[物理网卡 eth0
192.168.1.100] + docker0[docker0 网桥
172.17.0.1] + + subgraph Containers + subgraph ContainerA [容器 A] + eth0_A[eth0
172.17.0.2] + end + subgraph ContainerB [容器 B] + eth0_B[eth0
172.17.0.3] + end + end + + eth0 <--> docker0 + docker0 <--> eth0_A + docker0 <--> eth0_B + end + + Internet((互联网)) <--> eth0 +``` + +本章将详细介绍 Docker 网络配置的各个方面。 + +## 本章内容 + +* [配置 DNS](dns.md) +* [外部访问容器](port_mapping.md) +* [网络类型](network_types.md) +* [自定义网络](custom_network.md) +* [容器互联](container_linking.md) +* [网络隔离](network_isolation.md) diff --git a/09_network/container_linking.md b/09_network/container_linking.md new file mode 100644 index 0000000..2ae8877 --- /dev/null +++ b/09_network/container_linking.md @@ -0,0 +1,62 @@ +## 9.5 容器互联 + +容器之间的网络通信是 Docker 网络的核心功能之一。本节介绍容器互联的几种方式。 + +### 9.5.1 同一网络内的容器 + +同一自定义网络内的容器可以直接通过容器名通信,这是推荐的容器互联方式: + +```bash +## 创建网络 + +$ docker network create app-net + +## 启动应用和数据库 + +$ docker run -d --name redis --network app-net redis +$ docker run -d --name app --network app-net myapp + +## app 容器中可以用 redis:6379 连接 Redis + +... +``` + +### 9.5.2 连接到多个网络 + +一个容器可以同时连接到多个网络,这对于需要跨网络通信的中间件容器特别有用: + +```bash +## 启动容器 + +$ docker run -d --name multi-net-container --network frontend nginx + +## 再连接到另一个网络 + +$ docker network connect backend multi-net-container + +## 查看容器的网络 + +$ docker inspect multi-net-container --format '{{json .NetworkSettings.Networks}}' +``` + +### 9.5.3 ⚠️ --link 已废弃 + +`--link` 是 Docker 早期用于容器互联的方式,**已经被废弃**,不建议在新项目中使用。请使用自定义网络替代: + +```bash +## 旧方式(不推荐) + +$ docker run --link db:database myapp + +## 新方式(推荐) + +$ docker network create mynet +$ docker run --network mynet --name db postgres +$ docker run --network mynet --name app myapp +``` + +使用自定义网络的优势在于: + +- 原生支持 DNS 解析 +- 不需要在容器启动时显式声明依赖 +- 更灵活,可以动态 connect/disconnect diff --git a/09_network/custom_network.md b/09_network/custom_network.md new file mode 100644 index 0000000..3bd61c6 --- /dev/null +++ b/09_network/custom_network.md @@ -0,0 +1,93 @@ +## 9.4 用户自定义网络 (推荐) + +在生产环境中,推荐使用用户自定义网络代替默认的 bridge 网络。自定义网络提供了更好的隔离性和服务发现能力。 + +### 9.4.1 为什么要用自定义网络 + +默认 bridge 网络存在以下局限,而自定义网络可以很好地解决这些问题: + +| 问题 | 自定义网络的优势 | +|------|-----------------| +| 只能用 IP 通信 | 支持容器名 DNS 解析 | +| 所有容器在同一网络 | 更好的隔离性 | +| 需要 --link (已废弃)| 原生支持服务发现 | + +### 9.4.2 创建自定义网络 + +使用 `docker network create` 命令可以创建自定义网络: + +```bash +## 创建网络 + +$ docker network create mynet + +## 查看网络详情 + +$ docker network inspect mynet +``` + +### 9.4.3 使用自定义网络 + +启动容器时通过 `--network` 参数指定连接的网络: + +```bash +## 启动容器并连接到自定义网络 + +$ docker run -d --name web --network mynet nginx +$ docker run -d --name db --network mynet postgres + +## 在 web 容器中可以直接用容器名访问 db + +$ docker exec web ping db +PING db (172.18.0.3): 56 data bytes +64 bytes from 172.18.0.3: seq=0 ttl=64 time=0.083 ms +``` + +### 9.4.4 容器名 DNS 解析 + +自定义网络自动提供 DNS 服务。Docker 守护进程在 `127.0.0.11` 运行了一个嵌入式 DNS 服务器,容器内的 DNS 请求会被转发到这里: + +- 如果是容器名,解析为容器 IP +- 如果是外部域名 (如 google.com),转发给上游 DNS + +```mermaid +flowchart LR + subgraph MyNet ["mynet 网络 : web 容器可以用 'db' 作为主机名访问 db 容器"] + direction LR + Web["web
172.18.0.2"] -- "DNS: 'db' → 172.18.0.3" --> DB["db
172.18.0.3"] + end +``` + +### 9.4.5 常用网络命令 + +以下是 Docker 网络管理中常用的命令: + +```bash +## 列出网络 + +$ docker network ls + +## 创建网络 + +$ docker network create mynet + +## 查看网络详情 + +$ docker network inspect mynet + +## 连接容器到网络 + +$ docker network connect mynet mycontainer + +## 断开网络连接 + +$ docker network disconnect mynet mycontainer + +## 删除网络 + +$ docker network rm mynet + +## 清理未使用的网络 + +$ docker network prune +``` diff --git a/08_data_network/network/dns.md b/09_network/dns.md similarity index 84% rename from 08_data_network/network/dns.md rename to 09_network/dns.md index eca8e24..e246436 100644 --- a/08_data_network/network/dns.md +++ b/09_network/dns.md @@ -1,8 +1,8 @@ -## 8.7 配置 DNS +## 9.2 配置 DNS -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: +Docker 容器的 DNS 配置决定了容器如何解析域名。理解 DNS 机制对于容器网络的正确配置至关重要。 -### 8.7.1 容器的 DNS 机制 +### 9.2.1 容器的 DNS 机制 Docker 容器的 DNS 配置有两种情况: @@ -11,9 +11,9 @@ Docker 容器的 DNS 配置有两种情况: --- -### 8.7.2 嵌入式 DNS +### 9.2.2 嵌入式 DNS -这是 Docker 网络最强大的功能之一。在自定义网络中,容器可以通过 “名字” 找到彼此,而不需要知道对方的 IP (因为 IP 可能会变)。 +这是 Docker 网络最强大的功能之一。在自定义网络中,容器可以通过 "名字" 找到彼此,而不需要知道对方的 IP (因为 IP 可能会变)。 ```bash ## 1. 创建自定义网络 @@ -36,7 +36,7 @@ Docker 守护进程在 `127.0.0.11` 运行了一个 DNS 服务器。容器内的 --- -### 8.7.3 配置 DNS 参数 +### 9.2.3 配置 DNS 参数 如果你需要手动配置容器的 DNS (例如使用内网 DNS 服务器),可以在 `docker run` 中使用以下参数: @@ -67,7 +67,7 @@ $ docker run -h myweb nginx --- -### 8.7.4 全局 DNS 配置 +### 9.2.4 全局 DNS 配置 如果希望所有容器都使用特定的 DNS 服务器 (而不是继承宿主机),可以修改 `/etc/docker/daemon.json`: @@ -84,9 +84,9 @@ $ docker run -h myweb nginx --- -### 8.7.5 常见问题 +### 9.2.5 常见问题 -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: +以下是使用容器 DNS 时常见的问题及解决方法: #### Q:容器无法解析域名 diff --git a/09_network/network_isolation.md b/09_network/network_isolation.md new file mode 100644 index 0000000..5b783b8 --- /dev/null +++ b/09_network/network_isolation.md @@ -0,0 +1,81 @@ +## 9.7 网络隔离 + +Docker 网络提供了天然的隔离能力,不同网络之间的容器默认无法通信。这是 Docker 网络安全的重要基础。 + +### 9.7.1 网络隔离原理 + +不同网络之间默认隔离,容器只能与同一网络中的容器直接通信: + +```bash +## 创建两个网络 + +$ docker network create frontend +$ docker network create backend + +## 容器 A 在 frontend + +$ docker run -d --name web --network frontend nginx + +## 容器 B 在 backend + +$ docker run -d --name db --network backend postgres + +## web 无法直接访问 db(不同网络) + +$ docker exec web ping db +ping: db: Name or service not known +``` + +### 9.7.2 安全优势 + +这种隔离机制带来以下安全优势: + +| 场景 | 说明 | +|------|------| +| **前后端分离** | 前端容器无法直接访问数据库网络 | +| **微服务隔离** | 不同微服务组可以使用不同网络 | +| **多租户** | 不同租户的容器在不同网络中完全隔离 | +| **最小权限** | 容器只能访问必要的网络资源 | + +### 9.7.3 跨网络通信 + +如果确实需要某个容器跨网络通信,可以将其同时连接到多个网络: + +```bash +## 创建一个中间件容器,连接到两个网络 + +$ docker run -d --name api --network frontend myapi +$ docker network connect backend api + +## 现在 api 容器既可以访问 frontend 中的 web,也可以访问 backend 中的 db +``` + +这种方式让你可以精确控制哪些容器可以跨网络通信,遵循最小权限原则。 + +### 9.7.4 典型网络架构 + +一个典型的多层应用网络架构如下: + +```mermaid +graph TD + subgraph FrontendNet ["frontend 网络"] + LB["负载均衡器"] + Web1["Web 服务器 1"] + Web2["Web 服务器 2"] + end + + subgraph BackendNet ["backend 网络"] + API["API 服务器"] + DB["数据库"] + Cache["Redis 缓存"] + end + + LB --> Web1 + LB --> Web2 + Web1 -.-> API + Web2 -.-> API + API --> DB + API --> Cache +``` + +在这种架构中,API 服务器同时连接到 `frontend` 和 `backend` 网络,充当两个网络之间的桥梁。负载均衡器和 Web 服务器无法直接访问数据库,增强了安全性。 diff --git a/09_network/network_types.md b/09_network/network_types.md new file mode 100644 index 0000000..f795709 --- /dev/null +++ b/09_network/network_types.md @@ -0,0 +1,78 @@ +## 9.3 Docker 网络类型 + +Docker 提供了多种网络驱动来满足不同的使用场景。安装 Docker 后,系统会自动创建三个默认网络: + +```bash +$ docker network ls +NETWORK ID NAME DRIVER SCOPE +abc123... bridge bridge local +def456... host host local +ghi789... none null local +``` + +### 9.3.1 网络类型对比 + +各网络类型的特点和适用场景如下: + +| 网络类型 | 说明 | 适用场景 | +|---------|------|---------| +| **bridge** | 默认类型,容器连接到虚拟网桥 | 大多数单机场景 | +| **host** | 容器直接使用宿主机网络栈 | 需要最高网络性能时 | +| **none** | 禁用网络 | 完全隔离的容器 | +| **overlay** | 跨主机网络 | Docker Swarm 集群 | +| **macvlan** | 容器拥有独立 MAC 地址 | 需要直接接入物理网络 | + +### 9.3.2 Bridge 网络 (默认) + +Bridge 是 Docker 默认使用的网络模式。Docker 启动时会自动创建 `docker0` 虚拟网桥,所有未指定网络的容器都会连接到这个网桥上。 + +核心组件如下: + +| 组件 | 说明 | +|------|------| +| **docker0** | 虚拟网桥,充当交换机角色 | +| **veth pair** | 虚拟网卡对,一端在容器内,一端连接网桥 | +| **容器 eth0** | 容器内的网卡 | +| **IP 地址** | 自动从 172.17.0.0/16 网段分配 | + +### 9.3.3 Host 网络 + +使用 `--network host` 参数启动的容器会直接使用宿主机的网络栈,不再拥有独立的网络命名空间。容器内的端口就是宿主机的端口,无需端口映射。 + +```bash +$ docker run -d --network host nginx +``` + +这种模式下网络性能最高,但容器之间和宿主机之间没有网络隔离。 + +### 9.3.4 None 网络 + +使用 `--network none` 参数启动的容器只有 `lo` 回环网卡,完全没有外部网络连接。适用于只需要运行计算任务、不需要网络的容器。 + +```bash +$ docker run -it --network none alpine ip addr +1: lo: ... + inet 127.0.0.1/8 scope host lo +``` + +### 9.3.5 数据流向 + +容器网络中的数据流向可以分为以下几种情况: + +```mermaid +flowchart LR + subgraph Comm1 ["容器间通信"] + direction LR + C1A["容器 A (172.17.0.2)"] --> D0A["docker0"] --> C1B["容器 B (172.17.0.3)"] + end + + subgraph Comm2 ["访问外网"] + direction LR + C2A["容器 A (172.17.0.2)"] --> D0B["docker0"] --> Eth0A["eth0"] --> InternetA["互联网"] + end + + subgraph Comm3 ["被外部访问,需端口映射"] + direction LR + Req["外部请求"] --> Eth0B["eth0"] --> D0C["docker0"] --> C3A["容器 A"] + end +``` diff --git a/08_data_network/network/port_mapping.md b/09_network/port_mapping.md similarity index 70% rename from 08_data_network/network/port_mapping.md rename to 09_network/port_mapping.md index c6bcc93..108d402 100644 --- a/08_data_network/network/port_mapping.md +++ b/09_network/port_mapping.md @@ -1,10 +1,10 @@ -## 8.8 外部访问容器 +## 9.6 外部访问容器 -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: +容器运行在自己的隔离网络环境中 (通常是 Bridge 模式)。为了让外部网络访问容器内的服务,我们需要将容器的端口映射到宿主机的端口。 -### 8.8.1 为什么要映射端口 +### 9.6.1 为什么要映射端口 -容器运行在自己的隔离网络环境中 (通常是 Bridge 模式)。这意味着: +容器的网络访问规则如下: - **容器之间**:可以通过 IP 或容器名 (自定义网络) 互通。 - **宿主机访问容器**:可以通过容器 IP 访问。 @@ -21,16 +21,13 @@ flowchart TD --- -### 8.8.2 端口映射方式 +### 9.6.2 端口映射方式 -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: +Docker 提供了多种方式来指定端口映射。 -#### 1。指定映射 +#### 1. 指定映射 -Docker 提供了多种方式来指定端口映射,最常用的是 `-p` 参数。 - - -使用 `-p <宿主机端口>:<容器端口>` 格式。 +使用 `-p <宿主机端口>:<容器端口>` 格式: ```bash ## 将宿主机的 8080 端口映射到容器的 80 端口 @@ -49,12 +46,9 @@ $ docker run -d -p 8080:80 nginx | `hostPort:containerPort` | 绑定所有 IP (0.0.0.0) 的特定端口 | `-p 8080:80` (默认) | | `containerPort` | 绑定所有 IP 的随机端口 | `-p 80` | -#### 2。随机映射 +#### 2. 随机映射 -如果您不关心宿主机使用哪个端口,可以使用随机映射功能。 - - -使用 `-P` (大写) 参数,Docker 会随机映射 Dockerfile 中 `EXPOSE` 指令暴露的所有端口到宿主机的高端口 (49000-49900)。 +如果不关心宿主机使用哪个端口,可以使用随机映射。使用 `-P` (大写) 参数,Docker 会随机映射 Dockerfile 中 `EXPOSE` 指令暴露的所有端口到宿主机的高端口 (49000-49900)。 ```bash $ docker run -d -P nginx @@ -72,16 +66,13 @@ abc123456 0.0.0.0:49153->80/tcp --- -### 8.8.3 查看端口映射 +### 9.6.3 查看端口映射 -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: +可以使用以下命令查看容器的端口映射: #### docker port -我们可以使用 `docker port` 命令来查看当前容器的端口映射规则。 - - -运行以下命令: +运行 `docker port` 可以查看到指定容器的端口映射情况: ```bash $ docker port mycontainer @@ -91,7 +82,7 @@ $ docker port mycontainer #### docker ps -运行以下命令: +运行 `docker ps` 可以查看到所有容器的端口映射列表: ```bash $ docker ps @@ -101,14 +92,11 @@ abc123456 nginx 0.0.0.0:8080->80/tcp web --- -### 8.8.4 最佳实践与安全 +### 9.6.4 最佳实践与安全 -本节涵盖了相关内容与详细描述,主要探讨以下几个方面: - -#### 1。限制监听 IP - -为了保证服务的安全性,我们应该谨慎选择绑定的 IP 地址。 +在配置端口映射时,需要注意以下安全事项: +#### 1. 限制监听 IP 默认情况下,`-p 8080:80` 会监听 `0.0.0.0:8080`,这意味着任何人只要能连接你的宿主机 IP,就能访问该服务。 @@ -120,7 +108,7 @@ abc123456 nginx 0.0.0.0:8080->80/tcp web $ docker run -d -p 127.0.0.1:3306:3306 mysql ``` -#### 2。避免端口冲突 +#### 2. 避免端口冲突 如果宿主机 8080 已经被占用了,容器将无法启动。 @@ -129,7 +117,7 @@ $ docker run -d -p 127.0.0.1:3306:3306 mysql - 更换宿主机端口:`-p 8081:80` - 让 Docker 自动分配:`-p 80` -#### 3。UDP 映射 +#### 3. UDP 映射 默认是 TCP 协议。如果要映射 UDP 服务 (如 DNS,Syslog): @@ -139,7 +127,7 @@ $ docker run -d -p 53:53/udp dns-server --- -### 8.8.5 实现原理 +### 9.6.5 实现原理 Docker 使用 `docker-proxy` 进程 (用户态) 或 `iptables` DNAT 规则 (内核态) 来实现端口转发。 diff --git a/09_network/summary.md b/09_network/summary.md new file mode 100644 index 0000000..d1bed18 --- /dev/null +++ b/09_network/summary.md @@ -0,0 +1,24 @@ +## 9.8 本章小结 + +本章介绍了 Docker 网络配置的各个方面: + +| 概念 | 要点 | +|------|------| +| **DNS 配置** | 自定义网络支持嵌入式 DNS,可通过容器名解析 | +| **网络类型** | bridge (默认)、host、none、overlay、macvlan | +| **自定义网络** | 推荐使用,支持容器名 DNS 解析和更好的隔离 | +| **容器互联** | 同一自定义网络内容器可直接通过容器名通信 | +| **端口映射** | `-p 宿主机端口:容器端口` 暴露服务到外部 | +| **网络隔离** | 不同网络默认隔离,增强安全性 | +| **--link** | 已废弃,使用自定义网络替代 | + +### 9.8.1 延伸阅读 + +- [配置 DNS](dns.md):自定义 DNS 设置 +- [网络类型](network_types.md):Bridge、Host、None 等网络模式 +- [自定义网络](custom_network.md):创建和管理自定义网络 +- [容器互联](container_linking.md):容器间通信方式 +- [端口映射](port_mapping.md):高级端口配置 +- [网络隔离](network_isolation.md):网络安全与隔离策略 +- [EXPOSE 指令](../07_dockerfile/7.9_expose.md):在 Dockerfile 中声明端口 +- [Compose 网络](../11_compose/10.5_compose_file.md):Compose 中的网络配置 diff --git a/09_buildx/9.1_buildkit.md b/10_buildx/10.1_buildkit.md similarity index 97% rename from 09_buildx/9.1_buildkit.md rename to 10_buildx/10.1_buildkit.md index 788f694..7c8567f 100644 --- a/09_buildx/9.1_buildkit.md +++ b/10_buildx/10.1_buildkit.md @@ -1,4 +1,4 @@ -## 9.1 使用 `BuildKit` 构建镜像 +## 10.1 使用 `BuildKit` 构建镜像 **BuildKit** 是下一代的镜像构建组件,在 https://github.com/moby/buildkit 开源。 @@ -6,7 +6,7 @@ 目前,Docker Hub 自动构建已经支持 BuildKit,具体请参考 https://github.com/docker-practice/docker-hub-buildx -### 9.1.1 `Dockerfile` 新增指令详解 +### 10.1.1 `Dockerfile` 新增指令详解 BuildKit 引入了多项新指令,旨在优化构建缓存和安全性。以下将详细介绍这些指令的用法。 @@ -159,12 +159,12 @@ $ ssh-add ~/.ssh/id_rsa $ docker build -t test --ssh default=$SSH_AUTH_SOCK . ``` -### 9.1.2 使用 `docker compose build` 与 BuildKit +### 10.1.2 使用 `docker compose build` 与 BuildKit Docker Compose 同样支持 BuildKit,这使得多服务应用的构建更加高效。 自 Docker 23.0 起,BuildKit 已默认启用,无需额外配置。如果使用旧版本,可设置 `DOCKER_BUILDKIT=1` 环境变量启用。 -### 9.1.3 官方文档 +### 10.1.3 官方文档 * https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md diff --git a/09_buildx/9.2_buildx.md b/10_buildx/10.2_buildx.md similarity index 93% rename from 09_buildx/9.2_buildx.md rename to 10_buildx/10.2_buildx.md index bb0add3..4a7d73d 100644 --- a/09_buildx/9.2_buildx.md +++ b/10_buildx/10.2_buildx.md @@ -1,8 +1,8 @@ -## 9.2 使用 Buildx 构建镜像 +## 10.2 使用 Buildx 构建镜像 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: -### 9.2.1 使用 +### 10.2.1 使用 Buildx 的使用非常直观,绝大多数情况下可以替代 `docker build` 命令。 @@ -40,6 +40,6 @@ $ docker buildx build --sbom=true -t myimage . 该命令会在构建结果中包含 SPDX 或 CycloneDX 格式的 SBOM 数据。 -### 9.2.2 官方文档 +### 10.2.2 官方文档 * https://docs.docker.com/engine/reference/commandline/buildx/ diff --git a/09_buildx/9.3_multi-arch-images.md b/10_buildx/10.3_multi-arch-images.md similarity index 95% rename from 09_buildx/9.3_multi-arch-images.md rename to 10_buildx/10.3_multi-arch-images.md index 6049772..50e1aa0 100644 --- a/09_buildx/9.3_multi-arch-images.md +++ b/10_buildx/10.3_multi-arch-images.md @@ -1,8 +1,8 @@ -## 9.3 构建多种系统架构支持的 Docker 镜像 +## 10.3 构建多种系统架构支持的 Docker 镜像 Docker 镜像可以支持多种系统架构,这意味着你可以在 `x86_64`、`arm64` 等不同架构的机器上运行同一个镜像。这是通过一个名为 “manifest list” (或称为 “fat manifest”) 的文件来实现的。 -### 9.3.1 Manifest List 是什么? +### 10.3.1 Manifest List 是什么? 为了理解多架构镜像的原理,我们需要先了解 Manifest List 的概念。 @@ -40,7 +40,7 @@ $ docker manifest inspect hello-world } ``` -### 9.3.2 使用 `docker buildx` 构建多架构镜像 +### 10.3.2 使用 `docker buildx` 构建多架构镜像 `docker buildx` 是构建多架构镜像的最佳实践工具,它屏蔽了底层的复杂性,提供了一键构建多架构镜像的能力。 @@ -101,7 +101,7 @@ COPY bin/dist-${TARGETOS}-${TARGETARCH} /dist ENTRYPOINT ["/dist"] ``` -### 9.3.3 使用 `docker manifest` (底层工具) +### 10.3.3 使用 `docker manifest` (底层工具) 除了 `docker buildx`,我们也可以直接操作 Manifest List 来手动组合不同架构的镜像。 diff --git a/09_buildx/README.md b/10_buildx/README.md similarity index 95% rename from 09_buildx/README.md rename to 10_buildx/README.md index 16b6b0a..de4fadf 100644 --- a/09_buildx/README.md +++ b/10_buildx/README.md @@ -1,4 +1,4 @@ -# 第九章 Docker Buildx +# 第十章 Docker Buildx Docker Buildx 是一个 docker CLI 插件,其扩展了 docker 命令,支持 [Moby BuildKit](9.1_buildkit.md) 提供的功能。提供了与 docker build 相同的用户体验,并增加了许多新功能。 diff --git a/10_buildx/summary.md b/10_buildx/summary.md new file mode 100644 index 0000000..087ef5b --- /dev/null +++ b/10_buildx/summary.md @@ -0,0 +1,19 @@ +## 10.4 本章小结 + +Docker Buildx 是 Docker 构建系统的重要进化,提供了高效、安全且支持多平台的镜像构建能力。 + +| 概念 | 要点 | +|------|------| +| **BuildKit** | 下一代构建引擎,Docker 23.0+ 默认启用 | +| **缓存挂载** | `RUN --mount=type=cache` 加速依赖安装 | +| **Secret 挂载** | `RUN --mount=type=secret` 安全传递密钥 | +| **buildx build** | 替代 `docker build`,支持更多构建功能 | +| **多架构构建** | `--platform` 参数一键构建多种架构镜像 | +| **Manifest List** | 多架构镜像的索引文件 | +| **SBOM** | 通过 `--sbom=true` 生成软件物料清单 | + +### 10.4.1 延伸阅读 + +- [Dockerfile 指令详解](../07_dockerfile/README.md):Dockerfile 编写基础 +- [多阶段构建](../07_dockerfile/7.17_multistage_builds.md):优化镜像体积 +- [Dockerfile 最佳实践](../appendix/20.1_best_practices.md):编写高效 Dockerfile diff --git a/10_compose/10.1_introduction.md b/11_compose/11.1_introduction.md similarity index 97% rename from 10_compose/10.1_introduction.md rename to 11_compose/11.1_introduction.md index 4c8c1da..cabf4ad 100644 --- a/10_compose/10.1_introduction.md +++ b/11_compose/11.1_introduction.md @@ -1,4 +1,4 @@ -## 10.1 Compose 简介 +## 11.1 Compose 简介 `Compose` 项目是 Docker 官方的开源项目,负责实现对 Docker 容器集群的快速编排。从功能上看,跟 `OpenStack` 中的 `Heat` 十分类似。 @@ -10,11 +10,11 @@ `Compose` 恰好满足了这样的需求。它允许用户通过一个单独的 `compose.yaml` (历史默认名也常见为 `docker-compose.yml`) 模板文件 (YAML 格式) 来定义一组相关联的应用容器为一个项目 (project)。 -### 10.1.1 概述 +### 11.1.1 概述 总体概述了以下内容。 -### 10.1.2 模板文件规范 +### 11.1.2 模板文件规范 Compose 模板文件采用 YAML 格式,扩展名为 `.yml` 或 `.yaml`。 diff --git a/10_compose/10.2_install.md b/11_compose/11.2_install.md similarity index 93% rename from 10_compose/10.2_install.md rename to 11_compose/11.2_install.md index 6cb364e..c99cb8a 100644 --- a/10_compose/10.2_install.md +++ b/11_compose/11.2_install.md @@ -1,4 +1,4 @@ -## 10.2 安装与卸载 +## 11.2 安装与卸载 `Compose` 是 Docker 官方的开源项目,负责实现对 Docker 容器集群的快速编排。 @@ -10,7 +10,7 @@ Linux 系统请使用以下介绍的方法安装。 -### 10.2.1 Linux +### 11.2.1 Linux 在 Linux 上,你可以通过下载 Docker Compose CLI 插件 (二进制文件名为 `docker-compose`) 来安装。 @@ -32,7 +32,7 @@ $ curl -SL https://github.com/docker/compose/releases/download/v5.0.2/docker-com $ chmod +x $DOCKER_CONFIG/cli-plugins/docker-compose ``` -### 10.2.2 测试安装 +### 11.2.2 测试安装 运行以下命令: @@ -41,7 +41,7 @@ $ docker compose version Docker Compose version v5.0.2 ``` -### 10.2.3 bash 补全命令 +### 11.2.3 bash 补全命令 运行以下命令: @@ -49,7 +49,7 @@ Docker Compose version v5.0.2 $ curl -L https://raw.githubusercontent.com/docker/compose/v5.0.2/contrib/completion/bash/docker-compose | sudo tee /etc/bash_completion.d/docker-compose > /dev/null ``` -### 10.2.4 卸载 +### 11.2.4 卸载 如果是二进制包方式安装的,删除二进制文件即可。 diff --git a/10_compose/10.3_usage.md b/11_compose/11.3_usage.md similarity index 97% rename from 10_compose/10.3_usage.md rename to 11_compose/11.3_usage.md index 30b46b7..89a61d0 100644 --- a/10_compose/10.3_usage.md +++ b/11_compose/11.3_usage.md @@ -1,8 +1,8 @@ -## 10.3 使用 +## 11.3 使用 本节将通过一个具体的 Web 应用案例,介绍 Docker Compose 的基本概念和使用方法。 -### 10.3.1 术语 +### 11.3.1 术语 首先介绍几个术语。 @@ -12,7 +12,7 @@ 可见,一个项目可以由多个服务 (容器) 关联而成,`Compose` 面向项目进行管理。 -### 10.3.2 场景 +### 11.3.2 场景 最常见的项目是 web 网站,该项目应该包含 web 应用和缓存。 diff --git a/10_compose/10.4_commands.md b/11_compose/11.4_commands.md similarity index 98% rename from 10_compose/10.4_commands.md rename to 11_compose/11.4_commands.md index 5569a3d..5a81d8d 100644 --- a/10_compose/10.4_commands.md +++ b/11_compose/11.4_commands.md @@ -1,8 +1,8 @@ -## 10.4 Compose 命令说明 +## 11.4 Compose 命令说明 Docker Compose 提供了丰富的命令来管理项目和容器。本节将详细介绍这些命令的使用格式和常用选项。 -### 10.4.1 命令对象与格式 +### 11.4.1 命令对象与格式 对于 Compose 来说,大部分命令的对象既可以是项目本身,也可以指定为项目中的服务或者容器。如果没有特别的说明,命令对象将是项目,这意味着项目中所有的服务都会受到命令影响。 @@ -14,7 +14,7 @@ Docker Compose 提供了丰富的命令来管理项目和容器。本节将详 docker compose [-f=...] [options] [COMMAND] [ARGS...] ``` -### 10.4.2 命令选项 +### 11.4.2 命令选项 * `-f, --file FILE` 指定使用的 Compose 模板文件。默认会自动识别 `compose.yaml` (也兼容 `docker-compose.yml` 等),并且可以多次指定。 @@ -24,7 +24,7 @@ docker compose [-f=...] [options] [COMMAND] [ARGS...] * `-v, --version` 打印版本并退出。 -### 10.4.3 命令使用说明 +### 11.4.3 命令使用说明 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: diff --git a/10_compose/10.5_compose_file.md b/11_compose/11.5_compose_file.md similarity index 93% rename from 10_compose/10.5_compose_file.md rename to 11_compose/11.5_compose_file.md index 613bc09..e84d88c 100644 --- a/10_compose/10.5_compose_file.md +++ b/11_compose/11.5_compose_file.md @@ -1,4 +1,4 @@ -## 10.5 Compose 模板文件 +## 11.5 Compose 模板文件 模板文件是使用 `Compose` 的核心,涉及到的指令关键字也比较多。但大家不用担心,这里面大部分指令跟 `docker run` 相关参数的含义都是类似的。 @@ -20,7 +20,7 @@ services: 下面分别介绍各个指令的用法。 -### 10.5.1 `build` +### 11.5.1 `build` 指定 `Dockerfile` 所在文件夹的路径 (可以是绝对路径,或者相对 Compose 文件的路径)。`Compose` 将会利用它自动构建这个镜像,然后使用这个镜像。 @@ -56,7 +56,7 @@ build: - corp/web_app:3.14 ``` -### 10.5.2 `cap_add, cap_drop` +### 11.5.2 `cap_add, cap_drop` 指定容器的内核能力 (capacity) 分配。 @@ -74,7 +74,7 @@ cap_drop: - NET_ADMIN ``` -### 10.5.3 `command` +### 11.5.3 `command` 覆盖容器启动后默认执行的命令。 @@ -82,11 +82,11 @@ cap_drop: command: echo "hello world" ``` -### 10.5.4 `configs` +### 11.5.4 `configs` `configs` 来自 Compose Specification。它在 Swarm 中是原生对象;在本地 `docker compose` 模式下通常以文件挂载的形式实现,具体能力取决于 Compose 版本与运行平台。 -### 10.5.5 `cgroup_parent` +### 11.5.5 `cgroup_parent` 指定父 `cgroup` 组,意味着将继承该组的资源限制。 @@ -96,7 +96,7 @@ command: echo "hello world" cgroup_parent: cgroups_1 ``` -### 10.5.6 `container_name` +### 11.5.6 `container_name` 指定容器名称。默认将会使用 `项目名称_服务名称_序号` 这样的格式。 @@ -106,11 +106,11 @@ container_name: docker-web-container >注意:指定容器名称后,该服务将无法进行扩展 (scale),因为 Docker 不允许多个容器具有相同的名称。 -### 10.5.7 `deploy` +### 11.5.7 `deploy` `deploy` 用于描述副本数、更新策略、资源限制等部署参数。该字段在 Swarm 中支持最完整;在本地 `docker compose up` 场景下通常只有部分字段生效。 -### 10.5.8 `devices` +### 11.5.8 `devices` 指定设备映射关系。 @@ -119,7 +119,7 @@ devices: - "/dev/ttyUSB1:/dev/ttyUSB0" ``` -### 10.5.9 `depends_on` +### 11.5.9 `depends_on` 解决容器的依赖、启动先后的问题。以下例子中会先启动 `redis` `db` 再启动 `web` @@ -140,7 +140,7 @@ services: >注意:`web` 服务不会等待 `redis` `db` “完全启动” 之后才启动。 -### 10.5.10 `dns` +### 11.5.10 `dns` 自定义 `DNS` 服务器。可以是一个值,也可以是一个列表。 @@ -152,7 +152,7 @@ dns: - 114.114.114.114 ``` -### 10.5.11 `dns_search` +### 11.5.11 `dns_search` 配置 `DNS` 搜索域。可以是一个值,也可以是一个列表。 @@ -164,7 +164,7 @@ dns_search: - domain2.example.com ``` -### 10.5.12 `tmpfs` +### 11.5.12 `tmpfs` 挂载一个 tmpfs 文件系统到容器。 @@ -175,7 +175,7 @@ tmpfs: - /tmp ``` -### 10.5.13 `env_file` +### 11.5.13 `env_file` 从文件中获取环境变量,可以为单独的文件路径或列表。 @@ -200,7 +200,7 @@ env_file: PROG_ENV=development ``` -### 10.5.14 `environment` +### 11.5.14 `environment` 设置环境变量。你可以使用数组或字典两种格式。 @@ -222,7 +222,7 @@ environment: y|Y|yes|Yes|YES|n|N|no|No|NO|true|True|TRUE|false|False|FALSE|on|On|ON|off|Off|OFF ``` -### 10.5.15 `expose` +### 11.5.15 `expose` 暴露端口,但不映射到宿主机,只被连接的服务访问。 @@ -234,7 +234,7 @@ expose: - "8000" ``` -### 10.5.16 `external_links` +### 11.5.16 `external_links` >注意:不建议使用该指令。 @@ -247,7 +247,7 @@ external_links: - project_db_1:postgresql ``` -### 10.5.17 `extra_hosts` +### 11.5.17 `extra_hosts` 类似 Docker 中的 `--add-host` 参数,指定额外的 host 名称映射信息。 @@ -264,7 +264,7 @@ extra_hosts: 52.1.157.61 dockerhub ``` -### 10.5.18 `healthcheck` +### 11.5.18 `healthcheck` 通过命令检查容器是否健康运行。 @@ -276,7 +276,7 @@ healthcheck: retries: 3 ``` -### 10.5.19 `image` +### 11.5.19 `image` 指定为镜像名称或镜像 ID。如果镜像在本地不存在,`Compose` 将会尝试拉取这个镜像。 @@ -286,7 +286,7 @@ image: orchardup/postgresql image: a4bc65fd ``` -### 10.5.20 `labels` +### 11.5.20 `labels` 为容器添加 Docker 元数据 (metadata) 信息。例如可以为容器添加辅助说明信息。 @@ -297,11 +297,11 @@ labels: com.startupteam.release: "rc3 for v1.0" ``` -### 10.5.21 `links` +### 11.5.21 `links` >注意:不推荐使用该指令。容器之间应通过 Docker 网络 (networks) 进行互联。 -### 10.5.22 `logging` +### 11.5.22 `logging` 配置日志选项。 @@ -328,7 +328,7 @@ options: max-file: "10" ``` -### 10.5.23 `network_mode` +### 11.5.23 `network_mode` 设置网络模式。使用和 `docker run` 的 `--network` 参数一样的值。 @@ -340,7 +340,7 @@ network_mode: "service:[service name]" network_mode: "container:[container name/id]" ``` -### 10.5.24 `networks` +### 11.5.24 `networks` 配置容器连接的网络。 @@ -358,7 +358,7 @@ networks: other-network: ``` -### 10.5.25 `pid` +### 11.5.25 `pid` 跟主机系统共享进程命名空间。打开该选项的容器之间,以及容器和宿主机系统之间可以通过进程 ID 来相互访问和操作。 @@ -366,7 +366,7 @@ networks: pid: "host" ``` -### 10.5.26 `ports` +### 11.5.26 `ports` 暴露端口信息。 @@ -382,7 +382,7 @@ ports: *注意:当使用 `HOST:CONTAINER` 格式来映射端口时,如果你使用的容器端口小于 60 并且没放到引号里,可能会得到错误结果,因为 `YAML` 会自动解析 `xx:yy` 这种数字格式为 60 进制。为避免出现这种问题,建议数字串都采用引号包括起来的字符串格式。* -### 10.5.27 `secrets` +### 11.5.27 `secrets` 存储敏感数据,例如 `mysql` 服务密码。 @@ -405,7 +405,7 @@ secrets: external: true ``` -### 10.5.28 `security_opt` +### 11.5.28 `security_opt` 指定容器模板标签 (label) 机制的默认属性 (用户、角色、类型、级别等)。例如配置标签的用户名和角色名。 @@ -415,7 +415,7 @@ security_opt: - label:role:ROLE ``` -### 10.5.29 `stop_signal` +### 11.5.29 `stop_signal` 设置另一个信号来停止容器。在默认情况下使用的是 SIGTERM 停止容器。 @@ -423,7 +423,7 @@ security_opt: stop_signal: SIGUSR1 ``` -### 10.5.30 `sysctls` +### 11.5.30 `sysctls` 配置容器内核参数。 @@ -437,7 +437,7 @@ sysctls: - net.ipv4.tcp_syncookies=0 ``` -### 10.5.31 `ulimits` +### 11.5.31 `ulimits` 指定容器的 ulimits 限制值。 @@ -451,7 +451,7 @@ sysctls: hard: 40000 ``` -### 10.5.32 `volumes` +### 11.5.32 `volumes` 数据卷所挂载路径设置。可以设置为宿主机路径 (`HOST:CONTAINER`) 或者数据卷名称 (`VOLUME:CONTAINER`),并且可以设置访问模式 (`HOST:CONTAINER:ro`)。 @@ -477,7 +477,7 @@ volumes: mysql_data: ``` -### 10.5.33 其它指令 +### 11.5.33 其它指令 此外,还有包括 `domainname, entrypoint, hostname, ipc, mac_address, privileged, read_only, shm_size, restart, stdin_open, tty, user, working_dir` 等指令,基本跟 `docker run` 中对应参数的功能一致。 @@ -537,7 +537,7 @@ stdin_open: true tty: true ``` -### 10.5.34 读取变量 +### 11.5.34 读取变量 Compose 模板文件支持动态读取主机的系统环境变量和当前目录下的 `.env` 文件中的变量。 diff --git a/10_compose/10.6_django.md b/11_compose/11.6_django.md similarity index 95% rename from 10_compose/10.6_django.md rename to 11_compose/11.6_django.md index 33d183c..b4b5937 100644 --- a/10_compose/10.6_django.md +++ b/11_compose/11.6_django.md @@ -1,10 +1,10 @@ -## 10.6 使用 Django +## 11.6 使用 Django > 本小节内容适合 `Python` 开发人员阅读。 本节将使用 Docker Compose 配置并运行一个 **Django + PostgreSQL** 应用。笔者不仅会介绍具体步骤,还会解释每个配置项的作用,以及开发环境和生产环境的差异。 -### 10.6.1 架构概览 +### 11.6.1 架构概览 在开始之前,先看整体架构 (如图 10-1 所示): @@ -40,7 +40,7 @@ flowchart TD - 两个服务通过 Docker Compose 自动创建的网络相互通信 - `web` 服务可以通过服务名 `db` 访问数据库 (Docker 内置 DNS) -### 10.6.2 准备工作 +### 11.6.2 准备工作 创建一个项目目录并进入: @@ -50,7 +50,7 @@ $ mkdir django-docker && cd django-docker 我们需要创建三个文件:`Dockerfile`、`requirements.txt` 和 `compose.yaml`。 -### 10.6.3 步骤 1:创建 Dockerfile +### 11.6.3 步骤 1:创建 Dockerfile 如下代码块所示,展示了相关示例: @@ -90,7 +90,7 @@ COPY . /code/ > 💡 **笔者建议**:总是将变化频率低的文件先复制,变化频率高的后复制。这样可以最大化利用 Docker 的构建缓存。 -### 10.6.4 步骤 2:创建 requirements.txt +### 11.6.4 步骤 2:创建 requirements.txt 如下代码块所示,展示了相关示例: @@ -108,7 +108,7 @@ gunicorn>=21.0,<22.0 | `psycopg[binary]` | PostgreSQL 数据库驱动 (推荐使用 psycopg 3)| | `gunicorn` | 生产环境 WSGI 服务器 (可选,开发时可不用)| -### 10.6.5 步骤 3:创建 compose.yaml +### 11.6.5 步骤 3:创建 compose.yaml 配置如下: @@ -192,7 +192,7 @@ web: | `depends_on` + `healthcheck` | 启动顺序 | 确保数据库就绪后 Django 才启动,避免连接错误 | | `environment` | 环境变量 | 推荐用环境变量管理配置,避免硬编码 | -### 10.6.6 步骤 4:创建 Django 项目 +### 11.6.6 步骤 4:创建 Django 项目 运行以下命令创建新的 Django 项目: @@ -225,7 +225,7 @@ django-docker/ > 💡 **Linux 用户注意**:如果遇到权限问题,执行 `sudo chown -R $USER:$USER .` -### 10.6.7 步骤 5:配置数据库连接 +### 11.6.7 步骤 5:配置数据库连接 修改 `mysite/settings.py`,配置数据库连接: @@ -252,7 +252,7 @@ ALLOWED_HOSTS = ['*'] 在 Docker Compose 中,各服务通过服务名相互访问。Docker 内置的 DNS 会将 `db` 解析为 db 服务容器的 IP 地址。这是 Docker Compose 的核心功能之一。 -### 10.6.8 步骤 6:启动应用 +### 11.6.8 步骤 6:启动应用 运行以下命令: @@ -275,7 +275,7 @@ web-1 | Starting development server at http://0.0.0.0:8000/ 打开浏览器访问 http://localhost:8000,可以看到 Django 欢迎页面! -### 10.6.9 常用开发命令 +### 11.6.9 常用开发命令 在另一个终端窗口执行: @@ -299,7 +299,7 @@ $ docker compose exec db psql -U django_user -d django_db > 💡 笔者建议使用 `exec` 而不是 `run`。`exec` 在已运行的容器中执行命令,`run` 会创建新容器。 -### 10.6.10 常见问题排查 +### 11.6.10 常见问题排查 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -338,7 +338,7 @@ $ docker compose logs db $ sudo chown -R $USER:$USER . ``` -### 10.6.11 开发 vs 生产:关键差异 +### 11.6.11 开发 vs 生产:关键差异 笔者特别提醒,本节的配置是 **开发环境** 配置。生产环境需要以下调整: @@ -366,7 +366,7 @@ services: ``` -### 10.6.12 延伸阅读 +### 11.6.12 延伸阅读 - [Compose 模板文件详解](10.5_compose_file.md):深入理解 Compose 文件的所有配置项 - [使用 WordPress](10.8_wordpress.md):另一个 Compose 实战案例 diff --git a/10_compose/10.7_rails.md b/11_compose/11.7_rails.md similarity index 92% rename from 10_compose/10.7_rails.md rename to 11_compose/11.7_rails.md index 5623b51..2d8f546 100644 --- a/10_compose/10.7_rails.md +++ b/11_compose/11.7_rails.md @@ -1,10 +1,10 @@ -## 10.7 使用 Rails +## 11.7 使用 Rails > 本小节内容适合 Ruby 开发人员阅读。 本节使用 Docker Compose 配置并运行一个 **Rails + PostgreSQL** 应用。 -### 10.7.1 架构概览 +### 11.7.1 架构概览 如图 10-2 所示,Rails 与 PostgreSQL 在同一 Compose 网络中协同工作。 @@ -33,7 +33,7 @@ flowchart TD 图 10-2 Rails + PostgreSQL 的 Compose 架构 -### 10.7.2 准备工作 +### 11.7.2 准备工作 创建项目目录: @@ -43,7 +43,7 @@ $ mkdir rails-docker && cd rails-docker 需要创建三个文件:`Dockerfile`、`Gemfile` 和 `compose.yaml`。 -### 10.7.3 步骤 1:创建 Dockerfile +### 11.7.3 步骤 1:创建 Dockerfile 如下代码块所示,展示了相关示例: @@ -80,7 +80,7 @@ COPY . /myapp | `nodejs` | Rails Asset Pipeline 需要 | | 先复制 Gemfile | 只有依赖变化时才重新 `bundle install` | -### 10.7.4 步骤 2:创建 Gemfile +### 11.7.4 步骤 2:创建 Gemfile 创建一个初始的 `Gemfile`,稍后会被 `rails new` 覆盖: @@ -95,7 +95,7 @@ gem 'rails', '~> 7.1' $ touch Gemfile.lock ``` -### 10.7.5 步骤 3:创建 compose.yaml +### 11.7.5 步骤 3:创建 compose.yaml 配置如下: @@ -133,7 +133,7 @@ volumes: | `depends_on: db` | 确保数据库先启动 | | `DATABASE_URL` | Rails 12-factor 风格的数据库配置 | -### 10.7.6 步骤 4:生成 Rails 项目 +### 11.7.6 步骤 4:生成 Rails 项目 使用 `docker compose run` 生成项目骨架: @@ -160,7 +160,7 @@ compose.yaml bin db public > ⚠️ **Linux 用户**:如遇权限问题,执行 `sudo chown -R $USER:$USER .` -### 10.7.7 步骤 5:重新构建镜像 +### 11.7.7 步骤 5:重新构建镜像 由于生成了新的 Gemfile,需要重新构建镜像以安装完整依赖: @@ -168,7 +168,7 @@ compose.yaml bin db public $ docker compose build ``` -### 10.7.8 步骤 6:配置数据库连接 +### 11.7.8 步骤 6:配置数据库连接 修改 `config/database.yml`: @@ -192,7 +192,7 @@ production: > 💡 使用 `DATABASE_URL` 环境变量配置数据库,符合 12-factor 应用原则,便于在不同环境间切换。 -### 10.7.9 步骤 7:启动应用 +### 11.7.9 步骤 7:启动应用 运行以下命令: @@ -212,7 +212,7 @@ web-1 | Puma starting in single mode... web-1 | * Listening on http://0.0.0.0:3000 ``` -### 10.7.10 步骤 8:创建数据库 +### 11.7.10 步骤 8:创建数据库 在另一个终端执行: @@ -224,7 +224,7 @@ Created database 'myapp_test' 访问 http://localhost:3000 查看 Rails 欢迎页面。 -### 10.7.11 常用开发命令 +### 11.7.11 常用开发命令 运行以下命令: @@ -250,7 +250,7 @@ $ docker compose exec web rails generate scaffold Post title:string body:text $ docker compose exec web bash ``` -### 10.7.12 常见问题 +### 11.7.12 常见问题 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -281,7 +281,7 @@ $ docker compose exec web rm -f tmp/pids/server.pid $ docker compose run --rm web bundle update ``` -### 10.7.13 开发 vs 生产 +### 11.7.13 开发 vs 生产 相关信息如下表: @@ -292,7 +292,7 @@ $ docker compose run --rm web bundle update | 静态资源 | 动态编译 | 预编译 (`rails assets:precompile`) | | 数据库密码 | 明文配置 | 使用 Secrets 管理 | -### 10.7.14 延伸阅读 +### 11.7.14 延伸阅读 - [使用 Django](10.6_django.md):Python Web 框架实战 - [Compose 模板文件](10.5_compose_file.md):配置详解 diff --git a/10_compose/10.8_wordpress.md b/11_compose/11.8_wordpress.md similarity index 95% rename from 10_compose/10.8_wordpress.md rename to 11_compose/11.8_wordpress.md index 84f740b..5956a34 100644 --- a/10_compose/10.8_wordpress.md +++ b/11_compose/11.8_wordpress.md @@ -1,10 +1,10 @@ -## 10.8 实战 WordPress +## 11.8 实战 WordPress WordPress 是全球最流行的内容管理系统 (CMS)。使用 Docker Compose 可以在几分钟内搭建一个包含数据库、Web 服务和持久化存储的生产级 WordPress 环境。 --- -### 10.8.1 项目结构 +### 11.8.1 项目结构 如下代码块所示,展示了相关示例: @@ -18,7 +18,7 @@ wordpress/ --- -### 10.8.2 编写 `compose.yaml` +### 11.8.2 编写 `compose.yaml` 这是一个生产可用的最小化配置: @@ -79,7 +79,7 @@ networks: --- -### 10.8.3 配置文件详解 +### 11.8.3 配置文件详解 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -115,7 +115,7 @@ max_execution_time = 600 --- -### 10.8.4 启动与运行 +### 11.8.4 启动与运行 1. 启动服务: @@ -134,7 +134,7 @@ $ docker compose logs -f --- -### 10.8.5 生产环境最佳实践 +### 11.8.5 生产环境最佳实践 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -192,7 +192,7 @@ WordPress 支持 Redis 缓存以提高性能。 --- -### 10.8.6 常见问题 +### 11.8.6 常见问题 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -214,7 +214,7 @@ $ docker compose restart wordpress --- -### 10.8.7 延伸阅读 +### 11.8.7 延伸阅读 - [Compose 模板文件](10.5_compose_file.md):深入了解配置项 - [数据卷](../08_data_network/data/volume.md):理解数据持久化 diff --git a/10_compose/10.9_lnmp.md b/11_compose/11.9_lnmp.md similarity index 86% rename from 10_compose/10.9_lnmp.md rename to 11_compose/11.9_lnmp.md index 4bd06d4..ae96458 100644 --- a/10_compose/10.9_lnmp.md +++ b/11_compose/11.9_lnmp.md @@ -1,3 +1,3 @@ -## 10.9 使用 Compose 搭建 LNMP 环境 +## 11.9 使用 Compose 搭建 LNMP 环境 本项目的维护者 [khs1994](https://github.com/khs1994) 的开源项目 [khs1994-docker/lnmp](https://github.com/khs1994-docker/lnmp) 使用 Docker Compose 搭建了一套 LNMP 环境,各位开发者可以参考该项目在 Docker 或 Kubernetes 中运行 LNMP。 diff --git a/10_compose/README.md b/11_compose/README.md similarity index 94% rename from 10_compose/README.md rename to 11_compose/README.md index c150175..3aaf848 100644 --- a/10_compose/README.md +++ b/11_compose/README.md @@ -1,4 +1,4 @@ -# 第十章 Docker Compose +# 第十一章 Docker Compose `Docker Compose` 是 Docker 官方编排 (Orchestration) 项目之一,负责快速的部署分布式应用。 diff --git a/10_compose/demo/app/Dockerfile b/11_compose/demo/app/Dockerfile similarity index 100% rename from 10_compose/demo/app/Dockerfile rename to 11_compose/demo/app/Dockerfile diff --git a/10_compose/demo/app/app.py b/11_compose/demo/app/app.py similarity index 100% rename from 10_compose/demo/app/app.py rename to 11_compose/demo/app/app.py diff --git a/10_compose/demo/app/docker-compose.yml b/11_compose/demo/app/docker-compose.yml similarity index 100% rename from 10_compose/demo/app/docker-compose.yml rename to 11_compose/demo/app/docker-compose.yml diff --git a/10_compose/demo/django/.gitignore b/11_compose/demo/django/.gitignore similarity index 100% rename from 10_compose/demo/django/.gitignore rename to 11_compose/demo/django/.gitignore diff --git a/10_compose/demo/django/Dockerfile b/11_compose/demo/django/Dockerfile similarity index 100% rename from 10_compose/demo/django/Dockerfile rename to 11_compose/demo/django/Dockerfile diff --git a/10_compose/demo/django/docker-compose.yml b/11_compose/demo/django/docker-compose.yml similarity index 100% rename from 10_compose/demo/django/docker-compose.yml rename to 11_compose/demo/django/docker-compose.yml diff --git a/10_compose/demo/django/requirements.txt b/11_compose/demo/django/requirements.txt similarity index 100% rename from 10_compose/demo/django/requirements.txt rename to 11_compose/demo/django/requirements.txt diff --git a/10_compose/demo/wordpress/docker-compose.yml b/11_compose/demo/wordpress/docker-compose.yml similarity index 100% rename from 10_compose/demo/wordpress/docker-compose.yml rename to 11_compose/demo/wordpress/docker-compose.yml diff --git a/11_compose/summary.md b/11_compose/summary.md new file mode 100644 index 0000000..66419a1 --- /dev/null +++ b/11_compose/summary.md @@ -0,0 +1,21 @@ +## 11.10 本章小结 + +Docker Compose 是管理多容器应用的利器,通过 YAML 文件声明式地定义服务、网络和数据卷。 + +| 概念 | 要点 | +|------|------| +| **核心概念** | 服务 (service) 和项目 (project) | +| **配置文件** | `compose.yaml` (推荐) 或 `docker-compose.yml` | +| **版本** | Compose V2 为 Go 编写的 CLI 插件,通过 `docker compose` 使用 | +| **启动** | `docker compose up -d` 启动所有服务 | +| **停止** | `docker compose down` 停止并移除容器 | +| **查看状态** | `docker compose ps` 查看服务状态 | +| **查看日志** | `docker compose logs` 查看服务日志 | +| **模板文件** | 支持 `services`、`networks`、`volumes` 等顶级配置 | + +### 11.10.1 延伸阅读 + +- [Compose 模板文件](10.5_compose_file.md):详细模板语法参考 +- [Compose 命令说明](10.4_commands.md):完整命令列表 +- [网络配置](../09_network/README.md):Docker 网络基础 +- [数据管理](../08_data/README.md):数据卷管理 diff --git a/11_implementation/11.1_arch.md b/12_implementation/12.1_arch.md similarity index 95% rename from 11_implementation/11.1_arch.md rename to 12_implementation/12.1_arch.md index bd49e4b..fecc62e 100644 --- a/11_implementation/11.1_arch.md +++ b/12_implementation/12.1_arch.md @@ -1,8 +1,8 @@ -## 11.1 基本架构 +## 12.1 基本架构 Docker 的架构设计简洁而高效,主要由客户端和服务端两部分组成。 -### 11.1.1 核心架构图 +### 12.1.1 核心架构图 Docker 采用了 **C/S (客户端/服务端)** 架构。Client 向 Daemon 发送请求,Daemon 负责构建、运行和分发容器。 @@ -23,7 +23,7 @@ graph LR --- -### 11.1.2 组件详解 +### 12.1.2 组件详解 Docker 的内部架构如同洋葱一样分层,每一层专注解决特定问题: @@ -66,7 +66,7 @@ Docker 的大脑。 --- -### 11.1.3 容器启动流程 +### 12.1.3 容器启动流程 当执行 `docker run -d nginx` 时,内部发生了什么? @@ -110,7 +110,7 @@ flowchart TD --- -### 11.1.4 Docker Engine v29+ 变化 +### 12.1.4 Docker Engine v29+ 变化 从 Docker Engine v29 (2025/2026) 开始,架构进一步简化和标准化: @@ -119,7 +119,7 @@ flowchart TD --- -### 11.1.5 Docker Desktop 架构 +### 12.1.5 Docker Desktop 架构 在 macOS 和 Windows 上,因为内核差异,架构稍微复杂: @@ -140,7 +140,7 @@ flowchart TD --- -### 11.1.6 总结 +### 12.1.6 总结 相关信息如下表: @@ -152,7 +152,7 @@ flowchart TD | **Shim** | 监工 | 保持 IO,允许无守护进程重启 | | **Runc** | 工人 | 真正干活 (创建容器),干完就走 | -### 11.1.7 延伸阅读 +### 12.1.7 延伸阅读 - [命名空间](./11.2_namespace.md):Runc 如何隔离容器 - [控制组](./11.3_cgroups.md):Runc 如何限制资源 diff --git a/11_implementation/11.2_namespace.md b/12_implementation/12.2_namespace.md similarity index 96% rename from 11_implementation/11.2_namespace.md rename to 12_implementation/12.2_namespace.md index b807656..b40b57d 100644 --- a/11_implementation/11.2_namespace.md +++ b/12_implementation/12.2_namespace.md @@ -1,6 +1,6 @@ 命名空间 (Namespace) 是 Linux 内核的一个强大特性,为容器提供了隔离的运行环境。 -## 11.2 什么是 Namespace +## 12.2 什么是 Namespace > **Namespace 是 Linux 内核提供的资源隔离机制,它让容器内的进程仿佛运行在独立的操作系统中。** Namespace 是容器技术的核心基础之一。它回答了一个关键问题:**如何让一个进程 “以为” 自己独占整个系统?** @@ -24,7 +24,7 @@ flowchart LR H4 -. "(实际是宿主机的 1234)" .- C1 ``` -### 11.2.1 Namespace 的类型 +### 12.2.1 Namespace 的类型 Linux 内核提供了以下几种 Namespace,Docker 容器使用了全部: @@ -40,7 +40,7 @@ Linux 内核提供了以下几种 Namespace,Docker 容器使用了全部: --- -### 11.2.2 PID Namespace +### 12.2.2 PID Namespace PID Namespace 负责进程 ID 的隔离,使得容器内的进程彼此不可见。 @@ -75,7 +75,7 @@ PID USER COMMAND --- -### 11.2.3 NET Namespace +### 12.2.3 NET Namespace NET Namespace 负责网络栈的隔离,包括网卡、路由表和 iptables 规则等。 @@ -112,7 +112,7 @@ flowchart LR --- -### 11.2.4 MNT Namespace +### 12.2.4 MNT Namespace MNT Namespace 负责文件系统挂载点的隔离,确保容器看到独立的文件系统视图。 @@ -149,7 +149,7 @@ MNT Namespace 负责文件系统挂载点的隔离,确保容器看到独立的 --- -### 11.2.5 UTS Namespace +### 12.2.5 UTS Namespace UTS Namespace 主要用于隔离主机名和域名。 @@ -177,7 +177,7 @@ UTS = “UNIX Time-sharing System”,是历史遗留的名称。 --- -### 11.2.6 IPC Namespace +### 12.2.6 IPC Namespace IPC Namespace 用于隔离进程间通信资源,如 System V IPC 和 POSIX 消息队列。 @@ -198,7 +198,7 @@ IPC Namespace 用于隔离进程间通信资源,如 System V IPC 和 POSIX 消 --- -### 11.2.7 USER Namespace +### 12.2.7 USER Namespace USER Namespace 允许将容器内的用户 ID 映射到宿主机的不同用户 ID。 @@ -236,7 +236,7 @@ flowchart LR --- -### 11.2.8 动手实验:体验 Namespace +### 12.2.8 动手实验:体验 Namespace 使用 `unshare` 命令可以在不使用 Docker 的情况下体验 Namespace: @@ -301,7 +301,7 @@ $ ip addr --- -### 11.2.9 Namespace 的局限性 +### 12.2.9 Namespace 的局限性 Namespace 提供了隔离但不是安全边界: diff --git a/11_implementation/11.3_cgroups.md b/12_implementation/12.3_cgroups.md similarity index 95% rename from 11_implementation/11.3_cgroups.md rename to 12_implementation/12.3_cgroups.md index d0ec9b3..a3f2ab9 100644 --- a/11_implementation/11.3_cgroups.md +++ b/12_implementation/12.3_cgroups.md @@ -1,8 +1,8 @@ -## 11.3 控制组 +## 12.3 控制组 控制组 (Cgroups) 是 Linux 内核提供的另一种关键机制,主要用于资源的限制和审计。 -### 11.3.1 什么是控制组 +### 12.3.1 什么是控制组 控制组 (Control Groups,简称 cgroups) 是 Linux 内核的一个特性,用于 **限制、记录和隔离** 进程组的资源使用 (CPU、内存、磁盘 I/O、网络等)。 @@ -31,7 +31,7 @@ flowchart LR --- -### 11.3.2 cgroups 的历史 +### 12.3.2 cgroups 的历史 相关信息如下表: @@ -44,7 +44,7 @@ flowchart LR --- -### 11.3.3 cgroups 可以限制的资源 +### 12.3.3 cgroups 可以限制的资源 相关信息如下表: @@ -58,7 +58,7 @@ flowchart LR --- -### 11.3.4 Docker 中的资源限制 +### 12.3.4 Docker 中的资源限制 Docker 提供了丰富的参数来配置容器的资源限制,主要包括内存、CPU、磁盘 I/O 等。 @@ -142,7 +142,7 @@ $ docker run --pids-limit=100 myapp --- -### 11.3.5 查看容器资源使用 +### 12.3.5 查看容器资源使用 运行以下命令: @@ -165,7 +165,7 @@ $ docker inspect mycontainer --format '{{json .HostConfig}}' | jq --- -### 11.3.6 资源限制的效果 +### 12.3.6 资源限制的效果 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -209,7 +209,7 @@ $ docker run --rm --cpus=1 stress --cpu 4 --- -### 11.3.7 cgroups v1 vs v2 +### 12.3.7 cgroups v1 vs v2 相关信息如下表: @@ -245,7 +245,7 @@ nodev cgroup2 --- -### 11.3.8 在 Compose 中设置限制 +### 12.3.8 在 Compose 中设置限制 在 Compose 中设置限制配置如下: @@ -265,7 +265,7 @@ services: --- -### 11.3.9 最佳实践 +### 12.3.9 最佳实践 在使用 Cgroups 限制资源时,遵循一些最佳实践可以避免潜在的问题。 diff --git a/11_implementation/11.4_ufs.md b/12_implementation/12.4_ufs.md similarity index 95% rename from 11_implementation/11.4_ufs.md rename to 12_implementation/12.4_ufs.md index 5d8fa97..ea4c208 100644 --- a/11_implementation/11.4_ufs.md +++ b/12_implementation/12.4_ufs.md @@ -1,8 +1,8 @@ -## 11.4 联合文件系统 +## 12.4 联合文件系统 联合文件系统 (UnionFS) 是 Docker 镜像分层存储的基础,它允许将多个目录挂载为同一个虚拟文件系统。 -### 11.4.1 什么是联合文件系统 +### 12.4.1 什么是联合文件系统 联合文件系统 (UnionFS) 是一种 **分层、轻量级** 的文件系统,它将多个目录 “联合” 挂载到同一个虚拟目录,形成一个统一的文件系统视图。 @@ -24,7 +24,7 @@ flowchart TD --- -### 11.4.2 为什么 Docker 使用联合文件系统 +### 12.4.2 为什么 Docker 使用联合文件系统 Docker 选择联合文件系统作为其存储驱动,主要基于以下几个核心优势。 @@ -62,7 +62,7 @@ COPY . . # 层4:应用代码 --- -### 11.4.3 Copy-on-Write (写时复制) +### 12.4.3 Copy-on-Write (写时复制) 当容器修改只读层中的文件时: @@ -92,7 +92,7 @@ flowchart LR --- -### 11.4.4 Docker 支持的存储驱动 +### 12.4.4 Docker 支持的存储驱动 Docker 可使用多种联合文件系统实现: @@ -128,7 +128,7 @@ Storage Driver: overlay2 --- -### 11.4.5 overlay2 工作原理 +### 12.4.5 overlay2 工作原理 overlay2 是目前最推荐的存储驱动: @@ -169,7 +169,7 @@ flowchart TD --- -### 11.4.6 查看镜像层 +### 12.4.6 查看镜像层 运行以下命令: @@ -198,7 +198,7 @@ $ docker inspect nginx:alpine --format '{{json .GraphDriver.Data}}' | jq --- -### 11.4.7 最佳实践 +### 12.4.7 最佳实践 为了构建高效、轻量的镜像,我们在使用联合文件系统时应注意以下几点。 diff --git a/11_implementation/11.5_container_format.md b/12_implementation/12.5_container_format.md similarity index 94% rename from 11_implementation/11.5_container_format.md rename to 12_implementation/12.5_container_format.md index f718fbf..54737b2 100644 --- a/11_implementation/11.5_container_format.md +++ b/12_implementation/12.5_container_format.md @@ -1,3 +1,3 @@ -## 11.5 容器格式 +## 12.5 容器格式 最初,Docker 采用了 `LXC` 中的容器格式。从 0.7 版本以后开始去除 LXC,转而使用自行开发的 [libcontainer](https://github.com/docker/libcontainer),从 1.11 开始,则进一步演进为使用 [runC](https://github.com/opencontainers/runc) 和 [containerd](https://github.com/containerd/containerd)。 diff --git a/11_implementation/11.6_network.md b/12_implementation/12.6_network.md similarity index 97% rename from 11_implementation/11.6_network.md rename to 12_implementation/12.6_network.md index 569837e..d3a6d29 100644 --- a/11_implementation/11.6_network.md +++ b/12_implementation/12.6_network.md @@ -1,8 +1,8 @@ -## 11.6 Docker 网络实现 +## 12.6 Docker 网络实现 Docker 的网络实现其实就是利用了 Linux 上的网络命名空间和虚拟网络设备 (特别是 veth pair)。建议先熟悉了解这两部分的基本概念再阅读本章。 -### 11.6.1 基本原理 +### 12.6.1 基本原理 首先,要实现网络通信,机器需要至少一个网络接口 (物理接口或虚拟接口) 来收发数据包;此外,如果不同子网之间要进行通信,需要路由机制。 @@ -11,7 +11,7 @@ Linux 通过在内核中进行数据复制来实现虚拟接口之间的数据 Docker 容器网络就利用了这项技术。它在本地主机和容器内分别创建一个虚拟接口,并让它们彼此连通 (这样的一对接口叫做 `veth pair`)。 -### 11.6.2 创建网络参数 +### 12.6.2 创建网络参数 Docker 创建一个容器的时候,会执行如下操作: @@ -29,7 +29,7 @@ Docker 创建一个容器的时候,会执行如下操作: * `--net=container:NAME_or_ID` 让 Docker 将新建容器的进程放到一个已存在容器的网络栈中,新容器进程有自己的文件系统、进程列表和资源限制,但会和已存在的容器共享 IP 地址和端口等网络资源,两者进程可以直接通过 `lo` 环回接口通信。 * `--net=none` 让 Docker 将新容器放到隔离的网络栈中,但是不进行网络配置。之后,用户可以自己进行配置。 -### 11.6.3 网络配置细节 +### 12.6.3 网络配置细节 用户使用 `--net=none` 后,可以自行配置网络,让容器达到跟平常一样具有访问网络的权限。通过这个过程,可以了解 Docker 配置网络的细节。 diff --git a/11_implementation/README.md b/12_implementation/README.md similarity index 98% rename from 11_implementation/README.md rename to 12_implementation/README.md index e676bd9..83a3bdd 100644 --- a/11_implementation/README.md +++ b/12_implementation/README.md @@ -1,4 +1,4 @@ -# 第十一章 底层实现 +# 第十二章 底层实现 Docker 底层的核心技术包括 Linux 上的命名空间 (Namespaces)、控制组 (Control groups)、Union 文件系统 (Union file systems) 和容器格式 (Container format)。 diff --git a/11_implementation/summary.md b/12_implementation/summary.md similarity index 94% rename from 11_implementation/summary.md rename to 12_implementation/summary.md index 0dcd77a..84c8e35 100644 --- a/11_implementation/summary.md +++ b/12_implementation/summary.md @@ -1,4 +1,4 @@ -## 11.7 本章小结 +## 12.7 本章小结 相关信息如下表: @@ -11,7 +11,7 @@ | IPC | 进程间通信 | 容器间 IPC 隔离 | | USER | 用户 ID | 容器 root ≠ 宿主机 root | -### 11.7.1 延伸阅读 +### 12.7.1 延伸阅读 - [控制组 (Cgroups)](11.3_cgroups.md):资源限制机制 - [联合文件系统](11.4_ufs.md):分层存储的实现 @@ -26,7 +26,7 @@ | **磁盘 I/O** | `--device-write-bps` | `--device-write-bps /dev/sda:10mb` | | **进程数** | `--pids-limit` | `--pids-limit=100` | -### 11.7.2 延伸阅读 +### 12.7.2 延伸阅读 - [命名空间](11.2_namespace.md):资源隔离 - [安全](../17_security/README.md):容器安全概述 @@ -39,7 +39,7 @@ | **overlay2** | Docker 默认推荐的存储驱动 | | **分层好处** | 镜像复用、快速构建、快速启动 | -### 11.7.3 延伸阅读 +### 12.7.3 延伸阅读 - [镜像](../02_basic_concept/2.1_image.md):理解镜像分层 - [容器](../02_basic_concept/2.2_container.md):容器存储层 diff --git a/12_kubernetes_concepts/README.md b/13_kubernetes_concepts/README.md similarity index 100% rename from 12_kubernetes_concepts/README.md rename to 13_kubernetes_concepts/README.md diff --git a/12_kubernetes_concepts/_images/k8s_architecture.png b/13_kubernetes_concepts/_images/k8s_architecture.png similarity index 100% rename from 12_kubernetes_concepts/_images/k8s_architecture.png rename to 13_kubernetes_concepts/_images/k8s_architecture.png diff --git a/12_kubernetes_concepts/_images/kube-proxy.png b/13_kubernetes_concepts/_images/kube-proxy.png similarity index 100% rename from 12_kubernetes_concepts/_images/kube-proxy.png rename to 13_kubernetes_concepts/_images/kube-proxy.png diff --git a/12_kubernetes_concepts/_images/kubernetes_design.jpg b/13_kubernetes_concepts/_images/kubernetes_design.jpg similarity index 100% rename from 12_kubernetes_concepts/_images/kubernetes_design.jpg rename to 13_kubernetes_concepts/_images/kubernetes_design.jpg diff --git a/12_kubernetes_concepts/_images/kubernetes_logo.png b/13_kubernetes_concepts/_images/kubernetes_logo.png similarity index 100% rename from 12_kubernetes_concepts/_images/kubernetes_logo.png rename to 13_kubernetes_concepts/_images/kubernetes_logo.png diff --git a/12_kubernetes_concepts/advanced.md b/13_kubernetes_concepts/advanced.md similarity index 90% rename from 12_kubernetes_concepts/advanced.md rename to 13_kubernetes_concepts/advanced.md index fdb6817..e8ebeae 100644 --- a/12_kubernetes_concepts/advanced.md +++ b/13_kubernetes_concepts/advanced.md @@ -1,8 +1,8 @@ -## 12.4 Kubernetes 高级特性 +## 13.4 Kubernetes 高级特性 掌握了 Kubernetes 的核心概念 (Pod,Service,Deployment) 后,我们需要了解更多高级特性以构建生产级应用。 -### 12.4.1 Helm - 包管理工具 +### 13.4.1 Helm - 包管理工具 [Helm](https://helm.sh/) 被称为 Kubernetes 的包管理器 (类似于 Linux 的 apt/yum)。它将一组 Kubernetes 资源定义文件打包为一个 **Chart**。 @@ -10,7 +10,7 @@ * **版本管理**:轻松回滚应用的发布版本。 * **模板化**:支持复杂的应用部署逻辑配置。 -### 12.4.2 Ingress - 服务的入口 +### 13.4.2 Ingress - 服务的入口 Service 虽然提供了负载均衡,但通常是 4 层 (TCP/UDP)。**Ingress** 提供了 7 层 (HTTP/HTTPS) 路由能力,充当集群的网关。 @@ -20,7 +20,7 @@ Service 虽然提供了负载均衡,但通常是 4 层 (TCP/UDP)。**Ingress** 常见的 Ingress Controller 有 Nginx Ingress Controller,Traefik,Istio Gateway 等。 -### 12.4.3 Persistent Volume 与 StorageClass +### 13.4.3 Persistent Volume 与 StorageClass 容器内的文件是临时的。对于有状态应用 (如数据库),需要持久化存储。 @@ -28,7 +28,7 @@ Service 虽然提供了负载均衡,但通常是 4 层 (TCP/UDP)。**Ingress** * **PV (Persistent Volume)**:实际的存储资源 (NFS,AWS EBS,Ceph 等)。 * **StorageClass**:定义存储类,支持动态创建 PV。 -### 12.4.4 Horizontal Pod Autoscaling +### 13.4.4 Horizontal Pod Autoscaling HPA 根据 CPU 利用率或其他指标 (如内存、自定义指标) 自动扩缩 Deployment 或 ReplicaSet 中的 Pod 数量。 @@ -53,7 +53,7 @@ spec: averageUtilization: 50 ``` -### 12.4.5 ConfigMap 与 Secret +### 13.4.5 ConfigMap 与 Secret * **ConfigMap**:存储非机密的配置数据 (配置文件、环境变量)。 * **Secret**:存储机密数据 (密码、Token、证书),在 Etcd 中加密存储。 diff --git a/12_kubernetes_concepts/concepts.md b/13_kubernetes_concepts/concepts.md similarity index 97% rename from 12_kubernetes_concepts/concepts.md rename to 13_kubernetes_concepts/concepts.md index 62ad0ba..5e56fc0 100644 --- a/12_kubernetes_concepts/concepts.md +++ b/13_kubernetes_concepts/concepts.md @@ -1,4 +1,4 @@ -## 12.2 基本概念 +## 13.2 基本概念 如图 12-2 所示,Kubernetes 由控制平面与工作节点构成。 @@ -17,7 +17,7 @@ * web 界面 (`ux`):用户可以通过 web 界面操作 Kubernetes。 * 命令行操作 (`cli`):`kubectl` 命令。 -### 12.2.1 节点 +### 13.2.1 节点 在 `Kubernetes` 中,节点是实际工作的点,节点可以是虚拟机或者物理机器,依赖于一个集群环境。每个节点都有一些必要的服务以运行容器组,并且它们都可以通过主节点来管理。必要服务包括 Docker,kubelet 和代理服务。 @@ -69,7 +69,7 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中,有两个接 节点控制有一个同步轮询,主要监听所有云平台的虚拟实例,会根据节点状态创建和删除。可以通过 `--node_sync_period` 标志来控制该轮询。如果一个实例已经创建,节点控制将会为其创建一个结构。同样的,如果一个节点被删除,节点控制也会删除该结构。在 Kubernetes 启动时可用通过 `--machines` 标记来显示指定节点。同样可以使用 `kubectl` 来一条一条的添加节点,两者是相同的。通过设置 `--sync_nodes=false` 标记来禁止集群之间的节点同步,你也可以使用 api/kubectl 命令行来增删节点。 -### 12.2.2 容器组 +### 13.2.2 容器组 在 Kubernetes 中,使用的最小单位是容器组,容器组是创建,调度,管理的最小单位。一个容器组使用相同的 Docker 容器并共享卷 (挂载点)。一个容器组是一个特定应用的打包集合,包含一个或多个容器。 @@ -179,30 +179,30 @@ Kubernetes 校验节点可用依赖于 ID。在当前的版本中,有两个接 * 节点控制器标记容器组 `failed` * 如果容器组运行在一个控制器下,容器组将会在其他地方重新创建 -### 12.2.3 Replication Controllers +### 13.2.3 Replication Controllers > 注:Replication Controller (RC) 是早期的控制器类型,现代 Kubernetes 更推荐使用 ReplicaSet/Deployment。 -### 12.2.4 服务 +### 13.2.4 服务 > 注:服务 (Service) 定义一组 Pod 的逻辑集合和访问它们的策略。 -### 12.2.5 卷 +### 13.2.5 卷 > 注:卷 (Volume) 包含可被 Pod 中容器访问的数据的目录。 -### 12.2.6 标签 +### 13.2.6 标签 > 注:标签 (Label) 是附加到对象 (如 Pods) 上的键值对,用于组织和选择对象子集。 -### 12.2.7 接口权限 +### 13.2.7 接口权限 > 注:接口权限通过认证、授权和准入控制来保护 Kubernetes API 的访问。 -### 12.2.8 web 界面 +### 13.2.8 web 界面 > 注:Kubernetes Dashboard 是一个基于 Web 的用户界面,用于管理集群。 -### 12.2.9 命令行操作 +### 13.2.9 命令行操作 > 注:kubectl 是 Kubernetes 的命令行工具,用于与集群进行交互。 diff --git a/12_kubernetes_concepts/design.md b/13_kubernetes_concepts/design.md similarity index 95% rename from 12_kubernetes_concepts/design.md rename to 13_kubernetes_concepts/design.md index 0bc5d13..5e0c6a8 100644 --- a/12_kubernetes_concepts/design.md +++ b/13_kubernetes_concepts/design.md @@ -1,8 +1,8 @@ -## 12.3 架构设计 +## 13.3 架构设计 任何优秀的项目都离不开优秀的架构设计。本小节将介绍 Kubernetes 在架构方面的设计考虑。 -### 12.3.1 基本考虑 +### 13.3.1 基本考虑 如果让我们自己从头设计一套容器管理平台,有如下几个方面是很容易想到的: @@ -11,7 +11,7 @@ * 一套资源调度系统,管理哪个容器该分配到哪个节点上; * 一套对容器内服务进行抽象和 HA 的系统。 -### 12.3.2 运行原理 +### 13.3.2 运行原理 如图 12-3 所示,该图完整展示了 Kubernetes 的运行原理。 @@ -25,7 +25,7 @@ 从这张图上,我们没有能发现 Kubernetes 中对于控制平面的分布式实现,但是由于数据后端自身就是一套分布式的数据库 Etcd,因此可以很容易扩展到分布式实现。 -### 12.3.3 控制平面 +### 13.3.3 控制平面 控制平面 (Control Plane) 是 Kubernetes 集群的大脑,负责做出全局决策 (如调度) 以及检测和响应集群事件。 @@ -45,7 +45,7 @@ 组件可以自动的去侦测 Etcd 中的数值变化来获得通知,并且获得更新后的数据来执行相应的操作。 -### 12.3.4 工作节点 +### 13.3.4 工作节点 * kubelet 是工作节点执行操作的 agent,负责具体的容器生命周期管理,根据从数据库中获取的信息来管理容器,并上报 pod 运行状态等; * kube-proxy 是一个简单的网络访问代理,同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上的 Pod (同一类标签)。 diff --git a/12_kubernetes_concepts/intro.md b/13_kubernetes_concepts/intro.md similarity index 93% rename from 12_kubernetes_concepts/intro.md rename to 13_kubernetes_concepts/intro.md index 8199956..c93cc00 100644 --- a/12_kubernetes_concepts/intro.md +++ b/13_kubernetes_concepts/intro.md @@ -1,4 +1,4 @@ -## 12.1 Kubernetes 简介 +## 13.1 Kubernetes 简介 如图 12-1 所示,Kubernetes 使用舵手图标作为项目标识。 @@ -6,7 +6,7 @@ 图 12-1 Kubernetes 项目标识 -### 12.1.1 什么是 Kubernetes +### 13.1.1 什么是 Kubernetes Kubernetes (常简称为 K8s) 是 Google 开源的容器编排引擎。如果说 Docker 解决了 “如何打包和运送集装箱” 的问题,那么 Kubernetes 解决的就是 “如何管理海量集装箱的调度、运行和维护” 的问题。 @@ -16,7 +16,7 @@ Kubernetes (常简称为 K8s) 是 Google 开源的容器编排引擎。如果说 --- -### 12.1.2 为什么需要 Kubernetes +### 13.1.2 为什么需要 Kubernetes 当我们在单机运行几个容器时,Docker Compose 就足够了。但在生产环境中,我们需要面对: @@ -30,7 +30,7 @@ Kubernetes 完美解决了这些问题。 --- -### 12.1.3 核心概念 +### 13.1.3 核心概念 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -56,7 +56,7 @@ Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密 --- -### 12.1.4 Docker 用户如何过渡 +### 13.1.4 Docker 用户如何过渡 如果你已经熟悉 Docker,学习 K8s 会很容易: @@ -69,7 +69,7 @@ Kubernetes 的最小调度单位。一个 Pod 可以包含一个或多个紧密 --- -### 12.1.5 架构 +### 13.1.5 架构 Kubernetes 也是 C/S 架构,由 **Control Plane (控制平面)** 和 **Worker Node (工作节点)** 组成: @@ -78,7 +78,7 @@ Kubernetes 也是 C/S 架构,由 **Control Plane (控制平面)** 和 **Worker --- -### 12.1.6 学习建议 +### 13.1.6 学习建议 Kubernetes 的学习曲线较陡峭。建议的学习路径: @@ -89,7 +89,7 @@ Kubernetes 的学习曲线较陡峭。建议的学习路径: --- -### 12.1.7 延伸阅读 +### 13.1.7 延伸阅读 - [Minikube 安装](../setup/README.md):本地体验 K8s - [Kubernetes 官网](https://kubernetes.io/):官方文档 diff --git a/12_kubernetes_concepts/practice.md b/13_kubernetes_concepts/practice.md similarity index 88% rename from 12_kubernetes_concepts/practice.md rename to 13_kubernetes_concepts/practice.md index 9f8b4c3..e30e5e2 100644 --- a/12_kubernetes_concepts/practice.md +++ b/13_kubernetes_concepts/practice.md @@ -1,14 +1,14 @@ -## 12.5 Kubernetes 实战练习 +## 13.5 Kubernetes 实战练习 本章将通过一个具体的案例:部署一个 Nginx 网站,并为其配置 Service 和 Ingress,来串联前面学到的知识。 -### 12.5.1 目标 +### 13.5.1 目标 1. 部署一个 Nginx Deployment。 2. 创建一个 Service 暴露 Nginx。 3. (可选) 通过 Ingress 访问服务。 -### 12.5.2 步骤 1:创建 Deployment +### 13.5.2 步骤 1:创建 Deployment 创建一个名为 `nginx-deployment.yaml` 的文件: @@ -42,7 +42,7 @@ spec: kubectl apply -f nginx-deployment.yaml ``` -### 12.5.3 步骤 2:创建 Service +### 13.5.3 步骤 2:创建 Service 创建一个名为 `nginx-service.yaml` 的文件: @@ -75,7 +75,7 @@ kubectl get svc nginx-service 如果输出端口是 `80:30080/TCP`,你可以通过 `http://:30080` 访问 Nginx。 -### 12.5.4 步骤 3:模拟滚动更新 +### 13.5.4 步骤 3:模拟滚动更新 修改 `nginx-deployment.yaml`,将镜像版本改为 `nginx:1.27-alpine`。 @@ -89,7 +89,7 @@ kubectl apply -f nginx-deployment.yaml kubectl rollout status deployment/nginx-deployment ``` -### 12.5.5 步骤 4:清理资源 +### 13.5.5 步骤 4:清理资源 练习结束后,记得清理资源: diff --git a/13_kubernetes_concepts/summary.md b/13_kubernetes_concepts/summary.md new file mode 100644 index 0000000..07dcc82 --- /dev/null +++ b/13_kubernetes_concepts/summary.md @@ -0,0 +1,19 @@ +## 13.6 本章小结 + +Kubernetes 是当前最主流的容器编排平台,其声明式管理模型和丰富的 API 为大规模容器化应用提供了坚实的基础。 + +| 概念 | 要点 | +|------|------| +| **Pod** | 最小调度单位,包含一组共享网络和存储的容器 | +| **Deployment** | 管理 Pod 副本集,支持滚动更新和回滚 | +| **Service** | 为 Pod 提供稳定的网络访问入口和负载均衡 | +| **Namespace** | 资源隔离和多租户支持 | +| **ConfigMap/Secret** | 配置与敏感信息的管理 | +| **Master 节点** | 运行 API Server、Scheduler、Controller Manager | +| **Worker 节点** | 运行 kubelet、kube-proxy 和容器运行时 | + +### 13.6.1 延伸阅读 + +- [部署 Kubernetes](../14_kubernetes_setup/README.md):搭建 Kubernetes 集群 +- [Etcd](../15_etcd/README.md):Kubernetes 使用的分布式存储 +- [底层实现](../12_implementation/README.md):容器技术原理 diff --git a/13_kubernetes_setup/README.md b/14_kubernetes_setup/README.md similarity index 100% rename from 13_kubernetes_setup/README.md rename to 14_kubernetes_setup/README.md diff --git a/13_kubernetes_setup/dashboard.md b/14_kubernetes_setup/dashboard.md similarity index 92% rename from 13_kubernetes_setup/dashboard.md rename to 14_kubernetes_setup/dashboard.md index b686bc9..a1e464e 100644 --- a/13_kubernetes_setup/dashboard.md +++ b/14_kubernetes_setup/dashboard.md @@ -1,10 +1,10 @@ -## 13.7 Kubernetes Dashboard +## 14.7 Kubernetes Dashboard [Kubernetes Dashboard](https://github.com/kubernetes/dashboard) 是基于网页的 Kubernetes 用户界面。 ![图](https://d33wubrfki0l68.cloudfront.net/349824f68836152722dab89465835e604719caea/6e0b7/images/docs/ui-dashboard.png) -### 13.7.1 部署 +### 14.7.1 部署 执行以下命令即可部署 Dashboard: @@ -12,7 +12,7 @@ kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml ``` -### 13.7.2 访问 +### 14.7.2 访问 通过命令行代理访问,执行以下命令: @@ -22,7 +22,7 @@ $ kubectl proxy 到 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ 即可访问。 -### 13.7.3 登录 +### 14.7.3 登录 目前,Dashboard 仅支持使用 Bearer 令牌登录。下面教大家如何创建该令牌: @@ -40,6 +40,6 @@ echo ${DASHBOARD_LOGIN_TOKEN} 将结果粘贴到登录页面,即可登录。 -### 13.7.4 参考文档 +### 14.7.4 参考文档 * [官方文档](https://kubernetes.io/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) diff --git a/13_kubernetes_setup/docker-desktop.md b/14_kubernetes_setup/docker-desktop.md similarity index 89% rename from 13_kubernetes_setup/docker-desktop.md rename to 14_kubernetes_setup/docker-desktop.md index 8e2748d..0f10696 100644 --- a/13_kubernetes_setup/docker-desktop.md +++ b/14_kubernetes_setup/docker-desktop.md @@ -1,8 +1,8 @@ -## 13.3 Docker Desktop 启用 Kubernetes +## 14.3 Docker Desktop 启用 Kubernetes 使用 Docker Desktop 可以很方便的启用 Kubernetes。 -### 13.3.1 启用 Kubernetes +### 14.3.1 启用 Kubernetes 在 Docker Desktop 设置页面,点击 `Kubernetes`,选择 `Enable Kubernetes`,稍等片刻,看到左下方 `Kubernetes` 变为 `running`,Kubernetes 启动成功。 @@ -10,7 +10,7 @@ > 注意:Kubernetes 的镜像存储在 `registry.k8s.io`,如果国内网络无法直接访问,可以在 Docker Desktop 配置中的 `Docker Engine` 处配置镜像加速器,或者利用国内云服务商的镜像仓库手动拉取镜像并 retag。 -### 13.3.2 测试 +### 14.3.2 测试 运行以下命令: diff --git a/13_kubernetes_setup/k3s.md b/14_kubernetes_setup/k3s.md similarity index 92% rename from 13_kubernetes_setup/k3s.md rename to 14_kubernetes_setup/k3s.md index 34d7acd..c72cbbf 100644 --- a/13_kubernetes_setup/k3s.md +++ b/14_kubernetes_setup/k3s.md @@ -1,15 +1,15 @@ -## 13.5 K3s - 轻量级 Kubernetes +## 14.5 K3s - 轻量级 Kubernetes [K3s](https://k3s.io/) 是一个轻量级的 Kubernetes 发行版,由 Rancher Labs 开发。它专为边缘计算、物联网、CI、ARM 等资源受限的环境设计。K3s 被打包为单个二进制文件,只有不到 100MB,但通过了 CNCF 的一致性测试。 -### 13.5.1 核心特性 +### 14.5.1 核心特性 * **轻量级**:移除过时的、非必须的 Kubernetes 功能 (如传统的云提供商插件),使用 SQLite 作为默认数据存储 (也支持 Etcd/MySQL/Postgres)。 * **单一二进制**:所有组件 (API Server,Controller Manager,Scheduler,Kubelet,Kube-proxy) 打包在一个进程中运行。 * **开箱即用**:内置 Helm Controller、Traefik Ingress controller、ServiceLB、Local-Path-Provisioner。 * **安全**:默认启用安全配置,基于 TLS 通信。 -### 13.5.2 安装 +### 14.5.2 安装 K3s 的安装非常简单,官方提供了便捷的安装脚本。 @@ -37,7 +37,7 @@ NAME STATUS ROLES AGE VERSION k3s-master Ready control-plane,master 1m v1.35.1+k3s1 ``` -### 13.5.3 快速使用 +### 14.5.3 快速使用 K3s 内置了 `kubectl` 命令 (通过 `k3s kubectl` 调用),为了方便,通常会建立别名或配置 `KUBECONFIG`。 @@ -51,7 +51,7 @@ export KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl get pods -A ``` -### 13.5.4 清理卸载 +### 14.5.4 清理卸载 运行以下命令: diff --git a/13_kubernetes_setup/kind.md b/14_kubernetes_setup/kind.md similarity index 88% rename from 13_kubernetes_setup/kind.md rename to 14_kubernetes_setup/kind.md index 6117cd7..5d9c534 100644 --- a/13_kubernetes_setup/kind.md +++ b/14_kubernetes_setup/kind.md @@ -1,8 +1,8 @@ -## 13.4 Kind - Kubernetes IN Docker +## 14.4 Kind - Kubernetes IN Docker [Kind](https://kind.sigs.k8s.io/) (Kubernetes in Docker) 是一个使用 Docker 容器作为节点运行本地 Kubernetes 集群的工具。主要用于测试 Kubernetes 本身,也非常适合本地开发和 CI 环境。 -### 13.4.1 为什么选择 Kind +### 14.4.1 为什么选择 Kind Kind 相比其他本地集群方案 (如 Minikube) 有以下显著优势: @@ -11,7 +11,7 @@ Kind 相比其他本地集群方案 (如 Minikube) 有以下显著优势: * **多版本支持**:支持指定 Kubernetes 版本进行测试。 * **HA 支持**:支持模拟高可用集群 (多 Control Plane)。 -### 13.4.2 安装 Kind +### 14.4.2 安装 Kind Kind 是一个二进制文件,并在 PATH 中即可使用。以下是不同系统的安装方法。 @@ -35,7 +35,7 @@ chmod +x ./kind sudo mv ./kind /usr/local/bin/kind ``` -### 13.4.3 创建集群 +### 14.4.3 创建集群 最简单的创建方式: @@ -49,7 +49,7 @@ kind create cluster kind create cluster --name my-cluster ``` -### 13.4.4 与集群交互 +### 14.4.4 与集群交互 Kind 会自动将 kubeconfig 合并到 `~/.kube/config`。 @@ -58,7 +58,7 @@ kubectl cluster-info --context kind-kind kubectl get nodes ``` -### 13.4.5 高级用法:配置集群 +### 14.4.5 高级用法:配置集群 创建一个 `kind-config.yaml` 来定制集群,例如映射端口到宿主机: @@ -81,7 +81,7 @@ nodes: kind create cluster --config kind-config.yaml ``` -### 13.4.6 删除集群 +### 14.4.6 删除集群 运行以下命令: diff --git a/13_kubernetes_setup/kubeadm-docker.md b/14_kubernetes_setup/kubeadm-docker.md similarity index 95% rename from 13_kubernetes_setup/kubeadm-docker.md rename to 14_kubernetes_setup/kubeadm-docker.md index 742035e..45f2f24 100644 --- a/13_kubernetes_setup/kubeadm-docker.md +++ b/14_kubernetes_setup/kubeadm-docker.md @@ -1,4 +1,4 @@ -## 13.2 使用 kubeadm 部署 Kubernetes (使用 Docker) +## 14.2 使用 kubeadm 部署 Kubernetes (使用 Docker) `kubeadm` 提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令,作为快速创建 `Kubernetes` 集群的最佳实践。 @@ -6,11 +6,11 @@ > > 本文档主要用于历史环境/学习目的:如果你确实需要在较新版本中继续使用 Docker Engine,通常需要额外部署 `cri-dockerd` 并在 `kubeadm init/join` 中指定 `--cri-socket`。 -### 13.2.1 安装 Docker +### 14.2.1 安装 Docker 参考[安装 Docker](../../03_install/README.md) 一节安装 Docker。 -### 13.2.2 安装 **kubelet****kubeadm****kubectl** +### 14.2.2 安装 **kubelet****kubeadm****kubectl** 需要在每台机器上安装以下的软件包: @@ -56,7 +56,7 @@ EOF $ sudo yum install -y kubelet kubeadm kubectl ``` -### 13.2.3 修改内核的运行参数 +### 14.2.3 修改内核的运行参数 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -99,7 +99,7 @@ EOF $ sysctl --system ``` -### 13.2.4 配置 kubelet +### 14.2.4 配置 kubelet 为了让 kubelet 正确运行,我们需要对其进行一些必要的配置。 @@ -127,7 +127,7 @@ ExecStartPre=-/sbin/modprobe ip_vs_sh $ sudo systemctl daemon-reload ``` -### 13.2.5 部署 +### 14.2.5 部署 安装配置完成后,我们将分别在 Master 节点和 Worker 节点上进行部署操作。 @@ -182,7 +182,7 @@ $ kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \ --discovery-token-ca-cert-hash sha256:5edb316fd0d8ea2792cba15cdf1c899a366f147aa03cba52d4e5c5884ad836fe ``` -### 13.2.6 查看服务 +### 14.2.6 查看服务 所有服务启动后,查看本地实际运行的 Docker 容器。这些服务大概分为三类:主节点服务、工作节点服务和其它服务。 @@ -202,7 +202,7 @@ $ kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \ * Etcd 是所有状态的存储数据库; -### 13.2.7 使用 +### 14.2.7 使用 将 `/etc/kubernetes/admin.conf` 复制到 `~/.kube/config` @@ -210,7 +210,7 @@ $ kubeadm join 192.168.199.100:6443 --token cz81zt.orsy9gm9v649e5lf \ 由于未部署 CNI 插件,CoreDNS 未正常启动。如何使用 Kubernetes,请参考后续章节。 -### 13.2.8 部署 CNI +### 14.2.8 部署 CNI 这里以 `flannel` 为例进行介绍。 @@ -235,7 +235,7 @@ $ kubectl get node -o yaml | grep CIDR $ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.26.1/Documentation/kube-flannel.yml ``` -### 13.2.9 master 节点默认不能运行 pod +### 14.2.9 master 节点默认不能运行 pod 如果用 `kubeadm` 部署一个单节点集群,默认情况下无法使用,请执行以下命令解除限制 @@ -253,6 +253,6 @@ $ kubectl taint nodes --all node-role.kubernetes.io/master- ... ``` -### 13.2.10 参考文档 +### 14.2.10 参考文档 * [官方文档](https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) diff --git a/13_kubernetes_setup/kubeadm.md b/14_kubernetes_setup/kubeadm.md similarity index 96% rename from 13_kubernetes_setup/kubeadm.md rename to 14_kubernetes_setup/kubeadm.md index 8b63de9..cb437aa 100644 --- a/13_kubernetes_setup/kubeadm.md +++ b/14_kubernetes_setup/kubeadm.md @@ -1,10 +1,10 @@ -## 13.1 使用 kubeadm 部署 Kubernetes (CRI 使用 containerd) +## 14.1 使用 kubeadm 部署 Kubernetes (CRI 使用 containerd) `kubeadm` 提供了 `kubeadm init` 以及 `kubeadm join` 这两个命令,作为快速创建 `Kubernetes` 集群的最佳实践。 > **版本说明**:Kubernetes 版本更新较快 (约每 4 个月一个新版本),本文档基于 Kubernetes 1.35 编写。请访问 [Kubernetes 官方发布页](https://kubernetes.io/releases/)获取最新版本信息。 -### 13.1.1 安装 containerd +### 14.1.1 安装 containerd 参考[安装 Docker](../../03_install/README.md) 一节添加 apt/yum 源,之后执行如下命令。 @@ -18,7 +18,7 @@ $ sudo apt install containerd.io $ sudo yum install containerd.io ``` -### 13.1.2 配置 containerd +### 14.1.2 配置 containerd 新建 `/etc/systemd/system/cri-containerd.service` 文件 @@ -228,7 +228,7 @@ oom_score = 0 async_remove = false ``` -### 13.1.3 安装 **kubelet****kubeadm****kubectl****cri-tools****kubernetes-cni** +### 14.1.3 安装 **kubelet****kubeadm****kubectl****cri-tools****kubernetes-cni** 需要在每台机器上安装以下的软件包: @@ -274,7 +274,7 @@ EOF $ sudo yum install -y kubelet kubeadm kubectl cri-tools kubernetes-cni ``` -### 13.1.4 修改内核的运行参数 +### 14.1.4 修改内核的运行参数 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -317,7 +317,7 @@ EOF $ sysctl --system ``` -### 13.1.5 配置 kubelet +### 14.1.5 配置 kubelet 为了让 kubelet 正确运行,我们需要对其进行一些必要的配置。 @@ -345,7 +345,7 @@ ExecStartPre=-/sbin/modprobe ip_vs_sh $ sudo systemctl daemon-reload ``` -### 13.1.6 部署 +### 14.1.6 部署 安装配置完成后,我们将分别在 Master 节点和 Worker 节点上进行部署操作。 @@ -412,7 +412,7 @@ $ kubeadm join 192.168.199.100:6443 \ --cri-socket /run/cri-containerd/cri-containerd.sock ``` -### 13.1.7 查看服务 +### 14.1.7 查看服务 所有服务启动后,通过 `crictl` 查看本地实际运行的容器。这些服务大概分为三类:主节点服务、工作节点服务和其它服务。 @@ -436,7 +436,7 @@ CONTAINER_RUNTIME_ENDPOINT=/run/cri-containerd/cri-containerd.sock crictl ps -a * Etcd 是所有状态的存储数据库; -### 13.1.8 使用 +### 14.1.8 使用 将 `/etc/kubernetes/admin.conf` 复制到 `~/.kube/config` @@ -444,7 +444,7 @@ CONTAINER_RUNTIME_ENDPOINT=/run/cri-containerd/cri-containerd.sock crictl ps -a 由于未部署 CNI 插件,CoreDNS 未正常启动。如何使用 Kubernetes,请参考后续章节。 -### 13.1.9 部署 CNI +### 14.1.9 部署 CNI 这里以 `flannel` 为例进行介绍。 @@ -469,7 +469,7 @@ $ kubectl get node -o yaml | grep CIDR $ kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/v0.26.1/Documentation/kube-flannel.yml ``` -### 13.1.10 master 节点默认不能运行 pod +### 14.1.10 master 节点默认不能运行 pod 如果用 `kubeadm` 部署一个单节点集群,默认情况下无法使用,请执行以下命令解除限制 @@ -487,7 +487,7 @@ $ kubectl taint nodes --all node-role.kubernetes.io/master- ... ``` -### 13.1.11 参考文档 +### 14.1.11 参考文档 * [官方文档](https://kubernetes.io/zh/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) * [Container runtimes](https://kubernetes.io/docs/setup/production-environment/container-runtimes/#containerd) diff --git a/13_kubernetes_setup/kubectl.md b/14_kubernetes_setup/kubectl.md similarity index 77% rename from 13_kubernetes_setup/kubectl.md rename to 14_kubernetes_setup/kubectl.md index 2446ddb..c956262 100644 --- a/13_kubernetes_setup/kubectl.md +++ b/14_kubernetes_setup/kubectl.md @@ -8,74 +8,74 @@ kubectl [flags] kubectl [command] ``` -## 13.8 get +## 14.8 get 显示一个或多个资源 -## 13.8 describe +## 14.8 describe 显示资源详情 -## 13.8 create +## 14.8 create 从文件或标准输入创建资源 -## 13.8 update +## 14.8 update 从文件或标准输入更新资源 -## 13.8 delete +## 14.8 delete 通过文件名、标准输入、资源名或者 label selector 删除资源 -## 13.8 logs +## 14.8 logs 输出 pod 中一个容器的日志 -## 13.8 rollout +## 14.8 rollout 对 Deployment 等资源执行滚动更新/回滚 -## 13.8 exec +## 14.8 exec 在容器内部执行命令 -## 13.8 port-forward +## 14.8 port-forward 将本地端口转发到 Pod -## 13.8 proxy +## 14.8 proxy 为 Kubernetes API server 启动代理服务器 -## 13.8 run +## 14.8 run 在集群中使用指定镜像启动容器 -## 13.8 expose +## 14.8 expose 将 replication controller service 或 pod 暴露为新的 Kubernetes service -## 13.8 label +## 14.8 label 更新资源的 label -## 13.8 config +## 14.8 config 修改 Kubernetes 配置文件 -## 13.8 cluster-info +## 14.8 cluster-info 显示集群信息 -## 13.8 api-versions +## 14.8 api-versions 以 “组/版本” 的格式输出服务端支持的 API 版本 -## 13.8 version +## 14.8 version 输出服务端和客户端的版本信息 -## 13.8 help +## 14.8 help 显示各个命令的帮助信息 diff --git a/14_kubernetes_setup/summary.md b/14_kubernetes_setup/summary.md new file mode 100644 index 0000000..2535198 --- /dev/null +++ b/14_kubernetes_setup/summary.md @@ -0,0 +1,17 @@ +## 14.9 本章小结 + +部署 Kubernetes 集群有多种方式,应根据使用场景选择合适的方案。 + +| 部署方式 | 适用场景 | 特点 | +|---------|---------|------| +| **kubeadm** | 生产环境 | 官方推荐的集群部署工具 | +| **Docker Desktop** | 本地开发 | 一键启用,开箱即用 | +| **Kind** | CI/CD 测试 | Kubernetes IN Docker,快速创建集群 | +| **K3s** | 边缘计算/IoT | 轻量级,资源占用少 | +| **手动部署** | 学习原理 | 逐步配置每个组件,加深理解 | + +### 14.9.1 延伸阅读 + +- [容器编排基础](../13_kubernetes_concepts/README.md):Kubernetes 核心概念 +- [Dashboard](dashboard.md):部署可视化管理界面 +- [kubectl](kubectl.md):命令行工具使用指南 diff --git a/13_kubernetes_setup/systemd.md b/14_kubernetes_setup/systemd.md similarity index 80% rename from 13_kubernetes_setup/systemd.md rename to 14_kubernetes_setup/systemd.md index f50de7b..2687bdc 100644 --- a/13_kubernetes_setup/systemd.md +++ b/14_kubernetes_setup/systemd.md @@ -1,3 +1,3 @@ -## 13.6 一步步部署 Kubernetes 集群 +## 14.6 一步步部署 Kubernetes 集群 可以参考 [opsnull/follow-me-install-kubernetes-cluster](https://github.com/opsnull/follow-me-install-kubernetes-cluster) 项目一步步部署 Kubernetes 集群。 diff --git a/14_etcd/README.md b/15_etcd/README.md similarity index 100% rename from 14_etcd/README.md rename to 15_etcd/README.md diff --git a/14_etcd/_images/etcd_logo.png b/15_etcd/_images/etcd_logo.png similarity index 100% rename from 14_etcd/_images/etcd_logo.png rename to 15_etcd/_images/etcd_logo.png diff --git a/14_etcd/cluster.md b/15_etcd/cluster.md similarity index 99% rename from 14_etcd/cluster.md rename to 15_etcd/cluster.md index 148336b..96f3ea4 100644 --- a/14_etcd/cluster.md +++ b/15_etcd/cluster.md @@ -1,4 +1,4 @@ -## 14.3 etcd 集群 +## 15.3 etcd 集群 下面我们使用 [Docker Compose](../../10_compose/README.md) 模拟启动一个 3 节点的 `etcd` 集群。 diff --git a/14_etcd/demo/cluster/docker-compose.yml b/15_etcd/demo/cluster/docker-compose.yml similarity index 100% rename from 14_etcd/demo/cluster/docker-compose.yml rename to 15_etcd/demo/cluster/docker-compose.yml diff --git a/14_etcd/etcdctl.md b/15_etcd/etcdctl.md similarity index 98% rename from 14_etcd/etcdctl.md rename to 15_etcd/etcdctl.md index e62a5ff..e268be7 100644 --- a/14_etcd/etcdctl.md +++ b/15_etcd/etcdctl.md @@ -1,4 +1,4 @@ -## 14.4 使用 etcdctl +## 15.4 使用 etcdctl `etcdctl` 是一个命令行客户端,它能提供一些简洁的命令,供用户直接跟 `etcd` 服务打交道,而无需基于 `HTTP API` 方式。这在某些情况下将很方便,例如用户对服务进行测试或者手动修改数据库内容。我们也推荐在刚接触 `etcd` 时通过 `etcdctl` 命令来熟悉相关的操作,这些操作跟 `HTTP API` 实际上是对应的。 @@ -81,7 +81,7 @@ OPTIONS: -w, --write-out="simple" set the output format (fields, json, protobuf, simple, table) ``` -### 14.4.1 数据库操作 +### 15.4.1 数据库操作 数据库操作围绕对键值和目录的 CRUD (符合 REST 风格的一套操作:Create) 完整生命周期的管理。 @@ -125,7 +125,7 @@ $ etcdctl del testkey 1 ``` -### 14.4.2 非数据库操作 +### 15.4.2 非数据库操作 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: diff --git a/14_etcd/install.md b/15_etcd/install.md similarity index 96% rename from 14_etcd/install.md rename to 15_etcd/install.md index 77926d1..389ebe8 100644 --- a/14_etcd/install.md +++ b/15_etcd/install.md @@ -1,4 +1,4 @@ -## 14.2 安装 +## 15.2 安装 本节将介绍 etcd 的几种常见安装方式,包括二进制安装、Docker 镜像运行以及在 macOS 上的安装。 @@ -6,7 +6,7 @@ >注意:本章节内容基于 etcd `3.4.x` 版本 -### 14.2.1 二进制文件方式下载 +### 15.2.1 二进制文件方式下载 编译好的二进制文件都在 [github.com/etcd-io/etcd/releases](https://github.com/etcd-io/etcd/releases/) 页面,用户可以选择需要的版本,或通过下载工具下载。 @@ -61,7 +61,7 @@ hello world 说明 etcd 服务已经成功启动了。 -### 14.2.2 Docker 镜像方式运行 +### 15.2.2 Docker 镜像方式运行 镜像名称为 `quay.io/coreos/etcd`,可以通过下面的命令启动 `etcd` 服务监听到 `2379` 和 `2380` 端口。 @@ -89,7 +89,7 @@ quay.io/coreos/etcd:v3.4.0 \ 打开新的终端按照上一步的方法测试 `etcd` 是否成功启动。 -### 14.2.3 macOS 中运行 +### 15.2.3 macOS 中运行 运行以下命令: diff --git a/14_etcd/intro.md b/15_etcd/intro.md similarity index 99% rename from 14_etcd/intro.md rename to 15_etcd/intro.md index 47a03a8..b9c1d6c 100644 --- a/14_etcd/intro.md +++ b/15_etcd/intro.md @@ -1,4 +1,4 @@ -## 14.1 简介 +## 15.1 简介 如图 12-5 所示,etcd 项目使用该标识。 diff --git a/15_etcd/summary.md b/15_etcd/summary.md new file mode 100644 index 0000000..5f07734 --- /dev/null +++ b/15_etcd/summary.md @@ -0,0 +1,17 @@ +## 15.5 本章小结 + +etcd 是 Kubernetes 的核心存储组件,为分布式系统提供可靠的键值存储和服务发现能力。 + +| 概念 | 要点 | +|------|------| +| **定位** | 分布式键值存储系统,用于配置管理和服务发现 | +| **协议** | 基于 Raft 一致性算法,保证数据强一致 | +| **API** | 提供 gRPC 和 HTTP API | +| **集群** | 建议使用奇数节点 (3 或 5 个) 部署 | +| **etcdctl** | 命令行管理工具,支持 put/get/del/watch 等操作 | +| **安全** | 支持 TLS 加密通信和 RBAC 访问控制 | + +### 15.5.1 延伸阅读 + +- [容器编排基础](../13_kubernetes_concepts/README.md):Kubernetes 如何使用 etcd +- [部署 Kubernetes](../14_kubernetes_setup/README.md):在集群中部署 etcd diff --git a/15_cloud/README.md b/16_cloud/README.md similarity index 100% rename from 15_cloud/README.md rename to 16_cloud/README.md diff --git a/15_cloud/_images/ECS.jpg b/16_cloud/_images/ECS.jpg similarity index 100% rename from 15_cloud/_images/ECS.jpg rename to 16_cloud/_images/ECS.jpg diff --git a/15_cloud/_images/aliyun-logo.png b/16_cloud/_images/aliyun-logo.png similarity index 100% rename from 15_cloud/_images/aliyun-logo.png rename to 16_cloud/_images/aliyun-logo.png diff --git a/15_cloud/_images/aws-logo.jpg b/16_cloud/_images/aws-logo.jpg similarity index 100% rename from 15_cloud/_images/aws-logo.jpg rename to 16_cloud/_images/aws-logo.jpg diff --git a/15_cloud/_images/qcloud-logo.jpg b/16_cloud/_images/qcloud-logo.jpg similarity index 100% rename from 15_cloud/_images/qcloud-logo.jpg rename to 16_cloud/_images/qcloud-logo.jpg diff --git a/15_cloud/alicloud.md b/16_cloud/alicloud.md similarity index 98% rename from 15_cloud/alicloud.md rename to 16_cloud/alicloud.md index 6d3daf2..16da68e 100644 --- a/15_cloud/alicloud.md +++ b/16_cloud/alicloud.md @@ -1,4 +1,4 @@ -## 15.3 阿里云 +## 16.3 阿里云 如图 13-3 所示,阿里云是国内主流云服务平台之一。 diff --git a/15_cloud/aws.md b/16_cloud/aws.md similarity index 98% rename from 15_cloud/aws.md rename to 16_cloud/aws.md index 8030eb0..8fac926 100644 --- a/15_cloud/aws.md +++ b/16_cloud/aws.md @@ -1,4 +1,4 @@ -## 15.4 亚马逊云 +## 16.4 亚马逊云 如图 13-1 所示,AWS 是全球主流云服务平台之一。 diff --git a/15_cloud/intro.md b/16_cloud/intro.md similarity index 90% rename from 15_cloud/intro.md rename to 16_cloud/intro.md index 853ae1c..08f9a1b 100644 --- a/15_cloud/intro.md +++ b/16_cloud/intro.md @@ -1,22 +1,22 @@ -## 15.1 简介 +## 16.1 简介 随着容器技术的普及,目前主流的云计算服务商都提供了成熟的容器服务。与容器相关的云计算服务主要分为以下几种类型: -### 15.1.1 容器编排托管服务 +### 16.1.1 容器编排托管服务 这是目前最主流的形式。云厂商托管 Kubernetes 的控制平面 (Master 节点),用户只需管理工作节点 (Worker Node)。 * **优势**:降低了 Kubernetes 集群的维护成本,高可用性由厂商保证。 * **典型服务**:AWS EKS,Azure AKS,Google GKE,阿里云 ACK,腾讯云 TKE。 -### 15.1.2 容器实例服务 +### 16.1.2 容器实例服务 这一类服务通常被称为 CaaS (Container as a Service)。用户无需管理底层服务器 (EC2/CVM),只需提供镜像和配置即可运行容器。 * **优势**:极致的弹性,按秒计费,零运维。 * **典型服务**:AWS Fargate,Azure Container Instances,Google Cloud Run,阿里云 ECI。 -### 15.1.3 镜像仓库服务 +### 16.1.3 镜像仓库服务 提供安全、可靠的私有 Docker 镜像存储服务,通常与云厂商的 CI/CD 流水线深度集成。 diff --git a/15_cloud/multicloud.md b/16_cloud/multicloud.md similarity index 94% rename from 15_cloud/multicloud.md rename to 16_cloud/multicloud.md index 642950e..d25d084 100644 --- a/15_cloud/multicloud.md +++ b/16_cloud/multicloud.md @@ -1,8 +1,8 @@ -## 15.6 多云部署策略比较 +## 16.6 多云部署策略比较 企业在选择容器云平台时,通常会在 AWS EKS,Azure AKS,Google GKE 以及国内的阿里云 ACK,腾讯云 TKE 之间进行权衡。 -### 15.6.1 三大公有云 Kubernetes 服务对比 +### 16.6.1 三大公有云 Kubernetes 服务对比 相关信息如下表: @@ -14,7 +14,7 @@ | **网络模型** | VPC-native, 性能优秀 | AWS VPC CNI, Pod 直接获取 VPC IP | Azure CNI (消耗 IP 多) 或 Kubenet | | **集成度** | 与 GCP 数据分析、AI 服务集成紧密 | 与 AWS IAM, ALB, CloudWatch 集成深度高 | 与 Active Directory, Azure DevOps 集成好 | -### 15.6.2 多云部署策略 +### 16.6.2 多云部署策略 随着企业业务的扩展,单一云平台可能无法满足所有需求,多云部署成为趋势。 @@ -38,7 +38,7 @@ * **工具**:Google Anthos,AWS Outposts,Azure Arc 都是为了解决混合云统一管理而生。 -### 15.6.3 建议 +### 16.6.3 建议 * **技术选型**:尽量使用标准的 Kubernetes API,避免过度依赖特定云厂商的 CRD 或专有服务,以保持应用的可移植性。 * **IaC 管理**:使用 Terraform 或 Pulumi 等工具统一管理多云基础设施。 diff --git a/15_cloud/summary.md b/16_cloud/summary.md similarity index 96% rename from 15_cloud/summary.md rename to 16_cloud/summary.md index 23e9f0c..34b898c 100644 --- a/15_cloud/summary.md +++ b/16_cloud/summary.md @@ -1,4 +1,4 @@ -## 15.5 本章小结 +## 16.5 本章小结 本章介绍了公有云服务对 Docker 的积极支持,以及新出现的容器云平台。 diff --git a/15_cloud/tencentCloud.md b/16_cloud/tencentCloud.md similarity index 99% rename from 15_cloud/tencentCloud.md rename to 16_cloud/tencentCloud.md index fa206f6..112d0c9 100644 --- a/15_cloud/tencentCloud.md +++ b/16_cloud/tencentCloud.md @@ -1,4 +1,4 @@ -## 15.2 腾讯云 +## 16.2 腾讯云 如图 13-5 所示,腾讯云提供完整的云基础设施与容器能力。 diff --git a/16_ecosystem/README.md b/17_ecosystem/README.md similarity index 86% rename from 16_ecosystem/README.md rename to 17_ecosystem/README.md index 59056df..dd7079d 100644 --- a/16_ecosystem/README.md +++ b/17_ecosystem/README.md @@ -1,4 +1,4 @@ -# 第十六章 容器其它生态 +# 第十七章 容器其它生态 本章将介绍 Docker 和 Kubernetes 之外的容器生态技术。 diff --git a/16_ecosystem/coreos_README.md b/17_ecosystem/coreos_README.md similarity index 100% rename from 16_ecosystem/coreos_README.md rename to 17_ecosystem/coreos_README.md diff --git a/16_ecosystem/coreos_install.md b/17_ecosystem/coreos_install.md similarity index 83% rename from 16_ecosystem/coreos_install.md rename to 17_ecosystem/coreos_install.md index a06bb81..9cde1e3 100644 --- a/16_ecosystem/coreos_install.md +++ b/17_ecosystem/coreos_install.md @@ -1,12 +1,12 @@ -## 16.2 安装 Fedora CoreOS +## 17.2 安装 Fedora CoreOS 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: -### 16.2.1 下载 ISO +### 17.2.1 下载 ISO 在[下载页面](https://getfedora.org/coreos/download/) `Bare Metal & Virtualized` 标签页下载 ISO。 -### 16.2.2 编写 FCC +### 17.2.2 编写 FCC FCC 是 Fedora CoreOS Configuration (Fedora CoreOS 配置) 的简称。 @@ -24,7 +24,7 @@ passwd: 将 `ssh-rsa AAAA...` 替换为自己的 SSH 公钥 (位于 `~/.ssh/id_rsa.pub`)。 -### 16.2.3 转换 FCC 为 Ignition +### 17.2.3 转换 FCC 为 Ignition 运行以下命令: @@ -32,7 +32,7 @@ passwd: $ docker run -i --rm quay.io/coreos/fcct:v0.5.0 --pretty --strict < example.fcc > example.ign ``` -### 16.2.4 挂载 ISO 启动虚拟机并安装 +### 17.2.4 挂载 ISO 启动虚拟机并安装 > 虚拟机需要分配 3GB 以上内存,否则会无法启动。 @@ -44,7 +44,7 @@ $ sudo coreos-installer install /dev/sda --ignition-file example.ign 安装之后重新启动即可使用。 -### 16.2.5 使用 +### 17.2.5 使用 运行以下命令: @@ -54,6 +54,6 @@ $ ssh core@虚拟机IP $ docker --version ``` -### 16.2.6 参考链接 +### 17.2.6 参考链接 * [官方文档](https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/) diff --git a/16_ecosystem/coreos_intro.md b/17_ecosystem/coreos_intro.md similarity index 97% rename from 16_ecosystem/coreos_intro.md rename to 17_ecosystem/coreos_intro.md index e802c84..e02cc57 100644 --- a/16_ecosystem/coreos_intro.md +++ b/17_ecosystem/coreos_intro.md @@ -1,8 +1,8 @@ -## 16.1 Fedora CoreOS 介绍 +## 17.1 Fedora CoreOS 介绍 [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 强化等技术相集成。其目标是提供最佳的容器主机,以安全,大规模地运行容器化的工作负载。 -### 16.1.1 FCOS 特性 +### 17.1.1 FCOS 特性 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -24,7 +24,7 @@ FCOS 使用 rpm-ostree 系统进行事务性升级。无需像 yum 升级那样 对于诸如构建,复制和其他管理容器的任务,FCOS 用一组容器工具代替了 **Docker CLI**。**podman CLI** 工具支持许多容器运行时功能,例如运行,启动,停止,列出和删除容器和镜像。**skopeo CLI** 工具可以复制,认证和签名镜像。您还可以使用 **crictl CLI** 工具来处理 CRI-O 容器引擎中的容器和镜像。 -### 16.1.2 参考文档 +### 17.1.2 参考文档 * [官方文档](https://docs.fedoraproject.org/en-US/fedora-coreos/) * [openshift 官方文档](https://docs.openshift.com/container-platform/4.3/architecture/architecture-rhcos.html) diff --git a/16_ecosystem/demo/example.fcc b/17_ecosystem/demo/example.fcc similarity index 100% rename from 16_ecosystem/demo/example.fcc rename to 17_ecosystem/demo/example.fcc diff --git a/16_ecosystem/podman.md b/17_ecosystem/podman.md similarity index 90% rename from 16_ecosystem/podman.md rename to 17_ecosystem/podman.md index 241ece2..390dd40 100644 --- a/16_ecosystem/podman.md +++ b/17_ecosystem/podman.md @@ -2,7 +2,7 @@ [`podman`](https://github.com/containers/podman) 是一个无守护进程、与 Docker 命令高度兼容的下一代 Linux 容器工具。它由 Red Hat 开发,旨在提供一个更安全的容器运行环境。 -## 16.3 Podman vs Docker +## 17.3 Podman vs Docker Podman 和 Docker 在设计理念上存在显著差异,主要体现在架构和权限模型上。 @@ -13,11 +13,11 @@ Podman 和 Docker 在设计理念上存在显著差异,主要体现在架构 | **生态** | 完整的生态系统 (Compose, Swarm) | 专注单机容器,配合 Kubernetes 使用 | | **镜像构建** | `docker build` | `podman build` 或 `buildah` | -## 16.3 安装 +## 17.3 安装 Podman 支持多种操作系统,安装过程也相对简单。 -### 16.3.1 CentOS / RHEL +### 17.3.1 CentOS / RHEL 运行以下命令: @@ -25,7 +25,7 @@ Podman 支持多种操作系统,安装过程也相对简单。 $ sudo yum -y install podman ``` -### 16.3.2 macOS +### 17.3.2 macOS macOS 上需要安装 Podman Desktop 或通过 Homebrew 安装: @@ -35,11 +35,11 @@ $ podman machine init $ podman machine start ``` -## 16.3 使用 +## 17.3 使用 `podman` 的命令行几乎与 `docker` 完全兼容,大多数情况下,你只需将 `docker` 替换为 `podman` 即可。 -### 16.3.1 运行容器 +### 17.3.1 运行容器 运行以下命令: @@ -49,7 +49,7 @@ $ podman machine start $ podman run -d -p 80:80 nginx:alpine ``` -### 16.3.2 列出容器 +### 17.3.2 列出容器 运行以下命令: @@ -57,7 +57,7 @@ $ podman run -d -p 80:80 nginx:alpine $ podman ps ``` -### 16.3.3 构建镜像 +### 17.3.3 构建镜像 运行以下命令: @@ -65,7 +65,7 @@ $ podman ps $ podman build -t myimage . ``` -## 16.3 Pods 的概念 +## 17.3 Pods 的概念 与 Docker 不同,Podman 支持 “Pod” 的概念 (类似于 Kubernetes 的 Pod),允许你在同一个网络命名空间中运行多个容器。 @@ -79,7 +79,7 @@ $ podman pod create --name mypod -p 8080:80 $ podman run -d --pod mypod --name webbing nginx ``` -## 16.3 迁移到 Podman +## 17.3 迁移到 Podman 如果你习惯使用 `docker` 命令,可以简单地设置别名: @@ -87,7 +87,7 @@ $ podman run -d --pod mypod --name webbing nginx $ alias docker=podman ``` -### 16.3.1 进阶用法 +### 17.3.1 进阶用法 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -118,7 +118,7 @@ $ pip3 install podman-compose $ podman-compose up -d ``` -### 16.3.2 参考 +### 17.3.2 参考 * [Podman 官方网站](https://podman.io/) * [Podman GitHub 仓库](https://github.com/containers/podman) diff --git a/17_ecosystem/summary.md b/17_ecosystem/summary.md new file mode 100644 index 0000000..0a412ff --- /dev/null +++ b/17_ecosystem/summary.md @@ -0,0 +1,25 @@ +## 17.4 本章小结 + +Docker 并非容器生态的唯一选择,了解其他工具有助于根据场景做出合适的技术选型。 + +| 项目 | 定位 | 特点 | +|------|------|------| +| **Fedora CoreOS** | 容器化操作系统 | 自动更新、不可变基础设施、专为运行容器设计 | +| **Podman** | 容器引擎 | 无守护进程、兼容 Docker CLI、支持 Rootless 模式 | + +### 17.4.1 Podman vs Docker + +两者的主要区别: + +| 对比项 | Docker | Podman | +|--------|--------|--------| +| **守护进程** | 需要 dockerd | 无需守护进程 | +| **权限** | 默认需要 root | 原生支持 Rootless | +| **CLI 兼容** | - | 与 Docker 命令兼容 | +| **Pod 支持** | 不支持 | 原生支持 Pod 概念 | +| **Compose** | docker compose | podman-compose 或兼容模式 | + +### 17.4.2 延伸阅读 + +- [底层实现](../12_implementation/README.md):容器技术的内核基础 +- [安全](../18_security/README.md):容器安全实践 diff --git a/17_security/README.md b/18_security/README.md similarity index 100% rename from 17_security/README.md rename to 18_security/README.md diff --git a/17_security/control_group.md b/18_security/control_group.md similarity index 97% rename from 17_security/control_group.md rename to 18_security/control_group.md index 656d910..600b058 100644 --- a/17_security/control_group.md +++ b/18_security/control_group.md @@ -1,4 +1,4 @@ -## 17.2 控制组 +## 18.2 控制组 控制组是 Linux 容器机制的另外一个关键组件,负责实现资源的审计和限制。 diff --git a/17_security/daemon_sec.md b/18_security/daemon_sec.md similarity index 98% rename from 17_security/daemon_sec.md rename to 18_security/daemon_sec.md index ffead3b..ae3964f 100644 --- a/17_security/daemon_sec.md +++ b/18_security/daemon_sec.md @@ -1,4 +1,4 @@ -## 17.3 Docker 服务端的防护 +## 18.3 Docker 服务端的防护 运行一个容器或应用程序的核心是通过 Docker 服务端。Docker 服务的运行目前需要 root 权限,因此其安全性十分关键。 diff --git a/17_security/kernel_capability.md b/18_security/kernel_capability.md similarity index 98% rename from 17_security/kernel_capability.md rename to 18_security/kernel_capability.md index 83f0f69..ea8b21d 100644 --- a/17_security/kernel_capability.md +++ b/18_security/kernel_capability.md @@ -1,4 +1,4 @@ -## 17.4 内核能力机制 +## 18.4 内核能力机制 Docker 利用 Linux 的能力机制 (Capabilities) 来限制容器的权限,从而提高系统的安全性。 diff --git a/17_security/kernel_ns.md b/18_security/kernel_ns.md similarity index 98% rename from 17_security/kernel_ns.md rename to 18_security/kernel_ns.md index f4d803d..1237004 100644 --- a/17_security/kernel_ns.md +++ b/18_security/kernel_ns.md @@ -1,4 +1,4 @@ -## 17.1 内核命名空间 +## 18.1 内核命名空间 命名空间 (Namespace) 是 Linux 容器隔离的基础,它确保了容器内的进程无法干扰主机或其他容器。 diff --git a/17_security/other_feature.md b/18_security/other_feature.md similarity index 97% rename from 17_security/other_feature.md rename to 18_security/other_feature.md index 7f99522..56056ca 100644 --- a/17_security/other_feature.md +++ b/18_security/other_feature.md @@ -1,4 +1,4 @@ -## 17.5 其它安全特性 +## 18.5 其它安全特性 除了上述机制,Linux 内核还提供了一系列安全增强功能,可以进一步保护容器环境。 diff --git a/17_security/summary.md b/18_security/summary.md similarity index 97% rename from 17_security/summary.md rename to 18_security/summary.md index ffc9f6e..007a87e 100644 --- a/17_security/summary.md +++ b/18_security/summary.md @@ -1,4 +1,4 @@ -## 17.6 总结 +## 18.6 总结 Docker 的安全性依赖于多层隔离机制的协同工作,同时需要用户遵循最佳实践。 diff --git a/18_observability/README.md b/19_observability/README.md similarity index 92% rename from 18_observability/README.md rename to 19_observability/README.md index 637e567..2a4eb91 100644 --- a/18_observability/README.md +++ b/19_observability/README.md @@ -1,4 +1,4 @@ -# 第十八章 容器监控与日志 +# 第十九章 容器监控与日志 在生产环境中,容器化应用部署完成后,实时掌握容器集群的状态以及应用日志非常重要。本章将介绍针对 Docker 容器和 Kubernetes 集群的监控与日志管理方案。 diff --git a/18_observability/elk.md b/19_observability/elk.md similarity index 97% rename from 18_observability/elk.md rename to 19_observability/elk.md index 622cf8a..667b446 100644 --- a/18_observability/elk.md +++ b/19_observability/elk.md @@ -1,8 +1,8 @@ -## 18.2 ELK/EFK 堆栈 +## 19.2 ELK/EFK 堆栈 ELK (Elasticsearch,Logstash,Kibana) 是目前业界最流行的开源日志解决方案。而在容器领域,由于 Fluentd 更加轻量级且对容器支持更好,EFK (Elasticsearch,Fluentd,Kibana) 组合也变得非常流行。 -### 18.2.1 方案架构 +### 19.2.1 方案架构 我们将采用以下架构: @@ -11,7 +11,7 @@ ELK (Elasticsearch,Logstash,Kibana) 是目前业界最流行的开源日志 3. **Elasticsearch**:存储从 Fluentd 接收到的日志数据。 4. **Kibana**:从 Elasticsearch 读取数据并进行可视化展示。 -### 18.2.2 部署流程 +### 19.2.2 部署流程 我们将使用 Docker Compose 来一键部署整个日志堆栈。 @@ -125,6 +125,6 @@ docker run -d \ 4. 选择 `@timestamp` 作为时间字段。 5. 去 **Discover** 页面,你就能看到 Nginx 容器的日志了。 -### 18.2.3 总结 +### 19.2.3 总结 通过 Docker 的日志驱动机制,结合 ELK/EFK 强大的收集和分析能力,我们可以轻松构建一个能够处理海量日志的监控平台,这对于排查生产问题至关重要。 diff --git a/18_observability/prometheus.md b/19_observability/prometheus.md similarity index 95% rename from 18_observability/prometheus.md rename to 19_observability/prometheus.md index 7f6a4f2..aa197df 100644 --- a/18_observability/prometheus.md +++ b/19_observability/prometheus.md @@ -1,10 +1,10 @@ -## 18.1 Prometheus + Grafana +## 19.1 Prometheus + Grafana Prometheus 和 Grafana 是目前最流行的开源监控组合,前者负责数据采集与存储,后者负责数据可视化。 [Prometheus](https://prometheus.io/) 是一个开源的系统监控和报警工具包。它受 Google Borgmon 的启发,由 SoundCloud 在 2012 年创建。 -### 18.1.1 架构简介 +### 19.1.1 架构简介 Prometheus 的主要组件包括: @@ -13,7 +13,7 @@ Prometheus 的主要组件包括: * **Alertmanager**:处理报警发送。 * **Pushgateway**:用于支持短生命周期的 Job 推送数据。 -### 18.1.2 快速部署 +### 19.1.2 快速部署 我们可以使用 Docker Compose 快速部署一套 Prometheus + Grafana 监控环境。 @@ -101,7 +101,7 @@ $ docker compose up -d * Prometheus: `http://localhost:9090` * Grafana:`http://localhost:3000` (默认账号密码:admin/admin) -### 18.1.3 配置 Grafana 面板 +### 19.1.3 配置 Grafana 面板 1. 在 Grafana 中添加 Prometheus 数据源,URL 填写 `http://prometheus:9090`。 2. 导入现成的 Dashboard 模板,例如 [Node Exporter Full](https://grafana.com/grafana/dashboards/1860) (ID:1860) 和 [Docker Container](https://grafana.com/grafana/dashboards/193) (ID:193)。 diff --git a/18_observability/summary.md b/19_observability/summary.md similarity index 95% rename from 18_observability/summary.md rename to 19_observability/summary.md index 9fd5d1c..c7ecb39 100644 --- a/18_observability/summary.md +++ b/19_observability/summary.md @@ -2,7 +2,7 @@ 在容器化环境中,日志管理比传统环境更为复杂。容器是短暂的,意味着容器内的日志文件可能会随着容器的销毁而丢失。因此,我们需要一种集中式的日志管理方案来收集、存储和分析容器日志。 -## 18.3 Docker 日志驱动 +## 19.3 Docker 日志驱动 Docker 提供了多种日志驱动 (Log Driver) 机制,允许我们将容器日志转发到不同的后端。 @@ -15,7 +15,7 @@ Docker 提供了多种日志驱动 (Log Driver) 机制,允许我们将容器 * `gelf`:支持 GELF 协议的日志后端 (如 Graylog)。 * `awslogs`:发送到 Amazon CloudWatch Logs。 -## 18.3 日志管理方案 +## 19.3 日志管理方案 对于大规模的容器集群,我们通常会采用 EFK (Elasticsearch + Fluentd + Kibana) 或 ELK (Elasticsearch + Logstash + Kibana) 方案。 diff --git a/19_cases/README.md b/20_cases/README.md similarity index 87% rename from 19_cases/README.md rename to 20_cases/README.md index 9576aa9..d999c62 100644 --- a/19_cases/README.md +++ b/20_cases/README.md @@ -1,4 +1,4 @@ -# 第十九章实战案例 +# 第二十章实战案例 本章将介绍 Docker 在不同场景下的实战案例。 diff --git a/19_cases/ci/README.md b/20_cases/ci/README.md similarity index 100% rename from 19_cases/ci/README.md rename to 20_cases/ci/README.md diff --git a/19_cases/ci/actions/README.md b/20_cases/ci/actions/README.md similarity index 94% rename from 19_cases/ci/actions/README.md rename to 20_cases/ci/actions/README.md index 78be38f..5b71bbe 100644 --- a/19_cases/ci/actions/README.md +++ b/20_cases/ci/actions/README.md @@ -23,10 +23,10 @@ jobs: args: go version ``` -## 19.9 概述 +## 20.9 概述 总体概述了以下内容。 -## 19.9 参考资料 +## 20.9 参考资料 * [Actions Docs](https://docs.github.com/en/actions) diff --git a/19_cases/ci/devops_workflow.md b/20_cases/ci/devops_workflow.md similarity index 95% rename from 19_cases/ci/devops_workflow.md rename to 20_cases/ci/devops_workflow.md index 93a8088..7eb5713 100644 --- a/19_cases/ci/devops_workflow.md +++ b/20_cases/ci/devops_workflow.md @@ -1,8 +1,8 @@ -## 19.8 DevOps 工作流完整示例 +## 20.8 DevOps 工作流完整示例 本章将演示一个基于 Docker,Kubernetes 和 Jenkins/GitLab CI 的完整 DevOps 工作流。 -### 19.8.1 工作流概览 +### 20.8.1 工作流概览 1. **Code**:开发人员提交代码到 GitLab。 2. **Build**:GitLab CI 触发构建任务。 @@ -12,7 +12,7 @@ 6. **Verify**:人工或自动化验证。 7. **Release (Production)**:审批后自动部署到生产环境。 -### 19.8.2 关键配置示例 +### 20.8.2 关键配置示例 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: @@ -79,7 +79,7 @@ deploy_staging: - develop ``` -### 19.8.3 最佳实践 +### 20.8.3 最佳实践 1. **不可变基础设施**:一旦镜像构建完成,在各个环境 (Dev,Staging,Prod) 中都应该使用同一个镜像 tag (通常是 commit hash),而不是重新构建。 2. **配置分离**:使用 ConfigMap 和 Secret 管理环境特定的配置,不要打包进镜像。 diff --git a/19_cases/ci/drone/.env.example b/20_cases/ci/drone/.env.example similarity index 100% rename from 19_cases/ci/drone/.env.example rename to 20_cases/ci/drone/.env.example diff --git a/19_cases/ci/drone/.gitignore b/20_cases/ci/drone/.gitignore similarity index 100% rename from 19_cases/ci/drone/.gitignore rename to 20_cases/ci/drone/.gitignore diff --git a/19_cases/ci/drone/README.md b/20_cases/ci/drone/README.md similarity index 93% rename from 19_cases/ci/drone/README.md rename to 20_cases/ci/drone/README.md index 0563c34..de53d94 100644 --- a/19_cases/ci/drone/README.md +++ b/20_cases/ci/drone/README.md @@ -6,13 +6,13 @@ 本小节以 `GitHub` + `Drone` 来演示 `Drone` 的工作流程。当然在实际开发过程中,你的代码也许不在 GitHub 托管,那么你可以尝试使用 `Gogs` + `Drone` 来进行 `CI/CD`。 -## 19.10 Drone 关联项目 +## 20.10 Drone 关联项目 在 Github 新建一个名为 `drone-demo` 的仓库。 打开我们已经[部署好的 Drone 网站](install.md)或者 [Drone Cloud](https://cloud.drone.io),使用 GitHub 账号登录,在界面中关联刚刚新建的 `drone-demo` 仓库。 -## 19.10 编写项目源代码 +## 20.10 编写项目源代码 初始化一个 git 仓库 @@ -72,7 +72,7 @@ trigger: └── app.go ``` -## 19.10 推送项目源代码到 GitHub +## 20.10 推送项目源代码到 GitHub 运行以下命令: @@ -84,7 +84,7 @@ $ git commit -m "test drone ci" $ git push origin master ``` -## 19.10 查看项目构建过程及结果 +## 20.10 查看项目构建过程及结果 打开我们部署好的 `Drone` 网站或者 Drone Cloud,即可看到构建结果。 @@ -94,7 +94,7 @@ $ git push origin master 本书 GitBook 也使用 Drone 进行 CI/CD,具体配置信息请查看本书根目录 [`.drone.yml`](https://github.com/yeasy/docker_practice/blob/master/.drone.yml) 文件。 -## 19.10 参考链接 +## 20.10 参考链接 * [Drone Github](https://github.com/drone/drone) * [Drone 文档](https://docs.drone.io/) diff --git a/19_cases/ci/drone/demo/.drone.yml b/20_cases/ci/drone/demo/.drone.yml similarity index 100% rename from 19_cases/ci/drone/demo/.drone.yml rename to 20_cases/ci/drone/demo/.drone.yml diff --git a/19_cases/ci/drone/demo/README.md b/20_cases/ci/drone/demo/README.md similarity index 93% rename from 19_cases/ci/drone/demo/README.md rename to 20_cases/ci/drone/demo/README.md index 3d63ebb..6c84636 100644 --- a/19_cases/ci/drone/demo/README.md +++ b/20_cases/ci/drone/demo/README.md @@ -2,13 +2,13 @@ 这是一个基于 Go 语言编写的简单 Web 应用示例,用于演示 Drone CI 的持续集成流程。 -## 19.12 目录结构 +## 20.12 目录结构 * `app.go`:简单的 Go Web 服务器代码。 * `.drone.yml`:Drone CI 的配置文件,定义了构建和测试流程。 * `Dockerfile`:定义了如何将该应用构建为 Docker 镜像。 -## 19.12 如何运行 +## 20.12 如何运行 1. 确保本地已安装 Docker 环境。 2. 进入本目录构建镜像: diff --git a/19_cases/ci/drone/demo/app.go b/20_cases/ci/drone/demo/app.go similarity index 100% rename from 19_cases/ci/drone/demo/app.go rename to 20_cases/ci/drone/demo/app.go diff --git a/19_cases/ci/drone/docker-compose.yml b/20_cases/ci/drone/docker-compose.yml similarity index 100% rename from 19_cases/ci/drone/docker-compose.yml rename to 20_cases/ci/drone/docker-compose.yml diff --git a/19_cases/ci/drone/install.md b/20_cases/ci/drone/install.md similarity index 95% rename from 19_cases/ci/drone/install.md rename to 20_cases/ci/drone/install.md index ed05414..c027104 100644 --- a/19_cases/ci/drone/install.md +++ b/20_cases/ci/drone/install.md @@ -1,8 +1,8 @@ -## 19.11 部署 Drone +## 20.11 部署 Drone 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: -### 19.11.1 要求 +### 20.11.1 要求 * 拥有公网 IP、域名 (如果你不满足要求,可以尝试在本地使用 Gogs + Drone) @@ -14,7 +14,7 @@ * 对 `CI/CD` 有一定了解 -### 19.11.2 新建 GitHub 应用 +### 20.11.2 新建 GitHub 应用 登录 GitHub,在 https://github.com/settings/applications/new 新建一个应用。 @@ -22,7 +22,7 @@ 接下来查看这个应用的详情,记录 `Client ID` 和 `Client Secret`,之后配置 Drone 会用到。 -### 19.11.3 配置 Drone +### 20.11.3 配置 Drone 我们通过使用 `Docker Compose` 来启动 `Drone`,编写 `compose.yaml` (或 `docker-compose.yml`) 文件。 diff --git a/19_cases/ide/README.md b/20_cases/ide/README.md similarity index 100% rename from 19_cases/ide/README.md rename to 20_cases/ide/README.md diff --git a/19_cases/ide/vsCode.md b/20_cases/ide/vsCode.md similarity index 72% rename from 19_cases/ide/vsCode.md rename to 20_cases/ide/vsCode.md index e6d062d..d86c3d7 100644 --- a/19_cases/ide/vsCode.md +++ b/20_cases/ide/vsCode.md @@ -1,11 +1,11 @@ -## 19.14 VS Code 中使用 Docker +## 20.14 VS Code 中使用 Docker 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: -### 19.14.1 概述 +### 20.14.1 概述 总体概述了以下内容。 -### 19.14.2 将 Docker 容器作为远程开发环境 +### 20.14.2 将 Docker 容器作为远程开发环境 无需本地安装开发工具,直接将 Docker 容器作为开发环境,具体参考[官方文档](https://code.visualstudio.com/docs/remote/containers)。 diff --git a/19_cases/os/README.md b/20_cases/os/README.md similarity index 100% rename from 19_cases/os/README.md rename to 20_cases/os/README.md diff --git a/19_cases/os/alpine.md b/20_cases/os/alpine.md similarity index 96% rename from 19_cases/os/alpine.md rename to 20_cases/os/alpine.md index 9432316..03ae1ba 100644 --- a/19_cases/os/alpine.md +++ b/20_cases/os/alpine.md @@ -1,8 +1,8 @@ -## 19.3 Alpine +## 20.3 Alpine 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: -### 19.3.1 简介 +### 20.3.1 简介 下图直观地展示了本节内容: @@ -28,7 +28,7 @@ ubuntu latest b39b81afc8ca 188.3 MB centos latest 8efe422e6104 210 MB ``` -### 19.3.2 获取并使用官方镜像 +### 20.3.2 获取并使用官方镜像 由于镜像很小,下载时间往往很短,读者可以直接使用 `docker run` 指令直接运行一个 `Alpine` 容器,并指定运行的 Linux 指令,例如: @@ -37,7 +37,7 @@ $ docker run alpine echo '123' 123 ``` -### 19.3.3 迁移至 Alpine 基础镜像 +### 20.3.3 迁移至 Alpine 基础镜像 目前,大部分 Docker 官方镜像都已经支持 `Alpine` 作为基础镜像,可以很容易进行迁移。 @@ -67,7 +67,7 @@ RUN sed -i "s/dl-cdn.alpinelinux.org/mirrors.aliyun.com/g" /etc/apk/repositories && apk add --no-cache ``` -### 19.3.4 相关资源 +### 20.3.4 相关资源 * `Alpine` 官网:https://www.alpinelinux.org/ * `Alpine` 官方仓库:https://github.com/alpinelinux diff --git a/19_cases/os/busybox.md b/20_cases/os/busybox.md similarity index 97% rename from 19_cases/os/busybox.md rename to 20_cases/os/busybox.md index 766eed6..02765c0 100644 --- a/19_cases/os/busybox.md +++ b/20_cases/os/busybox.md @@ -1,8 +1,8 @@ -## 19.2 Busybox +## 20.2 Busybox 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: -### 19.2.1 简介 +### 20.2.1 简介 下图直观地展示了本节内容: @@ -13,7 +13,7 @@ `BusyBox` 可运行于多款 `POSIX` 环境的操作系统中,如 `Linux` (包括 `Android`)、`Hurd`、`FreeBSD` 等。 -### 19.2.2 获取官方镜像 +### 20.2.2 获取官方镜像 可以使用 `docker pull` 指令下载 `busybox:latest` 镜像: @@ -34,7 +34,7 @@ REPOSITORY TAG IMAGE ID CREATED busybox latest e72ac664f4f0 6 weeks ago 2.433 MB ``` -### 19.2.3 运行 busybox +### 20.2.3 运行 busybox 启动一个 `busybox` 容器,并在容器中执行 `grep` 命令。 @@ -112,7 +112,7 @@ tmpfs on /sys/firmware type tmpfs (ro,relatime) `busybox` 镜像虽然小巧,但包括了大量常见的 `Linux` 命令,读者可以用它快速熟悉 `Linux` 命令。 -### 19.2.4 相关资源 +### 20.2.4 相关资源 * `Busybox` 官网:https://busybox.net/ * `Busybox` 官方仓库:https://git.busybox.net/busybox/ diff --git a/19_cases/os/centos.md b/20_cases/os/centos.md similarity index 96% rename from 19_cases/os/centos.md rename to 20_cases/os/centos.md index 38d1c48..8644905 100644 --- a/19_cases/os/centos.md +++ b/20_cases/os/centos.md @@ -1,8 +1,8 @@ -## 19.5 CentOS 和 Fedora +## 20.5 CentOS 和 Fedora 本节涵盖了相关内容与详细描述,主要探讨以下几个方面: -### 19.5.1 CentOS 系统简介 +### 20.5.1 CentOS 系统简介 `CentOS` 和 `Fedora` 都是基于 `Redhat` 的常见 Linux 分支。`CentOS` 是目前企业级服务器的常用操作系统;`Fedora` 则主要面向个人桌面用户。 @@ -35,7 +35,7 @@ Status: Downloaded newer image for centos:7 CentOS Linux release 7.9.2009 (Core) ``` -### 19.5.2 Fedora 系统简介 +### 20.5.2 Fedora 系统简介 下图直观地展示了本节内容: @@ -64,7 +64,7 @@ Fedora release 39 (Thirty Nine) ``` -### 19.5.3 相关资源 +### 20.5.3 相关资源 * `Fedora` 官网:https://getfedora.org/ * `Fedora` 官方仓库:https://github.com/fedora-infra diff --git a/19_cases/os/debian.md b/20_cases/os/debian.md similarity index 98% rename from 19_cases/os/debian.md rename to 20_cases/os/debian.md index d3cca95..1dc6f36 100644 --- a/19_cases/os/debian.md +++ b/20_cases/os/debian.md @@ -1,8 +1,8 @@ -## 19.4 Debian Ubuntu +## 20.4 Debian Ubuntu `Debian` 和 `Ubuntu` 都是目前较为流行的 **Debian 系** 的服务器操作系统,十分适合研发场景。`Docker Hub` 上提供了官方镜像,国内各大容器云服务也基本都提供了相应的支持。 -### 19.4.1 Debian 系统简介 +### 20.4.1 Debian 系统简介 下图直观地展示了本节内容: @@ -34,7 +34,7 @@ Debian GNU/Linux 8 `Debian` 镜像很适合作为基础镜像,构建自定义镜像。 -### 19.4.2 Ubuntu 系统简介 +### 20.4.2 Ubuntu 系统简介 下图直观地展示了本节内容: @@ -143,7 +143,7 @@ root@7d93de07bf76:/# curl 127.0.0.1 配合使用 `-p` 参数对外映射服务端口,可以允许容器外来访问该服务。 -### 19.4.3 相关资源 +### 20.4.3 相关资源 * `Debian` 官网:https://www.debian.org/ * `Neuro Debian` 官网:http://neuro.debian.net/ diff --git a/19_cases/os/summary.md b/20_cases/os/summary.md similarity index 96% rename from 19_cases/os/summary.md rename to 20_cases/os/summary.md index 0a1ad25..73e7bbd 100644 --- a/19_cases/os/summary.md +++ b/20_cases/os/summary.md @@ -1,4 +1,4 @@ -## 19.6 本章小结 +## 20.6 本章小结 本章讲解了典型操作系统镜像的下载和使用。 diff --git a/README.md b/README.md index 98e605f..5e2aabd 100644 --- a/README.md +++ b/README.md @@ -19,6 +19,8 @@ ## 阅读方式 +本书按需提供多种阅读模式,具体如下: + ### 在线阅读 * **GitBook**: [yeasy.gitbook.io/docker_practice](https://yeasy.gitbook.io/docker_practice/) @@ -27,6 +29,8 @@ ### 本地阅读 +您也可以选择以下方式在本地离线阅读。 + #### 方式 1:Docker 镜像 (推荐) 无需安装任何依赖,一条命令即可启动。 diff --git a/SUMMARY.md b/SUMMARY.md index 2586d7e..0c5f477 100644 --- a/SUMMARY.md +++ b/SUMMARY.md @@ -27,6 +27,7 @@ * [3.8 Windows 10/11](03_install/3.8_windows.md) * [3.9 镜像加速器](03_install/3.9_mirror.md) * [3.10 开启实验特性](03_install/3.10_experimental.md) + * [本章小结](03_install/summary.md) * [第四章 使用镜像](04_image/README.md) * [4.1 获取镜像](04_image/4.1_pull.md) * [4.2 列出镜像](04_image/4.2_list.md) @@ -73,107 +74,115 @@ * [7.17 多阶段构建](07_dockerfile/7.17_multistage_builds.md) * [7.18 实战多阶段构建 Laravel 镜像](07_dockerfile/7.18_multistage_builds_laravel.md) * [本章小结](07_dockerfile/summary.md) -* [第八章 数据与网络管理](08_data_network/README.md) - * [数据管理](08_data_network/data/README.md) - * [数据卷](08_data_network/data/volume.md) - * [挂载主机目录](08_data_network/data/bind-mounts.md) - * [tmpfs 挂载](08_data_network/data/tmpfs.md) - * [本章小结](08_data_network/data/summary.md) - * [网络配置](08_data_network/network/README.md) - * [配置 DNS](08_data_network/network/dns.md) - * [外部访问容器](08_data_network/network/port_mapping.md) - * [本章小结](08_data_network/network/summary.md) -* [第九章 Docker Buildx](09_buildx/README.md) - * [9.1 BuildKit](09_buildx/9.1_buildkit.md) - * [9.2 使用 buildx 构建镜像](09_buildx/9.2_buildx.md) - * [9.3 使用 buildx 构建多种系统架构支持的 Docker 镜像](09_buildx/9.3_multi-arch-images.md) -* [第十章 Docker Compose](10_compose/README.md) - * [10.1 简介](10_compose/10.1_introduction.md) - * [10.2 安装与卸载](10_compose/10.2_install.md) - * [10.3 使用](10_compose/10.3_usage.md) - * [10.4 命令说明](10_compose/10.4_commands.md) - * [10.5 Compose 模板文件](10_compose/10.5_compose_file.md) - * [10.6 实战 Django](10_compose/10.6_django.md) - * [10.7 实战 Rails](10_compose/10.7_rails.md) - * [10.8 实战 WordPress](10_compose/10.8_wordpress.md) - * [10.9 实战 LNMP](10_compose/10.9_lnmp.md) +* [第八章 数据管理](08_data/README.md) + * [8.1 数据卷](08_data/volume.md) + * [8.2 挂载主机目录](08_data/bind-mounts.md) + * [8.3 tmpfs 挂载](08_data/tmpfs.md) + * [本章小结](08_data/summary.md) +* [第九章 网络配置](09_network/README.md) + * [9.1 配置 DNS](09_network/dns.md) + * [9.2 网络类型](09_network/network_types.md) + * [9.3 自定义网络](09_network/custom_network.md) + * [9.4 容器互联](09_network/container_linking.md) + * [9.5 外部访问容器](09_network/port_mapping.md) + * [9.6 网络隔离](09_network/network_isolation.md) + * [本章小结](09_network/summary.md) +* [第十章 Docker Buildx](10_buildx/README.md) + * [10.1 BuildKit](10_buildx/10.1_buildkit.md) + * [10.2 使用 buildx 构建镜像](10_buildx/10.2_buildx.md) + * [10.3 使用 buildx 构建多种系统架构支持的 Docker 镜像](10_buildx/10.3_multi-arch-images.md) + * [本章小结](10_buildx/summary.md) +* [第十一章 Docker Compose](11_compose/README.md) + * [11.1 简介](11_compose/11.1_introduction.md) + * [11.2 安装与卸载](11_compose/11.2_install.md) + * [11.3 使用](11_compose/11.3_usage.md) + * [11.4 命令说明](11_compose/11.4_commands.md) + * [11.5 Compose 模板文件](11_compose/11.5_compose_file.md) + * [11.6 实战 Django](11_compose/11.6_django.md) + * [11.7 实战 Rails](11_compose/11.7_rails.md) + * [11.8 实战 WordPress](11_compose/11.8_wordpress.md) + * [11.9 实战 LNMP](11_compose/11.9_lnmp.md) + * [本章小结](11_compose/summary.md) ## 第三部分:深入篇 -* [第十一章 底层实现](11_implementation/README.md) - * [基本架构](11_implementation/11.1_arch.md) - * [命名空间](11_implementation/11.2_namespace.md) - * [控制组](11_implementation/11.3_cgroups.md) - * [联合文件系统](11_implementation/11.4_ufs.md) - * [容器格式](11_implementation/11.5_container_format.md) - * [网络](11_implementation/11.6_network.md) - * [本章小结](11_implementation/summary.md) -* [第十二章 容器编排基础](12_kubernetes_concepts/README.md) - * [简介](12_kubernetes_concepts/intro.md) - * [基本概念](12_kubernetes_concepts/concepts.md) - * [架构设计](12_kubernetes_concepts/design.md) - * [高级特性](12_kubernetes_concepts/advanced.md) - * [实战练习](12_kubernetes_concepts/practice.md) -* [第十三章 部署 Kubernetes](13_kubernetes_setup/README.md) - * [使用 kubeadm 部署 Kubernetes (CRI 使用 containerd)](13_kubernetes_setup/kubeadm.md) - * [使用 kubeadm 部署 Kubernetes (使用 Docker)](13_kubernetes_setup/kubeadm-docker.md) - * [在 Docker Desktop 使用](13_kubernetes_setup/docker-desktop.md) - * [Kind - Kubernetes IN Docker](13_kubernetes_setup/kind.md) - * [K3s - 轻量级 Kubernetes](13_kubernetes_setup/k3s.md) - * [一步步部署 Kubernetes 集群](13_kubernetes_setup/systemd.md) - * [部署 Dashboard](13_kubernetes_setup/dashboard.md) - * [Kubernetes 命令行 kubectl](13_kubernetes_setup/kubectl.md) -* [第十四章 Etcd 项目](14_etcd/README.md) - * [简介](14_etcd/intro.md) - * [安装](14_etcd/install.md) - * [集群](14_etcd/cluster.md) - * [使用 etcdctl](14_etcd/etcdctl.md) -* [第十五章 容器与云计算](15_cloud/README.md) - * [简介](15_cloud/intro.md) - * [腾讯云](15_cloud/tencentCloud.md) - * [阿里云](15_cloud/alicloud.md) - * [亚马逊云](15_cloud/aws.md) - * [小结](15_cloud/summary.md) - * [多云部署策略](15_cloud/multicloud.md) -* [第十六章 容器其它生态](16_ecosystem/README.md) - * [Fedora CoreOS 简介](16_ecosystem/coreos_intro.md) - * [Fedora CoreOS 安装](16_ecosystem/coreos_install.md) - * [podman - 下一代 Linux 容器工具](16_ecosystem/podman.md) +* [第十二章 底层实现](12_implementation/README.md) + * [12.1 基本架构](12_implementation/12.1_arch.md) + * [12.2 命名空间](12_implementation/12.2_namespace.md) + * [12.3 控制组](12_implementation/12.3_cgroups.md) + * [12.4 联合文件系统](12_implementation/12.4_ufs.md) + * [12.5 容器格式](12_implementation/12.5_container_format.md) + * [12.6 网络](12_implementation/12.6_network.md) + * [本章小结](12_implementation/summary.md) +* [第十三章 容器编排基础](13_kubernetes_concepts/README.md) + * [13.1 简介](13_kubernetes_concepts/intro.md) + * [13.2 基本概念](13_kubernetes_concepts/concepts.md) + * [13.3 架构设计](13_kubernetes_concepts/design.md) + * [13.4 高级特性](13_kubernetes_concepts/advanced.md) + * [13.5 实战练习](13_kubernetes_concepts/practice.md) + * [本章小结](13_kubernetes_concepts/summary.md) +* [第十四章 部署 Kubernetes](14_kubernetes_setup/README.md) + * [14.1 使用 kubeadm 部署 Kubernetes (CRI 使用 containerd)](14_kubernetes_setup/kubeadm.md) + * [14.2 使用 kubeadm 部署 Kubernetes (使用 Docker)](14_kubernetes_setup/kubeadm-docker.md) + * [14.3 在 Docker Desktop 使用](14_kubernetes_setup/docker-desktop.md) + * [14.4 Kind - Kubernetes IN Docker](14_kubernetes_setup/kind.md) + * [14.5 K3s - 轻量级 Kubernetes](14_kubernetes_setup/k3s.md) + * [14.6 一步步部署 Kubernetes 集群](14_kubernetes_setup/systemd.md) + * [14.7 部署 Dashboard](14_kubernetes_setup/dashboard.md) + * [14.8 Kubernetes 命令行 kubectl](14_kubernetes_setup/kubectl.md) + * [本章小结](14_kubernetes_setup/summary.md) +* [第十五章 Etcd 项目](15_etcd/README.md) + * [15.1 简介](15_etcd/intro.md) + * [15.2 安装](15_etcd/install.md) + * [15.3 集群](15_etcd/cluster.md) + * [15.4 使用 etcdctl](15_etcd/etcdctl.md) + * [本章小结](15_etcd/summary.md) +* [第十六章 容器与云计算](16_cloud/README.md) + * [16.1 简介](16_cloud/intro.md) + * [16.2 腾讯云](16_cloud/tencentCloud.md) + * [16.3 阿里云](16_cloud/alicloud.md) + * [16.4 亚马逊云](16_cloud/aws.md) + * [16.5 小结](16_cloud/summary.md) + * [16.6 多云部署策略](16_cloud/multicloud.md) +* [第十七章 容器其它生态](17_ecosystem/README.md) + * [17.1 Fedora CoreOS 简介](17_ecosystem/coreos_intro.md) + * [17.2 Fedora CoreOS 安装](17_ecosystem/coreos_install.md) + * [17.3 podman - 下一代 Linux 容器工具](17_ecosystem/podman.md) + * [本章小结](17_ecosystem/summary.md) ## 第四部分:实战篇 -* [第十七章 安全](17_security/README.md) - * [内核命名空间](17_security/kernel_ns.md) - * [控制组](17_security/control_group.md) - * [服务端防护](17_security/daemon_sec.md) - * [内核能力机制](17_security/kernel_capability.md) - * [其它安全特性](17_security/other_feature.md) - * [总结](17_security/summary.md) -* [第十八章 容器监控与日志](18_observability/README.md) - * [Prometheus](18_observability/prometheus.md) - * [ELK 套件](18_observability/elk.md) - * [小结](18_observability/summary.md) -* [第十九章 实战案例](19_cases/README.md) - * [实战案例 - 操作系统](19_cases/os/README.md) - * [Busybox](19_cases/os/busybox.md) - * [Alpine](19_cases/os/alpine.md) - * [Debian Ubuntu](19_cases/os/debian.md) - * [CentOS Fedora](19_cases/os/centos.md) - * [本章小结](19_cases/os/summary.md) - * [实战案例 - CI/CD](19_cases/ci/README.md) - * [DevOps 完整工作流](19_cases/ci/devops_workflow.md) - * [GitHub Actions](19_cases/ci/actions/README.md) - * [Drone](19_cases/ci/drone/README.md) - * [部署 Drone](19_cases/ci/drone/install.md) - * [Drone Demo](19_cases/ci/drone/demo/README.md) - * [在 IDE 中使用 Docker](19_cases/ide/README.md) - * [VS Code](19_cases/ide/vsCode.md) +* [第十八章 安全](18_security/README.md) + * [18.1 内核命名空间](18_security/kernel_ns.md) + * [18.2 控制组](18_security/control_group.md) + * [18.3 服务端防护](18_security/daemon_sec.md) + * [18.4 内核能力机制](18_security/kernel_capability.md) + * [18.5 其它安全特性](18_security/other_feature.md) + * [18.6 总结](18_security/summary.md) +* [第十九章 容器监控与日志](19_observability/README.md) + * [19.1 Prometheus](19_observability/prometheus.md) + * [19.2 ELK 套件](19_observability/elk.md) + * [19.3 小结](19_observability/summary.md) +* [第二十章 实战案例](20_cases/README.md) + * [20.1 实战案例 - 操作系统](20_cases/os/README.md) + * [20.1.1 Busybox](20_cases/os/busybox.md) + * [20.1.2 Alpine](20_cases/os/alpine.md) + * [20.1.3 Debian Ubuntu](20_cases/os/debian.md) + * [20.1.4 CentOS Fedora](20_cases/os/centos.md) + * [本章小结](20_cases/os/summary.md) + * [20.2 实战案例 - CI/CD](20_cases/ci/README.md) + * [20.2.1 DevOps 完整工作流](20_cases/ci/devops_workflow.md) + * [20.2.2 GitHub Actions](20_cases/ci/actions/README.md) + * [20.2.3 Drone](20_cases/ci/drone/README.md) + * [部署 Drone](20_cases/ci/drone/install.md) + * [Drone Demo](20_cases/ci/drone/demo/README.md) + * [20.3 在 IDE 中使用 Docker](20_cases/ide/README.md) + * [20.3.1 VS Code](20_cases/ide/vsCode.md) ## 附录 * [附录](appendix/README.md) - * [附录一:常见问题总结](appendix/faq/README.md) - * [常见错误速查表](appendix/faq/errors.md) + * [附录一:常见问题与错误速查](appendix/faq/README.md) * [附录二:热门镜像介绍](appendix/repo/README.md) * [Ubuntu](appendix/repo/ubuntu.md) * [CentOS](appendix/repo/centos.md)