Docker基础教程（219）Docker Api之Restful：别再用命令行了！深度“解剖”Docker API：这把瑞士军刀，让你成为真正的“容器操盘手”

引言：从“驯兽师”到“造物主”的思维转变

想象一下，你是一个神奇的驯兽师。每次想让你的“容器兽”做点事情——启动、停止、搬家——你都需要走到它面前，用特定的咒语（也就是docker run， docker stop等命令）发出指令。这很酷，但效率不高，尤其是当你需要管理成百上千只“容器兽”时。

现在，告诉你一个秘密：每一只“容器兽”都听从一位更高维度的“造物主”的指令，这位“造物主”就是Docker Daemon（守护进程）。而你平时在命令行里敲的打字，只不过是和这位“造物主”沟通的一种方言。

今天，我们要抛弃方言，直接学习“造物主”的官方语言——Docker Engine API。这是一种基于HTTP的RESTful API，意味着你可以用任何能发送网络请求的工具（比如cURL、Postman，或者你心爱的Python/Go/Java代码）来直接命令Docker守护进程，完成所有你能想到的容器操作。

这不仅仅是酷，这是自动化、集成化和平台化的基石。CICD流水线、容器管理平台（如Portainer）、云服务商的容器服务，其底层无一例外都在与Docker API进行着密集的“交流”。

第一幕：揭秘Docker API的“藏身之处”与“接头暗号”

1. 理解通信渠道：Unix Socket vs. TCP

默认情况下，Docker守护进程在一个Unix套接字（Unix Socket） 上监听请求，位置通常是 unix:///var/run/docker.sock。这种设计基于安全考虑，只允许本地机器上的进程与之通信。

当你执行docker ps时，Docker命令行客户端其实就是去读写这个sock文件，将你的命令翻译成API请求发送给守护进程。

但在生产环境或需要远程管理的场景下，我们通常需要将其暴露在TCP端口上，例如 2375（非加密）或 2376（TLS加密）。警告：将Docker API暴露在非加密的TCP端口上极其危险，相当于给你的服务器 root 权限开了一道门！ 生产环境务必使用TLS加密。

2. 认证与安全（接头暗号）

与大多数RESTful API不同，基础的Docker API本身不内置用户名/密码认证。它的安全模型依赖于：

• Unix Socket的本地文件系统权限：谁能读写/var/run/docker.sock，谁就有权控制Docker。
• TLS证书：在TCP模式下，通过双向TLS认证（mTLS）来验证客户端和服务端的身份。这是远程管理的标准安全实践。

第二幕：深入核心，解读Docker API的“RESTful”设计哲学

Docker API的设计非常符合RESTful架构风格，它将各种资源（Resources）清晰地暴露出来。

核心资源模型：

• 镜像（Images）： 资源端点通常是 /images/*。对应操作：拉取（POST /images