正在加载

升级 Node.js

Kibana 需要特定的 Node.js 版本才能运行。从源代码运行 Kibana 时,您必须在本地安装此版本。

在创建 PR 以升级 Node.js 之前,我们必须首先生成与所需 Node.js 版本匹配的必需的自定义 Node.js 构建

所需的 Node.js 版本列在 Kibana 源代码中的几个不同文件中。 升级 Node.js 时必须更新这些文件

有关先前如何升级 Node.js 版本的示例,请参阅 PR #128123

升级到 Node.js 的新主要版本时,必须执行以下额外步骤

  • 将新的 Node.js 版本支持的平台列表与Kibana 支持矩阵进行比较。 例如,这是Node.js 18 支持的平台列表。 您可以通过更改所选分支来更改要查看的 Node.js 主要版本。 如果 Node.js 放弃了对 Kibana 仍然支持的平台的支持,则必须尽快采取适当的步骤来弃用对该平台的支持。 这样,可以在当前使用的主要 Node.js 版本达到生命周期结束之前放弃对它的支持。

由于 Node.js 16 即将提前结束生命周期,并且 Node.js 18 不再支持 Kibana 支持的相同平台(最值得注意的是 CentOS7/RHEL7),因此我们无法将官方 Node.js 二进制文件与 Kibana 的 Linux 可分发文件捆绑在一起。为了保持对这些旧平台的支持,我们将 Kibana 的 Linux 可分发文件与具有扩展的向后兼容性的自定义 Node.js 构建捆绑在一起。官方 Node.js 构建与我们的自定义构建之间的唯一区别是它编译所针对的 glibc 版本。

要生成新的自定义 Node.js 构建,请在我们的专用 Buildkite 管道上启动新的构建(需要 Elastic 员工权限)。 为其提供一个清晰的名称(例如 Node 20.15.1),并记住将自定义 OVERRIDE_TARGET_VERSION 环境变量设置为所需的 Node.js 版本 - 例如 OVERRIDE_TARGET_VERSION=20.15.1。 通过展开“新建构建”对话框中的“选项 >”来找到“环境变量”字段。

以下规则并非一成不变。 向后移植时请使用最佳判断。

通常,您希望将 Node.js 补丁升级向后移植到运行相同 主要 Node.js 版本的所有受支持的发行分支(目前所有分支都是这样,但将来可能会更改)

  • 如果当前版本是 8.1.x,则主要 PR 应该以 main 为目标,并向后移植到 7.178.1(GitHub 标签示例:backport:all-open)。

通常,您希望将 Node.js 次要升级向后移植到以前的主要 Kibana 发行分支(如果它运行相同的 主要 Node.js 版本)

  • 如果当前版本是 8.1.x,则主要 PR 应该以 main 为目标,并向后移植到 7.17,同时保持 8.1 分支不变(GitHub 标签示例:auto-backport + v7.17.13)。

通常,您希望将 Node.js 主要升级向后移植到以前的主要 Kibana 发行分支

  • 如果当前版本是 8.1.x,则主要 PR 应该以 main 为目标,并向后移植到 7.17,同时保持 8.1 分支不变(GitHub 标签示例:auto-backport + v7.17.13)。

以下说明假定使用nvm来管理本地安装的 Node.js 版本。

运行以下命令以安装新的 Node.js 版本。 将 <version> 替换为所需的 Node.js 版本

nvm install <version>

要获取与当前安装的相同全局 npm 模块以及新版本的 Node.js,请使用 --reinstall-packages-from 命令行参数(可选地将 16 替换为所需的源版本)

nvm install <version> --reinstall-packages-from=16

如果需要,可以通过运行以下命令卸载旧版本的 Node.js。 将 <old-version> 替换为应卸载的版本的完整版本号

nvm uninstall <old-version>

(可选)告诉 nvm 始终使用已安装的“最高”Node.js 16 版本。 如果需要不同的主要版本,请替换 16

nvm alias default 16

或者,在末尾包含完整版本号以指定特定的默认版本。

© . All rights reserved.