AWS EC2 npm 安装突然很慢
AWS EC2 npm install suddenly very slow
在我的 ElasticBeanstalk 环境中,我的 Node.js 应用程序部署以及实例从状态“待定”更改为“确定”的时间总是(多年) EB 健康选项卡。
自 5 月 14 日起,应用程序部署需要约 15 分钟,无需触及应用程序、基础设施、应用程序存储库、EB 环境或 EC2 linux 映像。同样的事情发生在生产环境和开发环境,都是独立的EB环境,部署同一个app。
查看 /var/log/eb-activity.log
,我发现这 15 分钟花费在步骤:
[Application deployment <APPID>/StartupStage0/AppDeployPreHook/50npm.sh] : Starting activity...
脚本本身只有 运行s:
/opt/elasticbeanstalk/containerfiles/ebnode.py --action npm-install
该脚本只是做一些文件检查和路径组合,然后 运行s:
npm --production install
为了进行比较,我清除了所有缓存文件并在本地 运行 执行了相同的命令,耗时约 11 分钟:
rm -rf node_modules
node cache clean -f
npm --production install
我用 运行 再次使用 --loglevel silly
命令,它表明 package.json
中有一个依赖项不是从 npm 注册表中提取的,而是直接从 GitHub 中提取的,指向一个标签:
npm sill pacote Retrying git command: ls-remote -h -t git://github.com/<org>/<repo>.git attempt # 2
npm sill pacote Retrying git command: ls-remote -h -t git://github.com/<org>/<repo>.git attempt # 3
npm verb prepareGitDep github:<org>/<repo>#<label>: installing devDeps and running prepare script.
每个 git ls-remote
命令的超时时间大约为 1 分钟,然后似乎要再安装 devDependencies 运行 和 prepare
脚本 5 分钟。我不确定这是否也发生在 EC2 实例上,但这是我发现的唯一提示。
3 个超时的 git ls-remote
命令和 prepare
脚本共约 8 分钟。因此,如果这是以前没有执行过的事情,它可能会解释较长的部署时间。但是,为什么部署会突然与多年来的部署有所不同?
我遇到了这个 GitHub blog post:
March 15, 2022
Changes made permanent. We’ll permanently stop accepting DSA keys. RSA keys uploaded after the cut-off point above will work only with SHA-2 signatures (but again, RSA keys uploaded before this date will continue to work with SHA-1). The deprecated MACs, ciphers, and unencrypted Git protocol will be permanently disabled.
所以 GitHub 停止接受使用 git://
协议的请求。也许这就是部署时间较长的原因,超时也发生在 EC2 中。但是这个变化在3月15日(正好2个月前)就已经永久化了,为什么现在才出现这个问题。
从 5 月 13 日开始,我们的代码库中出现了同样令人费解的行为。我不知道为什么直到现在 GitHub 依赖项才解决这些问题,但根据您分享的博客 post,这似乎是永久性的事情。
已针对该主题创建 GitHub issue,社区已提出各种解决该问题的方法。
一个这样的建议:
Solved by replacing github protocol with https at package-lock.json & package.json
另一位用户建议:
... we found out that updating npm to version 7.16.0 (at least, that was our go to version for other reasons) solved the issue
对于我们来说,我们选择了后者并开始使用 NPM 版本 7(具体来说,7.24.2
)。这确实需要我们将 package-lock.json
文件更新到版本 2,这带来了许多其他问题,但它似乎对我们有用。
以下是我在 Node.js 应用程序的 AWS EC2/ElasticBeanstalk 部署中解决问题的方法:
运行 .ebextensions
中的 command 与:
commands:
01-configure-git:
command: sudo git config --system url."https://github".insteadOf "git://github"
ignoreErrors: true # optionally, so deployment doesn't fail in case the command fails for some reason
仅检查您自己的 package.json
并更改协议可能还不够。如果有依赖也在GitHub中使用git
协议直接引用自己的依赖。上面的解决方案都占了。
在我的 ElasticBeanstalk 环境中,我的 Node.js 应用程序部署以及实例从状态“待定”更改为“确定”的时间总是(多年) EB 健康选项卡。
自 5 月 14 日起,应用程序部署需要约 15 分钟,无需触及应用程序、基础设施、应用程序存储库、EB 环境或 EC2 linux 映像。同样的事情发生在生产环境和开发环境,都是独立的EB环境,部署同一个app。
查看 /var/log/eb-activity.log
,我发现这 15 分钟花费在步骤:
[Application deployment <APPID>/StartupStage0/AppDeployPreHook/50npm.sh] : Starting activity...
脚本本身只有 运行s:
/opt/elasticbeanstalk/containerfiles/ebnode.py --action npm-install
该脚本只是做一些文件检查和路径组合,然后 运行s:
npm --production install
为了进行比较,我清除了所有缓存文件并在本地 运行 执行了相同的命令,耗时约 11 分钟:
rm -rf node_modules
node cache clean -f
npm --production install
我用 运行 再次使用 --loglevel silly
命令,它表明 package.json
中有一个依赖项不是从 npm 注册表中提取的,而是直接从 GitHub 中提取的,指向一个标签:
npm sill pacote Retrying git command: ls-remote -h -t git://github.com/<org>/<repo>.git attempt # 2
npm sill pacote Retrying git command: ls-remote -h -t git://github.com/<org>/<repo>.git attempt # 3
npm verb prepareGitDep github:<org>/<repo>#<label>: installing devDeps and running prepare script.
每个 git ls-remote
命令的超时时间大约为 1 分钟,然后似乎要再安装 devDependencies 运行 和 prepare
脚本 5 分钟。我不确定这是否也发生在 EC2 实例上,但这是我发现的唯一提示。
3 个超时的 git ls-remote
命令和 prepare
脚本共约 8 分钟。因此,如果这是以前没有执行过的事情,它可能会解释较长的部署时间。但是,为什么部署会突然与多年来的部署有所不同?
我遇到了这个 GitHub blog post:
March 15, 2022
Changes made permanent. We’ll permanently stop accepting DSA keys. RSA keys uploaded after the cut-off point above will work only with SHA-2 signatures (but again, RSA keys uploaded before this date will continue to work with SHA-1). The deprecated MACs, ciphers, and unencrypted Git protocol will be permanently disabled.
所以 GitHub 停止接受使用 git://
协议的请求。也许这就是部署时间较长的原因,超时也发生在 EC2 中。但是这个变化在3月15日(正好2个月前)就已经永久化了,为什么现在才出现这个问题。
从 5 月 13 日开始,我们的代码库中出现了同样令人费解的行为。我不知道为什么直到现在 GitHub 依赖项才解决这些问题,但根据您分享的博客 post,这似乎是永久性的事情。
已针对该主题创建 GitHub issue,社区已提出各种解决该问题的方法。
一个这样的建议:
Solved by replacing github protocol with https at package-lock.json & package.json
另一位用户建议:
... we found out that updating npm to version 7.16.0 (at least, that was our go to version for other reasons) solved the issue
对于我们来说,我们选择了后者并开始使用 NPM 版本 7(具体来说,7.24.2
)。这确实需要我们将 package-lock.json
文件更新到版本 2,这带来了许多其他问题,但它似乎对我们有用。
以下是我在 Node.js 应用程序的 AWS EC2/ElasticBeanstalk 部署中解决问题的方法:
运行 .ebextensions
中的 command 与:
commands:
01-configure-git:
command: sudo git config --system url."https://github".insteadOf "git://github"
ignoreErrors: true # optionally, so deployment doesn't fail in case the command fails for some reason
仅检查您自己的 package.json
并更改协议可能还不够。如果有依赖也在GitHub中使用git
协议直接引用自己的依赖。上面的解决方案都占了。