懒猫微服进阶心得（九）：商店 App 如何接管 Docker 引擎？

在之前的内容中，我们提到过懒猫微服采用三套独立的 Docker 环境来隔离系统组件、Playground Docker 与商店 App 的 Docker 实例。那么问题来了：**如何让商店中上架的 App 操作 Playground 中的 Docker 引擎？** 答案是：**通过挂载 `docker.sock` 文件来实现跨容器控制。** 所以我们可以在商店的APP中操作playground docker，其实也就是Docker面板或者轻量Docker面板做的事情。 为什么不操作其他两个Docker引擎？ - 系统组件Docker无需干预，重启之后可以复原。 - 应用商店有自己的生命周期，也无需干预。 ------ ### 一、在 `build.yml` 中挂载 Playground 路径 首先，在打包配置 `build.yml` 中新增 `services` 字段，用于将宿主机中的 `/data/playground` 挂载到容器内部： ```yml manifest: ./lzc-manifest.yml pkgout: ./ icon: ./logo.png services: containly: volumes: - bind: create_host_path: true source: /data/playground target: /lzcapp/run/playground type: bind ``` 打包后会生成一个名为 `compose.override.yml` 的文件。**请注意：即使你手动创建了 `compose.override.yml`，也可能无法直接生效，必须通过打包流程自动生成。**（此结论基于初步测试） 生成后的 `compose.override.yml` 内容如下： ```yml services: containly: volumes: - bind: create_host_path: true source: /data/playground target: /lzcapp/run/playground type: bind ``` ------ ### 二、修改 `manifest.yml` 实现 `docker.sock` 映射 为了让上架 App 操作 Docker，需要手动编辑 `manifest.yml` 文件，添加以下内容： ```yml binds: - /lzcapp/run/playground/docker.sock:/var/run/docker.sock environment: - DOCKGE_STACKS_DIR=/lzcapp/var/stacks - DOCKER_HOST=unix:///lzcapp/run/playground/docker.sock ``` 这样，容器内的 Docker CLI 或管理面板就可以通过 `DOCKER_HOST` 环境变量，控制宿主机的 Docker 引擎。 ------ ### 三、完整的 `manifest.yml` 示例 以下是完整可运行的 `manifest.yml` 配置： ```yml lzc-sdk-version: 0.1 package: xu.deploy.containly version: 0.0.2 name: Containly description: >- A fancy, easy-to-use and reactive self-hosted docker compose.yaml stack-oriented manager. license: https://choosealicense.com/licenses/mit/ homepage: https://github.com/cloudsmithy/Containly author: xu usage: >- 安装完成后，请重启懒猫微服以启用 Docker。 此应用将接管懒猫微服的独立 Docker 守护进程，可能存在安全风险。在授予容器 privileged 等权限之前，请确保容器是安全的，且不会执行危险操作。为了避免潜在风险，请确保： 1. 您了解容器的行为，并确认它们来自可信的源。 2. 容器中没有运行高危命令，且没有暴露不必要的端口或服务。 建议先查阅懒猫微服开发者手册，了解相关特性和限制，并根据手册中的安全建议配置容器。 application: subdomain: containly routes: - /=http://containly.xu.deploy.containly.lzcapp:5000/ services: containly: image: registry.lazycat.cloud/u04123229/cloudsmithy/containly:896f4251373d0ebe binds: - /lzcapp/run/playground/docker.sock:/var/run/docker.sock environment: - DOCKGE_STACKS_DIR=/lzcapp/var/stacks - DOCKER_HOST=unix:///lzcapp/run/playground/docker.sock ``` ------ ### 四、总结 通过挂载 `docker.sock` 文件和设置 `DOCKER_HOST`，我们可以让商店上架的 App 控制懒猫微服的 Playground Docker 实例。我用这个功能上架了自己写的Docker面板，一起来玩一玩嘛？ 

我用Amazon Q写了一个Docker客户端，并上架了懒猫微服商店

https://appstore.lazycat.cloud/#/shop/detail/xu.deploy.containly 自从被种草了Amazon Q，我陆陆续续写了不少小软件，其中这个 Docker 客户端是一个典型的例子，比较符合自己平时使用的习惯，也分享给一些朋友和 NAS 爱好者来用。  故事还要用上次折腾黑群晖说起，本意想把 NAS 和打印机共享二合一的，所以把闲着的软路由做了改装。顺便使用 Docker 跑一些服务，有老本行的 ES 集群，也有自己写的一些工具类型的服务。 随着时间增长，部署的服务多了，时间长了就会忘记服务的端口，甚至还要登录群晖Web 端进行查看，群晖的Container Manager 很好用，就是登录的密码策略比较复杂，每次登录都比较麻烦，所以后来使用了一个 HomePage 来保存这些服务。但是每次调试 Docker 都非常麻烦。与Portainer相比，我需要的只是一个简洁的面板来查看容器的URI、状态，并进行启停操作，因此我决定自己开发一个。  这个是群晖的 Container Manager，后面还有很多容器。记住这么多端口然后随时维护绝对不是一个容易的事。  我开发容器面板叫做Containly， 是一个Container 的管理工具。最早的时候用我是用 GPT 写的。但是随着项目越来越大，GPT 每次都会丢一些东西，而且还没办法操作本地目录，后来才转向了 Amazon Q，这个版本还是用 Q CLI来做的。 于是写好之后我把这个 APP 上架了懒猫微服的商店，这个是一款国产化的 NAS，可玩性非常高，对开发者也十分友好。上线当日就有很多开发者安装使用了。  Containly的核心功能是通过目录映射的Docker引擎读取所有容器信息，包括容器的启动、退出、停止及其他状态。例如，当容器处于“Create”状态时，它会被标记为“Other”状态，便于管理。  默认情况下，每个容器卡片会显示容器的网桥信息、端口映射和URL。默认使用HTTP协议，鼠标悬停时，会在右侧显示操作按钮。通过点击这些按钮，操作会被保留，再次点击会隐藏，这样子就整个比较美观。 按钮功能包括： * 停止/启动 * 重启 * 查看日志 * SSH进入容器 * 切换HTTP/HTTPS * 黑名单管理  此外，Containly还提供了一个输入框，用户可以输入需要监控的NAS域名，面板会自动根据域名和端口拼接成URI，并存储在localStorage中。更进一步，Containly还支持暗黑模式，提升了用户体验。  另外如果多节点部署服务的话，还可以把从节点放入黑名单，这样子就只显示主节点的信息，面板就比较清爽。如果需要从节点的信息再从黑名单移除。  利用面板的 SSH 功能， 能够直接从面板进去访问容器的 SHELL，不用执行再 docker exec 的命令。  看日志也很方便，也无需再使用 docker logs，这样调试容器的时候就很方便了。  我已经打包好了Docker镜像并配置了GitHub Actions，便于自动化部署。你可以通过以下方式部署Containly： #### **Docker部署命令** ```bash docker run -d \ --name containly \ -p 5000:5000 \ # 映射容器端口到主机 -v /var/run/docker.sock:/var/run/docker.sock \ # 挂载Docker socket，允许访问宿主机Docker cloudsmithy/containly:latest # 使用最新版本的Containly镜像 ``` #### **Compose配置** ```yaml version: "3.8" services: containly: image: cloudsmithy/containly:latest ports: - "5000:5000" volumes: - /var/run/docker.sock:/var/run/docker.sock restart: unless-stopped ``` 这个是使用 Q 修改的部分代码截图：  后来机缘巧合之下用了 Q pro，看来也不能优化再多。  除了使用Q CLI，我们还可以通过安装VSCode和JetBrains插件来使用Q，安装插件后，免费版本可以使用Builder ID登录，Pro版本则支持使用IAM Identity Center登录。  在VSCode中，你可以通过Q聊天面板与Q进行交互，并且支持中文聊天。  与GPT相比，Q的优势在于它可以直接操作本地文件，用户可以直接在文件夹中生成工程文件，极大提升了开发效率。 

懒猫微服开发篇（七）: 解析 Docker Compose Override

看过很多的Docker教程，也都不曾提到过compose override，第一次接触到这个是在懒猫微服上解开LPK看到的，用来注入docker 引擎的环境变量。但是还以为是懒猫微服的小技巧，今天整理笔记才发现原来的Docker compose用来做多环境部署的配置文件，比如用来给开发和生产分别注入不同的环境变量和配置文件。 > 参考文档：[Docker Compose Override - LazyCat Developer Guide](https://developer.lazycat.cloud/advanced-compose-override.html) 使用场景是这样，在实际开发中，通常我们需要分别为开发和生产环境配置不同的服务和环境变量。虽然可以为每个环境维护独立的 Compose 文件，Docker Compose 提供了一个非常有用的特性，可以将多个 Compose 文件结合使用，简化配置管理。 - **基础配置文件**：第一个 Compose 文件通常作为基础配置，后续的文件可以覆盖该基础文件中的配置。 - **覆盖配置**：每个额外的文件不仅可以覆盖基础文件中的已有配置，还可以添加新的配置。 默认情况下，Compose 会读取以下两个文件： - **docker-compose.yml**：基础配置文件 - **docker-compose.override.yml**：覆盖文件 你还可以通过 `-f` 参数指定多个非默认的覆盖文件，Compose 会按顺序合并这些文件。 ``` docker compose -f docker-compose.yml -f dev.override.yml up ``` - **docker-compose config**：这是一个非常有用的命令，可以帮助你验证最终的配置文件，尤其是在使用多个 Compose 文件时。它显示了合并后的 Compose 配置，帮助你确保配置符合预期。 ### 示例：Nginx 配置 #### docker-compose.yml ```yml services: web: image: nginx:latest ports: - "80:80" ``` #### docker-compose.override.yml ```yml services: web: volumes: - ./dev:/usr/share/nginx/html # 使用本地开发文件夹覆盖默认卷 environment: - DEBUG=true # 启用开发环境的调试模式 ```  在这个例子中，`docker-compose.override.yml` 覆盖了 `docker-compose.yml` 中的配置，添加了开发环境相关的文件挂载和环境变量设置。  ### 合并后的配置（查看通过 `docker-compose config` 命令生成的配置） ```bash name: "3" services: web: environment: DEBUG: "true" image: nginx:latest networks: default: null ports: - mode: ingress target: 80 published: "80" protocol: tcp volumes: - type: bind source: /Users/name/Desktop/dev target: /usr/share/nginx/html bind: create_host_path: true networks: default: name: 3_default ``` 可以看到，通过合并配置，开发环境的调试模式和本地文件夹挂载已经成功加入了配置。 ### 懒猫应用的上的compose override 针对一些 lpk 规范目前无法覆盖到的运行权限需求， 可以通过 [compose override](https://docs.docker.com/reference/compose-file/merge/) 机制来间接实现。 通过应用查看器可以看到，这是 **Docker Compose** 配置的一部分，用于定义容器中的 `containly` 服务，并映射playground的docker引擎。具体的配置说明如下： - **services**: 这是 Docker Compose 文件的顶级字段，定义了服务列表。`containly` 是定义的一个服务名称。 - **containly**: 这是服务的名称。在此配置下，的服务名是 `containly`。 - **volumes**: 定义了容器与宿主机（本地）之间的文件夹共享和挂载。该部分的配置是映射一个本地目录到容器内部的目录。 - **bind**: 使用绑定挂载的方式（bind mount），允许宿主机的文件或目录直接映射到容器内部。这里设置了 `create_host_path: true`，意思是如果宿主机上的 `/data/playground` 目录不存在，它会自动创建。 - **source**: 宿主机的路径，映射为容器中的目录。这里指定了 `/data/playground` 作为源路径，意味着宿主机上的这个目录将被挂载到容器内。 - **target**: 容器内的路径，即宿主机上的 `source` 目录映射到容器内部的 `/lzcapp/run/playground` 目录。容器内的应用可以访问这个目录。 - **type**: 这里设置的是 `bind`，表示采用绑定挂载方式  最后highlight下WIKI里的三句话： 1. **确认最终生成的 `lpk` 中存在名为 `compose.override.yml` 的文件**，并且内容是一个合法的 Compose 合并文件。 2. **通过 SSH 进入 `/data/system/pkgm/run/$appid` 目录**，确认该目录下是否存在 `override.yml` 文件。 3. **使用 `lzc-docker-compose config` 命令查看最终合并后的配置**，确保它符合预期。 子/data/system/pkgm/run/$appid目录里，我的结果如下,供参考。 ```bash docker compose config name: xudeploycontainly services: app: .... - type: bind source: /data/playground target: /lzcapp/run/playground bind: create_host_path: true ... (base) lzcbox-029c588e /data/system/pkgm/run/xu.deploy.containly # ls compose.override.yml docker-compose.yml pkg (base) lzcbox-029c588e /data/system/pkgm/run/xu.deploy.containly # cat compose.override.yml services: containly: volumes: - bind: create_host_path: true source: /data/playground target: /lzcapp/run/playground type: bind ```