mirror of
https://github.com/yeasy/docker_practice.git
synced 2026-08-10 16:37:34 +00:00
Update node-exporter to v1.11.1, fcct to butane
This commit is contained in:
yeasy
@@ -101,7 +101,6 @@ $ docker compose up
|
||||
#### 3. 资源效率
|
||||
|
||||
Docker 容器共享宿主机内核，无需为每个应用运行完整的操作系统。以一台 64GB 内存的物理服务器为例：
|
||||
|
||||
- **传统虚拟机方案**：每个虚拟机都需要运行完整的操作系统（每个额外占用如 2GB 内存），产生大量资源开销，实际可用于应用的内存可能只有约 18GB。
|
||||
- **Docker 方案**：容器直接共享宿主机系统，只需付出很少的基础开销（OS 及引擎约 4GB），即可将约 60GB 的内存全部用于实际应用。
|
||||
|
||||
|
||||
@@ -27,7 +27,6 @@ flowchart TD
|
||||
end
|
||||
```
|
||||
这种隔离主要通过 Linux 内核的 **Namespace** 实现，资源限制通常与 **cgroups** 配合。具体表现为：
|
||||
|
||||
- **进程空间**：容器看不到宿主机上的其他进程。
|
||||
- **网络**：在默认网络模式下，容器通常拥有独立的网络命名空间，并可分配独立 IP；使用 `host` 或 `container:` 等模式时则例外。
|
||||
- **文件系统**：容器拥有独立的 root 目录。
|
||||
|
||||
@@ -23,7 +23,6 @@ Docker Engine 主要提供 `stable` 和 `test` 两个更新频道；`test.docker
|
||||
### 国内用户的网络优化建议
|
||||
|
||||
值得注意的是，国内直接访问 Docker 官方源速度较慢，建议：
|
||||
|
||||
- **安装过程**：使用阿里云、腾讯云等国内镜像源
|
||||
- **镜像拉取**：安装完成后配置 Docker 镜像加速器（详见 [3.9 镜像加速器](3.9_mirror.md)），这一步对日常开发的体验提升最明显
|
||||
|
||||
|
||||
@@ -24,7 +24,6 @@
|
||||
- 推荐使用专业级方案（Nexus 3、Harbor）而非简单的 Registry
|
||||
|
||||
本章涵盖的方案从简到复杂：
|
||||
|
||||
- Docker Registry：最小化部署（适合简单场景）
|
||||
- 私有仓库高级配置：添加认证、HTTPS 等生产必需项
|
||||
- Nexus 3：企业级完整解决方案，支持权限管理、备份等
|
||||
|
||||
@@ -5,7 +5,6 @@
|
||||
`COPY` 是在构建镜像时，将构建上下文（Dockerfile 所在目录及其子目录）中的文件或目录复制到容器内的指令。它是处理应用代码、配置文件最常用的方式。
|
||||
|
||||
典型场景：
|
||||
|
||||
- 复制应用源码：`COPY . /app`
|
||||
- 复制配置文件：`COPY nginx.conf /etc/nginx/nginx.conf`
|
||||
- 复制静态资源：`COPY public /app/public`
|
||||
|
||||
@@ -5,7 +5,6 @@
|
||||
在深入 CMD 的细节之前，我们需要理解一个关键问题：**CMD 和 ENTRYPOINT 应该在什么时候使用？**
|
||||
|
||||
这是 Dockerfile 使用中最常见的困惑之一。简单的答案是：
|
||||
|
||||
- **CMD**：定义容器的”默认命令”。如果用户在 `docker run` 时提供命令，CMD 会被覆盖
|
||||
- **ENTRYPOINT**：定义容器的”入口脚本”。通常用于启动应用的某个特定部分
|
||||
|
||||
|
||||
@@ -21,7 +21,6 @@
|
||||
#### 1. 创建集群
|
||||
|
||||
登录腾讯云控制台，进入容器服务模块：
|
||||
|
||||
- 选择 “创建集群”，配置集群名称、地域和网络
|
||||
- 选择节点配置（云服务器规格和数量）
|
||||
- 设置 Kubernetes 版本和安全组
|
||||
|
||||
@@ -26,7 +26,6 @@
|
||||
#### 1. 创建集群
|
||||
|
||||
登录阿里云控制台，进入容器服务 > Kubernetes 集群：
|
||||
|
||||
- 点击 “创建集群”，选择集群配置
|
||||
- 配置集群名称、地域、可用区和节点类型
|
||||
- 选择节点规格和数量（支持弹性伸缩）
|
||||
|
||||
@@ -4,15 +4,15 @@
|
||||
|
||||
在[下载页面](https://getfedora.org/coreos/download/) `Bare Metal & Virtualized` 标签页下载 ISO。
|
||||
|
||||
### 17.2.2 编写 FCC
|
||||
### 17.2.2 编写 Butane 配置
|
||||
|
||||
FCC 是 Fedora CoreOS Configuration (Fedora CoreOS 配置) 的简称。
|
||||
> **注意**：Fedora CoreOS 配置工具已从 `fcct` (Fedora CoreOS Config Transpiler) 更名为 **Butane**。新版本使用 `.bu` 扩展名和更新的 spec 版本。
|
||||
|
||||
```yaml
|
||||
## example.fcc
|
||||
## example.bu
|
||||
|
||||
variant: fcos
|
||||
version: 1.0.0
|
||||
version: 1.6.0
|
||||
passwd:
|
||||
users:
|
||||
- name: core
|
||||
@@ -21,10 +21,10 @@ passwd:
|
||||
```
|
||||
将 `ssh-rsa AAAA...` 替换为自己的 SSH 公钥 (位于 `~/.ssh/id_rsa.pub`)。
|
||||
|
||||
### 17.2.3 转换 FCC 为 Ignition
|
||||
### 17.2.3 转换 Butane 配置为 Ignition
|
||||
|
||||
```bash
|
||||
$ docker run -i --rm quay.io/coreos/fcct:v0.5.0 --pretty --strict < example.fcc > example.ign
|
||||
$ docker run -i --rm quay.io/coreos/butane:release --pretty --strict < example.bu > example.ign
|
||||
```
|
||||
|
||||
### 17.2.4 挂载 ISO 启动虚拟机并安装
|
||||
|
||||
@@ -62,7 +62,6 @@ $ skopeo copy docker://docker.io/library/alpine:latest docker://registry.example
|
||||
$ skopeo copy docker://docker.io/library/alpine:latest oci:alpine-oci
|
||||
```
|
||||
如果我们要将本地的某个目录下的打包好的镜像再次推向 Registry 或转换为其它存储类型也是完全支持的，诸如：
|
||||
|
||||
- `docker://` 远端 Registry
|
||||
- `docker-archive:` / `docker-daemon:` Docker 对应的归档文件或本地守护进程
|
||||
- `oci:` / `oci-archive:` OCI 相关文件格式
|
||||
|
||||
@@ -7,7 +7,6 @@
|
||||
[containerd](https://containerd.io/) 是一个行业标准的容器运行时，它最初是由 Docker 引擎中剥离出来的一个核心组件，后来 Docker 将其捐赠给了云原生计算基金会（CNCF），目前已经是一个 CNCF 毕业（Graduated）项目。
|
||||
|
||||
它的主要职责是管理单个宿主机上完整的容器生命周期，包括：
|
||||
|
||||
- 镜像的传输和存储
|
||||
- 容器执行和管理
|
||||
- 存储和网络接口的管理
|
||||
@@ -41,7 +40,6 @@ Kubernetes 作为一个容器编排系统，为了屏蔽底层不同容器运行
|
||||
### 17.6.3 为什么直接使用 containerd？
|
||||
|
||||
对普通应用开发者来说，Docker 依然是本地开发和测试的首选。但对于构建云平台、自动化流水线或深度管理 Kubernetes 集群的系统工程师来说，直接使用 containerd 可以带来：
|
||||
|
||||
- **更高的性能与更少的开销**：去掉了 Docker Daemon 等附加组件的资源占用，链路更短。
|
||||
- **更强的稳定性**：作为专注于运行时的底层组件，它的核心功能极为稳定且更新受控。
|
||||
- **直接符合 Kubernetes CRI 标准**：在生产级 Kubernetes 集群中作为标准配置。
|
||||
|
||||
@@ -9,7 +9,6 @@
|
||||
默认情况下，Docker 容器对系统资源的使用是没有限制的：一个容器理论上可以使用宿主机所有的 CPU 计算能力、吃光所有的内存、耗尽所有的系统 PID。
|
||||
|
||||
想象一下以下场景：
|
||||
|
||||
- 一个恶意用户向你暴露在公网的应用发起海量并发请求。
|
||||
- 应用程序逻辑中存在内存泄漏漏洞。
|
||||
- 黑客在入侵容器后，在里面运行了挖矿木马程序。
|
||||
|
||||
@@ -81,7 +81,6 @@ $ docker version
|
||||
在企业环境中，对 Docker 守护进程的访问控制往往不仅限于文件系统权限，还需要更细粒度的授权策略。**Authorization Plugin** 机制允许在 API 层级对请求进行拦截和审批。
|
||||
|
||||
常见的授权插件包括：
|
||||
|
||||
- **OPA/Conftest**：开放策略引擎，支持声明式策略定义。
|
||||
- **Prisma Cloud（Twistlock）**：商业容器安全平台。
|
||||
- 自定义脚本：根据请求内容（镜像、命令、用户等）做出允许/拒绝决定。
|
||||
|
||||
@@ -9,14 +9,12 @@
|
||||
在默认情况下，即便一个容器是在以 `root` 用户运行，Docker 也只为其内核授予了所有可用能力中的 **一小部分“白名单”能力**。
|
||||
|
||||
常见的 Linux Capabilities 包含：
|
||||
|
||||
- `CAP_CHOWN`: 修改文件所有者。
|
||||
- `CAP_NET_BIND_SERVICE`: 绑定特权端口（即 1024 以下的端口）。
|
||||
- `CAP_NET_ADMIN`: 网络管理的最高权限（例如调整路由配置，设置防火墙规则等）。
|
||||
- `CAP_SYS_ADMIN`: 被誉为“Linux 内核的特权网管”，允许各种高危操作（挂载磁盘、访问敏感设备等）。
|
||||
|
||||
为了在 **“最小特权原则”** 的指导下加强安全，Docker 默认 **移除了** 大量可能导致容器大范围破坏宿主机的能力，例如：
|
||||
|
||||
* 完全禁止了任何通过 `CAP_SYS_ADMIN` 进行的核心挂载或设备操作。
|
||||
* 禁止修改内核模块。
|
||||
* 禁止直接访问硬件套接字。
|
||||
|
||||
@@ -43,7 +43,6 @@ chmod: /etc/passwd: Operation not permitted
|
||||
传统的 Linux 模型遵循 DAC（自主访问控制），这意味着如果一个文件被赋予了全员读写权限（`777`），普通隔离下任何人便都能修改。但 **MAC（强制访问控制）** 技术，诸如 `AppArmor` (常用于 Ubuntu/Debian) 或 `SELinux` (常用于 CentOS/RHEL)，可以制定比“文件所有权”更宏观且优先的策略控制模块。
|
||||
|
||||
在开启了上述机制的机器上：
|
||||
|
||||
- **AppArmor**: Docker 为所有启动的应用加载了一个默认的 `docker-default` 模板文件，如果你的某些异常写行为（比如往特殊的内核心脏目录写入配置）不在 AppArmor 许可列表之上，即使拥有物理 Root，写入同样失败。
|
||||
- **SELinux**: 所有的 Docker 操作强制附加特殊上下文标识标签。就算把主机的 `/` 绑定给了黑客的某服务，黑客对不属于 Docker 可见的标签的文件进行读写尝试亦会被阻止。
|
||||
|
||||
|
||||
@@ -530,7 +530,6 @@ push:
|
||||
**Q: 扫描报告中有过时的 CVE，如何处理？**
|
||||
|
||||
A: 某些 CVE 可能已经被修复但数据库未更新，可以：
|
||||
|
||||
- 手动验证安全补丁是否已应用
|
||||
- 使用工具的忽略列表功能（如 Trivy 的 `.trivyignore`）
|
||||
- 定期更新扫描工具和漏洞数据库
|
||||
@@ -538,7 +537,6 @@ A: 某些 CVE 可能已经被修复但数据库未更新，可以：
|
||||
**Q: 如何平衡镜像大小和安全性？**
|
||||
|
||||
A:
|
||||
|
||||
- 使用多阶段构建减少最终镜像大小
|
||||
- 使用精简基础镜像（Alpine、Distroless）
|
||||
- 定期更新依赖而不是一味求小
|
||||
@@ -547,7 +545,6 @@ A:
|
||||
**Q: 如何管理和轮换签名密钥？**
|
||||
|
||||
A:
|
||||
|
||||
- 在密钥管理系统（如 HashiCorp Vault）中存储密钥
|
||||
- 定期轮换密钥（建议每 90 天）
|
||||
- 使用 Keyless 签名消除密钥管理复杂性
|
||||
|
||||
@@ -82,7 +82,7 @@ services:
|
||||
- prometheus
|
||||
|
||||
node-exporter:
|
||||
image: prom/node-exporter:v1.8.2
|
||||
image: prom/node-exporter:v1.11.1
|
||||
ports:
|
||||
- "9100:9100"
|
||||
networks:
|
||||
|
||||
@@ -177,7 +177,7 @@ services:
|
||||
- monitoring
|
||||
|
||||
node-exporter:
|
||||
image: prom/node-exporter:v1.8.2
|
||||
image: prom/node-exporter:v1.11.1
|
||||
container_name: node-exporter
|
||||
ports:
|
||||
- "9100:9100"
|
||||
|
||||
@@ -419,7 +419,6 @@ Kubernetes 进阶 (Week 24-36)
|
||||
**Docker Certified Associate (DCA)**
|
||||
|
||||
考试信息：
|
||||
|
||||
- 题目数：55 道
|
||||
- 时间限制：90 分钟
|
||||
- 及格分数：73%（约 41 道题）
|
||||
|
||||
Reference in New Issue
Block a user