在 Fluent Bit 仓库中使用 Docker 构建 Zstandardzstd压缩工具镜像【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit导读Zstandard简称 zstd是一种追求实时压缩场景的高性能无损压缩算法其参考实现以 C 库加命令行工具的形式随本仓库一并托管于lib/zstd-1.5.7目录并被 Fluent Bit 的压缩模块如 flb_zstd.c直接复用。本文以仓库内 contrib/docker/README.md 为主体完整讲解如何通过 Dockerfile 多阶段构建产出仅包含 zstd 可执行文件的精简镜像、如何用一行管道命令验证压缩/解压链路并结合仓库源码逐层剖析构建脚本、安装产物与 CLI 行为帮助你掌握“源码级构建 容器化交付 管线验证”的完整方法。一、背景仓库中的 Zstandard 与这份 Docker 说明Zstandard 由 MetaFacebook开发并开源主打“zlib 级别的实时压缩场景 更好的压缩比”其帧格式已稳定并收录于 RFC 8878。本仓库中的 README.md 明确说明该目录是 zstd 的参考实现以 BSD 或 GPLv2 双许可证提供 C 库同时提供可处理.zst、.gz、.xz与.lz4文件的命令行工具。在本仓库中zstd 并不只是“顺带打包的第三方库”。Fluent Bit 通过 cmake/zstd.cmake 将lib/zstd-1.5.7集成进构建并在 src/flb_zstd.c 中直接调用其 C API例如flb_zstd_compress()使用压缩级别 1 进行快速压缩见 src/flb_zstd.c解压路径则设置了 64 KB 的分块缓冲FLB_ZSTD_DEFAULT_CHUNK与 100 MB 的解压上限FLB_ZSTD_DECOMPRESS_MAX以防御畸形数据造成的资源消耗见 src/flb_zstd.c。而contrib/docker目录提供的则是一套独立的容器化交付方案不依赖 Fluent Bit 主构建直接从 zstd 源码编译出独立的zstd命令行工具镜像。这份 README.md 就是它的使用说明篇幅虽短却覆盖了环境要求、构建命令、运行与测试三个关键环节下文将逐一展开并结合源码深入讲解。二、环境要求为什么需要 Docker 17.05原文档开篇给出的唯一硬性要求是构建Dockerfile需要docker版本不低于 17.05。这一版本要求并非随意设定。17.05 是 Docker 正式引入多阶段构建multi-stage build的版本允许在一个 Dockerfile 内使用多个FROM指令前一阶段编译产生的文件可以通过COPY --from精确拷贝到最终镜像中而构建过程中产生的中间层如编译器、头文件、依赖包全部被丢弃。对照 Dockerfile 可以看到它恰好就是多阶段构建的典型用法因此低于 17.05 的 Docker 无法解析该 Dockerfile。关于 Docker 本身的安装原文档指向 Docker 官方文档的 Ubuntu 安装指南ppa 方式可获得较新版本。这里不再赘述外部安装细节只需记住Ubuntu 等发行版自带仓库中的 docker 版本往往偏旧若docker build报出与多阶段构建/COPY --from相关的解析错误请优先升级 Docker 到 17.05 以上再重试。三、Dockerfile 逐行剖析多阶段构建如何产出“最小可用”镜像完整的构建脚本位于 lib/zstd-1.5.7/contrib/docker/Dockerfile全文仅 21 行却清晰地分为两个阶段。3.1 第一阶段builder编译并安装到临时目录# First image to build the binary FROM alpinesha256:69665d02cb32192e52e07644d76bc6f25abeb5410edc1c7a81a10ba3f0efb90a as builder RUN apk --no-cache add make gcc libc-dev COPY . /src RUN mkdir /pkg cd /src make make DESTDIR/pkg install要点拆解基础镜像使用固定的 digestalpinesha256:69665d02...而不是alpine:latest。锁定 digest 意味着每次构建使用完全相同的底层镜像保证可复现性避免latest标签漂移引入不可控变化。构建依赖仅装在 builder 阶段apk --no-cache add make gcc libc-dev安装 GNU make、gcc 与 C 标准库开发头文件。--no-cache表示不保留 apk 索引缓存进一步缩小中间层体积。COPY . /src把整个 zstd 源码树拷入镜像注意这里拷贝的是构建上下文通常即lib/zstd-1.5.7目录的全部内容。make与make DESTDIR/pkg install是关键两步先执行默认目标完成编译默认目标为lib-release与zstd-release见 Makefile随后以DESTDIR/pkg暂存安装将所有安装产物集中到/pkg下方便下一阶段整体拷贝。3.2 第二阶段运行只保留可执行产物# Second minimal image to only keep the built binary FROM alpinesha256:69665d02cb32192e52e07644d76bc6f25abeb5410edc1c7a81a10ba3f0efb90a # Copy the built files COPY --frombuilder /pkg / # Copy the license as well RUN mkdir -p /usr/local/share/licenses/zstd COPY --frombuilder /src/LICENSE /usr/local/share/licences/zstd/ # Just run zstd if no other command is given CMD [/usr/local/bin/zstd]要点拆解全新的干净基础镜像第二阶段重新从同一 alpine 镜像开始不再继承任何编译工具。通过COPY --frombuilder /pkg /把第一阶段安装到/pkg下的全部内容二进制、脚本、man page 等合并进根文件系统从而得到仅含运行产物的精简镜像——gcc、make 等一律不进入最终镜像。许可证文件的复制单独创建/usr/local/share/licenses/zstd目录并将源码树中的LICENSEBSD 风格仓库同时提供 COPYING 对应 GPLv2 选项一并放入镜像符合开源软件的许可证随发行物分发惯例。需要留意的是Dockerfile 中目标路径写成了licences英式拼写与上面创建的licenses目录并不一致——这是上游脚本中的一个拼写瑕疵最终许可证会被放到/usr/local/share/licences/zstd/下。默认入口CMD [/usr/local/bin/zstd]指定容器无参数启动时直接执行 zstd 命令。由于是CMD而非ENTRYPOINTdocker run zstd zstdcat这类带参数启动时会用传入命令覆盖默认值详见下文测试部分。3.3make install到底装了什么要理解最终镜像内容需要知道make DESTDIR/pkg install的安装清单。查看 programs/Makefile 的install目标可以看到安装zstd可执行文件到$(BINDIR)创建zstdcat、unzstd、zstdmt三个指向zstd的符号链接——这正是命令行工具“一个二进制、多个语义入口”的设计安装zstdless、zstdgrep辅助脚本安装zstd.1、zstdgrep.1、zstdless.1手册页。此外DESTDIR与PREFIX是标准 GNU 安装变量PREFIX控制默认安装根默认/usr/localDESTDIR用于将安装“暂存”到指定目录是打包、容器镜像制作的标准手法此处即用于把产物集中到/pkg。四、构建与运行三条命令完成交付与验证原文档给出的操作序列非常精简以下逐条展开并补充原理。4.1 构建镜像docker build -t zstd .-t zstd将镜像命名为zstd需要在包含 Dockerfile 的目录即lib/zstd-1.5.7/contrib/docker下执行.表示把当前目录作为构建上下文构建时请确保网络可访问 Docker Hub拉取 alpine 基础镜像与源码包如需要。4.2 一行命令完成压缩/解压管线验证原文档的测试方法是构建完成后在主机上执行echo foo | docker run -i --rm zstd | docker run -i --rm zstd zstdcat预期输出foo这条管道背后发生了什么值得拆解echo foo在主机上向 stdout 输出foo\n第一个docker run -i --rm zstd-i保持 stdin 打开把管道中的foo\n送入容器内的 zstd。由于没有额外参数且CMD是[/usr/local/bin/zstd]zstd 以从 stdin 读入、压缩到 stdout的模式工作这是 zstd 的管道语义输出一段.zst压缩帧这段二进制流经管道送入第二个容器docker run -i --rm zstd zstdcat以zstdcat覆盖默认CMD。而zstdcat等价于zstd -dcf见 programs/zstd.1.md即强制解压、写入 stdout 且不覆盖文件于是压缩帧被还原为foo\n--rm让每个容器在退出后自动删除测试不留任何残留容器。可见这条命令同时验证了压缩方向、容器 stdin/stdout 贯通、zstd 的管道读写模式以及zstdcat别名语义是镜像可用性的最小完备测试。五、镜像内 CLI 能力从 CLI 变体到常用参数构建出的镜像包含的是标准 zstd CLI。根据 programs/README.md该 CLI 支持 gzip 风格参数并内建字典构建器与基准测试模块。常用参数在 zstd.1.md 中有完整说明摘取与日常使用最相关的部分参数含义-#压缩级别 119默认 3级别越高压缩比越大、速度越慢--fast[#]使用负压缩级别换取更快的压缩/解压速度代价是压缩比下降-d/--decompress解压unzstd即zstd -d-t/--test仅测试完整性不输出解压结果-l/--list查看.zst文件的帧信息-T#/--threads#多线程压缩自动检测到 pthread 时默认启用可通过HAVE_THREAD编译变量控制--long[#]启用长距离匹配模式提升高压缩比场景的比率--train FILES字典训练模式用样本集生成字典显著改善小数据压缩效果配合容器使用时典型场景例如# 在镜像内压缩一个挂载文件 docker run --rm -v $PWD:/data zstd zstd -1 /data/app.log # 查看压缩文件信息 docker run --rm -v $PWD:/data zstd zstd -l /data/app.log.zst此外zstd与zstdcat、unzstd、zstdmt均为同一二进制的符号链接容器内按命令名自动切换行为解压时默认去掉.zst后缀、压缩时默认追加.zst后缀见 programs/zstd.1.md。六、进阶按需裁剪 CLI 的编译变量如果你希望在容器内获得更小的 zstd 二进制可以在 Dockerfile 的make阶段传入编译变量。参考 programs/README.md主要变量包括HAVE_THREAD0禁用多线程支持默认在检测到 pthread 时自动开启HAVE_ZLIB0/HAVE_LZMA0/HAVE_LZ40分别去掉.gz、.xz/.lzma、.lz4格式支持默认在检测到对应库时自动开启ZSTD_LEGACY_SUPPORT0不支持 v0.8.0 之前的旧版 zstd 帧格式默认支持 v0.4.0ZSTD_NOBENCH/ZSTD_NODICT去掉内建的基准测试与字典构建模块减小体积ZSTD_NOCOMPRESS/ZSTD_NODECOMPRESS编译成仅解压或仅压缩的专用版本。例如将构建命令改为RUN mkdir /pkg cd /src make zstd-small make DESTDIR/pkg install即可产出针对最小体积优化的 CLI。若在仓库内自行构建实验镜像仅需调整 Dockerfile 后重新docker build -t zstd .。七、与 Fluent Bit 主项目的衔接最后回到本仓库的整体视角。contrib/docker提供的是独立的 zstd 工具镜像而 Fluent Bit 本体对 zstd 的消费路径与之并行构建集成通过 cmake/zstd.cmake 将lib/zstd-1.5.7作为依赖编译进 Fluent Bit运行时集成核心压缩/解压逻辑集中在 src/flb_zstd.c对外暴露flb_zstd_compress()与flb_zstd_uncompress()两个接口内部使用ZSTD_compress、ZSTD_decompressStream等 C API并针对未知输出长度场景以 64 KB 缓冲迭代解压、以 100 MB 上限兜底见 src/flb_zstd.c。因此无论你是想在 CI/CD 中用本文的镜像做日志压缩预处理还是想理解 Fluent Bit 内置 zstd 压缩的底层机制lib/zstd-1.5.7下的这份 Docker 方案与源码都是相互印证的完整参考。小结围绕 contrib/docker/README.md 这份简短说明本文补齐了三条关键信息为什么要求 Docker 17.05多阶段构建、Dockerfile 两个阶段分别做了什么源码编译 → 精简交付、一行管道命令如何完整验证 zstd 镜像压缩、传输、解压、别名语义并在此基础上延伸到make install的安装清单、CLI 常用参数、可裁剪的编译变量以及与 Fluent Bit 主项目的集成关系。参照本文即可在本仓库内独立完成 zstd 工具镜像的构建、验证与定制。【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 Fluent Bit 仓库中使用 Docker 构建 Zstandard（zstd）压缩工具镜像
在 Fluent Bit 仓库中使用 Docker 构建 Zstandardzstd压缩工具镜像【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit导读Zstandard简称 zstd是一种追求实时压缩场景的高性能无损压缩算法其参考实现以 C 库加命令行工具的形式随本仓库一并托管于lib/zstd-1.5.7目录并被 Fluent Bit 的压缩模块如 flb_zstd.c直接复用。本文以仓库内 contrib/docker/README.md 为主体完整讲解如何通过 Dockerfile 多阶段构建产出仅包含 zstd 可执行文件的精简镜像、如何用一行管道命令验证压缩/解压链路并结合仓库源码逐层剖析构建脚本、安装产物与 CLI 行为帮助你掌握“源码级构建 容器化交付 管线验证”的完整方法。一、背景仓库中的 Zstandard 与这份 Docker 说明Zstandard 由 MetaFacebook开发并开源主打“zlib 级别的实时压缩场景 更好的压缩比”其帧格式已稳定并收录于 RFC 8878。本仓库中的 README.md 明确说明该目录是 zstd 的参考实现以 BSD 或 GPLv2 双许可证提供 C 库同时提供可处理.zst、.gz、.xz与.lz4文件的命令行工具。在本仓库中zstd 并不只是“顺带打包的第三方库”。Fluent Bit 通过 cmake/zstd.cmake 将lib/zstd-1.5.7集成进构建并在 src/flb_zstd.c 中直接调用其 C API例如flb_zstd_compress()使用压缩级别 1 进行快速压缩见 src/flb_zstd.c解压路径则设置了 64 KB 的分块缓冲FLB_ZSTD_DEFAULT_CHUNK与 100 MB 的解压上限FLB_ZSTD_DECOMPRESS_MAX以防御畸形数据造成的资源消耗见 src/flb_zstd.c。而contrib/docker目录提供的则是一套独立的容器化交付方案不依赖 Fluent Bit 主构建直接从 zstd 源码编译出独立的zstd命令行工具镜像。这份 README.md 就是它的使用说明篇幅虽短却覆盖了环境要求、构建命令、运行与测试三个关键环节下文将逐一展开并结合源码深入讲解。二、环境要求为什么需要 Docker 17.05原文档开篇给出的唯一硬性要求是构建Dockerfile需要docker版本不低于 17.05。这一版本要求并非随意设定。17.05 是 Docker 正式引入多阶段构建multi-stage build的版本允许在一个 Dockerfile 内使用多个FROM指令前一阶段编译产生的文件可以通过COPY --from精确拷贝到最终镜像中而构建过程中产生的中间层如编译器、头文件、依赖包全部被丢弃。对照 Dockerfile 可以看到它恰好就是多阶段构建的典型用法因此低于 17.05 的 Docker 无法解析该 Dockerfile。关于 Docker 本身的安装原文档指向 Docker 官方文档的 Ubuntu 安装指南ppa 方式可获得较新版本。这里不再赘述外部安装细节只需记住Ubuntu 等发行版自带仓库中的 docker 版本往往偏旧若docker build报出与多阶段构建/COPY --from相关的解析错误请优先升级 Docker 到 17.05 以上再重试。三、Dockerfile 逐行剖析多阶段构建如何产出“最小可用”镜像完整的构建脚本位于 lib/zstd-1.5.7/contrib/docker/Dockerfile全文仅 21 行却清晰地分为两个阶段。3.1 第一阶段builder编译并安装到临时目录# First image to build the binary FROM alpinesha256:69665d02cb32192e52e07644d76bc6f25abeb5410edc1c7a81a10ba3f0efb90a as builder RUN apk --no-cache add make gcc libc-dev COPY . /src RUN mkdir /pkg cd /src make make DESTDIR/pkg install要点拆解基础镜像使用固定的 digestalpinesha256:69665d02...而不是alpine:latest。锁定 digest 意味着每次构建使用完全相同的底层镜像保证可复现性避免latest标签漂移引入不可控变化。构建依赖仅装在 builder 阶段apk --no-cache add make gcc libc-dev安装 GNU make、gcc 与 C 标准库开发头文件。--no-cache表示不保留 apk 索引缓存进一步缩小中间层体积。COPY . /src把整个 zstd 源码树拷入镜像注意这里拷贝的是构建上下文通常即lib/zstd-1.5.7目录的全部内容。make与make DESTDIR/pkg install是关键两步先执行默认目标完成编译默认目标为lib-release与zstd-release见 Makefile随后以DESTDIR/pkg暂存安装将所有安装产物集中到/pkg下方便下一阶段整体拷贝。3.2 第二阶段运行只保留可执行产物# Second minimal image to only keep the built binary FROM alpinesha256:69665d02cb32192e52e07644d76bc6f25abeb5410edc1c7a81a10ba3f0efb90a # Copy the built files COPY --frombuilder /pkg / # Copy the license as well RUN mkdir -p /usr/local/share/licenses/zstd COPY --frombuilder /src/LICENSE /usr/local/share/licences/zstd/ # Just run zstd if no other command is given CMD [/usr/local/bin/zstd]要点拆解全新的干净基础镜像第二阶段重新从同一 alpine 镜像开始不再继承任何编译工具。通过COPY --frombuilder /pkg /把第一阶段安装到/pkg下的全部内容二进制、脚本、man page 等合并进根文件系统从而得到仅含运行产物的精简镜像——gcc、make 等一律不进入最终镜像。许可证文件的复制单独创建/usr/local/share/licenses/zstd目录并将源码树中的LICENSEBSD 风格仓库同时提供 COPYING 对应 GPLv2 选项一并放入镜像符合开源软件的许可证随发行物分发惯例。需要留意的是Dockerfile 中目标路径写成了licences英式拼写与上面创建的licenses目录并不一致——这是上游脚本中的一个拼写瑕疵最终许可证会被放到/usr/local/share/licences/zstd/下。默认入口CMD [/usr/local/bin/zstd]指定容器无参数启动时直接执行 zstd 命令。由于是CMD而非ENTRYPOINTdocker run zstd zstdcat这类带参数启动时会用传入命令覆盖默认值详见下文测试部分。3.3make install到底装了什么要理解最终镜像内容需要知道make DESTDIR/pkg install的安装清单。查看 programs/Makefile 的install目标可以看到安装zstd可执行文件到$(BINDIR)创建zstdcat、unzstd、zstdmt三个指向zstd的符号链接——这正是命令行工具“一个二进制、多个语义入口”的设计安装zstdless、zstdgrep辅助脚本安装zstd.1、zstdgrep.1、zstdless.1手册页。此外DESTDIR与PREFIX是标准 GNU 安装变量PREFIX控制默认安装根默认/usr/localDESTDIR用于将安装“暂存”到指定目录是打包、容器镜像制作的标准手法此处即用于把产物集中到/pkg。四、构建与运行三条命令完成交付与验证原文档给出的操作序列非常精简以下逐条展开并补充原理。4.1 构建镜像docker build -t zstd .-t zstd将镜像命名为zstd需要在包含 Dockerfile 的目录即lib/zstd-1.5.7/contrib/docker下执行.表示把当前目录作为构建上下文构建时请确保网络可访问 Docker Hub拉取 alpine 基础镜像与源码包如需要。4.2 一行命令完成压缩/解压管线验证原文档的测试方法是构建完成后在主机上执行echo foo | docker run -i --rm zstd | docker run -i --rm zstd zstdcat预期输出foo这条管道背后发生了什么值得拆解echo foo在主机上向 stdout 输出foo\n第一个docker run -i --rm zstd-i保持 stdin 打开把管道中的foo\n送入容器内的 zstd。由于没有额外参数且CMD是[/usr/local/bin/zstd]zstd 以从 stdin 读入、压缩到 stdout的模式工作这是 zstd 的管道语义输出一段.zst压缩帧这段二进制流经管道送入第二个容器docker run -i --rm zstd zstdcat以zstdcat覆盖默认CMD。而zstdcat等价于zstd -dcf见 programs/zstd.1.md即强制解压、写入 stdout 且不覆盖文件于是压缩帧被还原为foo\n--rm让每个容器在退出后自动删除测试不留任何残留容器。可见这条命令同时验证了压缩方向、容器 stdin/stdout 贯通、zstd 的管道读写模式以及zstdcat别名语义是镜像可用性的最小完备测试。五、镜像内 CLI 能力从 CLI 变体到常用参数构建出的镜像包含的是标准 zstd CLI。根据 programs/README.md该 CLI 支持 gzip 风格参数并内建字典构建器与基准测试模块。常用参数在 zstd.1.md 中有完整说明摘取与日常使用最相关的部分参数含义-#压缩级别 119默认 3级别越高压缩比越大、速度越慢--fast[#]使用负压缩级别换取更快的压缩/解压速度代价是压缩比下降-d/--decompress解压unzstd即zstd -d-t/--test仅测试完整性不输出解压结果-l/--list查看.zst文件的帧信息-T#/--threads#多线程压缩自动检测到 pthread 时默认启用可通过HAVE_THREAD编译变量控制--long[#]启用长距离匹配模式提升高压缩比场景的比率--train FILES字典训练模式用样本集生成字典显著改善小数据压缩效果配合容器使用时典型场景例如# 在镜像内压缩一个挂载文件 docker run --rm -v $PWD:/data zstd zstd -1 /data/app.log # 查看压缩文件信息 docker run --rm -v $PWD:/data zstd zstd -l /data/app.log.zst此外zstd与zstdcat、unzstd、zstdmt均为同一二进制的符号链接容器内按命令名自动切换行为解压时默认去掉.zst后缀、压缩时默认追加.zst后缀见 programs/zstd.1.md。六、进阶按需裁剪 CLI 的编译变量如果你希望在容器内获得更小的 zstd 二进制可以在 Dockerfile 的make阶段传入编译变量。参考 programs/README.md主要变量包括HAVE_THREAD0禁用多线程支持默认在检测到 pthread 时自动开启HAVE_ZLIB0/HAVE_LZMA0/HAVE_LZ40分别去掉.gz、.xz/.lzma、.lz4格式支持默认在检测到对应库时自动开启ZSTD_LEGACY_SUPPORT0不支持 v0.8.0 之前的旧版 zstd 帧格式默认支持 v0.4.0ZSTD_NOBENCH/ZSTD_NODICT去掉内建的基准测试与字典构建模块减小体积ZSTD_NOCOMPRESS/ZSTD_NODECOMPRESS编译成仅解压或仅压缩的专用版本。例如将构建命令改为RUN mkdir /pkg cd /src make zstd-small make DESTDIR/pkg install即可产出针对最小体积优化的 CLI。若在仓库内自行构建实验镜像仅需调整 Dockerfile 后重新docker build -t zstd .。七、与 Fluent Bit 主项目的衔接最后回到本仓库的整体视角。contrib/docker提供的是独立的 zstd 工具镜像而 Fluent Bit 本体对 zstd 的消费路径与之并行构建集成通过 cmake/zstd.cmake 将lib/zstd-1.5.7作为依赖编译进 Fluent Bit运行时集成核心压缩/解压逻辑集中在 src/flb_zstd.c对外暴露flb_zstd_compress()与flb_zstd_uncompress()两个接口内部使用ZSTD_compress、ZSTD_decompressStream等 C API并针对未知输出长度场景以 64 KB 缓冲迭代解压、以 100 MB 上限兜底见 src/flb_zstd.c。因此无论你是想在 CI/CD 中用本文的镜像做日志压缩预处理还是想理解 Fluent Bit 内置 zstd 压缩的底层机制lib/zstd-1.5.7下的这份 Docker 方案与源码都是相互印证的完整参考。小结围绕 contrib/docker/README.md 这份简短说明本文补齐了三条关键信息为什么要求 Docker 17.05多阶段构建、Dockerfile 两个阶段分别做了什么源码编译 → 精简交付、一行管道命令如何完整验证 zstd 镜像压缩、传输、解压、别名语义并在此基础上延伸到make install的安装清单、CLI 常用参数、可裁剪的编译变量以及与 Fluent Bit 主项目的集成关系。参照本文即可在本仓库内独立完成 zstd 工具镜像的构建、验证与定制。【免费下载链接】fluent-bitFast and Lightweight Logs, Metrics and Traces processor for Linux, BSD, OSX and Windows项目地址: https://gitcode.com/GitHub_Trending/fl/fluent-bit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考