Baserow 插件安装实战Docker 镜像定制、运行时安装与环境变量自动安装的完整指南【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow本文基于 Baserow 官方插件安装文档docs/plugins/installation.md并结合仓库内deploy/plugins/下的真实安装脚本实现系统讲解 Baserow 插件的三种安装方式自定义 Dockerfile、现有容器内安装、启动时环境变量、插件目录结构与安全校验机制、运行时安装的容器重建注意事项以及插件卸载与查询的全部操作。读完后你将能够在自建self-hosted的 Baserow 环境中安全地安装、升级、卸载和审计任意社区或自研插件。需要先明确一点Baserow 插件目前仍处于early preview早期预览阶段文档明确列出了以下安全前提任何安装操作都应以此为准插件安装后对你的数据拥有完全访问权限可以执行任意代码。Baserow 不对插件做沙箱隔离、也不做任何安全检查Baserow 不验证、不担保任何插件的安全性也不对因安装或使用插件导致的任何损坏或损失承担责任使用插件完全由你自行承担风险——务必信任插件来源并在启用任何插件之前做好数据备份备份方法参见 Docker 安装指南的备份章节该功能只推荐给熟悉 Docker、volume、容器和命令行的高级用户部分能力目前缺失例如没有用于查看已安装插件的 UI所有管理操作都通过命令行完成。理解这些限制后下面的内容就聚焦于具体怎么装、怎么卸、怎么查并用仓库源码解释每一步背后脚本到底做了什么。方式一构建自定义 all-in-one 镜像最推荐官方文档指出构建自己的 all-in-one 镜像是目前最简单、最快、最可靠的插件安装方式。完整流程如下强烈建议先备份数据。插件拥有完全访问权限备份是官方流程的第一步详见 Docker 安装指南的备份章节。确保本机已安装并保持 Docker 为最新。创建一个名为Dockerfile的新文件用它来构建一个预装所需插件的自定义 Baserow 镜像。将以下内容复制进DockerfileFROM baserow/baserow:2.3.3 # You can install a plugin found in a git repo: RUN /baserow/plugins/install_plugin.sh \ --git https://github.com/example/example_baserow_plugin.git # Or you can download a tar.gz directly from an url RUN /baserow/plugins/install_plugin.sh \ --url https://example.com/plugin.tar.gz # Or you can install the plugin from a local folder by copying it into the image and \ # then installing using --folder COPY ./some_local_dir_containing_your_plugin/ /baserow/data/plugins/your_plugin/ RUN /baserow/plugins/install_plugin.sh \ --folder /baserow/data/plugins/your_plugin/ # The --hash flag below will make the install_plugin.sh script check that the # plugin exactly matches the provided hash. # # We recommend you provide this flag to make sure the downloaded plugin has not # been maliciously modified. # # To get the hash of a plugin simply run the docker build with a nonsense --hash # value. Then the build will fail and install_plugin.sh will print the hash of the # downloaded plugin. Then you can replace your nonsense --hash value with the printed # one and build again. RUN /baserow/plugins/install_plugin.sh \ --git https://github.com/example/example_baserow_plugin.git \ --hash hash_of_plugin_2从上面的RUN命令中只保留你要用的那一条删除其余的并把示例 URL 替换成你的插件地址。构建自定义镜像docker build -t my-customized-baserow:2.3.3 .像运行普通 Baserow 镜像一样运行新镜像docker run -p 80:80 -v baserow_data:/baserow/data my-customized-baserow:2.3.3源码印证install_plugin.sh到底做了什么上述Dockerfile中调用的/baserow/plugins/install_plugin.sh在仓库中对应 deploy/plugins/install_plugin.sh它在构建 all-in-one 镜像时会被复制到镜像内见 deploy/all-in-one/Dockerfile 中的COPY deploy/plugins/*.sh /baserow/plugins/与BASEROW_PLUGIN_DIR/baserow/data/plugins环境变量定义。阅读该脚本可以确认几个实操中容易踩坑的细节三种来源互斥。脚本用getopt解析参数--folder、--url、--git三个标志中必须且只能提供一个提供 0 个或多个都会报错退出exclusive_flag_count检查。参数含义如下--folder plugin folder插件所在文件夹路径--git https git repo url包含插件的 https git 仓库地址--url plugin url包含插件的.tar.gz文件下载地址--hash plugin hash若提供安装前会对插件内容做哈希校验不匹配则安装失败见下文--dev以开发模式安装pip install -e可编辑安装前端yarn install而非构建--runtime触发运行时 setup 脚本从 Dockerfile 调用时永远不应设置此参数--overwrite覆盖同名已安装插件并强制重装/重建。git 仓库有结构要求使用--git时脚本git clone后要求仓库中的plugins/子目录下有且只有一个子目录否则报错 does not look like a Baserow plugin。tar.gz 包同样有结构要求使用--url时脚本curl -Ls $url | tar xz解压后要求归档内含有一个plugins/目录且其中恰好只有一个插件子目录。插件目录结构每个插件是一个以插件名命名的文件夹内含backend/必须是合法的 Python 包和/或web-frontend/必须是合法的 node 包子目录若存在backend/build.sh或web-frontend/build.sh会在安装时执行以完成额外安装任务。哈希校验的具体算法--hash校验的实现是对插件目录内所有文件先sha1sum再对排序后的文件清单结果做一次sha1sumfind $folder -type f -print0 | sort -z | xargs -0 sha1sum | sha1sum。这正是文档建议的先填一个假 hash 值触发构建失败、从报错输出中读取真实 hash 再回填操作可行的原因——校验失败时脚本会同时打印实际 hash 与期望 hash。由于插件可以执行任意代码这一校验步骤对来自不可信来源的插件尤其重要文档明确推荐使用--hash。安装动作本身backend 模块通过pip3 install装入/baserow/venvweb-frontend 模块通过yarn add引入并触发 Nuxt 构建。脚本还会创建/baserow/container_markers目录写入构建标记文件如plugin.backend-built用于避免重复安装——这也解释了文档容器重建注意事项一节的行为见后文。方式二安装到现有的 all-in-one 容器这种方式直接把插件安装进一个已经存在的容器及其数据卷适合不想重新构建镜像的场景。前提是容器已停止。同样强烈建议先备份数据参见 Docker 安装指南的备份章节。对已停止的容器执行安装替换示例 URL 与可选 hash 为你自己的插件docker exec baserow \ ./baserow.sh install-plugin \ --git https://github.com/example/example_baserow_plugin.git \ --hash hash_of_plugin_1重启服务器以启用插件docker restart baserow从 deploy/all-in-one/baserow.sh 可以看到install-plugin子命令实际等价于在容器内执行/baserow/plugins/install_plugin.sh --runtime并透传其余参数——注意脚本自动附加了--runtime标志与 Dockerfile 构建方式的关键区别就在于此运行时安装会额外执行插件提供的runtime_setup.sh如果存在。这也说明文档中必须先把容器停止再 exec的原因安装过程会改动容器文件系统内的依赖环境。方式三通过环境变量在启动时安装使用官方 Baserow 镜像时可以通过两个环境变量在容器启动阶段自动安装插件BASEROW_PLUGIN_GIT_REPOS逗号分隔的 https git 仓库 URL 列表启动时逐个下载并安装BASEROW_PLUGIN_URLS逗号分隔的 URL 列表启动时下载并安装其中的.tar.gz插件包。示例——启动一个已预装两个插件的新容器docker run \ -v baserow_data:/baserow/data \ # ... 其他常规启动参数写在这里 -e BASEROW_PLUGIN_GIT_REPOShttps://example.com/example/plugin1.git,https://example.com/example/plugin2.git \ baserow:2.3.3启动时的自动安装机制从源码可以确认这两个环境变量并非魔法而是由启动流程显式处理all-in-one 容器的启动脚本 deploy/all-in-one/supervisor/start.sh 在拉起 supervisord 之前会source /baserow/plugins/utils.sh并调用startup_plugin_setupdeploy/plugins/utils.sh 中的startup_plugin_setup函数做了三件事遍历$BASEROW_PLUGIN_DIR在 all-in-one 镜像中被设置为/baserow/data/plugins下每个插件目录对尚未在当前容器内安装完成的插件重新执行install_plugin.sh --runtime --folder ...将BASEROW_PLUGIN_URLS按逗号拆分逐个执行install_plugin.sh --runtime --url ...将BASEROW_PLUGIN_GIT_REPOS按逗号拆分逐个执行install_plugin.sh --runtime --git ...。若设置了BASEROW_DISABLE_PLUGIN_INSTALL_ON_STARTUP则跳过上述全部逻辑并打印提示日志。这意味着两点实践结论其一这两个环境变量只在容器启动时触发一次安装之后不会持续监听其二卸载一个用环境变量安装的插件不能只uninstall-plugin加重启否则重启时环境变量会把它再装回来文档在环境变量方式卸载一节对此有专门警告见下文。容器重建注意事项Caveats文档特别强调了一个容易误解的场景如果删除了曾在其内运行时安装过插件的容器再重新创建新容器是从不含任何插件的baserow/baserow:2.3.3基础镜像创建的。但只要数据卷没丢插件不会消失原因在源码中很清晰无论构建时还是运行时安装插件本体都保存在数据卷挂载的/baserow/data/plugins目录下而非镜像层启动时startup_plugin_setup会扫描该目录对插件目录存在但当前容器内尚未安装的插件自动重新执行安装是否已安装的判断依据是/baserow/container_markers中的标记文件plugin.backend-built、plugin.web-frontend-built等它们位于容器文件系统内而非数据卷——这正是为什么容器从零重建后会看到插件重新安装一遍的现象。结论与文档一致只要复用同一个数据卷即使删除并重建容器也不会丢失任何插件数据唯一影响是新建容器的首次启动日志中会看到插件自我重装的过程。在 standalone 服务镜像中安装除了 all-in-one 镜像Baserow 还提供baserow/backend:2.3.3与baserow/web-frontend:2.3.3镜像它们只分别运行 backend/celery 或 web-frontend 服务面向多服务 docker-compose、k8s 等更高级的自托管部署。这些镜像同样提供install-plugin/uninstall-plugin/list-pluginsCLI配合docker run指定命令以及上文提到的两个插件环境变量。例如docker run --rm baserow/backend:2.3.3 install-plugin ... docker run -e BASEROW_PLUGIN_GIT_REPOShttps://example.com/example/plugin1.git,https://example.com/example/plugin2.git --rm baserow/backend:2.3.3用法与上文各节完全相同既可以写进 Dockerfile 也可以在运行时执行。脚本会自动检测自己运行在 backend-only 还是 web-frontend-only 镜像中并只安装对应那一侧的插件模块——从 install_plugin.sh 的实现可以看到安装逻辑就是分别判断/baserow/backend与/baserow/web-frontend目录是否存在只处理与插件实际包含的子模块匹配的那一侧。文档中提到插件样板工程plugin boilerplate提供了在backend.Dockerfile和web-frontend.Dockerfile中这样做的示例可参见 docs/plugins/boilerplate.md该文档注明样板工程适用于 Baserow 2.0.6 及更早版本新版请参照其指向的 boilerplate 仓库。卸载插件警告原文强调卸载会把插件从 Baserow 安装中移除并永久删除其全部关联数据。卸载脚本 deploy/plugins/uninstall_plugin.sh 的行为是执行插件自带的backend/uninstall.sh/web-frontend/uninstall.sh如果存在然后pip3 uninstall后端包、yarn remove前端包并触发 Nuxt 重新构建最后删除插件目录与 container markers。由于卸载过程可能需要回滚数据库迁移all-in-one 镜像的uninstall-plugin子命令会通过 baserow.sh 中的run_cmd_with_db先拉起嵌入式 PostgreSQL 再执行卸载——这与安装路径安装时数据库变更可留待启动时以正常迁移完成不同是理解卸载必须先停容器/需要数据库的关键。场景一卸载通过自定义 Dockerfile 安装的插件强烈建议先备份数据参见 Docker 安装指南的备份章节。先停止 Baserow 服务器docker stop baserow用官方镜像挂载同一数据卷执行卸载docker run --rm -v baserow_data:/baserow/data baserow:2.3.3 uninstall-plugin plugin_name插件已卸载自身、全部关联数据已删除。编辑自定义Dockerfile删除对应的插件安装步骤。重新构建镜像docker build -t my-customized-baserow:2.3.3 .删除基于旧镜像的容器docker rm baserow用去掉插件的新镜像重新运行docker run -p 80:80 -v baserow_data:/baserow/data my-customized-baserow:2.3.3文档特别提醒如果不完成第 5–8 步由于插件文件夹仍留在数据卷的/baserow/data/plugins中自定义镜像里也仍装着该插件任何一次容器重建都会触发启动时自动重装插件会复活。场景二卸载直接装入容器的插件强烈建议先备份数据。针对不用 Dockerfile、而是直接装入现有容器的插件在容器运行中执行假设容器名为baserowdocker exec baserow ./baserow.sh uninstall-plugin plugin_name插件卸载自身、关联数据被删除。重启服务器docker restart baserow场景三卸载通过环境变量安装的插件强烈建议先备份数据。若插件是用BASEROW_PLUGIN_GIT_REPOS或BASEROW_PLUGIN_URLS安装的必须删除并重建容器且新容器的环境变量中不再包含该插件。如果只用uninstall-plugindocker restart由于环境变量仍含有旧插件地址重启时startup_plugin_setup会把它再装回来。正确步骤docker stop baserowdocker run --rm -v baserow_data:/baserow/data baserow:2.3.3 uninstall-plugin plugin_name插件及其数据已移除。用与原启动命令相同的docker run重新创建容器仅把该插件从对应环境变量中剔除。查看已安装的插件使用list-plugins子命令或镜像内置的/baserow/plugins/list_plugins.sh脚本查看当前已安装的插件docker run \ --rm \ -v baserow_data:/baserow/data \ baserow:2.3.3 list-plugins # 或在运行中的容器里 docker exec baserow /baserow/plugins/list_plugins.sh需要指出一个原文档的笔误其运行中容器示例写的是/baserow/plugins/list_plugin.sh单数而仓库中的实际脚本名是 list_plugins.sh复数baserow.sh 调用的也是复数形式实际操作请以复数名为准。从 list_plugins.sh 的实现看它会遍历/baserow/data/pluginsBASEROW_PLUGIN_DIR下的每个插件目录并打印名称若插件携带baserow_plugin_info.json元数据文件还会解析并显示其中的description字段——这是目前最接近查看已安装插件的 UI 替代品文档已说明正式 UI 尚缺。小结与操作速查操作命令/配置关键注意点构建期安装推荐Dockerfile中RUN /baserow/plugins/install_plugin.sh --git/--url/--folder来源三选一互斥git 仓库plugins/下须恰好一个子目录建议加--hash运行时安装docker exec baserow ./baserow.sh install-plugin --git url [--hash h]容器须先停止装完docker restart baserow启动时自动安装-e BASEROW_PLUGIN_GIT_REPOSurl1,url2/-e BASEROW_PLUGIN_URLSurl1,url2仅启动时触发一次卸载须改环境变量并重建容器卸载docker run --rm -v baserow_data:/baserow/data baserow:2.3.3 uninstall-plugin name会删除全部关联数据先备份Dockerfile 方式须再重建镜像查询docker run --rm -v baserow_data:/baserow/data baserow:2.3.3 list-plugins会显示插件名与baserow_plugin_info.json中的描述禁用启动自动安装BASEROW_DISABLE_PLUGIN_INSTALL_ON_STARTUP设置后启动不再扫描数据卷与环境变量安装插件以上所有流程均基于当前仓库deploy/plugins/下的脚本实现与docs/plugins/installation.md文档交叉验证由于插件处于 early preview 阶段且官方不做任何安全隔离请始终将信任来源 先备份 --hash校验作为安装前的标准动作。【免费下载链接】baserowBuild databases, automations, apps agents with AI — no code. Open source platform available on cloud and self-hosted. GDPR, HIPAA, SOC 2 compliant. Best Airtable alternative.项目地址: https://gitcode.com/GitHub_Trending/ba/baserow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考