docker run --hostname 是设置容器 hostname 的最直接方式，启动时生效且永久稳定，影响进程感知、DNS 解析、日志标记及服务注册；需符合 DNS 规范（禁用下划线），推荐与 --name、--label、-e HOSTNAME 等协同使用以增强标识一致性。
通过 docker run --hostname 设置容器的 hostname，是为容器赋予稳定、可识别身份标识的最直接方式。它不仅影响容器内进程看到的主机名（如 hostname 命令输出、/proc/sys/kernel/hostname），还会影响 dns 解析行为（尤其在自定义网络中）、日志标记、服务注册（如 consul、eureka）以及某些应用的绑定逻辑（如 java 的 inetaddress.getlocalhost()）。关键在于：该值在容器启动时生效，运行时不可更改，因此需在设计阶段就明确其用途和命名规范。
Hostname 是容器的静态身份锚点
不同于容器 ID 或临时分配的 IP，--hostname 是用户可控、语义明确的标识。它不随重启变化（只要命令一致），也不依赖外部服务分配，适合用于：
- 区分同一服务的多个实例（如
web-01、web-02） - 匹配监控系统中的标签（Prometheus 的
instance标签可设为 hostname） - 作为日志前缀（如 Log4j 配置中使用
%X{host}，配合环境变量注入） - 满足许可证或授权机制对主机名的校验要求
与网络和 DNS 的协同使用
在 Docker 自定义 bridge 网络中，设置 --hostname 后，其他容器可通过该 hostname 直接解析通信（无需额外配置）：
docker network create mynet docker run -d --network mynet --hostname db redis:alpine docker run -it --network mynet alpine ping db # 成功解析并连通
注意：--hostname 不会自动注册到外部 DNS；若需全局解析，应结合 --add-host 或部署内部 DNS 服务（如 CoreDNS）。同时，避免使用下划线（_）——它不符合 DNS 主机名规范，可能导致部分工具（如 glibc 的 getaddrinfo）解析失败。
配合容器运行时参数增强标识一致性
单独设置 hostname 可能不够，建议组合使用以下参数形成完整身份上下文：
-
--name：提供友好的容器名称，便于 CLI 管理（如docker logs web-01） -
--label：添加结构化元数据（如com.example.service=api、com.example.env=prod），供编排工具或监控采集 -
-e HOSTNAME=...：显式向容器传递 hostname 环境变量，确保应用层（尤其是未读取 /etc/hostname 的程序）也能感知 -
--read-only --tmpfs /etc/hostname：若需防止应用意外修改 hostname 文件，可用只读根文件系统 + tmpfs 挂载 /etc/hostname（但注意这不会影响内核 hostname）
常见误区与注意事项
hostname 不是唯一标识符，也不替代服务发现：
- 多个容器可设相同 hostname（不推荐），Docker 不做冲突检查
- 容器重启后，hostname 保持不变，但 IP 可能变（bridge 网络下默认如此）；若需固定 IP，应搭配
--ip使用 - 在 Kubernetes 中，
hostname由 Pod 名称决定，docker run --hostname不适用；K8s 场景应使用 Downward API 注入 - 某些基础镜像（如 Alpine）默认不安装 hostname 工具，但内核 hostname 仍有效；验证请用
cat /proc/sys/kernel/hostname
