Установка AWS EC2 npm внезапно очень медленная

В моей среде ElasticBeanstalk всегда (в течение многих лет) требовалось ~ 5 минут для развертывания моего приложения Node.js и для изменения состояния экземпляра с «Ожидание» на «ОК» на вкладке EB Health.

С 14 мая развертывание приложения занимает примерно 15 минут без вмешательства в приложение, инфраструктуру, репозиторий приложений, среду EB или образ Linux EC2. То же самое произошло в рабочей среде и среде разработки, обе они являются отдельными средами EB, развертывающими одно и то же приложение.

Глядя на /var/log/eb-activity.log, я вижу, что эти 15 минут тратятся на шаг:

[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 Сообщение блога:

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. Но это изменение уже было сделано постоянным 15 марта (ровно 2 месяца назад), так почему проблема появилась только сейчас.

🤔 А знаете ли вы, что...
Node.js позволяет выполнять JavaScript на стороне сервера, а не только в браузере.


2
98
1

Ответ:

Решено

У нас было такое же загадочное поведение в нашей кодовой базе, начиная с 13 мая. Я понятия не имею, почему зависимости GitHub до сих пор не столкнулись с этими проблемами, но, согласно сообщению в блоге, которым вы поделились, это кажется постоянным.

На эту тему был создан Проблема с GitHub, и сообщество предложило различные способы решения проблемы.

Одно такое предложение:

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, что принесло с собой целый ряд других проблем, но, похоже, это сработало для нас.