在我的 ElasticBeanstalk 環境中，部署我的 Node.js 應用程式以及在 EB Health 選項卡中將狀態從“Pending”更改為“OK”的實體通常需要大約 5 分鐘（多年來）。
自 5 月 14 日起，應用程式部署大約需要 15 分鐘，無需觸及應用程式、基礎設施、應用程式存盤庫、EB 環境或 EC2 linux 映像。同樣的事情發生在生產和開發環境中，都是獨立的 EB 環境，部署的是同一個應用。
看著/var/log/eb-activity.log，我看到這 15 分鐘都花在了 step 上：
[Application deployment <APPID>/StartupStage0/AppDeployPreHook/50npm.sh] : Starting activity...
腳本本身只運行：
/opt/elasticbeanstalk/containerfiles/ebnode.py --action npm-install
該腳本只是進行一些檔案檢查和路徑組合，然后運行：
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博客文章：
2022 年 3 月 15 日
更改永久生效。我們將永久停止接受 DSA 密鑰。在上述截止點之后上傳的 RSA 密鑰僅適用于 SHA-2 簽名（但同樣，在此日期之前上傳的 RSA 密鑰將繼續適用于 SHA-1）。已棄用的 MAC、密碼和未加密的 Git 協議將被永久禁用。
因此 GitHub 停止使用該git://協議接受請求。也許這就是部署時間較長的原因，超時也發生在 EC2 中。但這種變化已經在 3 月 15 日（正好是 2 個月前）永久生效，為什么這個問題現在才出現。
uj5u.com熱心網友回復：
從 5 月 13 日開始，我們的代碼庫中出現了同樣令人費解的行為。我不知道為什么直到現在 GitHub 依賴項才解決這些問題，但根據您分享的博客文章，這似乎是一件永久性的事情。
已在該主題上創建了一個GitHub 問題，社區提出了各種解決該問題的方法。
一個這樣的建議：
通過在 package-lock.json & package.json 用 https 替換 github 協議解決
另一位用戶建議：
...我們發現將 npm 更新到 7.16.0 版本（至少，由于其他原因，這是我們的版本）解決了這個問題
對于我們來說，我們選擇了后者并開始使用 NPM 版本 7（特別是7.24.2）。這確實需要我們將package-lock.json檔案更新到版本 2，這帶來了許多其他問題，但它似乎對我們有用。
uj5u.com熱心網友回復：
這是在 Node.js 應用程式的 AWS EC2 / ElasticBeanstalk 部署中為我解決的問題：
運行命令.ebextensions：_
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并更改協議可能還不夠。如果有依賴項也使用git協議直接在 GitHub 中參考它們自己的依賴項。上述解決方案說明了所有這些。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/477773.html
標籤：节点.js 混帐 亚马逊网络服务 npm 亚马逊-ec2