模块预构建版本

[soulteary]

@ADD-SP 你好👋，我看到有用户反馈编译构建失败，所以做了一个简单的，基于官方容器环境和构建参数的预构建版本（目前只有ubuntu/alpine）

后续或许可以将 scratch 中的二进制模块添加到项目的 release 中，以及添加更多不同的版本预构建文件、以及支持更多的系统/平台。

https://github.com/nginx-with-docker/ngx_http_waf_module

希望对项目有帮助。

[ADD-SP]

@soulteary 十分感谢您的努力！

我之前就有提供各个 os/arch 的预构建模块的想法，因为交叉编译比较麻烦所以一直没弄。感觉使用 QEMU + Docker 完成交叉编译的工作可行，之后我会尝试通过提 PR 来完善您的项目。

顺便一提，libsodium 并不总是静态链接的，所以目前您构建的模块应该是不能用的，除系统中存在 libsodium 的动态库。这个问题我也会在后续提的 PR 中修复。链接模式是如何选择的可以看一下下面的代码片段。

ngx_waf/config

Lines 128 to 133 in 5655af6

	if [ -n "$LIB_SODIUM" ] ; then
	ngx_http_waf_module_inc_path="${ngx_http_waf_module_inc_path} ${LIB_SODIUM}/include"
	ngx_http_waf_module_libs=" ${ngx_http_waf_module_libs} -L ${LIB_SODIUM}/lib -Wl,-Bstatic -l sodium -Wl,-Bdynamic "
	else
	ngx_http_waf_module_libs=" ${ngx_http_waf_module_libs} -l sodium "
	fi

[soulteary]

感谢回复 以及 PR 。刚刚看到 PR 返回了这个帖子，讨论结束后，我会进行合并。

看到你的 PR 中使用了 libsodium 的 stable 分支作为代码基，这里或许应该使用具体的版本号，比如最新的 1.0.18 ，除非原项目作者在代码管理上出现纰漏，并未将最新的代码进行版本化发布，而你的代码也依赖更新的上游代码。

这样做还有另外一个好处，就是无论谁在何时何地计划使用容器进行构建，他们所得到的项目编译结果可以“近乎”一致，代码和产物都会更加透明、可信赖。

如果你认同上面的观点，或许可以更新 PR 中的实现，或者我将基于你的实现进行进一步的修改，但是我需要确认你的代码是否如上所述，依赖 stable 分支的某次提交后的上游代码。

[ADD-SP]

感谢回复 以及 PR 。刚刚看到 PR 返回了这个帖子，讨论结束后，我会进行合并。

看到你的 PR 中使用了 libsodium 的 stable 分支作为代码基，这里或许应该使用具体的版本号，比如最新的 1.0.18 ，除非原项目作者在代码管理上出现纰漏，并未将最新的代码进行版本化发布，而你的代码也依赖更新的上游代码。

这样做还有另外一个好处，就是无论谁在何时何地计划使用容器进行构建，他们所得到的项目编译结果可以“近乎”一致，代码和产物都会更加透明、可信赖。

如果你认同上面的观点，或许可以更新 PR 中的实现，或者我将基于你的实现进行进一步的修改，但是我需要确认你的代码是否如上所述，依赖 stable 分支的某次提交后的上游代码。

认同观点，本仓库的 beta 版已经改用具体的版本号。

[ADD-SP]

如果有什么想法可以在这里讨论一下。我目前希望可以通过 Github Action 自动完成构建和发布。

[soulteary]

如果有什么想法可以在这里讨论一下。我目前希望可以通过 Github Action 自动完成构建和发布。

单一项目使用 GitHub Action 进行编译体验还是非常好的，默认的配额足够应付固定版本以及每日构建。

[ADD-SP]

@soulteary
实际上，我昨天刚刚发布了 v6.0.0-beta.4 并提供了预构建的模块。支持稳定和主线版本的 nginx 和两种 libc 的实现（GNU 和 musl）。详情可以看一下 https://github.com/ADD-SP/ngx_waf/blob/dev/.github/workflows/docker.yml 。

预构建的模块依赖特定的 libc 的实现，因为实践中似乎无法将 libc 静态链接到模块中，而 libc 的不同实现之间并不总是二进制兼容的，所以只能针对不同的实现分别构建模块。

编译完成后包含模块的 docker 镜像会被推送到 docker hub，https://hub.docker.com/r/addsp/ngx_waf-prebuild 。

下面是预构建模块支持的 os/arch。

ngx_waf/.github/workflows/docker.yml

Lines 41 to 46 in 45c2999

	platforms: |
	linux/amd64
	linux/arm64
	linux/386
	linux/arm/v7
	linux/arm/v6

我建议您的项目以本项目上传的镜像作为基础镜像进行构建。这样的话工作就很简单了，将模块拷贝到 scratch 即可。Debian 的 libc 是 GNU 实现，Alpine 则是 musl 实现。

这么做的好处是一旦出现问题，无论是编译上的问题还是模块本身的 bug，都是首先在本仓库修复并重新构建镜像的，而您的项目只需要重新构建即可完成更新，比 PR -> review -> merge 的流程高效很多。如果使用 Github Action 完成重新构建的话几乎就不要人工参与了，因为 Github Action 允许通过 API 触发和定期触发。

不过本仓库提供的预构建模块只支持 nginx-stable 和 nginx-mainline，您的仓库在构建时需要知道具体的版本号，您可以通过 lastversion 来获取具体的版本号。我也可以在镜像中保存版本号信息。这样就可以在构建前获取版本号，并将其作为构建参数传入验证内外版本号是否一致。

不过如果需要的话我也可以提供带有版本号的镜像。

[ADD-SP]

@soulteary 更新了一下 Github Action 的配置文件，现在上传的镜像 Tag 带上版本号了。Tag 的含义也很明显，https://hub.docker.com/r/addsp/ngx_waf-prebuild 。

[soulteary]

干得漂亮～

我最近在折腾另外一个项目，稍晚时候，我更新下构建。

// 小建议，能否构建下 stable 版本，一般维护最后三个版本就OK。

[ADD-SP]

@soulteary 预计下周发 stable，发了之后就自动构建了。