在现代的IT基础设施和DevOps实践中，容器化技术已成为标配，Docker作为其中的佼佼者，其管理效率至关重要，我们在服务器上直接使用Docker命令行进行管理，但在复杂的场景下，如CI/CD流水线、集中式管理平台或多服务器集群维护时，能够从一台客户端机器远程访问和控制另一台CentOS服务器上的Docker守护进程，会极大地提升工作效率，本文将详细介绍如何在CentOS系统上安全、正确地配置Docker的远程访问功能。
配置Docker守护进程以监听远程连接
实现远程访问的核心是让Docker守护进程监听一个网络端口，而不仅仅是本地的Unix套接字,以下是详细的配置步骤。
修改Docker守护进程配置
Docker的守护进程配置文件通常位于/etc/docker/daemon.json，如果该文件不存在，则需要手动创建，我们需要在此文件中添加hosts配置项,以指定Docker监听的地址和端口。
推荐的做法是同时保留本地Unix套接字和TCP网络套接字，这样既不会影响本地的docker命令使用,又能开启远程访问。
创建或编辑/etc/docker/daemon.json文件,添加以下内容：
{
"hosts": [
"fd://",
"tcp://0.0.0.0:2375"
]
} 配置解析：
"fd://"：这是一个与Systemd集成的特殊值，它使用Systemd传递的套接字激活功能，这是CentOS 7+及现代Linux发行版的推荐方式，确保本地CLI工具正常工作，如果此方式不兼容，也可以使用"unix:///var/run/docker.sock"。"tcp://0.0.0.0:2375"：这是开启远程访问的关键，它告诉Docker在所有网络接口（0.0.0）的2375端口上监听TCP连接。
覆盖Systemd的Docker服务配置
在CentOS上，Docker通常由Systemd管理，Systemd的默认服务文件可能会覆盖我们刚才在daemon.json中的设置,更稳健的方法是创建一个Systemd的覆盖配置文件。
执行以下命令,这会打开一个编辑器：
sudo systemctl edit docker.service
在打开的编辑器中，输入以下内容，为ExecStart命令添加TCP监听参数：
[Service] ExecStart= ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375
说明：
- 第一行
ExecStart=清空了原有的启动参数。 - 第二行
ExecStart=...设置了新的启动参数，同时包含了Systemd的fd://和我们的TCPtcp://0.0.0.0:2375，这种方法优先级更高,且不会被系统更新覆盖。
保存并退出编辑器，Systemd会自动在/etc/systemd/system/docker.service.d/override.conf目录下创建覆盖文件。
重启Docker服务并配置防火墙
配置修改完成后,需要重新加载Systemd配置并重启Docker服务使其生效。
sudo systemctl daemon-reload sudo systemctl restart docker
确保CentOS的防火墙允许2375端口的入站连接。
sudo firewall-cmd --zone=public --add-port=2375/tcp --permanent sudo firewall-cmd --reload
至此，服务器端的配置已全部完成,你可以使用以下命令验证Docker是否正在监听2375端口：
netstat -tulpn | grep 2375
从客户端连接远程Docker守护进程
你可以在任何能够访问到CentOS服务器IP地址的机器上,通过多种方式连接到远程Docker。
使用 -H 参数
在Docker命令后添加-H（或--host）参数,指定远程守护进程的地址。
docker -H tcp://<服务器IP地址>:2375 version docker -H tcp://<服务器IP地址>:2375 ps
将<服务器IP地址>替换为你的CentOS服务器的实际IP。
设置 DOCKER_HOST 环境变量
为了避免每次都输入-H参数，可以设置一个环境变量,这种方式在脚本和持续集成中特别常用。
在Linux或macOS上：
export DOCKER_HOST="tcp://<服务器IP地址>:2375" docker images docker run ...
在Windows PowerShell上：
env:DOCKER_HOST="tcp://<服务器IP地址>:2375" docker images
设置后，所有后续的Docker命令都将自动指向远程守护进程，要取消，只需将DOCKER_HOST变量置空（unset DOCKER_HOST）。
安全性考量与TLS加密
需要强调的是，上述配置（使用2375端口）是完全不加密、无认证的，这在开发或受信任的内网测试环境中或许可以接受，但在任何公开网络或生产环境中都是极其危险的，任何能够连接到该端口的人都可以获得对宿主机的完全控制权,等同于获取了root权限。
在生产环境中，必须使用TLS（传输层安全协议）对远程API连接进行加密和认证，TLS配置通常使用2376端口，它要求客户端和服务端都拥有由同一个证书颁发机构（CA）签发的证书，配置过程相对复杂，涉及生成CA私钥、服务器证书、客户端证书等，开启TLS后，daemon.json和客户端连接命令都会变得更加复杂,但安全性得到了根本保障。
配置方法对比
为了更清晰地理解不同配置方案的差异,下表小编总结了非加密和TLS加密两种方式的特点。
| 配置项 | 非加密方式 (端口2375) | TLS加密方式 (端口2376) |
|---|---|---|
| 安全性 | 极低，明文传输，无认证 | 高，双向加密与认证 |
| 适用场景 | 临时调试、开发环境、完全隔离的可信内网 | 生产环境、公网访问、任何对安全有要求的场景 |
| 配置复杂度 | 简单，仅需修改配置文件 | 复杂，需要创建和管理多套证书 |
| 推荐度 | 不推荐用于任何严肃环境 | 强烈推荐用于所有远程访问场景 |
相关问答FAQs
解答： 这个问题通常是由于在配置daemon.json或Systemd覆盖文件时，只添加了TCP监听地址（如tcp://0.0.0.0:2375），而移除或忘记了本地Unix套接字的监听地址（fd://或unix:///var/run/docker.sock），Docker客户端默认通过Unix套接字与守护进程通信，当这个通道被关闭后，本地命令自然就失败了，请确保你的hosts数组或ExecStart指令中同时包含了本地和远程两种监听方式。
为什么强烈不建议在生产环境中使用2375端口？
解答： 使用2375端口开启的远程访问是“裸奔”模式，它既没有加密也没有身份验证，这意味着网络中的任何用户（甚至在某些情况下，是互联网上的任何用户）只要能发现这个端口，就可以无需密码直接连接到你的Docker守护进程，一旦连接成功，他们就可以执行任意Docker命令，例如挂载宿主机根目录到容器中，从而轻易地获得服务器的root权限，窃取数据、植入恶意软件，造成灾难性的后果，在生产环境中,必须采用TLS加密的2376端口或通过SSH隧道等更安全的方式进行远程访问。
【版权声明】：本站所有内容均来自网络，若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
发表回复