将 Alpine Linux 从实验版升级为第二级平台

这个功能将解决什么问题？ 目前有大量使用 Alpine Linux（使用 musl 作为 libc 实现的 Linux）的用户。 从非官方构建服务器下载的直接 tarball 每小时大约有 1000 次下载，x64 版本，arm64 版本大约有 25 次。 我们目前没有 dockerhub 上容器镜像的数据，但我预计也会很高。 考虑到有这么多人使用这个构建，我认为通过正常流程发布这个功能是合理的，这样它就能在与其他 Tier 1/2 平台相同的时间内提供。 这将使安全更新能够及时提供，还将帮助减少由于 Docker-node 项目中容器镜像的发布延迟而给客户带来的任何延迟（我还要指出，有建议将 Alpine 分离，但这不会解决在向我们的 Alpine 用户提供更新时可能出现延迟的问题）。 我们还应该记住，很可能有许多用户并不知道 Alpine 处于实验阶段，也不了解在生产环境中使用该平台的后果。 尽管从非官方构建服务器下载时可能很清楚（hostname 提示了这一点），但在 dockerhub 上查看时，它与其他平台没有什么区别，后者作为“官方”容器镜像发布。 从表面上看，我希望将 Alpine 添加到 x64/aarch64 平台上是一个低风险的选择，因为 x64/aarch64 平台上的 Linux/glibc 受到很好的支持，而可能的风险在于它使用 musl 而不是 GNU libc。 我不确定我们是否曾经因为这个差异遇到过任何问题，但我不记得有什么。 注意到 Alpine/x64 已经是正常 CI 测试的一部分，因此该平台上的故障将会被注意到，但作为一个实验平台，任何 CI 失败目前不会阻止发布周期。 虽然我没有将其视为本提案的一部分，但我会指出一些背景信息，以说明我们之前已经在 Docker-node 项目中发布了 Alpine/ppc64le 和 Alpine/s390x 容器镜像。 Alpine/ppc64le 在 node 22 期间被停用，我建议对 Alpine/s390x 采取同样的措施。