码厩开发者笔记

#6 Docker 容器对宿主机的访问故障

#5 Docker 镜像联通性测试

docker-mirror-check.py

-> % cat /etc/docker/daemon.json
{
  "default-address-pools": [
    {
      "base": "10.0.0.0/8",
      "size": 24
    }
  ],
  "log-driver": "json-file",
  "log-opts": {
    "max-file": "3",
    "max-size": "10m"
  },
  "registry-mirrors": [
    "https://docker.1ms.run",
    "https://dockerproxy.net",
    "https://proxy.vvvv.ee",
    "https://dockerproxy.link"
  ]
}

-> % python ~/Projects/StdEnv/scripts/docker-mirror-check.py
Testing 4 registry mirrors:

https://docker.1ms.run              HTTP 401 | 0.180s
https://dockerproxy.net             ERROR _ssl.c:1063: The handshake operation timed out | 9.268s
https://proxy.vvvv.ee               HTTP 200 | 0.680s
https://dockerproxy.link            HTTP 200 | 0.657s

调整镜像配置之后重启 Docker：

sudo systemctl daemon-reload
sudo systemctl restart docker

#4 Podman 为什么不需要 root 权限

Docker 和 Podman 都是主流容器工具，但它们的架构设计存在明显差异。Docker Engine 采用中心化的守护进程架构，Podman 则从设计上支持无守护进程运行。

Docker 的核心是 dockerd。 传统模式下，dockerd 通常以 root 权限运行，负责接收客户端请求，并通过 containerd、containerd-shim 和 runc 等组件管理容器生命周期。用户加入 Docker 组后，便可以通过守护进程执行高权限操作，因此 Docker 组通常具有接近 root 的主机控制能力。

Docker 并非无法实现 Rootless。它也支持让守护进程和容器以普通用户权限运行，但需要额外配置，且部分网络、存储和特权操作存在限制。

Podman 采用不同的设计。 它不依赖常驻的中心化守护进程，而是通过自身进程调用底层运行时（如 crun），并使用 conmon 监控容器。配合 Linux 用户命名空间，容器内的 root 可以映射为宿主机上的普通用户，从而降低容器对主机的权限要求。Podman 还可以与 systemd 集成，将容器和 Pod 管理为用户级服务。

Rootless 模式需要解决 UID/GID 映射问题。容器内可能存在多个用户，因此通常需要为宿主机用户配置 subordinate UID/GID 范围，即 /etc/subuid 和 /etc/subgid。

为什么 Docker 不默认采用 Podman 的设计？ 这主要是历史路径和生态兼容性的取舍。Docker 早期便围绕守护进程构建了完整的 API、Compose 和自动化工具生态。改变默认架构不仅涉及权限，还会影响资源管理、容器生命周期及现有工作流。此外，Rootless 并不能完全替代宿主机管理员权限，网络、存储和设备访问仍有兼容性边界。

总体而言，Docker 优先考虑集中管理与生态兼容，Podman 更强调无守护进程和 Rootless 安全模型。对于希望在 Ubuntu 上以普通用户运行容器、通过 systemd 管理服务的场景，Podman 值得考虑；如果高度依赖现有 Docker 工具链，Docker Engine 依然是合理选择。两者并非绝对对立，真正的差异在于架构取舍与默认运行模式。

#3 Docker 轻量基础镜像：scratch、Distroless、Alpine 与 Debian Slim

在 Docker 镜像构建中，基础镜像决定了应用的运行环境，也直接影响镜像体积、安全性、兼容性和后期维护成本。
很多开发者在追求轻量化时，首先会想到 Alpine。但实际上，scratch、Distroless、Alpine 和 Debian Slim 分别代表了不同的设计思路，并不存在绝对最优的方案。
选择基础镜像的核心，不是单纯追求体积最小，而是在运行依赖、安全性和可维护性之间取得平衡。

#2 CentOS 安装 Docker

# sudo yum remove docker \
#                   docker-client \
#                   docker-client-latest \
#                   docker-common \
#                   docker-latest \
#                   docker-latest-logrotate \
#                   docker-logrotate \
#                   docker-engine

# 检查是否有旧的安装
yum list installed | grep docker
sudo yum remove ...

sudo yum install -y yum-utils

# 使用国内镜像
# sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo

yum list docker-ce --showduplicates | sort -r

sudo yum install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

参考：https://docs.docker.com/engine/install/centos/

#1 不加 sudo 执行 Docker 命令

因为公司组织培训 Docker，为了更好参与课程，我提前一周开始预习 Docker 技术。

安装 Docker 之后，首次执行 docker info 时接到错误信息：“Cannot connect to the Docker daemon. Is the docker daemon running on this host?”。
当时，我再三确认了 Docker 服务运行状态，确实没有任何问题，傻眼了。
之后，加上 sudo 试试才运行正确。