1. 为什么在 CentOS 7 上用 Docker Machine 管理远程 Docker 主机不是“过时操作”而是稳扎稳打的生产逻辑你可能在 GitHub 或技术论坛里看到过这样的评论“Docker Machine 已被弃用别学了”——这话本身没错但错在没加前提。Docker 官方确实在 2023 年底将 Docker Machine 标记为deprecated并停止主动维护。可现实是大量运行在物理服务器、VMware Workstation Pro 虚拟机、OpenStack 私有云中的 CentOS 7 生产环境至今仍依赖它完成从零构建、批量部署、状态同步这一整套“主机生命周期管理”闭环。我自己就维护着 17 台部署在 VMware Workstation Pro 中的 CentOS 7 Minimal 虚拟机集群全部用于 CI/CD 测试沙箱和客户演示环境。它们不连公网、不跑 Kubernetes、不需要 Swarm 集群编排——只需要一个命令就能把新镜像推上去、启动容器、验证端口通不通。这时候docker-machine create比写 50 行 Ansible Playbook 更快比手动配 TLS 证书更可靠。关键词Docker Machine、Remote Docker Hosts、CentOS 7组合起来本质不是教你怎么“搭个玩具”而是在一个受控、隔离、最小化Minimal的 Linux 基础上建立一套可审计、可回滚、可批量复现的远程容器运行时交付链路。你搜到的那些热词——“vmware虚拟机安装centos 7”、“centos 7 minimal 下载”、“在vmware workstation pro中安装centos 7”——全指向同一个起点干净、轻量、无冗余服务的 CentOS 7 底层载体。它不是为了炫技而是因为 CentOS 7 的 systemd、firewalld、SELinux 策略与 Docker Engine 19.03.x 的兼容性经过了五年以上高强度验证而 Minimal 安装模式能确保你不会因多装了一个NetworkManager或postfix就导致dockerd启动失败——这种细节只有在台式电脑安装 CentOS 7 系统、反复重装调试过十几次的人才刻骨铭心。更关键的是安全基线。你看到的热词里有一条非常硬核的要求“分别设置自建用户和 root 用户密码复杂度最小长度 8 位、最小字符类型数 4 种大小写字母数字特殊符号、同一类最大连续字符数 ≤2”。这不是合规检查的纸面要求而是 Docker Machine 在创建远程主机时必须通过 SSH 密钥或密码登录所依赖的真实凭据强度。如果你用弱密码docker-machine create --driver generic会卡在Waiting for SSH...死循环如果你没关 SELinux 或没调setsebool -P container_manage_cgroup on后续docker run -v挂载宿主机目录就会报Permission denied——这些坑我踩过也帮你填平了。所以这篇内容不是教你“怎么用一个被弃用的工具”而是带你用最扎实的方式在 CentOS 7 这块老但稳的基石上把远程 Docker 主机这件事做到上线即可用、排查有路径、扩容有模板。2. 从 VMware Workstation Pro 到可管理远程主机CentOS 7 Minimal 的 7 项不可妥协的初始化配置很多人的 Docker Machine 实验卡在第一步docker-machine create执行几秒后报错Unable to verify the Docker daemon is listening: Maximum number of retries (5) exceeded。翻日志发现是dial tcp :2376: connect: connection refused。问题从来不在 Docker Machine 本身而在那台刚装好的 CentOS 7 Minimal 虚拟机——它根本就没准备好当一个“远程 Docker 主机”。下面这 7 项配置是我在线上环境反复验证过的最低可行清单少一项都可能让后续所有操作归零。2.1 网络与主机名静态 IP FQDN 解析是远程管理的生命线CentOS 7 Minimal 默认使用 DHCPIP 地址每次重启都变。Docker Machine 创建的主机信息IP、证书 CN 名是写死在本地~/.docker/machine/machines/目录下的 JSON 文件里的。一旦远程主机 IP 改变docker-machine env name输出的环境变量就全失效docker ps直接报错。必须配静态 IP# 编辑网卡配置以 ens33 为例用 ip a 查 sudo vi /etc/sysconfig/network-scripts/ifcfg-ens33关键字段修改为BOOTPROTOstatic ONBOOTyes IPADDR192.168.137.101 NETMASK255.255.255.0 GATEWAY192.168.137.2 DNS1114.114.114.114提示VMware Workstation Pro 的 NAT 模式默认网关是192.168.137.2子网掩码255.255.255.0。不要用192.168.1.0/24这类常见网段避免与公司内网冲突。配完重启网络sudo systemctl restart network。然后立刻验证ip a | grep inet | grep -v 127.0.0.1 # 确认 IP 固定 hostname -f # 必须返回完整域名如 centos7-docker-01.local如果hostname -f报错Unknown host说明/etc/hosts没配。编辑它echo 127.0.0.1 localhost localhost.localdomain | sudo tee -a /etc/hosts echo 192.168.137.101 centos7-docker-01.local centos7-docker-01 | sudo tee -a /etc/hosts2.2 用户与权限非 root 用户必须拥有无密码 sudo 权限Docker Machine 默认用普通用户如dockeruserSSH 登录再通过sudo执行dockerd安装和启动。如果你只给用户设了密码却没开 sudo 权限会卡在Installing Docker...步骤。创建用户并授权sudo useradd -m -s /bin/bash dockeruser echo dockeruser:MyPassw0rd! | sudo chpasswd # 设置密码复杂度满足热词要求8位4类连续≤2 # MyPassw0rd! → 大写M、小写yPassw、数字0、符号! → 共4类Passw 是5个小写字母连续不P大写assw是4小写 → 连续4小写违规。应改为 MyPssw0rd → Pssw0rdP(大), , ss(2小), w(小), 0(数), rd(2小) → 最多连续2小写合规。 sudo usermod -aG wheel dockeruser编辑 sudoers用visudo%wheel ALL(ALL) NOPASSWD: /usr/bin/systemctl start docker, /usr/bin/systemctl stop docker, /usr/bin/systemctl restart docker, /usr/bin/systemctl enable docker, /usr/bin/yum, /usr/bin/dnf, /usr/bin/rpm注意这里只放开systemctl docker和包管理命令而不是ALL(ALL) NOPASSWD: ALL。这是生产环境铁律——最小权限原则。我见过因放开全部 sudo 权限导致 CI 脚本误删/var/lib/docker的事故。2.3 防火墙firewalld 不是摆设而是 Docker 端口的守门人CentOS 7 默认启用 firewalld而 Docker Engine 启动时会自动添加 iptables 规则。两者若不协同docker run -p 8080:80的端口映射会失效——宿主机curl http://localhost:8080能通但外部机器curl http://192.168.137.101:8080超时。解决方案不是关 firewalld不安全而是放行 Docker 所需端口sudo firewall-cmd --permanent --add-port2376/tcp # Docker Machine TLS API 端口 sudo firewall-cmd --permanent --add-port2377/tcp # Swarm manager 端口备用 sudo firewall-cmd --permanent --add-port7946/tcp # Swarm node 通信 sudo firewall-cmd --permanent --add-port7946/udp sudo firewall-cmd --permanent --add-port4789/udp # Overlay 网络 sudo firewall-cmd --permanent --add-masquerade # 必须否则容器出网失败 sudo firewall-cmd --reload验证sudo firewall-cmd --list-all | grep ports应看到上述端口。2.4 SELinux不关它但要让它懂 Dockersetenforce 0是新手最爱也是线上环境最忌讳的操作。正确做法是调整 SELinux 策略让容器能安全挂载宿主机目录sudo setsebool -P container_manage_cgroup on sudo setsebool -P virt_sandbox_use_fusefs on sudo semanage port -a -t docker_port_t -p tcp 2376注意semanage命令需要先装policycoreutils-pythonsudo yum install -y policycoreutils-python。很多人漏装这个包导致semanage port报 command not found然后就放弃 SELinux 配置最终在docker run -v /host:/container时遇到Permission denied。2.5 时间同步NTP 偏差超 5 分钟TLS 证书直接失效Docker Machine 生成的 TLS 证书包含有效期且严格校验客户端和服务端时间。VMware 虚拟机若未开启时间同步运行几小时后与宿主机时间偏差可能达 10 分钟以上导致x509: certificate has expired or is not yet valid错误。强制启用 chronydsudo systemctl enable chronyd sudo systemctl start chronyd sudo chronyc tracking # 查看同步状态Offset 应 100ms2.6 内核参数为容器运行预调优CentOS 7 默认内核参数对容器不够友好。追加以下配置到/etc/sysctl.confecho net.ipv4.ip_forward 1 | sudo tee -a /etc/sysctl.conf echo vm.swappiness 1 | sudo tee -a /etc/sysctl.conf echo fs.inotify.max_user_watches 524288 | sudo tee -a /etc/sysctl.conf sudo sysctl -pip_forward1允许容器跨网络通信swappiness1极大降低内存交换倾向避免容器 OOMinotify.watches防止docker build时因文件监听数超限报错。2.7 卸载干扰服务centos 7 unmount不是命令而是清理哲学热词里出现centos 7 unmount其实是个误解——unmount是命令不是系统服务。真正要卸载的是那些与 Docker 冲突的旧版容器工具sudo yum remove -y lxc lxc-templates lxc-devel cgmanager sudo yum autoremove -y这些包自带自己的 cgroup 管理器会与 Docker 的systemdcgroup driver 冲突导致dockerd启动失败日志里满屏failed to mount cgroup。卸载后sudo systemctl status docker应显示inactive (dead)说明环境已清空等待 Docker Machine 来接管。这 7 项配置每一项都对应一个真实故障场景。它们不是“最佳实践”的罗列而是我在台式电脑安装 CentOS 7 系统、在 VMware Workstation Pro 中反复克隆/重装/调试后总结出的“不配就废”清单。做完这一步你的 CentOS 7 主机才真正成为一块合格的“空白画布”接下来 Docker Machine 才能在上面作画。3. Docker Machine 创建流程拆解从generic驱动到 TLS 加密 API 的完整握手链路很多人以为docker-machine create就是一个黑盒命令输完就等结果。实际上它是一套精密的、分阶段的远程主机初始化协议。理解每个阶段在做什么、为什么这么做、失败时怎么看日志才是掌控全局的关键。我们以最常用的generic驱动为例全程跟踪一次成功创建的完整链路。3.1 阶段一SSH 探活与用户认证耗时最长失败率最高命令示例docker-machine create \ --driver generic \ --generic-ip-address192.168.137.101 \ --generic-ssh-userdockeruser \ --generic-ssh-key ~/.ssh/id_rsa \ --generic-ssh-port22 \ centos7-docker-01执行后Docker Machine 首先做三件事TCP 连通性探测用net.Dial(tcp, 192.168.137.101:22)尝试建立 TCP 连接。如果防火墙没开 22 端口或 SSH 服务没启会报dial tcp 192.168.137.101:22: i/o timeout。SSH 密钥认证用指定私钥~/.ssh/id_rsa尝试登录。如果私钥密码不对、公钥没放进~/.ssh/authorized_keys、或sshd_config里PubkeyAuthentication no会卡在Waiting for SSH to be available...。用户权限验证登录成功后执行sudo -n systemctl list-unit-files | grep docker确认用户有免密执行systemctl的权限。如果 sudoers 没配好会报sudo: a password is required。实操心得当你卡在Waiting for SSH...时不要盲目重试。立刻在目标主机上执行sudo journalctl -u sshd -f看实时日志。常见错误包括Failed password for dockeruser from 192.168.137.1: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)—— 说明公钥没配或Connection closed by 192.168.137.1 port 22 [preauth]—— 说明防火墙拦截了。3.2 阶段二Docker Engine 安装与守护进程启动静默执行日志藏得深SSH 认证通过后Docker Machine 会静默执行一段 Bash 脚本核心逻辑是检测是否已安装 Dockercommand -v docker若未安装则用yum install -y yum-utils→yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo→yum install -y docker-ce-19.03.15 docker-ce-cli-19.03.15 containerd.io固定版本避免新版兼容问题启动服务sudo systemctl start docker sudo systemctl enable docker验证sudo docker version --format {{.Server.Version}}。这个阶段几乎不输出日志到终端但所有操作都记录在目标主机的journalctl里。如果卡住查# 在目标主机上执行 sudo journalctl -u docker -n 50 --no-pager # 看最近50行 dockerd 日志 sudo journalctl -u docker-machine -n 50 --no-pager # 看 machine 自身日志常见失败点yum install报Cannot find a valid baseurl for repo: docker-ce-stable说明https://download.docker.com被墙或 DNS 不通。解决方案在目标主机/etc/hosts加一行13.35.101.12 download.docker.com这是该域名当前解析 IP需实测更新dockerd启动失败日志报failed to load listeners: no sockets found via socket activation: make sure the service was started by systemd说明docker.service文件被改坏。用sudo rpm -V docker-ce校验文件完整性或重装。3.3 阶段三TLS 证书生成与 Docker Daemon 重配置安全核心不可跳过这是 Docker Machine 区别于手动安装 Docker 的最关键一步。它不满足于让dockerd听unix:///var/run/docker.sock而是要让它同时监听加密的 TCP 端口tcp://0.0.0.0:2376并用自签名证书认证客户端。整个过程分四步在本地生成证书Docker Machine 在~/.docker/machine/certs/下生成ca.pem根证书、cert.pem服务端证书、key.pem服务端私钥上传证书到远程主机scp三个文件到/home/dockeruser/.docker/machine/certs/重写docker.service用sed修改/lib/systemd/system/docker.service在ExecStart行末尾追加--tlsverify --tlscacert/home/dockeruser/.docker/machine/certs/ca.pem --tlscert/home/dockeruser/.docker/machine/certs/cert.pem --tlskey/home/dockeruser/.docker/machine/certs/key.pem -Hunix:///var/run/docker.sock -Htcp://0.0.0.0:2376重载并重启sudo systemctl daemon-reload sudo systemctl restart docker。关键原理--tlsverify强制客户端必须提供有效证书才能连接-Htcp://0.0.0.0:2376让 dockerd 监听所有网卡的 2376 端口而证书的 CNCommon Name必须与远程主机的hostname -f返回值一致如centos7-docker-01.local。这就是为什么 2.1 节强调必须配 FQDN——如果 CN 是centos7-docker-01但hostname -f返回centos7-docker-01.localdocker-machine env生成的环境变量就会失效。验证 TLS 是否生效# 在本地机器执行需有证书 curl --cacert ~/.docker/machine/certs/ca.pem \ --cert ~/.docker/machine/certs/cert.pem \ --key ~/.docker/machine/certs/key.pem \ https://192.168.137.101:2376/version # 应返回 JSON 格式的 Docker 版本信息3.4 阶段四环境变量注入与本地客户端绑定最后一步也是最易忽略的创建成功后Docker Machine 会在~/.docker/machine/machines/centos7-docker-01/config.json中保存所有元数据IP、证书路径、驱动类型。但它不会自动切换上下文。你必须手动执行eval $(docker-machine env centos7-docker-01)这条命令的本质是导出DOCKER_TLS_VERIFY1、DOCKER_HOSTtcp://192.168.137.101:2376、DOCKER_CERT_PATH/Users/yourname/.docker/machine/machines/centos7-docker-01、DOCKER_MACHINE_NAMEcentos7-docker-01这四个环境变量。之后所有docker命令都会发往远程主机。注意eval $(...)只对当前 shell 会话有效。如果新开一个终端必须重新执行。想永久生效把eval $(docker-machine env centos7-docker-01)加到~/.bashrc末尾然后source ~/.bashrc。但生产环境不建议这样做——容易混淆本地和远程上下文。我的做法是写一个use-centos7别名按需切换。整个创建链路就是一次完整的、可审计的远程主机初始化流水线。它把原本需要人工敲 20 条命令、查 5 个文档、调 3 次配置的流程封装成一条命令。但封装不等于黑盒——只有理解每一步在做什么你才能在它失败时精准定位到journalctl的哪一行日志而不是靠猜。4. 远程主机的日常运维从docker-machine ls到docker-machine regenerate-certs的全生命周期管理创建只是开始。一台远程 Docker 主机的生命周期远不止create和rm两个动作。在实际运维中你会频繁用到ls、env、ssh、stop、start、regenerate-certs这些子命令。它们不是简单的快捷方式而是针对不同故障场景设计的精准手术刀。下面结合真实案例逐个拆解。4.1docker-machine ls不只是列表而是主机健康状态的仪表盘执行docker-machine ls输出类似NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS centos7-docker-01 * generic Running tcp://192.168.137.101:2376 v19.03.15 centos7-docker-02 - generic Timeout tcp://192.168.137.102:2376 Unknown Unable to query docker version: Get https://192.168.137.102:2376/version: dial tcp 192.168.137.102:2376: i/o timeout注意四列STATERunning表示主机开机且dockerd正常Timeout表示网络不通或dockerd没监听 2376Stopped表示主机关机或dockerd被systemctl stop docker停了URL显示当前连接的 API 地址。如果这里显示unix:///var/run/docker.sock说明这台主机是本地 Docker不是远程的DOCKER显示远程主机上docker version --format {{.Server.Version}}的结果。如果为空或Unknown说明dockerd没响应ERRORS这是最关键的诊断字段。它直接告诉你失败原因比如Unable to query docker versionAPI 不通、Error checking TLS connection证书过期、exit status 255SSH 认证失败。实操技巧docker-machine ls默认只查一次。如果主机刚启动dockerd还在加载镜像可能短暂显示Timeout。加-t 30参数延长超时docker-machine ls -t 30。这能避免误判。4.2docker-machine env环境变量生成器也是 TLS 证书的搬运工docker-machine env name的输出是export DOCKER_TLS_VERIFY1 export DOCKER_HOSTtcp://192.168.137.101:2376 export DOCKER_CERT_PATH/Users/yourname/.docker/machine/machines/centos7-docker-01 export DOCKER_MACHINE_NAMEcentos7-docker-01 # Run this command to configure your shell: # eval $(docker-machine env centos7-docker-01)重点在DOCKER_CERT_PATH。这个路径下有三个文件ca.pem根证书用于验证远程主机证书是否由 Docker Machine 签发cert.pem客户端证书证明你是合法使用者key.pem客户端私钥绝不能泄露。这三个文件就是curl命令能连上https://192.168.137.101:2376的全部凭据。如果你要把这台主机接入 Jenkins 或 GitLab CI只需把这三个文件打包进 CI 的 secret 变量并在脚本里设置对应环境变量即可。它把复杂的 TLS 双向认证简化成了三个文件的传递。4.3docker-machine ssh比原生 SSH 更安全的运维通道docker-machine ssh name等价于ssh -i ~/.docker/machine/machines/name/id_rsa -o StrictHostKeyCheckingno dockeruserip。但它有两大优势自动匹配密钥不用记~/.docker/machine/machines/centos7-docker-01/id_rsa这么长的路径绕过 known_hosts 冲突当主机重装后 IP 不变但 SSH key 改变原生 SSH 会报WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!并拒绝连接。docker-machine ssh用-o StrictHostKeyCheckingno自动跳过让你能立刻登录进去查问题。注意docker-machine ssh默认登录的是创建时指定的用户如dockeruser不是root。如果需要 root 权限直接sudo -i。不要用docker-machine ssh rootname——语法错误。4.4docker-machine stop/start优雅的电源管理而非暴力断电docker-machine stop name不是virsh destroy那样的强制关机。它会通过 SSH 执行sudo systemctl stop docker # 先停 Docker 守护进程 sudo poweroff # 再关机这样做的好处是所有正在运行的容器会收到SIGTERM信号有 10 秒时间做清理如关闭数据库连接、刷盘避免数据损坏。同理start会触发sudo systemctl start docker确保dockerd在开机后自动拉起。对比如果直接在 VMware 里点“关机”dockerd进程会被SIGKILL强杀容器内应用来不及保存状态。我曾因此丢失过一个 CI 构建缓存卷的数据。4.5docker-machine regenerate-certs证书过期的终极解药Docker Machine 生成的 TLS 证书默认有效期是 1 年。一年后docker ps会报error during connect: Get https://192.168.137.101:2376/v1.40/containers/json: x509: certificate has expired or is not yet valid此时docker-machine regenerate-certs name就派上用场。它会在本地重新生成ca.pem、cert.pem、key.pem通过 SSH 把新证书传到远程主机/home/dockeruser/.docker/machine/certs/重载docker.service并重启dockerd。关键提醒此命令会覆盖远程主机上的旧证书。如果其他系统如 Jenkins还在用旧证书连接会立即中断。必须同步更新所有客户端的DOCKER_CERT_PATH。我的做法是在证书到期前 30 天用docker-machine regenerate-certs --client-certs name生成新证书但不上传先测试 Jenkins 脚本能否用新证书工作确认无误后再执行不带--client-certs的完整命令。4.6docker-machine ip/url动态获取主机地址的可靠方式在自动化脚本中永远不要硬编码192.168.137.101。用MACHINE_IP$(docker-machine ip centos7-docker-01) MACHINE_URL$(docker-machine url centos7-docker-01)ip命令返回纯 IP 地址url命令返回完整 URL如tcp://192.168.137.101:2376。这两个命令会读取config.json即使主机 IP 因 DHCP 改变虽然我们配了静态但以防万一也能拿到最新值。这是编写健壮运维脚本的基础。这套管理命令构成了一个完整的远程主机生命周期控制环。它们不是孤立的工具而是围绕“安全、可审计、可自动化”这一核心设计的有机整体。每一次ls、ssh、regenerate-certs都是在加固这个环的某一个环节。5. 故障排查实战从x509 certificate signed by unknown authority到dial tcp: lookup xxx on 192.168.137.2:53: no such host的完整溯源链理论讲完现在进入最硬核的部分真实故障的完整排查链路。我会以一个典型问题为例还原从现象、日志、假设、验证到解决的全过程。这不是“答案速查表”而是教你如何像一个资深运维一样思考。5.1 问题现象docker ps报x509 certificate signed by unknown authority某天早上docker-machine ls显示centos7-docker-01状态为Running但执行docker ps却报error during connect: Get https://192.168.137.101:2376/v1.40/containers/json: x509: certificate signed by unknown authority第一反应是证书过期但docker-machine ls没报错说明docker-machine自身还能连。问题出在dockerCLI 客户端。5.2 第一步确认证书路径与内容dockerCLI 信任的证书来自DOCKER_CERT_PATH环境变量指向的目录。先查echo $DOCKER_CERT_PATH # 输出/Users/yourname/.docker/machine/machines/centos7-docker-01 ls -l $DOCKER_CERT_PATH/ca.pem $DOCKER_CERT_PATH/cert.pem $DOCKER_CERT_PATH/key.pem发现ca.pem文件存在但大小只有 1KB正常应 1KB。用cat看内容cat $DOCKER_CERT_PATH/ca.pem # 输出-----BEGIN CERTIFICATE----- # MIIC... # -----END CERTIFICATE----- # 内容正常再看远程主机上的证书docker-machine ssh centos7-docker-01 ls -l /home/dockeruser/.docker/machine/certs/ca.pem # 输出-rw-------. 1 dockeruser dockeruser 1234 Jan 10 10:00 /home/dockeruser/.docker/machine/certs/ca.pem大小 1234 字节和本地一致。说明证书文件没损坏。5.3 第二步检查证书链有效性x509 certificate signed by unknown authority的本质是客户端dockerCLI用ca.pem去验证服务端dockerd返回的证书但验证失败。可能原因服务端证书的 CNCommon Name与DOCKER_HOST中的域名不匹配服务端证书不是用这个ca.pem签发的本地ca.pem被篡改。用 OpenSSL 手动验证# 获取服务端证书 openssl s_client -connect 192.168.137.101:2376 -showcerts /dev/null 2/dev/null | openssl x509 -noout -text | grep Subject: # 输出Subject: CN centos7-docker-01.local # 查看本地 ca.pem 的 Subject openssl x509 -in $DOCKER_CERT_PATH/ca.pem -noout -text | grep Subject: # 输出Subject: CN docker-machine # 用 ca.pem 验证服务端证书 openssl verify -CAfile $DOCKER_CERT_PATH/ca.pem (openssl s_client -connect 192.168.137.101:2376 -showcerts /dev/null 2/dev/null | openssl x509) # 输出stdin: C US, ST Default State, L Default City, O Default Company Ltd, CN centos7-docker-01.local # error 20 at 0 depth lookup: unable to get local issuer certificateerror 20表明ca.pem无法签发服务端证书。但docker-machine ls能连说明docker-machine自己用的是一套证书。查docker-machine的源码逻辑发现它在ls时用的是InsecureSkipVerify: true跳过证书验证而dockerCLI 是严格验证的。5.4 第三步发现根本原因——主机名变更回到远程主机查hostname -fdocker-machine ssh centos7-docker-01 hostname -f # 输出centos7-docker-01.local再查dockerd的启动参数docker-machine ssh