使用 Portainer 管理 Docker：基于 dockerd 配置文件修改的安全性和实现步骤

在容器化应用逐渐成为主流的今天，Docker 已经成为开发和运维中不可或缺的工具。为了有效地管理 Docker 容器，很多团队选择使用图形化管理工具 Portainer，它不仅简化了 Docker 容器管理，还提供了直观的界面和多种功能。

在这篇文章中，我们将介绍如何通过修改 Docker 守护进程配置，暴露 Docker API 端口并通过 Portainer 实现容器管理。我们还将讨论这个过程的安全性考虑、配置步骤以及如何验证 API 接口的有效性。

---

一、目标：通过 Portainer 管理 Docker 容器

Portainer 是一个轻量级的 Docker 管理工具，提供了一个简洁的 Web 界面来管理 Docker 容器、镜像、网络和卷。通过 Portainer，你可以轻松地执行以下操作：

• 查看 Docker 容器的状态、日志和指标。
• 启动、停止、重启容器。
• 管理 Docker 镜像和网络。
  

为了能够通过 Portainer 远程管理 Docker，我们需要开放 Docker 的 API 接口，使得 Portainer 能够与 Docker 守护进程进行通信。

二、安全性考虑

暴露 Docker API 端口是一个潜在的安全风险。如果没有加密和身份验证，恶意用户可能会远程访问并控制你的 Docker 守护进程。因此，在开放 Docker API 时，必须采取以下安全措施：

• ​只允许信任的 IP 访问​：通过防火墙或其他网络访问控制限制可以访问 Docker API 的 IP 地址。
• ​启用 TLS 加密​：使用 TLS 加密通信，确保 Docker API 与客户端之间的通信是安全的。
• ​认证机制​：使用客户端证书来验证访问 Docker API 的请求，确保只有授权的客户端才能访问。
  

如果仅用于局域网内的开发环境，可以暂时通过未加密的 TCP 端口来开放 Docker API，但这应当尽量避免在生产环境中使用。

三、调整 Docker 服务配置

默认情况下，Docker 守护进程仅监听本地 Unix socket (/var/run/docker.sock​)，这意味着只能通过本地访问 Docker。但是，如果你希望通过远程方式管理 Docker，尤其是通过 Portainer 来管理 Docker，则需要调整 Docker 服务配置，使其监听指定的 TCP 端口。

1. 修改 Docker 配置文件

修改 Docker 服务配置文件，指定 Docker 守护进程监听所有 IP 地址的端口（如 2375）。

首先，打开 Docker 的服务文件（通常是 /etc/systemd/system/docker.service​ 或 /lib/systemd/system/docker.service​）。

sudo nano /etc/systemd/system/docker.service

然后，在 ExecStart​ 行中修改为：

1. ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 --containerd=/run/containerd/containerd.sock

复制代码

这里的参数含义如下：

• ​-H fd://​：Docker 守护进程继续通过默认的 Unix socket 进行本地通信。
• ​-H tcp://0.0.0.0:2375​：Docker 守护进程会在所有网络接口上监听 2375 端口，允许通过 TCP 协议访问 Docker API。
• ​--containerd=/run/containerd/containerd.sock​：指定 containerd​ 套接字文件位置。
• 完成配置文件内容：
• 1. [Unit]
     
  2. Description=Docker Application Container Engine
     
  3. Documentation=https://docs.docker.com
     
  4. After=network-online.target nss-lookup.target docker.socket firewalld.service containerd.service time-set.target
     
  5. Wants=network-online.target containerd.service
     
  6. Requires=docker.socket
     
  7. 
     
  8. [Service]
     
  9. Type=notify
     
  10. # the default is not to use systemd for cgroups because the delegate issues still
      
  11. # exists and systemd currently does not support the cgroup feature set required
      
  12. # for containers run by docker
      
  13. ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2375 --containerd=/run/containerd/containerd.sock
      
  14. ExecReload=/bin/kill -s HUP $MAINPID
      
  15. TimeoutStartSec=0
      
  16. RestartSec=2
      
  17. Restart=always
      
  18. 
      
  19. # Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
      
  20. # Both the old, and new location are accepted by systemd 229 and up, so using the old location
      
  21. # to make them work for either version of systemd.
      
  22. StartLimitBurst=3
      
  23. 
      
  24. # Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
      
  25. # Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
      
  26. # this option work for either version of systemd.
      
  27. StartLimitInterval=60s
      
  28. 
      
  29. # Having non-zero Limit*s causes performance problems due to accounting overhead
      
  30. # in the kernel. We recommend using cgroups to do container-local accounting.
      
  31. LimitNPROC=infinity
      
  32. LimitCORE=infinity
      
  33. 
      
  34. # Comment TasksMax if your systemd version does not support it.
      
  35. # Only systemd 226 and above support this option.
      
  36. TasksMax=infinity
      
  37. 
      
  38. # set delegate yes so that systemd does not reset the cgroups of docker containers
      
  39. Delegate=yes
      
  40. 
      
  41. # kill only the docker process, not all processes in the cgroup
      
  42. KillMode=process
      
  43. OOMScoreAdjust=-500
      
  44. 
      
  45. [Install]
      
  46. WantedBy=multi-user.target

  复制代码

  
  
  
  

2. 重新加载 Docker 配置并重启服务

修改完服务文件后，需要重新加载 systemd 配置并重启 Docker 服务。

1. sudo systemctl daemon-reload
   
2. sudo systemctl restart docker

复制代码

1. sudo ufw allow from 10.10.0.0/24 to any port 2375

复制代码

如果你使用 iptables​，可以使用类似的规则来控制访问。

四、安装并配置 Portainer

1.拉取 Portainer 镜像并启动

Portainer 通过 Docker 运行，所以首先需要从 Docker Hub 拉取 Portainer 镜像并运行它：

1. docker pull portainer/portainer-ce

复制代码

然后运行 Portainer 容器：

1. docker run -d -p 9000:9000 -p 8000:8000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock portainer/portainer-ce

复制代码

Portainer 容器 docker-compose:

1. services:
   
2.   portainer:
   
3.     image: portainer/portainer-ce:lts
   
4.     container_name: portainer
   
5.     restart: unless-stopped
   
6.     ports:
   
7.       - "3013:9000"
   
8.     volumes:
   
9.       - /var/run/docker.sock:/var/run/docker.sock
   
10.       - ./data:/data
    
11.     networks:
    
12.       - service
    
13. 
    
14. networks:
    
15.   service:
    
16.     external: true

复制代码

上述命令将 Portainer 容器映射到宿主机的 9000 端口（Web 界面）和 8000 端口（用于 Docker Socket API）。

2.访问 Portainer Web 界面

通过浏览器访问 http://<docker_host>:9000​，你将看到 Portainer 的登录界面。使用管理员账户登录后，你可以开始使用 Portainer 管理 Docker。

五、验证 Docker API 接口是否可用

在修改了 Docker 配置并启动了 Portainer 后，需要验证 Docker API 接口是否已经正确开放并能够通过 Portainer 进行管理。

5.1. 使用 Curl 测试 API

1. curl http://<docker_host>:2375/containers/json
   
2. 
   
3. # 实际curl命令
   
4. curl http://10.10.0.253:2375/containers/json

复制代码

你可以使用 curl​ 命令验证 Docker API 是否正常工作：

如果配置正确，该命令将返回所有容器的 JSON 列表。如果 Docker API 正常工作，你将看到一个类似以下的响应：

1. [{"Id":"d1e2a2f4e65b","Names":["/my_container"],"Image":"nginx:latest","Status":"Up 5 minutes"}]

复制代码

5.2. 在 Portainer 中验证

登录到 Portainer 后，选择 Docker 环境，如果配置正确，Portainer 会自动连接到远程 Docker 守护进程，你将能够在 Portainer 的 Web 界面上看到所有容器、镜像和网络等信息。

​

                               
登录/注册后可看大图

​

六、结论

通过修改 Docker 配置文件并开放远程 API，我们成功地实现了通过 Portainer 管理 Docker 容器。虽然这种方法非常方便，但在生产环境中一定要注意安全性问题，尤其是要避免暴露 Docker API 给公共网络。

总结来说：

• 暴露 Docker API 使得 Docker 可以被远程管理。
• Portainer 提供了简洁易用的图形界面来管理 Docker。
• ​安全性考虑​：必须加密通信、配置防火墙以及限制访问 IP 地址。
• ​验证 API 接口​：使用 curl​ 或 Portainer 验证 Docker API 是否正常工作。
  

通过这种方式，你可以更高效地管理 Docker 容器，同时保持对 Docker API 的控制和安全性。