渡序
← 返回项目列表

Docker Develop

一套面向团队本地开发的 Docker 工作台，统一管理 PHP、Hyperf、Go 项目与常用基础服务。

  • Docker
  • Docker Compose
  • Hyperf
  • Go
查看源码

把本地开发环境做成一个工作台：Docker Develop

我经常需要在 PHP、Hyperf 和 Go 项目之间切换。每个项目单独搭建环境并不难，但当 PHP 版本、Nginx 站点、Redis、路径映射和启动命令逐渐增多，重复配置就会变成一种稳定的时间消耗。

于是我做了 Docker Develop：一套面向团队本地开发的 Docker 工作台。它不只是把服务写进 docker-compose.yml，还希望让新成员拉下代码后，用一个命令就能完成初始化、环境检查和项目启动。

Docker Develop 工作台概览

我想解决的不只是“安装环境”

真正让本地开发变慢的，往往不是 Docker 本身，而是大量零散的差异：

  • 有的项目需要 PHP 7.3，有的已经升到 PHP 8.3。
  • Laravel 和普通 PHP 适合共用 PHP-FPM，Hyperf 却更适合拥有自己的常驻容器。
  • Windows、WSL2 和 macOS 的宿主机路径写法不同。
  • 开发者常常忘记某个项目需要哪些服务、端口和启动命令。
  • 环境启动失败时，问题可能在 Docker、Compose、路径映射、端口或网络源的任意一层。

所以 Docker Develop 的目标不是做一个“服务越多越好”的镜像集合，而是把初始化、项目接入、容器操作、站点配置和诊断收到一个可理解的流程里。

从容器编排到本地工作台

当前的核心结构分成几类：

  • docker-panel：基于 Hyperf + Swoole 的本地 Web 面板，统一管理项目、容器、站点和配置。
  • nginx + php-fpm：服务于 Laravel、ThinkPHP、普通 PHP 和静态站点，并支持 PHP 7.3、8.0、8.1 和 8.3。
  • hyperf-*：每个 Hyperf 项目使用独立容器，避免常驻进程互相影响。
  • go：包含 Go 开发环境和独立的 module/build 缓存，用于运行、测试和调试 Go 项目。
  • redis：作为常用公共服务。
  • workspace：保留为临时通用工具箱，不再承担所有项目的主运行环境。

这种划分有一个很实用的原则：能共享的基础服务就共享，需要保持独立生命周期的项目就拆开。

第一次启动只留一个入口

在 Windows Docker Desktop 下，首次使用只需要运行：


start-panel.bat

在 WSL2 或 macOS 下则是：


bash ./start-panel.sh

启动脚本会自动复制或补全 .env，创建 data 和 logs 目录，统一默认 PHP 8.3，配置 Composer 国内源和 Go Proxy，最后继续运行 doctor 诊断。即使还没有自己的业务项目，也可以通过内置 PHP Demo 先验证 Nginx、PHP-FPM 和路径映射。

我希望这个入口能把“启动环境”变成一个可预期的动作，而不是一串只有原作者记得的命令。

Projects 启动器：管理环境，不碰业务源码

Docker Develop 项目启动器

面板中的 Projects 启动器是我最常用的部分。接入项目时可以选择“完整接入环境”，让面板生成 Nginx 或 Compose 配置；也可以只添加管理卡片，接管已经存在的环境。

不同类型的项目会采用不同策略：

  • Laravel、普通 PHP-FPM 和静态站点会共用 Nginx 与 PHP 容器。
  • Hyperf 会生成项目专属容器；存在 server:watch 时使用热更新，否则回退到普通启动。
  • Go 项目可以直接在 go 工具容器中执行 go mod tidy、go test ./... 或 go run .。

项目卡片提供启动、停止、重启、日志和命令执行。删除操作清理的也只是环境配置与容器，面板不提供删除业务源码的界面或 API。这是我特意保留的安全边界。

路径映射必须是每台电脑自己的配置

跨平台最容易出错的地方是路径。Docker Develop 把宿主机项目共同父目录和容器内目录明确放在 .env 中：


HOST_PROJECT_PATH=D:\Develop

CONTAINER_PROJECT_PATH=/develop

例如宿主机的 D:\Develop\company\order-api 会映射为容器内的 /develop/company/order-api。WSL2 可以把同一个目录写成 /mnt/d/Develop，macOS 则可以使用 /Users/you/Develop。

这类本机差异不应该被硬编码进 Compose，也不应该要求所有人使用相同盘符。只要容器内统一使用 /develop，上层的 Nginx、项目卡片和执行命令就能保持一致。

doctor 让环境问题先有证据

当环境无法启动时，我不希望第一个动作是重装 Docker。项目因此提供了 Windows 和 Unix 两套诊断脚本：


.\doctor.ps1



bash ./doctor.sh

它们会检查 Docker、Compose、Docker Socket、端口、.env、路径映射、Composer 源、Go Proxy 和 Compose 配置。先把问题定位到具体层，比反复删容器、重建镜像更有效。

本地工具也需要清晰的安全边界

docker-panel 会挂载 /var/run/docker.sock，因此拥有管理本机 Docker 的能力。为了方便本地开发，当前面板默认免登录；同时它也明确只绑定：


127.0.0.1:9501

这不是一个应该暴露到公网或不可信局域网的管理面板。便利可以作为本地环境的默认值，但网络边界必须同时被限制。

这个项目带给我的几个确认

Docker Develop 目前仍在迭代，但它已经让我对开发工具有了几个更清晰的判断：

1. 好的默认值比选项数量更重要。 新用户先能跑起来，再根据项目调整细节。

2. 诊断必须跟启动一样容易找到。 当工具只提供启动按钮而没有错误证据，使用者最终还是会回到猜测。

3. 环境操作和源码操作要分开。 面板可以重建容器、生成站点或删除配置，但不应该因此获得删除项目源码的权限。

4. 跨平台不是强行统一所有路径。 应该统一容器内的视图，把宿主机差异保留在每台机器自己的配置中。

后续我会继续完善项目模板、配置验证和常用环境预设，但不会让面板变成另一个需要专门维护的重型平台。它仍然应该围绕最初的目标：减少重复配置，让项目更快进入可开发状态。

---

项目源码：github.com/chenbb0128/docker-develop